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 List<String>, 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?
