atom feed52 messages in org.apache.lucene.java-devLucene 3.0 and Java 5 (was Re: Finish...
FromSent OnAttachments
11 earlier messages
Mark MillerAug 19, 2009 12:08 pm 
Grant IngersollAug 19, 2009 1:08 pm 
Mark MillerAug 19, 2009 1:19 pm 
Michael BuschAug 19, 2009 1:24 pm 
Michael BuschAug 19, 2009 2:02 pm 
Mark MillerAug 19, 2009 2:37 pm 
Uwe SchindlerAug 19, 2009 3:16 pm 
Mark MillerAug 19, 2009 3:21 pm 
Michael BuschAug 19, 2009 4:20 pm 
Michael McCandlessAug 20, 2009 3:08 am 
Mark MillerAug 20, 2009 5:58 am 
Shai EreraAug 20, 2009 6:05 am 
Mark MillerAug 20, 2009 6:08 am 
Uwe SchindlerAug 20, 2009 1:29 pm 
Grant IngersollAug 20, 2009 6:50 pm 
Mark MillerAug 20, 2009 7:00 pm 
Mark MillerAug 20, 2009 7:02 pm 
Uwe SchindlerAug 20, 2009 10:42 pm 
Michael BuschAug 21, 2009 12:39 am 
Michael McCandlessAug 23, 2009 10:18 am 
Mark MillerAug 23, 2009 10:37 am 
Robert MuirAug 23, 2009 10:38 am 
Simon WillnauerAug 23, 2009 11:06 am 
Mark MillerAug 23, 2009 11:46 am 
DM SmithAug 23, 2009 12:36 pm 
Michael McCandlessAug 24, 2009 3:29 am 
Tim SmithAug 24, 2009 5:19 am 
Mark MillerAug 24, 2009 5:21 am 
Uwe SchindlerAug 24, 2009 5:26 am 
Uwe SchindlerAug 24, 2009 5:27 am 
Michael McCandlessAug 24, 2009 8:44 am 
Marvin HumphreyAug 24, 2009 9:12 am 
Jason RutherglenAug 24, 2009 10:32 am 
Michael McCandlessAug 24, 2009 10:46 am 
Marvin HumphreyAug 24, 2009 11:11 am 
Shai EreraAug 24, 2009 12:15 pm 
Marvin HumphreyAug 24, 2009 12:50 pm 
Andi VajdaAug 25, 2009 8:44 am 
Andi VajdaAug 25, 2009 9:00 am 
Andi VajdaAug 25, 2009 9:11 am 
Mark MillerAug 25, 2009 9:16 am 
Subject:Lucene 3.0 and Java 5 (was Re: Finishing Lucene 2.9)
From:DM Smith (dmsm@gmail.com)
Date:Aug 23, 2009 12:36:07 pm
List:org.apache.lucene.java-dev

On Aug 23, 2009, at 2:06 PM, Simon Willnauer wrote:

On Sun, Aug 23, 2009 at 7:38 PM, Robert Muir<rcm@gmail.com> wrote:

just wanted to mention this (i honestly don't have any opinion either way):

Right, this (you can jump to 2.9, fix all deprecations, then easily move to 3.0 and see no deprecations) is my understanding too, but I don't see what's particularly useful about that. It does produce a Lucene release that has zero deprecated APIs (assuming we remove all of them), but I don't think that's very important. Also, it's extra work having to do a "no-op, except for deprecations removal and generics addition" release :)

But isn't it also true it could be a bit more than no-op: 1) changing to "better" defaults in cases where back compat prevents this. I think I remember a few of these? 2) bugfixes found after release of 2.9 3) performance improvements, not just from #1 but also from removal of back-compat shims (i.e. tokenstream reflection)

I am not saying this stuff is really important to users to merit a release, but I don't think it is a no-op either.

I agree with robert that this is very likely not to be a no-op release. Changing to 1.5 brings in generics and lots of other stuff which could bring improvements. All the concurrent improvements, VarArgs and Utils in classes like Integer (valueOf) etc. I believe that we find may places in the code where existing stuff could be improved with the ability to commit 1.5 code. Moving to 1.5 with 3.0 would be a clean step in my eyes. Having 3.0 with 1.4 back-compat and then 3.1 which get rid of this would confuse users.

My two cents. I think the contract of the 3.0 release is that it is a drop in replacement for the 2.9 release but requires Java 1.5. I expect to compile against Lucene 2.9 using Java 1.4, removing deprecations. And then go to Lucene 3.0 changing the compiler to Java 1.5 but making no code changes.

To that end, any introduction of Java 1.5 into the end-user/non-expert/ non-experimental/non-contrib API needs to work with existing code as is. It may require the user to compile with lax permissions using Java 1.5 and run with Java 1.5.

Requiring Java 1.5 can be as easy as using a Java 1.5 feature internally, in the expert or experimental APIs, and classes that are not part of the backward compatibility contract (e.g. utility classes).

I don't think there should be any effort to maintain Java 1.4 compatibility, but I also think changes should be made only where it makes sense, giving a clear advantage (performance, maintainability, ....). If that results in 1.4 compatibility it is a temporary benefit not guaranteed during the 3.x series.

I agree with previous threads that there is both a blessing and a curse with Lucene's backward compatibility release policy. My biggest gripe is the evolution toward bad class names. I would like to see a 4.0 release dedicated to fixing the name/api problems and making the API of Lucene be what it should have been for a 3.0 release. I'd also suggest that repackaging, suggested in a prior thread, be tackled also. This could follow a 3.0 release quickly.