I like that approach. So we just need a volunteer to do at least step
1, for 3.0, which should be reasonably straightforward.
Another big effort for 3.0 will be fixing all places internal to
Lucene (including contrib, tests) that still use deprecated APIs.
Mike
Uwe Schindler wrote:
A good idea would be to do the transformation to generics like the
following:
- write a patch that replaces all *public* API declarations with
generics
(especially Document, Fieldable and so on where a lot of List/Sets
occur).
The Lucene code behind these declarations will compile without any
problem,
it will only print out warnings (e.g. a method takes an argument
List<Fieldable> but the internal member variable is just List, the
assignment will generate the warning. By adding <compilerarg
line="-Xlint:unchecked" /> to the build.xml scripts, the compiler
will print
the warnings more detailed with line numbers etc., can be much
output). At
return values you sometimes have to place a cast (assign not-
generics to a
generics type does not work with 1.5). This cast also generates an
unsafe
warning.
- start to fix all places in Lucene where the compiler produces
warnings.
You start with the parts directly behind the public API, when
finished the
compiler gives warnings for the next and so on.
The first could be one patch available in Lucene starting with 3.0
(so the
public API is generics, without much hassle). The other patches can
be done
step by step to remove the compiler warnings.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-----Original Message-----
From: Michael McCandless [mailto:luc...@mikemccandless.com]
Sent: Sunday, December 14, 2008 12:31 PM
To: java-dev@lucene.apache.org
Subject: Re: 2.9/3.0 plan & Java 1.5
Uwe Schindler wrote:
EG I haven't yet tested for JAR drop-in compatibility, eg if in 3.1
we
wanted to swap in more generics, would a 3.0 app be able to drop in
the 3.1 Lucene jar w/o problems?
It should, because in the compiled JVM code, generics do simply not
appear.
Ahhhh, right. So I think this means we can safely, over time, swap
in
generics for these APIs w/o going through our normal back
compatibility steps (deprecate old, rename to new, etc.). Even say
in
the 3.1 release (a minor release) we can swap in generics for APIs.
Great!
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
