lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: 3.0, back-compat, Java 1.5 etc
Date Fri, 12 Jun 2009 12:03:32 GMT
I think we should also insert the generics to at least the public APIs
before 3.0. This is not a real change to backwards compatibility or
anything, it is just adding the "annotations" which data types are used in
java collections and so on. But it should be done before 3.0, because after
3.0 it would a break to change the return value of a functions from List<?>
(which it is by default) to List<Field> or similar. As 3.0 is the first 1.5
release it should be done before!

I wanted to do this directly after the 2.9 release, there are tools, that
can do this half-automatically in e.g. Eclipse.

Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen

> From: Michael McCandless []
> Sent: Friday, June 12, 2009 12:33 PM
> To:;
> Subject: Re: 3.0, back-compat, Java 1.5 etc
> On Fri, Jun 12, 2009 at 3:50 AM, Simon
> Willnauer<> wrote:
> > I'm curious if there is a kind of a roadmap or a document where I can
> > get up-to-date with all those targets and especially what we want to
> > achieve in 3.0.
> I don't think we have such a doc...
> I think "the plan" at this point is quite straightforward: we are
> trying to wind down 2.9, and release it.  We have 36 issues still open
> now...
> 3.0 will then be a mechanical release: "simply" remove all deprecated
> APIs, fix all core, contrib, tests to not use those APIs, release, and
> immediately begin accepting 1.5 patches.
> > I also saw a comment on LUCENE-1407 "...Searcher extend the RMI class,
> > but that will leave RMI in core. Or I can have Searchable implement
> > new methods, but that won't take us in the ultimate direction we want
> > - getting rid of interfaces."
> > I'm curious about why lucene wants to get rid of interfaces though?
> Because you can't add a new method to an interface w/o breaking
> back-compat.  Vs an abstract class, where you can add the method w/ a
> default impl.  We are trying to move away from interfaces for all but
> the most trivial situations now...
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message