Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
DM Smith wrote: Generally open source projects have a policy to change as little of the file as possible, only changing what is necessary. Hmmm. Necessary by what criterion? Necessary to make, say, Lucene exploit the new interator constructs to avoid run-time type-checking? Necessary to make the code more readable? Necessary to prevent use with Java 1.4? :-) I'm not sure I've ever seen a policy expressed in that way -- patches generally should be clear, concise and do what they're intended to do, but that doesn't necessarily mean minimising the size of the patch and it doesn't necessarily mean keeping the source compatible with some old compiler or environment. Indeed, to be hypothetical and not entirely off-topic, it easy to imagine two patches that are better than one. For the two patches, reorganise a class so that it exploits Java 1.5 features and the real patch that uses that new structure to cleanly and elegantly implement some new feature. For the one patch, leave the code compatible with 1.4, but the functional patch is now much larger, more complex and harder to verify. It's possible that such a hypothetical patch (or pair of patches) is at the core of the question of this thread. Does one embrace new language features because they provide some tangible benefit to the maintainability, functionality or complexity of the code? If so, for how long? Should Lucene development freeze at 1.4 until there's no working hardware that runs 1.4? Would that also preclude changes to Lucene that make it work dramatically better on a machine with the current de-facto standard memory? What happens when that's, say, 4Gb and some old hardware simply won't let you install that much memory? Would it not be better to freeze application development that needs an old environment and simply back-port bug fixes and, where it makes sense, functionality to the version of Lucene that is used in that environment? The approach taken by Red Hat with their Enterprise Linux series is that they'll support a version of the platform for several years, back-porting bug fixes, adding small, incremental functional changes and so on. That means that this antique computer that happily runs RHEL3 will be able to carry on running an OS and applications that work on that hardware until it finally gives p the ghost . jch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Jun 22, 2006, at 4:31 AM, John Haxby wrote:
DM Smith wrote:
Generally open source projects have a policy to change as little
of the file
as possible, only changing what is necessary.
Hmmm. Necessary by what criterion? Necessary to make, say,
Lucene exploit the new interator constructs to avoid run-time type-
checking? Necessary to make the code more readable? Necessary
to prevent use with Java 1.4? :-)
I'm not sure I've ever seen a policy expressed in that way --
patches generally should be clear, concise and do what they're
intended to do, but that doesn't necessarily mean minimising the
size of the patch and it doesn't necessarily mean keeping the
source compatible with some old compiler or environment.
I wasn't trying to be argumentative (with this statement). I probably
stated it badly.
I simply meant that the change that is being made should be done in
such a way that one applying the patch can readily see what is being
changed. The most common case of unnecessary change is that of
whitespace. Changing indentation, changing the placement of curly
braces, reordering methods and variables and so forth are all
unnecessary.
There are structural changes to the code that can be done that do not
change the behavior of the code. Some developers feel strongly about
one construct over another. For example take the following example:
public int f(int x)
{
if (x 0)
return x * 2;
else
return x * -2;
}
Some think its dumb that there is an else clause as above.
public int f(int x)
{
if (x 0)
return x * 2;
return x * -2;
}
Others feel strongly that there should only be one exit in a method:
public int f(int x)
{
int ret = 0;
if (x 0)
ret = x * -2;
else
ret = x * -2;
return ret;
}
Some like brevity:
public int f(int x) { return x*(x0?2:-2;}
Such a change is most likely unnecessary.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
DM Smith wrote: I simply meant that the change that is being made should be done in such a way that one applying the patch can readily see what is being changed. The most common case of unnecessary change is that of whitespace. Changing indentation, changing the placement of curly braces, reordering methods and variables and so forth are all unnecessary. [snip] Such a change is most likely unnecessary. Others, probably including me, would disagree. Changes to make the source have a consistent style and a consistent layout are not uncommon. Look through the Linux kernel change logs for whitespace clean up (or white space and cleanup, spaces are optional :-)). The GNU glibc maintainers will reject patches that do not conform to the coding style for glibc -- and that includes stylistic choices like the ones you mentioned (that I cut in the interests of brevity). Style may make no functional difference to the code but it does affect maintainability. It may well also affect correctness. You could declare all your variables as Object and simply cast to the right type to get the method you want. There would be no functional difference (one could argue that eliminating run-time type checking is merely an optimisation) but would you seriously want to code this way. Similarly, and I'm struggling to keep vaguely on-topic here, the Java 1.5 iteration constructs are functionally no different to their 1.4 equivalent. But to dismiss the 1.5 changes as syntactic sugar or fluff is to denigrate their importance to the reliability and maintenance of software. If you declared all your variables as Object would your code be more reliable, about the same or less? (That's a rhetoric question, I hope.) jch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/22/06, John Haxby [EMAIL PROTECTED] wrote: DM Smith wrote: I simply meant that the change that is being made should be done in such a way that one applying the patch can readily see what is being changed. The most common case of unnecessary change is that of whitespace. Changing indentation, changing the placement of curly braces, reordering methods and variables and so forth are all unnecessary. [snip] Such a change is most likely unnecessary. Others, probably including me, would disagree. Changes to make the source have a consistent style and a consistent layout are not uncommon. I agree with you 100% that consistent style and layout are important. Look through the Linux kernel change logs for whitespace clean up (or white space and cleanup, spaces are optional :-)). The GNU glibc maintainers will reject patches that do not conform to the coding style for glibc -- and that includes stylistic choices like the ones you mentioned (that I cut in the interests of brevity). And I also agree here that the committers have the responsibility to be the gatekeepers of that. Similarly, and I'm struggling to keep vaguely on-topic here, the Java 1.5 iteration constructs are functionally no different to their 1.4 equivalent. But to dismiss the 1.5 changes as syntactic sugar or fluff is to denigrate their importance to the reliability and maintenance of software. In an earlier note, I suggested that there needs to be guidance as to how Java 5 constructs are to be incorporated into code, contrib and core. (Sooner or later, core will change to Java 5) Or does anything go?
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/22/06, Doug Cutting [EMAIL PROTECTED] wrote: DM Smith wrote: In an earlier note, I suggested that there needs to be guidance as to how Java 5 constructs are to be incorporated into code, contrib and core. (Sooner or later, core will change to Java 5) Or does anything go? Once we decide to accept Java 5 code, we should of course encourage new contributions to use new language features that improve, e.g., type safety and maintainability. If someone wishes to upgrade existing code to use new language features, these should be done as separate contributions. We could state a goal of upgrading all existing code, but that won't make it happen. I prefer not to make ambitious roadmaps, but rather have things driven bottom-up, by contributors. So my bottom-up-oriented guideline is that I would not reject contributions that do nothing but upgrade existing code to use new language features. Is that the sort of guidance you seek, or do you think we need something more specific, with feature-by-feature guidelines? Developing such guidelines collaboratively might be difficult. One of the things I liked about 2.0 was that 1.9 was a bridge to it from 1.4.3 via deprecations. It made migration fairly straightforward. I would like to see this going forward to 2.1. If so there needs to be some thought to how and whether the existing API will be deprecated in the same fashion as Java 5 is introduced. I was thinking more specific, feature-by-feature guidelines. There are not that many new language features, so I don't think that it would be too onerous. Since the committers are ultimately the ones to accept or reject a contribution, I think they can decide. For example (my opinions), Static Import Try to avoid. It tends to make code unreadable. Autoboxing/unboxing Use sparingly, and if used, provide test cases showing that performance sensitive code is not adversely affected. Varargs Don't use as a substitute for overloading. Use as a replacement for an array of objects. e.g. void f(T[] t) becomes void f(T... t). Enhanced for loops: Use whenever possible. When modifying existing code to add one, change all others, if possible. Typesafe Enum Use wherever possible, internally. Associate behavior with the enumerations when it makes sense. Replace existing enumerations that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Generics Use for all internal collections. When changing a class, ensure that the class is self consistent in its usage of generics. Enhance existing collections that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Annotations: ??
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/22/06, DM Smith [EMAIL PROTECTED] wrote: On 6/22/06, Doug Cutting [EMAIL PROTECTED] wrote: DM Smith wrote: In an earlier note, I suggested that there needs to be guidance as to how Java 5 constructs are to be incorporated into code, contrib and core. (Sooner or later, core will change to Java 5) Or does anything go? Once we decide to accept Java 5 code, we should of course encourage new contributions to use new language features that improve, e.g., type safety and maintainability. If someone wishes to upgrade existing code to use new language features, these should be done as separate contributions. We could state a goal of upgrading all existing code, but that won't make it happen. I prefer not to make ambitious roadmaps, but rather have things driven bottom-up, by contributors. So my bottom-up-oriented guideline is that I would not reject contributions that do nothing but upgrade existing code to use new language features. Is that the sort of guidance you seek, or do you think we need something more specific, with feature-by-feature guidelines? Developing such guidelines collaboratively might be difficult. One of the things I liked about 2.0 was that 1.9 was a bridge to it from 1.4.3 via deprecations. It made migration fairly straightforward. I would like to see this going forward to 2.1. If so there needs to be some thought to how and whether the existing API will be deprecated in the same fashion as Java 5 is introduced. I was thinking more specific, feature-by-feature guidelines. There are not that many new language features, so I don't think that it would be too onerous. Since the committers are ultimately the ones to accept or reject a contribution, I think they can decide. For example (my opinions), Static Import Try to avoid. It tends to make code unreadable. Autoboxing/unboxing Use sparingly, and if used, provide test cases showing that performance sensitive code is not adversely affected. Varargs Don't use as a substitute for overloading. Use as a replacement for an array of objects. e.g. void f(T[] t) becomes void f(T... t). Enhanced for loops: Use whenever possible. When modifying existing code to add one, change all others, if possible. Typesafe Enum Use wherever possible, internally. Associate behavior with the enumerations when it makes sense. Replace existing enumerations that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Generics Use for all internal collections. When changing a class, ensure that the class is self consistent in its usage of generics. Enhance existing collections that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Annotations: ?? I assume that many people realize these features as new features in Java 5.0. In my opinion there is at least one more feature beside the improvements inside the jvm and the garbage collection and build in Java Management Extension. The feature I'm pointing to is rather a new library than a feature to be honest but it can improve concurrent application in performance and stability matters. The Concurrent Utils in the j2se 5.0 give you much more control of concurrent parts of you application and I guess the lucene project can gain from these new classes to synchronize writing and parallel reading where possible. I think a great deal of adding build in JMX support to the lucene core or rather as a contrib project to enable modification of configurable components like merge factors or similar things. Extensions like this should have some guidelines as Doug said feature-by-feature. Java 1.5 is much more than type save collection and a lot of features are quiet hidden sometimes. Replacing the use of StringBuffer with StringBuilder can also gain some performance improvements, this just as an example that improved parts of the api are quiet important and should be considered first before moving in all the nice compile time code sharing generics. regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I agree. This is probably the first compelling argument that I would agree with the use of 1.5. IIRC, Concurrent utils were available for the 1.4 available at http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html before it was accepted into official 1.5 util package. It is continuing to be maintained right now. I'm also supportive about Doug's base-guideline. As far as annotation goes, I really don't see future uses of annotations within the internal code. It would most likley end up being used by the user to annotate a POJO for as a document maybe. ray, On 6/22/06, Simon Willnauer [EMAIL PROTECTED] wrote: On 6/22/06, DM Smith [EMAIL PROTECTED] wrote: On 6/22/06, Doug Cutting [EMAIL PROTECTED] wrote: DM Smith wrote: In an earlier note, I suggested that there needs to be guidance as to how Java 5 constructs are to be incorporated into code, contrib and core. (Sooner or later, core will change to Java 5) Or does anything go? Once we decide to accept Java 5 code, we should of course encourage new contributions to use new language features that improve, e.g., type safety and maintainability. If someone wishes to upgrade existing code to use new language features, these should be done as separate contributions. We could state a goal of upgrading all existing code, but that won't make it happen. I prefer not to make ambitious roadmaps, but rather have things driven bottom-up, by contributors. So my bottom-up-oriented guideline is that I would not reject contributions that do nothing but upgrade existing code to use new language features. Is that the sort of guidance you seek, or do you think we need something more specific, with feature-by-feature guidelines? Developing such guidelines collaboratively might be difficult. One of the things I liked about 2.0 was that 1.9 was a bridge to it from 1.4.3 via deprecations. It made migration fairly straightforward. I would like to see this going forward to 2.1. If so there needs to be some thought to how and whether the existing API will be deprecated in the same fashion as Java 5 is introduced. I was thinking more specific, feature-by-feature guidelines. There are not that many new language features, so I don't think that it would be too onerous. Since the committers are ultimately the ones to accept or reject a contribution, I think they can decide. For example (my opinions), Static Import Try to avoid. It tends to make code unreadable. Autoboxing/unboxing Use sparingly, and if used, provide test cases showing that performance sensitive code is not adversely affected. Varargs Don't use as a substitute for overloading. Use as a replacement for an array of objects. e.g. void f(T[] t) becomes void f(T... t). Enhanced for loops: Use whenever possible. When modifying existing code to add one, change all others, if possible. Typesafe Enum Use wherever possible, internally. Associate behavior with the enumerations when it makes sense. Replace existing enumerations that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Generics Use for all internal collections. When changing a class, ensure that the class is self consistent in its usage of generics. Enhance existing collections that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Annotations: ?? I assume that many people realize these features as new features in Java 5.0. In my opinion there is at least one more feature beside the improvements inside the jvm and the garbage collection and build in Java Management Extension. The feature I'm pointing to is rather a new library than a feature to be honest but it can improve concurrent application in performance and stability matters. The Concurrent Utils in the j2se 5.0 give you much more control of concurrent parts of you application and I guess the lucene project can gain from these new classes to synchronize writing and parallel reading where possible. I think a great deal of adding build in JMX support to the lucene core or rather as a contrib project to enable modification of configurable components like merge factors or similar things. Extensions like this should have some guidelines as Doug said feature-by-feature. Java 1.5 is much more than type save collection and a lot of features are quiet hidden sometimes. Replacing the use of StringBuffer with StringBuilder can also gain some performance improvements, this just as an example that improved parts of the api are quiet important and should be considered first before moving in all the nice compile time code sharing generics. regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
There are some big performance differences between the J2SE 5.0 concurrent package, and previous outside the JRE packages - the 1.5 JVM has some internal primitives that make the concurrent classes far more efficient. -Original Message- From: Ray Tsang [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 3:22 PM To: java-dev@lucene.apache.org; [EMAIL PROTECTED] Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I agree. This is probably the first compelling argument that I would agree with the use of 1.5. IIRC, Concurrent utils were available for the 1.4 available at http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.h tml before it was accepted into official 1.5 util package. It is continuing to be maintained right now. I'm also supportive about Doug's base-guideline. As far as annotation goes, I really don't see future uses of annotations within the internal code. It would most likley end up being used by the user to annotate a POJO for as a document maybe. ray, On 6/22/06, Simon Willnauer [EMAIL PROTECTED] wrote: On 6/22/06, DM Smith [EMAIL PROTECTED] wrote: On 6/22/06, Doug Cutting [EMAIL PROTECTED] wrote: DM Smith wrote: In an earlier note, I suggested that there needs to be guidance as to how Java 5 constructs are to be incorporated into code, contrib and core. (Sooner or later, core will change to Java 5) Or does anything go? Once we decide to accept Java 5 code, we should of course encourage new contributions to use new language features that improve, e.g., type safety and maintainability. If someone wishes to upgrade existing code to use new language features, these should be done as separate contributions. We could state a goal of upgrading all existing code, but that won't make it happen. I prefer not to make ambitious roadmaps, but rather have things driven bottom-up, by contributors. So my bottom-up-oriented guideline is that I would not reject contributions that do nothing but upgrade existing code to use new language features. Is that the sort of guidance you seek, or do you think we need something more specific, with feature-by-feature guidelines? Developing such guidelines collaboratively might be difficult. One of the things I liked about 2.0 was that 1.9 was a bridge to it from 1.4.3 via deprecations. It made migration fairly straightforward. I would like to see this going forward to 2.1. If so there needs to be some thought to how and whether the existing API will be deprecated in the same fashion as Java 5 is introduced. I was thinking more specific, feature-by-feature guidelines. There are not that many new language features, so I don't think that it would be too onerous. Since the committers are ultimately the ones to accept or reject a contribution, I think they can decide. For example (my opinions), Static Import Try to avoid. It tends to make code unreadable. Autoboxing/unboxing Use sparingly, and if used, provide test cases showing that performance sensitive code is not adversely affected. Varargs Don't use as a substitute for overloading. Use as a replacement for an array of objects. e.g. void f(T[] t) becomes void f(T... t). Enhanced for loops: Use whenever possible. When modifying existing code to add one, change all others, if possible. Typesafe Enum Use wherever possible, internally. Associate behavior with the enumerations when it makes sense. Replace existing enumerations that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Generics Use for all internal collections. When changing a class, ensure that the class is self consistent in its usage of generics. Enhance existing collections that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Annotations: ?? I assume that many people realize these features as new features in Java 5.0. In my opinion there is at least one more feature beside the improvements inside the jvm and the garbage collection and build in Java Management Extension. The feature I'm pointing to is rather a new library than a feature to be honest but it can improve concurrent application in performance and stability matters. The Concurrent Utils in the j2se 5.0 give you much more control of concurrent parts of you application and I guess the lucene project can gain from these new classes to synchronize writing and parallel reading where possible. I think a great deal of adding build in JMX support to the lucene core or rather as a contrib project to enable modification of configurable components like merge factors or similar things. Extensions like this should have some guidelines as Doug said feature-by-feature
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
DM Smith wrote: One of the things I liked about 2.0 was that 1.9 was a bridge to it from 1.4.3 via deprecations. It made migration fairly straightforward. I would like to see this going forward to 2.1. If so there needs to be some thought to how and whether the existing API will be deprecated in the same fashion as Java 5 is introduced. If 2.1 will break API compatibility then it should be called 3.0. Major release numbers are all about API compatibility. If code works with Lucene X.Y, then it should also compile against Lucene X.Y+1, but it may not work with Lucene X+1.Z. The third digit in release numbers is for bugfix releases. In effect, X.Y.0 is a beta, or release candidate. We should never add new features or do anything but fix serious bugs in these releases. JVM version is orthogonal to this, no? Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
: If 2.1 will break API compatibility then it should be called 3.0. Major : release numbers are all about API compatibility. If code works with : Lucene X.Y, then it should also compile against Lucene X.Y+1, but it may : not work with Lucene X+1.Z. : JVM version is orthogonal to this, no? One could argue that the JVM Lucene can run in is the most important API of the jar ... if lucene-core-2.0.jar can run in a java1.4 JVM, and lucene-core-2.1.jar doesn't then I would consider that at least as serious of an API compatability change as removing a heavily used public method. Put another way, if I have a class Foo which can currently compile against Lucene 2.0 in my java1.4 JVM, then I think it is an API change if an Foo doesn't compile against Lucene 2.1 in that same java1.4 JVM. But this strikes me as a symantec issue ... if API changes require reving the major version number, then a descision to allow java1.5 in the trunk requires that the next release from the trunk be 3.X (not 2.1) but it neither procludes nor implies that 1.5 should or shouldn't be used on the trunk. -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Jun 22, 2006, at 5:46 PM, Doug Cutting wrote: DM Smith wrote: One of the things I liked about 2.0 was that 1.9 was a bridge to it from 1.4.3 via deprecations. It made migration fairly straightforward. I would like to see this going forward to 2.1. If so there needs to be some thought to how and whether the existing API will be deprecated in the same fashion as Java 5 is introduced. If 2.1 will break API compatibility then it should be called 3.0. Major release numbers are all about API compatibility. If code works with Lucene X.Y, then it should also compile against Lucene X.Y+1, but it may not work with Lucene X+1.Z. The third digit in release numbers is for bugfix releases. In effect, X.Y.0 is a beta, or release candidate. We should never add new features or do anything but fix serious bugs in these releases. I guess this is what has been bugging me. I see the introduction of Java 5 into the API as a compatibility break. (Using it internally is a client problem for me) I probably would not have spoken up (as loudly) if it was declared that 3.0 would be Java 5 and break compatibility. (I would still like the 2.9 bridge of deprecations as 1.9 was.) 3.0 just sounds a lot further off than 2.1 :-) I have been surveying the code to see what the impact would be to using the new Java 5 language features on existing code. So far I have gotten through a bit more than half of it. So what I am about to say is half baked. The first obvious use of it is the various enums. My experience with them is that the client code does not need to change. (Unless methods are added to the enum members and even then probably no change will be needed.) Internally, there are quite a number of collections being used. Using generics for these make sense. I have only seen one place where collections are used as part of the interface, and that with the new Fieldable stuff, i.e. List getFields(); Since this is new, it would not be subject to breaking the API since. The only place I saw that varargs might be used is with the String[] stopWords parameter to several methods. But my guess is that it does not serve much of an advantage for it, as one won't likely inline a list of stop words. I think the place where it will really come into play will be new code. JVM version is orthogonal to this, no? Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/22/06, DM Smith [EMAIL PROTECTED] wrote: I think the place where it will really come into play will be new code. Absolutely... I wrote some new code recently that uses Java 1.5 (ArrayQueue and BufferedTokenFilter) that is meant to make it easier to write TokenFilters that need state (lookahead, etc) to make decisions. That needs to be downgraded to 1.4 (among other things) before it can be committed to Lucene. Java5 is something you naturally start writing in... at some point it will be the same as ANSI C vs KR ;-) I just wish they had done more... -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Jun 20, 2006, at 6:43 PM, Yonik Seeley wrote: On 6/20/06, DM Smith [EMAIL PROTECTED] wrote: The problem we have is trying to explain to users how to install java in order to get our application to work. Ahh... if you didn't already have a large code base, I'd suggest trying PyLucene in conjunction with freeze (which can make a python program into a standalone executable). Some kind of native-code thing does seem ideal for wide distribution to non-technical end users. Yes. We have a large code base. So rewriting it is non-trivial. We are using NSIS for Windows in a non-GUI mode to check for java, download and install it if not present and if possible and then launch the application. Very nice when it works, but many report that the download does not work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Jun 20, 2006, at 6:42 PM, Robert Engels wrote: Finding good SWT support on anything but the latest (and major) OS's is going to be rather poor and inconsistent. Just check the SWT bugs (especially for things like printing). For a company that seems to want to allow their users to stay in the dark ages - good luck with SWT. This is the major reason we have not done it. We are still in the planning phase. SWT keeps getting better and only through testing on the platforms on which our users are currently on will we make the final decision to switch. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:24 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:21 PM, Yonik Seeley wrote: On 6/20/06, DM Smith [EMAIL PROTECTED] wrote: In any case, there is still GCJ too. If GCJ supported 1.5, and we could make a 1.4 library with Retrotranslator, that should cover most users, right? If I am not mistaken: future support for 1.5 in gcj is ambiguous and/or will be incomplete. You don't use GCJ right? Correct. We couldn't because of our use of Swing. It appears that it is sufficiently far along that it is worth trying again. The problem we have is trying to explain to users how to install java in order to get our application to work. If we could redistribute java as a seamless part of our application we would. We are planning to migrate from Swing to Eclipse's RCP/JFace/SWT and then we can and would use GCJ. If Lucene goes to Java 5, we will need to re- examine those plans. GCJ is currently incomplete, and needs patches to get it to work with lucene (and lucene committers have accepted patches to ease this porting in the past). GCJ support in Lucene isn't as much for the end-user IMO, but for developers who maintain other Lucene ports. Time will tell how good the Java5 support is for GCJ. Hopefully less time rather than more ;-) -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
This sounds reasonable to me... Robert Engels wrote: I don't follow... If a user came to you and said I want to run BibleDesktop, and they have MS-DOS, you would tell them you can't (or you might have to run the very old BibleDesktop 1.0). If they told you they have Windows 98 with Java 1.4 and 256mb or memory, you would say you can run BibleDesktop 2.0 (which includes Lucene 2.0). If they told you they have Windows XP with Java 1.5, you would say you can run BibleDesktop 3.0 (which includes Lucene 2.1). Certainly seems like a packaging/marketing issue for you. Your users would not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor would they care. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:17 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. I am using the Java 5 compiler to build a 1.4 compatible binary. So I get the compiler improvements for all my users. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. It's not up to me. Each user of BibleDesktop has to decide for themselves. Users of MacOS 10.3 and earlier are stuck using Java 1.4. Users that have upgraded to Java 5 get the advantages of that runtime. As for me I am running Java 5. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part of an external contribution that happens to use 1.5 because the contributor uses 1.5 in his/her work and doesn't have time to downgrade the code, just so it can be accepted in Lucene. That's the core argument that you are making and it is a good one. If it could be designated in Jira whether the attachment were Java 5 then others (perhaps myself) could take the patch, downgrade it and attach it to the same issue. It sure would beat forking the project. How many external contributions are to the core Lucene? If the core Lucene contribution can be applied and then downgraded to Java 1.4 easily, what harm is in that? OG: I don't know the number, but JIRA would be the place to look. My guess is about a dozen or more people. Steve Rowe found something that can downgrade 1.5 code to 1.4 and looks promising. If so then perhaps the committers could run the code through it after applying the patch. Then the contributers would not be adversely affected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Grant Ingersoll Sr. Software Engineer Center for Natural Language Processing Syracuse University School of Information Studies 335 Hinds Hall Syracuse, NY 13244 http://www.cnlp.org Voice: 315-443-5484 Fax: 315-443-6886 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Jun 21, 2006, at 7:52 AM, Grant Ingersoll wrote: This sounds reasonable to me... But it is not at all reasonable for us. Our application is designed with a write one, run anywhere mentality for the hardware/OS base that our users currently have. Again many of our users use old, beyond belief machines that anyone in their right mind would have gotten rid of. Wait, that's precisely why they have them. They are hand me downs from those who were in their right mind Recently we went through an exercise to migrate to Java 5. We upgraded all our iterator loops, made the use of collections type- safe, added annotations, refactored our type-safe enums..., every last new language feature was examined and applied if it did not affect performance. There was really no necessity to do it. We did it for fun. That release was not received well and we found out that we have a much larger base of users on Mac 10.3 and earlier. Unfortunately, we also made other material changes and going back to Java 1.4 was a fall forward rather than a revert. But we did go back to Java 1.4. All releases of BibleDesktop for the last 4 years support MacOS 9 and higher, Windows 98 and higher (don't know whether it runs on Win95) and Linux as far back as I know. Robert Engels wrote: I don't follow... If a user came to you and said I want to run BibleDesktop, and they have MS-DOS, you would tell them you can't (or you might have to run the very old BibleDesktop 1.0). If they told you they have Windows 98 with Java 1.4 and 256mb or memory, you would say you can run BibleDesktop 2.0 (which includes Lucene 2.0). If they told you they have Windows XP with Java 1.5, you would say you can run BibleDesktop 3.0 (which includes Lucene 2.1). Certainly seems like a packaging/marketing issue for you. Your users would not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor would they care. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:17 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. I am using the Java 5 compiler to build a 1.4 compatible binary. So I get the compiler improvements for all my users. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. It's not up to me. Each user of BibleDesktop has to decide for themselves. Users of MacOS 10.3 and earlier are stuck using Java 1.4. Users that have upgraded to Java 5 get the advantages of that runtime. As for me I am running Java 5. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part of an external contribution that happens to use 1.5 because the contributor uses 1.5 in his/ her work and doesn't have time to downgrade the code, just so it can be accepted in Lucene. That's the core argument that you are making and it is a good one. If it could be designated in Jira whether the attachment were Java 5 then others (perhaps myself) could take the patch, downgrade it and attach it to the same issue. It sure would beat forking the project. How many external contributions are to the core Lucene? If the core Lucene contribution can be applied and then downgraded to Java 1.4 easily, what harm is in that? OG: I don't know the number, but JIRA would be the place to look. My guess is about a dozen or more people. Steve Rowe found something that can downgrade 1.5 code to 1.4 and looks promising. If so then perhaps the committers could run the code through it after applying the patch. Then the contributers would not be adversely affected. - To unsubscribe, e-mail: [EMAIL PROTECTED
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
It sounds like you did something ill-advised. Why change your code to 1.5 if a significant portion of your users can run it, and the previous release was not essentially bug free (if it was, your users would not have seen any difference). It also seems very unlikely you need any significant changes to Lucene (I reviewed your projects), and if Lucene progresses along with the current state of hardware your users won't be able to run it anyway. I still don't understand the harm in BibleDesktop staying at 2.0 (even forever if you'd like - so you'd have one version). At some point Lucene WILL BE 1.5, your users will still not be able to run it - what would you do then - you would run the last version of Lucene that worked with 1.4.2. Your users obviously don't use the latest and greatest software, so why should Lucene be any different. In the meantime, maybe the good lord will see fit to perform some miracle and upgrade your user's systems. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 7:58 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 21, 2006, at 7:52 AM, Grant Ingersoll wrote: This sounds reasonable to me... But it is not at all reasonable for us. Our application is designed with a write one, run anywhere mentality for the hardware/OS base that our users currently have. Again many of our users use old, beyond belief machines that anyone in their right mind would have gotten rid of. Wait, that's precisely why they have them. They are hand me downs from those who were in their right mind Recently we went through an exercise to migrate to Java 5. We upgraded all our iterator loops, made the use of collections type- safe, added annotations, refactored our type-safe enums..., every last new language feature was examined and applied if it did not affect performance. There was really no necessity to do it. We did it for fun. That release was not received well and we found out that we have a much larger base of users on Mac 10.3 and earlier. Unfortunately, we also made other material changes and going back to Java 1.4 was a fall forward rather than a revert. But we did go back to Java 1.4. All releases of BibleDesktop for the last 4 years support MacOS 9 and higher, Windows 98 and higher (don't know whether it runs on Win95) and Linux as far back as I know. Robert Engels wrote: I don't follow... If a user came to you and said I want to run BibleDesktop, and they have MS-DOS, you would tell them you can't (or you might have to run the very old BibleDesktop 1.0). If they told you they have Windows 98 with Java 1.4 and 256mb or memory, you would say you can run BibleDesktop 2.0 (which includes Lucene 2.0). If they told you they have Windows XP with Java 1.5, you would say you can run BibleDesktop 3.0 (which includes Lucene 2.1). Certainly seems like a packaging/marketing issue for you. Your users would not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor would they care. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:17 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. I am using the Java 5 compiler to build a 1.4 compatible binary. So I get the compiler improvements for all my users. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. It's not up to me. Each user of BibleDesktop has to decide for themselves. Users of MacOS 10.3 and earlier are stuck using Java 1.4. Users that have upgraded to Java 5 get the advantages of that runtime. As for me I am running Java 5. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Hi, - Original Message From: DM Smith [EMAIL PROTECTED] On Jun 21, 2006, at 7:52 AM, Grant Ingersoll wrote: This sounds reasonable to me... OG: It sounded reasonable to me, too. I don't quite understand why that's SO hard to accept. Btw., I run Lucene 1.4.3 on Java 1.4.2 as well, so I'm not trying to push 1.5 because of my personal interests. OG: To be perfectly honest, and that may turn out to be a mistake, this argument is starting to sound kind of selfish - a handful of people want the latest Lucene, but won't let it advance with 1.5 contributions because 1.5 wouldn't work for them. At the same time they are not thinking of the majority that would benefit from new contributions. Again, we still run Lucene 1.4.3 on Java 1.4.2 on technorati.com, for example, and I'm purely arguing this case because I don't want to reject the nice people who contribute 1.5 code. But it is not at all reasonable for us. Our application is designed with a write one, run anywhere mentality for the hardware/OS base that our users currently have. Again many of our users use old, OG: Not to be mean or anything like that, but it sounds like that's a problem with the design of this particular application. It has to run on customers' computers that you are not in control of, yet designed in a monolithic write one, run anywhere fashion. Isn't this always going to be a problem for you? If your users are already users of hand-me-down computers and are very used to running old software and hardware, do they really need the latest and greatest Lucene? Why? Otis Robert Engels wrote: I don't follow... If a user came to you and said I want to run BibleDesktop, and they have MS-DOS, you would tell them you can't (or you might have to run the very old BibleDesktop 1.0). If they told you they have Windows 98 with Java 1.4 and 256mb or memory, you would say you can run BibleDesktop 2.0 (which includes Lucene 2.0). If they told you they have Windows XP with Java 1.5, you would say you can run BibleDesktop 3.0 (which includes Lucene 2.1). Certainly seems like a packaging/marketing issue for you. Your users would not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor would they care. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:17 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. I am using the Java 5 compiler to build a 1.4 compatible binary. So I get the compiler improvements for all my users. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. It's not up to me. Each user of BibleDesktop has to decide for themselves. Users of MacOS 10.3 and earlier are stuck using Java 1.4. Users that have upgraded to Java 5 get the advantages of that runtime. As for me I am running Java 5. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part of an external contribution that happens to use 1.5 because the contributor uses 1.5 in his/ her work and doesn't have time to downgrade the code, just so it can be accepted in Lucene. That's the core argument that you are making and it is a good one. If it could be designated in Jira whether the attachment were Java 5 then others (perhaps myself) could take the patch, downgrade it and attach it to the same issue. It sure would beat forking the project. How many external contributions are to the core Lucene? If the core Lucene contribution can be applied and then downgraded to Java 1.4 easily, what harm is in that? OG: I don't know the number, but JIRA would be the place to look. My guess is about a dozen or more people. Steve Rowe found
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/21/06, Robert Engels [EMAIL PROTECTED] wrote: It sounds like you did something ill-advised. Why change your code to 1.5if a significant portion of your users can run it, and the previous release was not essentially bug free (if it was, your users would not have seen any difference). It was ill advised. When we heard that Java 5 was released for MacOS, we did not read the fine print (i.e. for 10.4 and higher only). Shame on us. It was a fun experiment though:) Our thought was to have a consistent code style throughout. We did not want Java 5 syntax to creep in gradually only as code was changed. The previous release was essentially bug free. It also seems very unlikely you need any significant changes to Lucene (I reviewed your projects), I appreciate that you took a look at it! and if Lucene progresses along with the current state of hardware your users won't be able to run it anyway. Correct. Our use of Lucene is very simple, but very central to our product. That is why I have suggested in a separate thread that the central core of lucene be maintained from all the other great additions. I am not sure what you mean by if Lucene progresses I am impressed with how Lucene performs on an old Windows box and on an old iMac. Are you saying that future releases will have a bigger resource footprint? I still don't understand the harm in BibleDesktop staying at 2.0 (even forever if you'd like - so you'd have one version). The only harm would be that I could not provide them with new features that are implemented in Java 1.5 Lucene. Same goes for bugs and performance enhancements. And we may very well have to do that at the point that Lucene embraces 1.5for its fundamental features. At some point Lucene WILL BE 1.5, your users will still not be able to run it - what would you do then - you would run the last version of Lucene that worked with 1.4.2. Yes. That will be the case. Your users obviously don't use the latest and greatest software, so why should Lucene be any different. Our users want the latest and greatest BibleDesktop (at any rate, that's what we tell ourselves). Lucene is immaterial to them. In the meantime, maybe the good lord will see fit to perform some miracle and upgrade your user's systems. I would like that very much! -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 7:58 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 21, 2006, at 7:52 AM, Grant Ingersoll wrote: This sounds reasonable to me... But it is not at all reasonable for us. Our application is designed with a write one, run anywhere mentality for the hardware/OS base that our users currently have. Again many of our users use old, beyond belief machines that anyone in their right mind would have gotten rid of. Wait, that's precisely why they have them. They are hand me downs from those who were in their right mind Recently we went through an exercise to migrate to Java 5. We upgraded all our iterator loops, made the use of collections type- safe, added annotations, refactored our type-safe enums..., every last new language feature was examined and applied if it did not affect performance. There was really no necessity to do it. We did it for fun. That release was not received well and we found out that we have a much larger base of users on Mac 10.3 and earlier. Unfortunately, we also made other material changes and going back to Java 1.4 was a fall forward rather than a revert. But we did go back to Java 1.4. All releases of BibleDesktop for the last 4 years support MacOS 9 and higher, Windows 98 and higher (don't know whether it runs on Win95) and Linux as far back as I know. Robert Engels wrote: I don't follow... If a user came to you and said I want to run BibleDesktop, and they have MS-DOS, you would tell them you can't (or you might have to run the very old BibleDesktop 1.0). If they told you they have Windows 98 with Java 1.4 and 256mb or memory, you would say you can run BibleDesktop 2.0 (which includes Lucene 2.0). If they told you they have Windows XP with Java 1.5, you would say you can run BibleDesktop 3.0 (which includes Lucene 2.1). Certainly seems like a packaging/marketing issue for you. Your users would not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor would they care. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:17 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
for leading wild card search. (I'm not wanting to reopen that discussion.) One of the things that we do not do right now is searching stems. Our primary domain for that would be Biblical Greek and Hebrew. Related to this is the ability to search for Biblical concepts/topics such as grace. Another feature we want to add is the ability to search accented text without regard to accents. And another is to search via transliteration, that is, the user types in a transliteration of Greek or Hebrew to search Greek and Hebrew. I really have not looked into it to see what Lucene provides or what is available otherwise. I imagine that some of these will be layered on top of Lucene and may change how we build the index. For all of these things, I don't see that we need to abandon the older machines. It may be that Lucene 2.0.x will provide everything that we might want to add. Or that we can downgrade Java 1.5 contributions and use that. Otis Robert Engels wrote: I don't follow... If a user came to you and said I want to run BibleDesktop, and they have MS-DOS, you would tell them you can't (or you might have to run the very old BibleDesktop 1.0). If they told you they have Windows 98 with Java 1.4 and 256mb or memory, you would say you can run BibleDesktop 2.0 (which includes Lucene 2.0). If they told you they have Windows XP with Java 1.5, you would say you can run BibleDesktop 3.0 (which includes Lucene 2.1). Certainly seems like a packaging/marketing issue for you. Your users would not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor would they care. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] ] Sent: Tuesday, June 20, 2006 5:17 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. I am using the Java 5 compiler to build a 1.4 compatible binary. So I get the compiler improvements for all my users. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. It's not up to me. Each user of BibleDesktop has to decide for themselves. Users of MacOS 10.3 and earlier are stuck using Java 1.4. Users that have upgraded to Java 5 get the advantages of that runtime. As for me I am running Java 5. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part of an external contribution that happens to use 1.5 because the contributor uses 1.5 in his/ her work and doesn't have time to downgrade the code, just so it can be accepted in Lucene. That's the core argument that you are making and it is a good one. If it could be designated in Jira whether the attachment were Java 5 then others (perhaps myself) could take the patch, downgrade it and attach it to the same issue. It sure would beat forking the project. How many external contributions are to the core Lucene? If the core Lucene contribution can be applied and then downgraded to Java 1.4 easily, what harm is in that? OG: I don't know the number, but JIRA would be the place to look. My guess is about a dozen or more people. Steve Rowe found something that can downgrade 1.5 code to 1.4 and looks promising. If so then perhaps the committers could run the code through it after applying the patch. Then the contributers would not be adversely affected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Grant Ingersoll Sr. Software Engineer Center for Natural Language Processing Syracuse University School of Information Studies 335 Hinds Hall Syracuse, NY 13244
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
: From: Robert Engels : The lazy refers to the ability/desire of the 1.4 users developers to : devote their resources to back-porting the code to the 2.0.X release. Rather : than having the 1.5 developers having to waste their time thinking in 1.4 : when their work is predominately being performed using 1.5 : features/compilers/tools. There is NOTHING stopping the 1.4 community from : doing this, except their laziness in wanting to (especially given their : common assessment that 1.5 is nothing more than syntactic sugar). At the start of this brew-ha, I was very much in favor of 2.1.x allowing java1.5 features ... but comments like this make me question that opionion, because they suggest (in this case explicitly) the existence of a 1.4 community that can backport things if they want to ... perhaps it's idealistic of me, but I'd like to think there is one big happy Lucene community that helps eachother, and I'd hate to knowingly and willfully take steps to fracture that community in half (more then this discussion already has). The whole is certainly greater then the sum of it's parts. : From: DM Smith : Can I stick with 2.0.x? Certainly. However, I'd rather not. I keep reading : about refactoring providing a significant, incremental improvement, and I'd : like to provide that, especially for those older machines! And here is where the other half of my brain chimes in -- The reason I initially supported the idea of using java1.5 for the 2.1.x release is because there is no doubt in my mind that being able to use 1.5 language features (specificly generics and concurrency utils) will make refactoring and cleaning up the core Lucene APIs easier, faster, and safer then if we constrain ourselves to java1.4. -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Robert Engels wrote: People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. Why? Many reasons. The first - because they implement an official HL7 specification - and the specification says that the implementation needs to support Java 1.4. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). Lucene is a low level library that is used to build many great applications. If you make the jump to 1.5 today - you are going to be leaving people behind. And judging by the poll, you are going to be leaving a fairly significant number of people behind. Lucene has great policy on not breaking backwards compatibility in their API - why should this be looked at any differently? Rather than having the 1.5 developers having to waste their time thinking in 1.4 when their work is predominately being performed using 1.5 features/compilers/tools. I don't think that the caliber of developers that are working on the Lucene core are going to be slowed down any by using 1.4 syntax over 1.5. (It actually takes longer to type in all of those generics :) All of my tools - Eclipse and Java 1.5 - have a check box that will cause them to generate 1.4 compatible code. Its really _not_ a big deal to write 1.4 code even if you are used to 1.5. This particular argument just isn't compelling to me. My personal opinion for the path that Lucene should take: Core bugs fixes must be 1.4 compatible. Core improvements must be 1.4 compatible. Contrib / sandbox can be 1.5 or 1.6. Of course, at some point - Lucene Core does need to advance. But I don't just don't feel that syntactic sugar in 1.5 is enough of a reason to break backwards compatibility. I haven't followed 1.6 - I don't know what the new features are there. Assuming that there are great new features in 1.6 - that would improve the lucene core if they were used - I think that that is when this issue gets revisited. This isn't the type of question that should be decided by a poll. This should be decided by thoughtfully looking at the consequences of each choice. For me - the negative consequences of choosing 1.5 - leaving behind a lot of users - is much worse than the negative consequences of staying at 1.4 - making a couple dozen highly skilled developers check an extra box in their lucene development environments? If any developers have actually read this far (sorry - it got kind of long) - thanks again for all of your great work - Lucene is a great tool - and a great community. Dan -- Daniel Armbrust Biomedical Informatics Mayo Clinic Rochester daniel.armbrust(at)mayo.edu http://informatics.mayo.edu/
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
To set the record straight, I think the Lucene product and community are fantastic. Period. I was also not the one who starting in with what could be termed 'aggressive' language. Our company does not fully support 1.5. I was the loudest voice against the move to 1.5. After almost 2 years I now back the move. Why? Several reasons: 1. Sun is very slow, if at all to fix bugs in 1.4 (of which there are many). For example, the current problems in Lucene regarding ThreadLocals. Although this is not a bug per se, it is probably not intuitive or desired behavior. The Lucene developers have been forced to both diagnose and create workarounds problems already fixed in 1.5. The licensing of Java does not allow for the easy fix bugs by non-Sun developers. 2. The type safe collections are far more efficient to program/debug with. 3. The standardized concurrent facilities can be of great benefit to multithreaded programs. 4. It is what students graduating from college understand and use. 5. It is what the currently available books explain and use. It just seems that many people believe that if there is ONE person (or a minority) that can't switch, then Lucene cannot switch. It seems that Bob is in this category of never being able to switch (I am fairly certain 1.5 will probably never be released for OS 9) - does that mean that Lucene developers can never use 1.5 features? What about the argument I made of using alternative algorithms that may not be as useable on older, slower machines. We have users that cannot upgrade to the latest release of our software because of inadequate hardware (or unwillingness to change). They have 3 choices. Stick with the old, upgrade their machines, or move to a competitor. The last of which we surely do not want, but that is their choice. At the same time, if we did not continue to grow and evolve our software, we would lose far more of our customers to competitors. This is open-source software. A clear majority has voted. Why can't we listen to them and move forward??? -Original Message- From: Dan Armbrust [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 8:42 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) Robert Engels wrote: People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. Why? Many reasons. The first - because they implement an official HL7 specification - and the specification says that the implementation needs to support Java 1.4. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). Lucene is a low level library that is used to build many great applications. If you make the jump to 1.5 today - you are going to be leaving people behind. And judging by the poll, you are going
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I have another idea. Why don't we just let the voted committers decide amongst themselves. Since they are principally charged with maintaining the code quality and feature set, they are in the best position to make the decision. -Original Message- From: Dan Armbrust [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 8:42 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) Robert Engels wrote: People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. Why? Many reasons. The first - because they implement an official HL7 specification - and the specification says that the implementation needs to support Java 1.4. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). Lucene is a low level library that is used to build many great applications. If you make the jump to 1.5 today - you are going to be leaving people behind. And judging by the poll, you are going to be leaving a fairly significant number of people behind. Lucene has great policy on not breaking backwards compatibility in their API - why should this be looked at any differently? Rather than having the 1.5 developers having to waste their time thinking in 1.4 when their work is predominately being performed using 1.5 features/compilers/tools. I don't think that the caliber of developers that are working on the Lucene core are going to be slowed down any by using 1.4 syntax over 1.5. (It actually takes longer to type in all of those generics :) All of my tools - Eclipse and Java 1.5 - have a check box that will cause them to generate 1.4 compatible code. Its really _not_ a big deal to write 1.4 code even if you are used to 1.5. This particular argument just isn't compelling to me. My personal opinion for the path that Lucene should take: Core bugs fixes must be 1.4 compatible. Core improvements must be 1.4 compatible. Contrib / sandbox can be 1.5 or 1.6. Of course, at some point - Lucene Core does need to advance. But I don't just don't feel that syntactic sugar in 1.5 is enough of a reason to break backwards compatibility. I haven't followed 1.6 - I don't know what the new features are there. Assuming that there are great new features in 1.6 - that would improve the lucene core if they were used - I think that that is when this issue gets revisited. This isn't the type of question that should be decided by a poll. This should be decided by thoughtfully looking at the consequences of each choice. For me - the negative consequences of choosing 1.5 - leaving behind a lot of users - is much worse than the negative consequences of staying at 1.4 - making a couple dozen highly skilled developers check an extra box in their lucene development
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Robert Engels wrote: To set the record straight, I think the Lucene product and community are fantastic. Period. Ditto. [snip] After almost 2 years I now back the move. Why? Several reasons: 1. Sun is very slow, if at all to fix bugs in 1.4 (of which there are many). For example, the current problems in Lucene regarding ThreadLocals. Although this is not a bug per se, it is probably not intuitive or desired behavior. The Lucene developers have been forced to both diagnose and create workarounds problems already fixed in 1.5. The licensing of Java does not allow for the easy fix bugs by non-Sun developers. 2. The type safe collections are far more efficient to program/debug with. 3. The standardized concurrent facilities can be of great benefit to multithreaded programs. 4. It is what students graduating from college understand and use. 5. It is what the currently available books explain and use. For my money (2) is the most important reason for moving to 1.5. My early years (!) involved a lot of work with programming languages and finally having type-safe collections and the syntactic conventions that go along with those immediately struck me as a good step forward. That first impression was borne out when I converted some of my java code to use the 1.5 type-safe constructs. Not only was the code shorter and more understandable (aka more maintainable) but it brought to light some bugs that had lain their dormant for quite a while. Lucene is well-tested and stable and written by better people better at writing Java than me so it's unlikely that there'll be any bugs like that lurking in dark corners. On the other hand, new code stands a better chance of being bug free precisely because of the improvements in the language and the improved type-safety. (3) comes second for me though -- I'm a big fan of Doug Lea's util.concurrent classes and having them well integrated in Java 1.5 makes them even better, but that's the operating system personality talking. jch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. - Original Message From: Dan Armbrust [EMAIL PROTECTED] Robert Engels wrote: People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. OG: I think you are missing or misinterpreting things here. Lucene contributors tend to be people who write nice extensions to Lucene, and want to give them back to Lucene. Typically those extensions come out of their day jobs, or at least that is my impression. When they use 1.5 there, their contribution will be 1.5. External contributors already spend extra time and effort to do this. Requiring them to modify their code not to use 1.5 would mean they will be less likely to contribute. I wouldn't bother, if I had to take extra time and effort to contribute, and even go backwards with my code, when what I really want is for my piece of code to become a part of Lucene, so I can just use that code instead of maintaining my own variation of it. OG: My main concern is losing those contributions. We already have a TON of good patches in JIRA that we didn't integrate, and lots of them are lost, because patches no longer apply. I hate treating kind contributors like that. I feel ungrateful. OG: So, instead of only thinking how if Lucene 2.1 goes the 1.5 route you won't be able to use the latest and greatest, one can also think about losing the latest and greatest contributions because they are written with 1.5 in mind. And this is not a loss only to those who are already on 1.5. This is a loss for _everyone_ in the long run. Those running 1.4 now, will be running 1.5 one day, but they won't be getting Lucene with contributions that were rejected, because in the second half of 2006 we were forced to reject all 1.5 contributions. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. OG: Exactly. There will ALWAYS be people who have to stay with 1.4 or older Java. At some point you have to decide not support the older versions, just like at some point we decided to stop supporting 1.3. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. OG: Again, exactly. If this is an environment where upgrades are very carefully planned and thus probably rare, why does this environment care SO much to have the cutting edge Lucene, when at the same time they are ok with a old version of Java? Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? OG: It is NOT syntactic sugar only. This is FUD! :) Really. I just found a bug in my code that was hidden for several weeks because I was using a List instead of ListString, for instance! Also, this entire ecosystem of potential users seems a bit exaggerated. :) They certainly didn't seem to take part in that survey. I think J2ME on mobile devices might even be 1.2 Java, not sure. While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
, if that ever is done.) BTW, Java 6 is beta for MacOS 10.4. We have users that cannot upgrade to the latest release of our software because of inadequate hardware (or unwillingness to change). I have run a lucene application on a Win98 laptop with a 333Mhz CPU, 4200rpm harddrive and 32M ram. The performance of the searches is just fine. Old hardware is not the issue. The issue is availability of Java for the OS that runs on the old hardware. (And for the record Java 5 runs just fine on that laptop.) The other issue is that we do not control the environment owned by our users. As application developers, we use lucene, so we are lucene users. But our users don't care what we use. All they care is whether our application works for them in their environment. They have 3 choices. Stick with the old, upgrade their machines, or move to a competitor. The last of which we surely do not want, but that is their choice. At the same time, if we did not continue to grow and evolve our software, we would lose far more of our customers to competitors. This is open-source software. A clear majority has voted. Why can't we listen to them and move forward??? The vote was not for whether Lucene should go to Java 5, but whether the application base can migrate to Java 5 within a year. The vote was very telling. 1/3rd of the voters are java 1.4 and cannot go to Java 5 in the next 12 months. This does not represent ONE person but potentially many more people than the 45 that did vote. -Original Message- From: Dan Armbrust [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 8:42 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) Robert Engels wrote: People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. Why? Many reasons. The first - because they implement an official HL7 specification - and the specification says that the implementation needs to support Java 1.4. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). Lucene is a low level library that is used to build many great applications. If you make the jump to 1.5 today - you are going to be leaving people behind. And judging by the poll, you are going to be leaving a fairly significant number of people behind. Lucene has great policy on not breaking backwards compatibility in their API - why should this be looked at any differently? Rather than having the 1.5 developers having to waste their time thinking in 1.4 when their work is predominately being performed using 1.5 features/compilers/tools. I don't think that the caliber of developers that are working on the Lucene core are going to be slowed down any by using 1.4 syntax over 1.5. (It actually
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think Otis put things perfectly and would like to second everything he's said. This is about facilitating more contributions from the majority vs. creating a version that the minority can use. To answer Otis's question, How small does the percentage of 1.4 users need to be, before we can have 1.5 in Lucene?, I think there are some other factors that need to be considered. How many contributors to Lucene are generating contributions out of work they are doing for their companies or other vocations, submitting these to Lucene to achieve the benefits of community usage/maintenance/enhancement, and using 1.5 as their daily environment? My suspicion is that while the user ratio may be 2:1 1.5:1.4 that the contributor ratio is even more skewed in favor of 1.5. One of the reasons I suspect this is that the 1.4 users who have spoken up thus far do not seem to fully appreciate the volunteer-contribution model of the Lucene community (e.g., see the thread below). I think it is safe to assume that potential contributors will be less motivated if they are forced to back port their code. If Lucene makes the 1.5 decision, about 1/3 of the Lucene user base today will not be able to build off the head, although they will have a fully supported 2.0.x. The 1/3 portion will decline continually, but this is still a substantial problem. I'm sure the Lucene pmc/committers do not want to leave so many users behind. If Lucene makes the 1.4 decision, it will get fewer contributions. As one example, I will only submit bug fixes. I'm waiting to see how this turns out to decide whether or not to contribute some new features that are all coded in 1.5. The question is how many contributors are in a similar situation? If this number is say greater than 80%, rather than the 67% indicated in the usage poll, then making the 1.4 decision is also a substantial problem for Lucene's future. Chuck Otis Gospodnetic wrote on 06/20/2006 09:33 AM: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. - Original Message From: Dan Armbrust [EMAIL PROTECTED] Robert Engels wrote: People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. OG: I think you are missing or misinterpreting things here. Lucene contributors tend to be people who write nice extensions to Lucene, and want to give them back to Lucene. Typically those extensions come out of their day jobs, or at least that is my impression. When they use 1.5 there, their contribution will be 1.5. External contributors already spend extra time and effort to do this. Requiring them to modify their code not to use 1.5 would mean they will be less likely to contribute. I wouldn't bother, if I had to take extra time and effort to contribute, and even go backwards with my code, when what I really want is for my piece of code to become a part of Lucene, so I can just use that code instead of maintaining my own variation of it. OG: My main concern is losing those contributions. We already have a TON of good patches in JIRA that we didn't integrate, and lots of them are lost, because patches no longer apply. I hate treating kind contributors like that. I feel ungrateful. OG: So, instead of only thinking how if Lucene 2.1 goes the 1.5 route you won't be able to use the latest and greatest, one can also think about losing the latest and greatest contributions because they are written with 1.5 in mind. And this is not a loss only to those who are already on 1.5. This is a loss for _everyone_ in the long run. Those running 1.4 now, will be running 1.5 one day, but they won't be getting Lucene with contributions that were rejected, because in the second half of 2006 we were forced to reject all 1.5 contributions. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. OG: Exactly. There will ALWAYS be people who have to stay with 1.4 or older Java. At some point you have to decide not support the older versions, just like at some point we decided to stop supporting 1.3. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Robert Engels wrote: I have another idea. Why don't we just let the voted committers decide amongst themselves. If push comes to shove, this decision will be made by consensus of the Lucene PMC. Any member of the PMC can veto any change to the code. http://www.apache.org/foundation/voting.html As a member of the PMC, I presently find the arguments of those who'd like to keep the Lucene core in 1.4 more compelling, although I don't know yet whether I'd use my veto power. In the history of Lucene we've rarely had to even resort to voting to make code decisions, and I don't think anyone has ever vetoed anything. It would be best if we could come to an agreement here without alienating anyone and without resorting to vetoes. For this to happen, we all need to try hard to understand the concerns of others. Some folks reasonably want to use the latest features of Lucene but also have constraints about what Java version their users can use. Developers whose users are not so constrained want to be able to use the latest features of Java. I think the inconvenience to the former (lack of user access to new Lucene features) affects more folks than that to the latter (lack of developer access to new Java features). In the end, we develop Lucene for users, no? We obviously can't always please all of them, but this isn't a user-versus-user issue, but rather a user-versus-developer issue, where we, the developers, have all the power. We have the power to be kind and thoughtful, or to be selfish. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Could someone shed light on how the decision to transition from Java 1.3 to Java 1.4 unfolded? Any lessons learned or applicable here? Mike Robert Engels [EMAIL PROTECTED] 06/20/2006 02:24 PM Please respond to java-dev@lucene.apache.org To java-dev@lucene.apache.org cc Subject RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I think your statement do not seem to fully appreciate the volunteer-contribution model hits the nail on the head. There is a minority that wants everything for free, wants it work exactly as they want, and then have the audacity to tell the others they should do more even work to make them happy - all without contributing a single hour of work to the product (maybe via testing...). -Original Message- From: Chuck Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 1:15 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I think Otis put things perfectly and would like to second everything he's said. This is about facilitating more contributions from the majority vs. creating a version that the minority can use. To answer Otis's question, How small does the percentage of 1.4 users need to be, before we can have 1.5 in Lucene?, I think there are some other factors that need to be considered. How many contributors to Lucene are generating contributions out of work they are doing for their companies or other vocations, submitting these to Lucene to achieve the benefits of community usage/maintenance/enhancement, and using 1.5 as their daily environment? My suspicion is that while the user ratio may be 2:1 1.5:1.4 that the contributor ratio is even more skewed in favor of 1.5. One of the reasons I suspect this is that the 1.4 users who have spoken up thus far do not seem to fully appreciate the volunteer-contribution model of the Lucene community (e.g., see the thread below). I think it is safe to assume that potential contributors will be less motivated if they are forced to back port their code. If Lucene makes the 1.5 decision, about 1/3 of the Lucene user base today will not be able to build off the head, although they will have a fully supported 2.0.x. The 1/3 portion will decline continually, but this is still a substantial problem. I'm sure the Lucene pmc/committers do not want to leave so many users behind. If Lucene makes the 1.4 decision, it will get fewer contributions. As one example, I will only submit bug fixes. I'm waiting to see how this turns out to decide whether or not to contribute some new features that are all coded in 1.5. The question is how many contributors are in a similar situation? If this number is say greater than 80%, rather than the 67% indicated in the usage poll, then making the 1.4 decision is also a substantial problem for Lucene's future. Chuck Otis Gospodnetic wrote on 06/20/2006 09:33 AM: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. - Original Message From: Dan Armbrust [EMAIL PROTECTED] Robert Engels wrote: People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. OG: I think you are missing or misinterpreting things here. Lucene contributors tend to be people who write nice extensions to Lucene, and want to give them back to Lucene. Typically those extensions come out of their day jobs, or at least that is my impression. When they use 1.5 there, their contribution will be 1.5. External contributors already spend extra time and effort to do this. Requiring them to modify their code not to use 1.5 would mean they will be less likely to contribute. I wouldn't bother, if I had to take extra time and effort to contribute, and even go backwards with my code, when what I really want is for my piece of code to become a part of Lucene, so I can just use that code instead of maintaining my own variation of it. OG: My main concern is losing those contributions. We already have a TON of good patches in JIRA that we didn't integrate, and lots of them are lost, because patches no longer apply. I hate treating kind contributors like that. I feel ungrateful. OG: So, instead of only thinking how if Lucene 2.1 goes the 1.5 route you won't be able to use the latest and greatest, one can also think about losing the latest and greatest contributions because they are written with 1.5 in mind. And this is not a loss only to those who are already on 1.5
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, Otis Gospodnetic [EMAIL PROTECTED] wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. - Original Message From: Dan Armbrust [EMAIL PROTECTED] Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. OG: Again, exactly. If this is an environment where upgrades are very carefully planned and thus probably rare, why does this environment care SO much to have the cutting edge Lucene, when at the same time they are ok with a old version of Java? In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? OG: It is NOT syntactic sugar only. This is FUD! :) Really. I just found a bug in my code that was hidden for several weeks because I was using a List instead of ListString, for instance! I think I was the first to suggest that some of Java 5's features were syntatic sugar. In saying this, I had no intention of spreading Fear, Uncertainty or Doubt. That strong type checking is valuable is certainly beyond a doubt. It is a syntax addition to the language that's really sweet! However, one can carefully write correct code without it. The other features such as autoboxing have a runtime cost that probably would be best to avoid. But boy is it easier to write code when you don't have to convert an integer to an Integer! Using the new iterator construct is simple and much more straightforward, but it does not add much to the code. While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. One can get the performance gains just by using the Java 5 jre. I don't think that the caliber of developers that are working on the Lucene core are going to be slowed down any by using 1.4 syntax over 1.5. (It actually takes longer to type in all of those generics :) All of my tools - Eclipse and Java 1.5 - have a check box that will cause them to generate 1.4 compatible code. Its really _not_ a big deal to write 1.4 code even if you are used to 1.5. This particular argument just isn't compelling to me. OG: Please read what I wrote all the way up. In my mind, it is not so much about core Lucene developers, as it is about external contributions. Core developer will know what we agreed on and will write the code to suit our agreement. External contributor will contribute code she/he wrote for work. As the poll shows, more people use 1.5 at work, thus... My personal opinion for the path that Lucene should take: Core bugs fixes must be 1.4 compatible. Core improvements must be 1.4 compatible. Contrib / sandbox can be 1.5 or 1.6. How many external contributions are to the core Lucene? If the core Lucene contribution can be applied and then downgraded to Java 1.4 easily, what harm is in that?
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
This poll does not indicate anything about Lucene. It is open to anyone who goes to quimble and searches on Java. On 6/16/06, Otis Gospodnetic [EMAIL PROTECTED] wrote: It looks like I would have won a beer had anyone wagered me. 1.5 IS the Java version that the majority Lucene users use, not 1.4! Does this mean we can now start accepting 1.5 code? Otis - Original Message From: Otis Gospodnetic [EMAIL PROTECTED] To: java-user@lucene.apache.org Sent: Friday, June 16, 2006 11:48:15 AM Subject: Survey: Lucene and Java 1.4 vs. 1.5 Hello everyone, If you have 15 seconds to spare, please let us (Lucene developers) know which version of Java you are using with Lucene: 1.4 or 1.5 All it takes is 1 click on one of the two choices: http://www.quimble.com/poll/view/2156 No cheating, please. Thanks! Otis
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I agree with most of the points Otis makes. As a developer I would prefer to develop in Java5. As I do all my Solr development in Java5, it would be nice to be able to move some common stuff to Lucene more easily. Now I have to plan ahead of time if I think it has a decent probability of being wanted by the Lucene community, and avoid any Java5 features. A couple of points: - syntactic sugar is a rather broad categorization, including some very useful things. It is not synonymous with irrelevant or should not be seriously considered, although it has that connotation. I'd recommend avoiding that phrase. - I disagree with many of the arguments 1.4 proponents are making about the Java5 language/library improvements themselves. The real compelling argument is that moving to Java5 now will inconvenience a fair number of people. I'd personally be more comfortable moving to Java5 if at least GCJ had support (which it looks like it's getting!) -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, Steven Rowe [EMAIL PROTECTED] wrote: Could not tools like Retrotranslator[2] or Retroweaver[3] be used to satisfy both camps? That's an interesting option Steven... Retrotranslator certainly looks like they handle almost everything! If we ended up taking that route, we have enough 1.4 users that I think it would be nice to have - a 1.4 compatible jar included in the distributions along with the 1.5 jar - an easy way to run all the unit tests against the 1.4 compatible jar -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think retrotranslator only work on the syntax, but not on the 1.5 specific libraries (for obvious reasons). A real use case was written up by a Java 5 web mvc framework at http://stripes.mc4j.org/confluence/display/stripes/Java+1.4+and+Stripes Once again, so long we stay away from non-1.4 compatible language features of 1.5, we can always compile to 1.4 code anyways. I don't know exactly what everyone is saying that makes it convinient for them to develop in 1.5. But I believe majority of it are in basic syntax improvements of 1.5 which are (should) fully compatible to be compiled into 1.4 bytecode (although i could see a use of the concurrent package?) Looking at hibernate and spring, do we see them rushing into 1.5? They do have great support for users using both 1.4 and 1.5. Surely it's on a different scale, different user base, and different type of libraries. But the point is they have a good compromise between the 2, and there is no branching, but incremental versions that adds 1.5 extensions on top of what they already have. I think to avoid branching, it can come down to what 1.5 language features are we willing to accept in the core, and anything-goes in the contributions. We do realize that not every feature needs to be in the core, right? ray, On 6/20/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 6/20/06, Steven Rowe [EMAIL PROTECTED] wrote: Could not tools like Retrotranslator[2] or Retroweaver[3] be used to satisfy both camps? That's an interesting option Steven... Retrotranslator certainly looks like they handle almost everything! If we ended up taking that route, we have enough 1.4 users that I think it would be nice to have - a 1.4 compatible jar included in the distributions along with the 1.5 jar - an easy way to run all the unit tests against the 1.4 compatible jar -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I don't know much about those tools, but it wouldn't seem feasible to supply 1.5 compatible libraries (otherwise the stupid classpath project would have been abandoned long ago). I think the bug fixing that has gone into 1.5 libraries is just as important as the language changes. -Original Message- From: Yonik Seeley [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 2:31 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On 6/20/06, Steven Rowe [EMAIL PROTECTED] wrote: Could not tools like Retrotranslator[2] or Retroweaver[3] be used to satisfy both camps? That's an interesting option Steven... Retrotranslator certainly looks like they handle almost everything! If we ended up taking that route, we have enough 1.4 users that I think it would be nice to have - a 1.4 compatible jar included in the distributions along with the 1.5 jar - an easy way to run all the unit tests against the 1.4 compatible jar -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, Ray Tsang [EMAIL PROTECTED] wrote: I think retrotranslator only work on the syntax, but not on the 1.5 specific libraries (for obvious reasons). I was going by the link provided: http://retrotranslator.sourceforge.net/ What Java 5.0 features are supported? * Generics (generic types) * Annotations (metadata) * Reflection on generics and annotations * Typesafe enums (enumerated types) * Autoboxing/unboxing * Enhanced for loop (for-each loop) * Varargs (variable arguments) * Covariant return types * Static import * Concurrency utilities * Collections framework enhancements It looks like there are some runtime components. In any case, there is still GCJ too. If GCJ supported 1.5, and we could make a 1.4 library with Retrotranslator, that should cover most users, right? Then there is the question of if it's worth the effort to support 1.4 via Retrotranslator over just coding Lucene stuff in 1.4 or backporting... -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, Yonik Seeley [EMAIL PROTECTED] wrote: In any case, there is still GCJ too. If GCJ supported 1.5, and we could make a 1.4 library with Retrotranslator, that should cover most users, right? I just took a look at GCJ again. If I am not mistaken: future support for 1.5 in gcj is ambiguous and/or will be incomplete. GCJ uses Classpath to provide open implementations of Java. It's stated goal is to be Java 1.2 compliant by the time it gets to a 1.0 release. It is largely 1.4 compliant. Significant for me, the swing classes don't support all the Look and Feels I support, e.g. no MacOS LaF. And while it says that there is some support for some Java 5 classes, I could not find an enumeration of them. I would speculate that incorporating the concurrency classes will be relatively easy since the cpj, on which Sun's implementation is based, is public domain. However, I would also speculate that all bets are off on the other classes as to when they will show up. GCJ will be using Eclipse's java compiler as its new compiler. When this happens it will have the support for the new language features. Interestingly this is dependent upon the GPLv3 which is stated as being a year away from being finalized (I don't know when the page was written, so it could be some time soon) and I don't know if it needs to be finalized before the compiler is released.
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
- Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part of an external contribution that happens to use 1.5 because the contributor uses 1.5 in his/her work and doesn't have time to downgrade the code, just so it can be accepted in Lucene. How many external contributions are to the core Lucene? If the core Lucene contribution can be applied and then downgraded to Java 1.4 easily, what harm is in that? OG: I don't know the number, but JIRA would be the place to look. My guess is about a dozen or more people. Steve Rowe found something that can downgrade 1.5 code to 1.4 and looks promising. Otis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. I am using the Java 5 compiler to build a 1.4 compatible binary. So I get the compiler improvements for all my users. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. It's not up to me. Each user of BibleDesktop has to decide for themselves. Users of MacOS 10.3 and earlier are stuck using Java 1.4. Users that have upgraded to Java 5 get the advantages of that runtime. As for me I am running Java 5. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part of an external contribution that happens to use 1.5 because the contributor uses 1.5 in his/her work and doesn't have time to downgrade the code, just so it can be accepted in Lucene. That's the core argument that you are making and it is a good one. If it could be designated in Jira whether the attachment were Java 5 then others (perhaps myself) could take the patch, downgrade it and attach it to the same issue. It sure would beat forking the project. How many external contributions are to the core Lucene? If the core Lucene contribution can be applied and then downgraded to Java 1.4 easily, what harm is in that? OG: I don't know the number, but JIRA would be the place to look. My guess is about a dozen or more people. Steve Rowe found something that can downgrade 1.5 code to 1.4 and looks promising. If so then perhaps the committers could run the code through it after applying the patch. Then the contributers would not be adversely affected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I don't follow... If a user came to you and said I want to run BibleDesktop, and they have MS-DOS, you would tell them you can't (or you might have to run the very old BibleDesktop 1.0). If they told you they have Windows 98 with Java 1.4 and 256mb or memory, you would say you can run BibleDesktop 2.0 (which includes Lucene 2.0). If they told you they have Windows XP with Java 1.5, you would say you can run BibleDesktop 3.0 (which includes Lucene 2.1). Certainly seems like a packaging/marketing issue for you. Your users would not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor would they care. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:17 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend on replies, so I'll use OG for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. I am using the Java 5 compiler to build a 1.4 compatible binary. So I get the compiler improvements for all my users. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. It's not up to me. Each user of BibleDesktop has to decide for themselves. Users of MacOS 10.3 and earlier are stuck using Java 1.4. Users that have upgraded to Java 5 get the advantages of that runtime. As for me I am running Java 5. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part of an external contribution that happens to use 1.5 because the contributor uses 1.5 in his/her work and doesn't have time to downgrade the code, just so it can be accepted in Lucene. That's the core argument that you are making and it is a good one. If it could be designated in Jira whether the attachment were Java 5 then others (perhaps myself) could take the patch, downgrade it and attach it to the same issue. It sure would beat forking the project. How many external contributions are to the core Lucene? If the core Lucene contribution can be applied and then downgraded to Java 1.4 easily, what harm is in that? OG: I don't know the number, but JIRA would be the place to look. My guess is about a dozen or more people. Steve Rowe found something that can downgrade 1.5 code to 1.4 and looks promising. If so then perhaps the committers could run the code through it after applying the patch. Then the contributers would not be adversely affected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Installing Java requires about 2 mouse clicks from java.sun.com. Installing Java from your distribution CD (if you don't have one) requires no mouse clicks. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:24 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:21 PM, Yonik Seeley wrote: On 6/20/06, DM Smith [EMAIL PROTECTED] wrote: In any case, there is still GCJ too. If GCJ supported 1.5, and we could make a 1.4 library with Retrotranslator, that should cover most users, right? If I am not mistaken: future support for 1.5 in gcj is ambiguous and/or will be incomplete. You don't use GCJ right? Correct. We couldn't because of our use of Swing. It appears that it is sufficiently far along that it is worth trying again. The problem we have is trying to explain to users how to install java in order to get our application to work. If we could redistribute java as a seamless part of our application we would. We are planning to migrate from Swing to Eclipse's RCP/JFace/SWT and then we can and would use GCJ. If Lucene goes to Java 5, we will need to re-examine those plans. GCJ is currently incomplete, and needs patches to get it to work with lucene (and lucene committers have accepted patches to ease this porting in the past). GCJ support in Lucene isn't as much for the end-user IMO, but for developers who maintain other Lucene ports. Time will tell how good the Java5 support is for GCJ. Hopefully less time rather than more ;-) -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Tue, 20 Jun 2006, DM Smith wrote: We are planning to migrate from Swing to Eclipse's RCP/JFace/SWT and then we can and would use GCJ. If Lucene goes to Java 5, we will need to re-examine those plans. If you are planning to compile Java Lucene with gcj you may want to take a look at the tricks and patches used in the PyLucene project where this is done. - apply these patches: http://svn.osafoundation.org/pylucene/trunk/patches.lucene - use ant and javac to compile from .java to .jar - use gcj to compile from .jar to .o Which version of gcj to use depends on your constraints and your platform. I use gcj 4.0.2 (patched) on Intel Mac OS X, gcj 3.4.5 on PPC Mac OS X, gcj 3.4.6 on Ubuntu 6.06 Linux. I've been able to also use gcj 4.1.0 on PPC Mac OS X, but the same didn't work on Ubuntu 6.06. As for Java 1.5 support, the ecj integration seems to be going well. This very recent post should prove interesting: http://gcc.gnu.org/ml/java/2006-06/msg00146.html Still, there is no date promises attached here and a full gcj release cycle can be quite long. And then, usually, it takes a (long) while for a new gcj platform to be stable and usable on platforms other than Red Hat Linux. (See the version details I wrote about above). GCJ is currently incomplete, and needs patches to get it to work with lucene (and lucene committers have accepted patches to ease this porting in the past). GCJ support in Lucene isn't as much for the end-user IMO, but for developers who maintain other Lucene ports. libgcj, mostly based on the classpath project is indeed incomplete but is actively being working on and is complete enough to cover Java Lucene (of course your app may have needs beyond that). I've only had to patch in regex support in libgcj 3.4.x so far. Andi.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Finding good SWT support on anything but the latest (and major) OS's is going to be rather poor and inconsistent. Just check the SWT bugs (especially for things like printing). For a company that seems to want to allow their users to stay in the dark ages - good luck with SWT. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:24 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:21 PM, Yonik Seeley wrote: On 6/20/06, DM Smith [EMAIL PROTECTED] wrote: In any case, there is still GCJ too. If GCJ supported 1.5, and we could make a 1.4 library with Retrotranslator, that should cover most users, right? If I am not mistaken: future support for 1.5 in gcj is ambiguous and/or will be incomplete. You don't use GCJ right? Correct. We couldn't because of our use of Swing. It appears that it is sufficiently far along that it is worth trying again. The problem we have is trying to explain to users how to install java in order to get our application to work. If we could redistribute java as a seamless part of our application we would. We are planning to migrate from Swing to Eclipse's RCP/JFace/SWT and then we can and would use GCJ. If Lucene goes to Java 5, we will need to re-examine those plans. GCJ is currently incomplete, and needs patches to get it to work with lucene (and lucene committers have accepted patches to ease this porting in the past). GCJ support in Lucene isn't as much for the end-user IMO, but for developers who maintain other Lucene ports. Time will tell how good the Java5 support is for GCJ. Hopefully less time rather than more ;-) -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, DM Smith [EMAIL PROTECTED] wrote: The problem we have is trying to explain to users how to install java in order to get our application to work. Ahh... if you didn't already have a large code base, I'd suggest trying PyLucene in conjunction with freeze (which can make a python program into a standalone executable). Some kind of native-code thing does seem ideal for wide distribution to non-technical end users. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Any specific reason why PorterStemmer class in org.apache.lucene.analysis is not made public? Thank you, Best Regards, Bhoomi Mehta Sr. Project Leader I- Link Infosoft (G) Pvt . Ltd. Ahmedabad Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/17/06, Chuck Williams [EMAIL PROTECTED] wrote: Ray Tsang wrote on 06/17/2006 06:29 AM: I think the problem right now isn't whether we are going to have 1.5 code or not. We will eventually have to have 1.5 code anyways. But we need a sound plan that will make the transition easy. I believe the transition from 1.4 to 1.5 is not an over night thing. I disagree. 1.5 was specifically designed to make transition easy, including the inclusion of non-features that ensure smooth interoperability (e.g., raw types and no runtime presence whatsoever of generics -- quite different from how it was done in .Net 2.0 for example). But will 1.4 jvm be able to run the new Lucene w/ 1.5 core? Secondly can we specifically find places where some people _will_ contribute code immediately if it's 1.5 is accepted? I already have. That's what started this second round of debate. What is it? Who else? How many? Do we have statistics? We have statistics of number of users between 1.4 vs. 1.5 (which btw didn't present a significant polarization), but how about actual numbers potential of contributions between the 2? Like what I have suggested before, why not have contribution modules that act as a transition into 1.5 code? Much like what other framework has a tiger module. This module may have say, a 1.5 compatible layer on top of 1.4 core, or other components of lucene that was made to be extensible, e.g. 1.5 version of QueryParser, Directory, etc. I think this would make it unnecessarily complex. How is it unnecessary or complex? If it only means layering, extending classes, adding implementations, it should be relatively easy with the existing design. It's something we do everyday regardless what lucene's direction takes. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Lastly, how did the commercial application people who use Lucene in their product respond? ray, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Ray Tsang wrote: We have statistics of number of users between 1.4 vs. 1.5 (which btw didn't present a significant polarization) Does 63% for 1.5, a nearly 2:1 ratio, really represent an insignificant polarization? (As of this writing, 88/140 reported using 1.5). but how about actual numbers potential of contributions between the 2? Good point -- the survey was announced on the java-user list. Is it not safe to assume that all contributors are subscribed to the java-dev list? The contribution guide http://wiki.apache.org/jakarta-lucene/HowToContribute says to subscribe to java-dev as the first step after getting the source. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Ray Tsang wrote on 06/19/2006 09:06 AM: On 6/17/06, Chuck Williams [EMAIL PROTECTED] wrote: Ray Tsang wrote on 06/17/2006 06:29 AM: I think the problem right now isn't whether we are going to have 1.5 code or not. We will eventually have to have 1.5 code anyways. But we need a sound plan that will make the transition easy. I believe the transition from 1.4 to 1.5 is not an over night thing. I disagree. 1.5 was specifically designed to make transition easy, including the inclusion of non-features that ensure smooth interoperability (e.g., raw types and no runtime presence whatsoever of generics -- quite different from how it was done in .Net 2.0 for example). But will 1.4 jvm be able to run the new Lucene w/ 1.5 core? If 1.5 features are fully embraced, no. Secondly can we specifically find places where some people _will_ contribute code immediately if it's 1.5 is accepted? I already have. That's what started this second round of debate. What is it? ParallelWriter (see LUCENE-600). I have quite a few more behind that. Whether or not various people will find them useful is tbd, but they are all working well for me and essential to meet my requirements, and some are for things often requested on the various lists (e.g., a general purpose fast bulk index updater that supports arbitrary transformations on the values of fields). Who else? How many? Do we have statistics? We have statistics of number of users between 1.4 vs. 1.5 (which btw didn't present a significant polarization), but how about actual numbers potential of contributions between the 2? There has been a proposal to poll java-dev for this. Wagers on the outcome? Like what I have suggested before, why not have contribution modules that act as a transition into 1.5 code? Much like what other framework has a tiger module. This module may have say, a 1.5 compatible layer on top of 1.4 core, or other components of lucene that was made to be extensible, e.g. 1.5 version of QueryParser, Directory, etc. I think this would make it unnecessarily complex. How is it unnecessary or complex? If it only means layering, extending classes, adding implementations, it should be relatively easy with the existing design. It's something we do everyday regardless what lucene's direction takes. Contributing to Lucene is a volunteer effort. The more difficult you make it, the fewer people will do it. That's what this is all about. Accept 1.5 contributions and I believe you will get more high quality contributions. Of course, this comes at a high cost for those who cannot transition to 1.5, since they would need to stick with Lucene 2.0.x. If I had a vote on this, honestly I'm not sure how I would vote. It's a tough call either way. Do you support a significant minority of users and contributors who are stuck on an old java platform, or do you strike forward with a more robust contributing community from the majority at the cost of cutting out the minority from the latest and greatest? My first comment on this topic was something like, why would somebody who is on an old java platform expect to have the latest and greatest lucene?. I think if I was stuck on 1.4, I wouldn't be happy about a 1.5 decision for lucene 2.1+, but I would understand it, accept it, and do whatever I could to speed my transition to 1.5. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/19/06, Steven Rowe [EMAIL PROTECTED] wrote: Ray Tsang wrote: We have statistics of number of users between 1.4 vs. 1.5 (which btw didn't present a significant polarization) Does 63% for 1.5, a nearly 2:1 ratio, really represent an insignificant polarization? (As of this writing, 88/140 reported using 1.5). What about the rest of the 52 ppl? it's not like thare are only 10 people are going to be left behind. but how about actual numbers potential of contributions between the 2? Good point -- the survey was announced on the java-user list. Is it not safe to assume that all contributors are subscribed to the java-dev list? The contribution guide http://wiki.apache.org/jakarta-lucene/HowToContribute says to subscribe to java-dev as the first step after getting the source. uhm? Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/19/06, Chuck Williams [EMAIL PROTECTED] wrote: Ray Tsang wrote on 06/19/2006 09:06 AM: On 6/17/06, Chuck Williams [EMAIL PROTECTED] wrote: Ray Tsang wrote on 06/17/2006 06:29 AM: I think the problem right now isn't whether we are going to have 1.5 code or not. We will eventually have to have 1.5 code anyways. But we need a sound plan that will make the transition easy. I believe the transition from 1.4 to 1.5 is not an over night thing. I disagree. 1.5 was specifically designed to make transition easy, including the inclusion of non-features that ensure smooth interoperability (e.g., raw types and no runtime presence whatsoever of generics -- quite different from how it was done in .Net 2.0 for example). But will 1.4 jvm be able to run the new Lucene w/ 1.5 core? If 1.5 features are fully embraced, no. Secondly can we specifically find places where some people _will_ contribute code immediately if it's 1.5 is accepted? I already have. That's what started this second round of debate. What is it? ParallelWriter (see LUCENE-600). I have quite a few more behind that. Whether or not various people will find them useful is tbd, but they are all working well for me and essential to meet my requirements, and some are for things often requested on the various lists (e.g., a general purpose fast bulk index updater that supports arbitrary transformations on the values of fields). That sounds great actually! Would you say it does not necessarily need to go into the core? I would use something like that though. Who else? How many? Do we have statistics? We have statistics of number of users between 1.4 vs. 1.5 (which btw didn't present a significant polarization), but how about actual numbers potential of contributions between the 2? There has been a proposal to poll java-dev for this. Wagers on the outcome? Like what I have suggested before, why not have contribution modules that act as a transition into 1.5 code? Much like what other framework has a tiger module. This module may have say, a 1.5 compatible layer on top of 1.4 core, or other components of lucene that was made to be extensible, e.g. 1.5 version of QueryParser, Directory, etc. I think this would make it unnecessarily complex. How is it unnecessary or complex? If it only means layering, extending classes, adding implementations, it should be relatively easy with the existing design. It's something we do everyday regardless what lucene's direction takes. Contributing to Lucene is a volunteer effort. The more difficult you make it, the fewer people will do it. That's what this is all about. Accept 1.5 contributions and I believe you will get more high quality contributions. Of course, this comes at a high cost for those who cannot transition to 1.5, since they would need to stick with Lucene 2.0.x. Don't get me wrong. My point is _not_ not to accept 1.5 code. By all means we should accept it. But it'll be better if there is a simple way to accept it while at least majority of lucene-core.jar is compatible w/ 1.4 at bytecode level, while, say, lucene-tiger.jar are add ons for full 1.5 specific code that will not be bytecode compatible with 1.4? If I had a vote on this, honestly I'm not sure how I would vote. It's a tough call either way. Do you support a significant minority of users and contributors who are stuck on an old java platform, or do you strike forward with a more robust contributing community from the majority at the cost of cutting out the minority from the latest and greatest? My first comment on this topic was something like, why would somebody who is on an old java platform expect to have the latest and greatest lucene?. I think if I was stuck on 1.4, I wouldn't be happy about a 1.5 decision for lucene 2.1+, but I would understand it, accept it, and do whatever I could to speed my transition to 1.5. I would agree, but i'm sure there can be compromises. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Why not just make 2.1 use 1.5, and if there are enough 1.4 people they can back-port the changes into 2.0 using JDK 1.4 only code? If they decide it is too much work, they can move forward to JDK 1.5, stick with Lucene 2.0 release X, or find another search project. Although I agree with Doug that Lucene is a library and there are different factors that control the dependencies, JDK 1.5 is also no where near bleeding edge, with several years of stable deployment on many platforms, and no one is stating that Lucene will not work on those platforms, just not Lucene 2.1. It is like trying to support COM on MS-DOS - it just didn't happen (as far as I know). It was possible, but just wasn't worth the effort. If Lucene 2.1 encourages other companies that provide JREs to move to support 1.5 that is even better. -Original Message- From: Ray Tsang [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 11:06 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On 6/17/06, Chuck Williams [EMAIL PROTECTED] wrote: Ray Tsang wrote on 06/17/2006 06:29 AM: I think the problem right now isn't whether we are going to have 1.5 code or not. We will eventually have to have 1.5 code anyways. But we need a sound plan that will make the transition easy. I believe the transition from 1.4 to 1.5 is not an over night thing. I disagree. 1.5 was specifically designed to make transition easy, including the inclusion of non-features that ensure smooth interoperability (e.g., raw types and no runtime presence whatsoever of generics -- quite different from how it was done in .Net 2.0 for example). But will 1.4 jvm be able to run the new Lucene w/ 1.5 core? Secondly can we specifically find places where some people _will_ contribute code immediately if it's 1.5 is accepted? I already have. That's what started this second round of debate. What is it? Who else? How many? Do we have statistics? We have statistics of number of users between 1.4 vs. 1.5 (which btw didn't present a significant polarization), but how about actual numbers potential of contributions between the 2? Like what I have suggested before, why not have contribution modules that act as a transition into 1.5 code? Much like what other framework has a tiger module. This module may have say, a 1.5 compatible layer on top of 1.4 core, or other components of lucene that was made to be extensible, e.g. 1.5 version of QueryParser, Directory, etc. I think this would make it unnecessarily complex. How is it unnecessary or complex? If it only means layering, extending classes, adding implementations, it should be relatively easy with the existing design. It's something we do everyday regardless what lucene's direction takes. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Lastly, how did the commercial application people who use Lucene in their product respond? ray, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/19/06, Robert Engels [EMAIL PROTECTED] wrote: Why not just make 2.1 use 1.5, and if there are enough 1.4 people they can back-port the changes into 2.0 using JDK 1.4 only code? If they decide it is too much work, they can move forward to JDK 1.5, stick with Lucene 2.0 release X, or find another search project. I like this idea also. However it will introduce a new branch (think Linux). But it can definiltey work. And I assume that eventually when the 1.4 supporters move on to 1.5, the 1.4 branch will die off naturally. Although I agree with Doug that Lucene is a library and there are different factors that control the dependencies, JDK 1.5 is also no where near bleeding edge, with several years of stable deployment on many platforms, and no one is stating that Lucene will not work on those platforms, just not Lucene 2.1. It is like trying to support COM on MS-DOS - it just didn't happen (as far as I know). It was possible, but just wasn't worth the effort. If Lucene 2.1 encourages other companies that provide JREs to move to support 1.5 that is even better. -Original Message- From: Ray Tsang [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 11:06 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On 6/17/06, Chuck Williams [EMAIL PROTECTED] wrote: Ray Tsang wrote on 06/17/2006 06:29 AM: I think the problem right now isn't whether we are going to have 1.5 code or not. We will eventually have to have 1.5 code anyways. But we need a sound plan that will make the transition easy. I believe the transition from 1.4 to 1.5 is not an over night thing. I disagree. 1.5 was specifically designed to make transition easy, including the inclusion of non-features that ensure smooth interoperability (e.g., raw types and no runtime presence whatsoever of generics -- quite different from how it was done in .Net 2.0 for example). But will 1.4 jvm be able to run the new Lucene w/ 1.5 core? Secondly can we specifically find places where some people _will_ contribute code immediately if it's 1.5 is accepted? I already have. That's what started this second round of debate. What is it? Who else? How many? Do we have statistics? We have statistics of number of users between 1.4 vs. 1.5 (which btw didn't present a significant polarization), but how about actual numbers potential of contributions between the 2? Like what I have suggested before, why not have contribution modules that act as a transition into 1.5 code? Much like what other framework has a tiger module. This module may have say, a 1.5 compatible layer on top of 1.4 core, or other components of lucene that was made to be extensible, e.g. 1.5 version of QueryParser, Directory, etc. I think this would make it unnecessarily complex. How is it unnecessary or complex? If it only means layering, extending classes, adding implementations, it should be relatively easy with the existing design. It's something we do everyday regardless what lucene's direction takes. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Lastly, how did the commercial application people who use Lucene in their product respond? ray, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Ray Tsang wrote on 06/19/2006 09:06 AM: Don't get me wrong. My point is _not_ not to accept 1.5 code. By all means we should accept it. But it'll be better if there is a simple way to accept it while at least majority of lucene-core.jar is compatible w/ 1.4 at bytecode level, while, say, lucene-tiger.jar are add ons for full 1.5 specific code that will not be bytecode compatible with 1.4? I don't know of an easy way to do this. We can branch, but there is really no need for an additional branch - we already have the branch for 2.0.* and you can think of that as the 1.4 branch. The question here is whether we can treat the trunk as the 1.5 is OK here branch. So far we have a more than 2:1 ratio in favour of 1.5, not counting those who say they will move to 1.5 in the near future (1-12 months). Counting those we currently have a 100:43 ratio going got 1.5, and this includes people from Kamchatka, too. One point that I feel keeps getting ignored is that we are talking about the _future_ releases. My guess is that we won't see a major new Lucene release before 2007, and by that time the latest JVM will probably be 1.6. Otis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I don't think this should be dismissed as a non-argument. You want to live on the edge of Lucene, but at the same time don't want to (probably can't, I know) use the current JVM that's been out for a long time now (a year or more, I think, didn't check). You can look at the but I want the latest Lucene argument the other way around, too - I'd hate to lose contributions with 1.5 code because it suits the minority to stay with 1.4. I think Chuck's suggestion was the best one so far: - allow 1.5 in trunk - those who want/need 1.4 can back-port it That way we don't reject 1.5 contributions, and those who need 1.4 can scratch their itch by back-porting. I doubt we'll get (m)any contributors to rewrite their code to work with 1.4 JVM if they aready used 1.5 stuff, even if it's just syntactic sugar. Oh, and maybe we could say that 1.5 is okay only for new features, while any bug fix should remain 1.4 compatible, so that patches can be applied to the 2.0.* branch. Otis - Original Message From: markharw00d [EMAIL PROTECTED] To: java-dev@lucene.apache.org Sent: Monday, June 19, 2006 4:40:57 PM Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) One point that I feel keeps getting ignored is that we are talking about the _future_ releases. My guess is that we won't see a major new Lucene release before 2007, and by that time the latest JVM will probably be 1.6. I think that's a non-argument as it is common practice for people to work with the latest trunk version and in practice we have often recommended users to do so (a credit to the stability of the code and quality of commits). e.g. Erik's post from http://www.gossamer-threads.com/lists/lucene/java-user/30227?search_string=production%20stable;#30227 The only difference between Subversion trunk and a released version is the time and effort someone has taken to build it, package it, sign it, and upload it (and of course a consensus vote authorizing it). While I know that many environments demand that such blessing has occurred, I cannot say that I altogether understand it. I much prefer, personally, to be on the trunk and know that any issues I do happen to encounter can be easily reported, likely fixed if identified specifically enough, fixed, and integrated back into my projects right away. This decision is therefore not just one that will effect users in 2007 but more likely as soon as we decide a 1.5 commit takes place. Cheers, Mark ___ All new Yahoo! Mail The new Interface is stunning in its simplicity and ease of use. - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think Chuck's suggestion was the best one so far: - allow 1.5 in trunk - those who want/need 1.4 can back-port it Hmmm, seems a lot like just kissing off 1.4 users. Just-an-interested-bystander-here, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I am getting really tired of the tone by some of comments. Nothing that is being proposed here is ANY DIFFERENT than any other software package or library. As software progresses the requirements change - whether it is hardware needed, or software needed. No one is kissing off 1.4 users - 1.4 users can ALWAYS use version 2.0.X. No one stated that bug fixes would not be back-ported to 2.0.X, so where is the kiss off??? And if the 1.4 community really wants a feature from 2.1 THEY can back-port it. People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. -Original Message- From: Bill Janssen [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 7:23 PM To: java-dev@lucene.apache.org; Otis Gospodnetic Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I think Chuck's suggestion was the best one so far: - allow 1.5 in trunk - those who want/need 1.4 can back-port it Hmmm, seems a lot like just kissing off 1.4 users. Just-an-interested-bystander-here, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think my comment is being taken in a way that was not totally intended. The lazy refers to the ability/desire of the 1.4 users developers to devote their resources to back-porting the code to the 2.0.X release. Rather than having the 1.5 developers having to waste their time thinking in 1.4 when their work is predominately being performed using 1.5 features/compilers/tools. There is NOTHING stopping the 1.4 community from doing this, except their laziness in wanting to (especially given their common assessment that 1.5 is nothing more than syntactic sugar). The ill-informed refers to the 1.4 community's inability to grasp that they can continue to use the 2.0.X code base, and their lack of understanding that for the code base to continue to improve, Lucene needs access to the best developers and those with the most time to offer - not make them jump through hoops by using a JDK that is being close to 2 major releases old. Maybe selfish would have been a better choice. The argument of not being able to move to 1.5 seems to hold little water. If the users can't upgrade their OS, or hardware, etc. then they are most likely in a fairly stagnant state anyway - why would they want to keep updating their software? It is easily conceivable that given inexpensive RAM, abundant disk space, and/or CPU performance that a future version of Lucene might use completely different persistence scheme (e.g. no compression, load the tables completely into memory, etc.) that older machines cannot possibly work with. Should Lucene be left behind because there are some users that can't operate in that environment? NO. Let them stick with what has been working for them, and let Lucene move forward. You make reference to the apache libraries. I know that if I had to work on a actively developed code set that used the apache commons collections - rather than the JDK Collections - I'd go nuts - and I'm sure many (most?) developers would feel the same. Why the 1.4 Lucene community fails to understand this I don't know. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 10:47 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) Just got back from a long weekend vacation without any net access. Talk about withdrawal:) I have just gotten through reading this entire thread... Whew. On Jun 19, 2006, at 8:48 PM, Robert Engels wrote: People making these arguments against 1.5 sound really ill- informed, or lazy. Neither of which is good for open-source development. Ouch. I'm not sure which I am: Is it ill-informed or lazy? I lurk here to see what is being developed and am impressed with the care and the thoughtfulness that goes into the code. I'm probably better served by joining the user's mailing list, but I find this more educational. So, my comment is that of a user. I'll repeat myself. I am a contributor to the open source project, BibleDesktop, which allows a user to search Bibles using boolean logic. We have settled on Java 1.4 because all of our user community has Java 1.4 available. Our user community consists of people and groups that use hand me down hardware, that was past due when they got it. Most of these users are not computer literate, but use their computer as a tool to do their work. So even if their hardware could be upgraded to a newer OS, it it not likely. (The vast majority of our user base uses Windows 98, but a few use MacOS 9!) When will we stop supporting Win98 and MacOS 9? When our users no longer use it. (No a lone hold out won't stop progress... And yes Win98 runs Java 1.5 just fine! But if it weren't for those reliable Mac machines, we might not have to stay with Java 1.4!) We use quite a few apache and jakarta libraries and we upgrade to the latest and greatest as soon as we can. So far, there have been no Java 5.0 libraries and the new libraries have not provided any stability/performance problems. Can I stick with 2.0.x? Certainly. However, I'd rather not. I keep reading about refactoring providing a significant, incremental improvement, and I'd like to provide that, especially for those older machines! Can Lucene's going to Java 1.5 change/influence a migration of BibleDesktop to Java 1.5. Nope. The only thing that can influence that is business decisions So, which is it: Ill-informed or lazy? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Robert Engels wrote: Do you have any hard numbers to support this? The last time I checked, gcj had minimal improvement over JVM 1.5. In terms of speed, there is not much difference between native code and classes (see sample timings). However, the pragmatic availability of java 5 environment for even somewhat _exotic_ platforms is sadly limited. My current environment is linux on a dual core x86_64. One can only ride a jrocket into 1.5 land and still address 64 bits of goodness ! more, l8r, v BTW, given a native compile and link, [EMAIL PROTECTED] lucene-415145]$ ldd build/indexFiles libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x003f0040) libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x003efec0) libgcj.so.7 = /usr/lib64/libgcj.so.7 (0x2aac2000) libm.so.6 = /lib64/libm.so.6 (0x003ef910) libpthread.so.0 = /lib64/libpthread.so.0 (0x003efa50) libz.so.1 = /usr/lib64/libz.so.1 (0x003ef950) libdl.so.2 = /lib64/libdl.so.2 (0x003ef930) libc.so.6 = /lib64/libc.so.6 (0x003ef8e0) /lib64/ld-linux-x86-64.so.2 (0x003ef8c0) The native indexing, [EMAIL PROTECTED] lucene-415145]$ time build/indexFiles . 21 /dev/null real0m22.932s user0m16.581s sys 0m6.224s The virtual machine indexing, [EMAIL PROTECTED] lucene-415145]$ time java -d64 -Xmx8192m -cp build/lucene-demos-2.0-rc1-dev.jar:build/lucene-core-2.0-rc1-dev.jar org.apache.lucene.demo.IndexFiles . 21 /dev/null real0m23.224s user0m33.238s sys 0m5.184s Side note, the jrocket seems to use both processors just about 1/3 of the way through, where as the gcj doesn't . . . -- The future is here. It's just not evenly distributed yet. -- William Gibson, quoted by Whitfield Diffie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Are you sure about the JVM numbers? I would think that user + sys must always be real (unless maybe the multiprocessor affects this - i.e. sums the processor time used on each). -Original Message- From: Vic Bancroft [mailto:[EMAIL PROTECTED] Sent: Sunday, June 18, 2006 11:55 AM To: [EMAIL PROTECTED] Cc: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) Robert Engels wrote: Do you have any hard numbers to support this? The last time I checked, gcj had minimal improvement over JVM 1.5. In terms of speed, there is not much difference between native code and classes (see sample timings). However, the pragmatic availability of java 5 environment for even somewhat _exotic_ platforms is sadly limited. My current environment is linux on a dual core x86_64. One can only ride a jrocket into 1.5 land and still address 64 bits of goodness ! more, l8r, v BTW, given a native compile and link, [EMAIL PROTECTED] lucene-415145]$ ldd build/indexFiles libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x003f0040) libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x003efec0) libgcj.so.7 = /usr/lib64/libgcj.so.7 (0x2aac2000) libm.so.6 = /lib64/libm.so.6 (0x003ef910) libpthread.so.0 = /lib64/libpthread.so.0 (0x003efa50) libz.so.1 = /usr/lib64/libz.so.1 (0x003ef950) libdl.so.2 = /lib64/libdl.so.2 (0x003ef930) libc.so.6 = /lib64/libc.so.6 (0x003ef8e0) /lib64/ld-linux-x86-64.so.2 (0x003ef8c0) The native indexing, [EMAIL PROTECTED] lucene-415145]$ time build/indexFiles . 21 /dev/null real0m22.932s user0m16.581s sys 0m6.224s The virtual machine indexing, [EMAIL PROTECTED] lucene-415145]$ time java -d64 -Xmx8192m -cp build/lucene-demos-2.0-rc1-dev.jar:build/lucene-core-2.0-rc1-dev.jar org.apache.lucene.demo.IndexFiles . 21 /dev/null real0m23.224s user0m33.238s sys 0m5.184s Side note, the jrocket seems to use both processors just about 1/3 of the way through, where as the gcj doesn't . . . -- The future is here. It's just not evenly distributed yet. -- William Gibson, quoted by Whitfield Diffie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Saturday 17 June 2006 01:33, markharw00d wrote: That's a long-winded way of saying -1 unless I hear of any arguments which are based on something much more substantial than 1.5 makes coding easier. As for coding convenience from 1.4: last time I had a look there was not a single assert statement in the core code, so I don't think coding convenience is a good argument to move to 1.5 already now. Regards, Paul Elschot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Until there is a free java 5 alternative, it would be nice to have a clean compile in 1.4. We might also consider waiting until gcj does the 1.5 move, since some of us are loving the native binaries, particularly on x86_64. How else can you index billions of documents (aside from expensive big blue boxes) . . . more, l8r, v -- The future is here. It's just not evenly distributed yet. -- William Gibson, quoted by Whitfield Diffie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think the problem right now isn't whether we are going to have 1.5 code or not. We will eventually have to have 1.5 code anyways. But we need a sound plan that will make the transition easy. I believe the transition from 1.4 to 1.5 is not an over night thing. Secondly can we specifically find places where some people _will_ contribute code immediately if it's 1.5 is accepted? Like what I have suggested before, why not have contribution modules that act as a transition into 1.5 code? Much like what other framework has a tiger module. This module may have say, a 1.5 compatible layer on top of 1.4 core, or other components of lucene that was made to be extensible, e.g. 1.5 version of QueryParser, Directory, etc. ray, On 6/17/06, Paul Elschot [EMAIL PROTECTED] wrote: On Saturday 17 June 2006 01:33, markharw00d wrote: That's a long-winded way of saying -1 unless I hear of any arguments which are based on something much more substantial than 1.5 makes coding easier. As for coding convenience from 1.4: last time I had a look there was not a single assert statement in the core code, so I don't think coding convenience is a good argument to move to 1.5 already now. Regards, Paul Elschot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
--- Robert Engels [EMAIL PROTECTED] wrote: I think you should port Lucene to MS-DOS... If your app can't move beyond MS-DOS, then you stick with version 1.9 (or 2.0 in this case). If you can't innovate and move forward, you die. Java has a GREAT history of supporting prior versions. At some point though you need to be able to move forward since developers may not be trained in the legacy environment. While this is true, I thinks that comparisons of Lucene to, say, MS-DOS are at best a knee-jerk comments, or otherwise imply some lack of perspective and common sense (probably former though). Lucene has moved away from JDK 1.1 support, and at this point 1.4 is probably the baseline. This has happened over time, as platform has advanced. And it's bit curious as to what the current mad rush regarding migration is -- beyond the convenience and syntactic sugar, only the concurrency package seems like a tempting immediate reason? Now, I think Doug had best points regarding inertia that low-level libraries and components should consider. Apps are first to move to newest versions; top-level libraries then, and finally fundamental components and engines. I would think Lucene falls into this category: it has few dependencies of its own, but has tons of downstream dependencies. I don't know if this has suggested yet, but how about switching to 1.5, when Sun declares 1.6 to be the official stable JDK (ie. when it comes out of its beta status)? Anyway, it obviously comes down to the active committers to decide the time/version for the cut-off. But I hope it can be a practical decision made with cool minds. -+ Tatu +- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Tatu Saloranta wrote on 06/17/2006 06:54 AM: And it's bit curious as to what the current mad rush regarding migration is -- beyond the convenience and syntactic sugar, only the concurrency package seems like a tempting immediate reason? The only people who keep bringing up these non-arguments are those on the con side. You should read the arguments on the pro side -- they are not these. I hope it can be a practical decision made with cool minds. Agreed. I think a key part of this is to listen to what the other side is saying. This all boils down to people and the environments they use. People using 1.4 want the latest and greatest Lucene and don't understand why it's important to use 1.5 anyway. People using 1.5 are writing 1.5 code everyday and want to be able to make contributions to Lucene without backporting and retesting. Also, they don't want to consciously write code that might be a Lucene contribution in 1.4 because a) the cognitive shift back to 1.4 is not easy once you are fully indoctrinated into 1.5 (primarily generics), and b) 1.4 code is not type-safe in the sense that 1.5 code is. So, do 1.4 people live with Lucene 2.0.x until they move to 1.5, or do 1.5 people get limited or cut out from making contributions. Neither option is appealing, especially to those negative affected. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Chuck, you nailed it! This reverse view is really what brings clarity, at least to me. It boils down to the question Who is loosing what? Move to 1.5: some people will not have an oportunity to use new cool features that will come in 2.x versions. So they know the feeling, they cannot use cool new features of java 1.5 as well. Stay by 1.4: Lucene will progress slower than in other case, so people that are allready using 1.5 will not benefit from Lucene progress as fast. As far as I can tell, from pure selfish perspective, moving to 1.5 would be preffered option. Trying to be objective here, gut feeling is to say also move to 1.5 as Lucene will move forward faster, which kind of brings benefits to both sides as there is tomorrow. Pople that created this great thing called Lucene should decide. I am sure whichever decision is made, it will not be premature or without considering the needs of the other side. cheers - Original Message From: Chuck Williams [EMAIL PROTECTED] To: java-dev@lucene.apache.org Sent: Saturday, 17 June, 2006 9:46:23 PM Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) Tatu Saloranta wrote on 06/17/2006 06:54 AM: And it's bit curious as to what the current mad rush regarding migration is -- beyond the convenience and syntactic sugar, only the concurrency package seems like a tempting immediate reason? The only people who keep bringing up these non-arguments are those on the con side. You should read the arguments on the pro side -- they are not these. I hope it can be a practical decision made with cool minds. Agreed. I think a key part of this is to listen to what the other side is saying. This all boils down to people and the environments they use. People using 1.4 want the latest and greatest Lucene and don't understand why it's important to use 1.5 anyway. People using 1.5 are writing 1.5 code everyday and want to be able to make contributions to Lucene without backporting and retesting. Also, they don't want to consciously write code that might be a Lucene contribution in 1.4 because a) the cognitive shift back to 1.4 is not easy once you are fully indoctrinated into 1.5 (primarily generics), and b) 1.4 code is not type-safe in the sense that 1.5 code is. So, do 1.4 people live with Lucene 2.0.x until they move to 1.5, or do 1.5 people get limited or cut out from making contributions. Neither option is appealing, especially to those negative affected. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
It looks like I would have won a beer had anyone wagered me. 1.5 IS the Java version that the majority Lucene users use, not 1.4! Does this mean we can now start accepting 1.5 code? Otis - Original Message From: Otis Gospodnetic [EMAIL PROTECTED] To: java-user@lucene.apache.org Sent: Friday, June 16, 2006 11:48:15 AM Subject: Survey: Lucene and Java 1.4 vs. 1.5 Hello everyone, If you have 15 seconds to spare, please let us (Lucene developers) know which version of Java you are using with Lucene: 1.4 or 1.5 All it takes is 1 click on one of the two choices: http://www.quimble.com/poll/view/2156 No cheating, please. Thanks! Otis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
go tiger go! everybody not using 1.5 should visite java.sun.com downloading the 1.5 vm!! On 6/16/06, Otis Gospodnetic [EMAIL PROTECTED] wrote: It looks like I would have won a beer had anyone wagered me. 1.5 IS the Java version that the majority Lucene users use, not 1.4! Does this mean we can now start accepting 1.5 code? gdata already does ;) Otis - Original Message From: Otis Gospodnetic [EMAIL PROTECTED] To: java-user@lucene.apache.org Sent: Friday, June 16, 2006 11:48:15 AM Subject: Survey: Lucene and Java 1.4 vs. 1.5 Hello everyone, If you have 15 seconds to spare, please let us (Lucene developers) know which version of Java you are using with Lucene: 1.4 or 1.5 All it takes is 1 click on one of the two choices: http://www.quimble.com/poll/view/2156 No cheating, please. Thanks! Otis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
1.5 IS the Java version that the majority Lucene users use, not 1.4! Does this mean we can now start accepting 1.5 code? This isn't simply about which JVM gets used the most wins. This is about how many Lucene users will we inconvenience or lose by moving to 1.5? Right now the survey sample tells me roughly a third which doesn't seem like a good thing. Maybe the question is more usefully who can't/won't move to 1.5 in the immediate future? I believe we shouldn't select the minimum platform based on the coding convenience it may offer us which seems to be the major objective behind 1.5 adoption. When developing a library deployed in many applications/environments over which you have no control and where careful consideration of runtime performance not coding convenience/speed of development is the primary concern my preference would be to choose 1.4. Not all deployment environments can be upgraded easily. Take my current application at work. It's applet-based and rolled out to hundreds of corporate desktops which are stuck on 1.4 (this won't change anytime soon). Lucene isn't on the client but all client and server code in the app has been written in 1.4 to avoid any issues of any 1.5 code leaking onto the 1.4 client. All of the many 3rd party libraries in use (Spring, database drivers etc) are 1.4 compatible in their latest versions. I'd like to stick with the latest Lucene codebase but mandating 1.5 for Lucene would introduce a code management headache to this app with the mixed JVMs Unless there are *really* good runtime benefits that are solely based on 1.5 libraries or source code I would prefer to see Lucene stick with 1.4 as a base rather than limit Lucene's deployment options simply because of code-time benefits the new 1.5 syntax offers. I see that the Spring framework recognise this dilemma and still seek to support as far back as 1.3 (see http://www.springframework.org/node/220). Simon said everyone should download 1.5. It's nice to think you can accelerate the global adoption of 1.5 by changing projects like Lucene but the reality is corporates do not change platforms overnight because of such a change. That's a long-winded way of saying -1 unless I hear of any arguments which are based on something much more substantial than 1.5 makes coding easier. Cheers, Mark ___ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
