lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <>
Subject Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Date Thu, 22 Jun 2006 23:11:42 GMT

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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message