Doug Cutting wrote on 05/30/2006 08:51 AM: > Chris Hostetter wrote: >> : Agreed. But, I have not heard one compelling argument for the JDK 5 >> for >> : core. (JVM certainly) >> >> Off the top of my head... >> >> * Generics for cleaner more type safe APIs >> * Varargs for cleaner APIs >> * Concurrency Libraries, in particular the new j.u.concurrent.locks >> package * One user earlier in this thread reported a 40% performance improvement * My argument about contributions from the community to the core (patches). Most community members appear to be on 1.5. Once you've coded in 1.5, 1.4 seems arcane. Lucene will get more user contributions if 1.5 code can be in the core. * Extended for loops for more readable code
Also, I'd like to add that the arguments against mixing 1.4 and 1.5 code in the kernel are not valid. 1.5 was specifically designed to be interoperable with 1.4 even where this came at the expense of 1.5 features (e.g., support unsafe raw types). 1.4 and 1.5 code mix with no real issues. > > The key word was "compelling". What compells one may not compell > another. Sure, these are improvements, but that does not compell us > to use them. We may *elect* to start using them, that the pain they > make by leaving some folks behind who'd like to stay with the latest > Lucene features is outweighed by the pleasure they bring to folks > constructing new features for Lucene. Again, that's neither an easy > nor an obvious calculation. I still don't understand why environments that are years behind in java and most other apps should expect to be on the latest and greatest lucene. > > Technically this will be decided by a lazy consensus of committers, > with other members of the community also eligble to cast non-binding > votes. > The most concrete plan to date is Hoss's: > > > 1a) Lucene Core 2.0.* releases garuntee java1.4 compatibility > > 1b) Lucene Contrib modules in 2.0.* releases are free to require any > java > > version they choose. > > > > 2a) Lucene Core 2.1.* release garuntee java1.5 compatibility. > > 2b) Lucene Contrib modules in 2.1.* releases are free to require any > java > > version they choose. Consider this my non-binding +1 for Hoss's plan > > Since we don't know the timeframe of these releases, it's hard to be > sure what this really means. The rubber will really only hit the road > when we schedule a 2.1 release. In effect, this punts the issue to > 2.1 release planning, which is fine by me. Doesn't it hit the road now? Presumably 2.0 should be branched at this point with the svn head becoming the future 2.1. E.g., what if I contribute a bunch of (1.5) code for 2.1 now and the committers think at least some of it should be included? Chuck --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
