Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of dmsmith555@gmail.com
 designates 74.125.92.25 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=KRM25hRpetysoBUFiSTExThIGrGtY76X52XRpl1A77y7VR9xwPsDdNI7Vv1+E9POlb
         cBvQeLEfDSDgG8Es+e28U94M8KXFF3w8qRBMCXHn4kO+TOUbrg0yqxg7zisinYkbGLNh
         wik+niS//xu7cGvBIMdj2RvZ9wa2/62TM5UHc=
Message-Id: <90F51F83-4238-4DCD-9369-4809C48ABB29@gmail.com>
From: DM Smith <dmsmith555@gmail.com>
To: java-dev@lucene.apache.org
In-Reply-To: <f18c9dde0908231106n2b15dd99n8cd3e0559415bf1@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Lucene 3.0 and Java 5 (was Re: Finishing Lucene 2.9)
Date: Sun, 23 Aug 2009 15:36:07 -0400
References: <4A89DF01.8060204@gmail.com> <4A8B0053.4030104@gmail.com>
 <9ac0c6aa0908181228o2c1cda63l2f77a09959c34a69@mail.gmail.com>
 <4A8C10FB.4030108@gmail.com> <596D2C98A44141778B23462582A1BE6E@VEGA>
 <4A8C7AE5.5040409@gmail.com>
 <9ac0c6aa0908200308o27e6a63atcf57188d5e6bc4af@mail.gmail.com>
 <4A8D485A.2010106@gmail.com>
 <9ac0c6aa0908231018s8c7a746h89da4e4e2a886489@mail.gmail.com>
 <8f0ad1f30908231038q475ff87bued2bd64e4f803d90@mail.gmail.com>
 <f18c9dde0908231106n2b15dd99n8cd3e0559415bf1@mail.gmail.com>


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

> On Sun, Aug 23, 2009 at 7:38 PM, Robert Muir<rcmuir@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.

-- DM Smith


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org