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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
