lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Lucene 2.9 and deprecated methods
Date Fri, 02 Oct 2009 23:33:06 GMT
Sigh.  The introduction of new but deprecated methods is silly.  Is
there some simple automated way to catch/prevent these?

The proliferation of ctors/factory methods is a nightmare.

Part of the story with is the switch to readOnly
IndexReaders.  After the long back-compat discussion we settled on
adding new ctors as the best way to make the change.

On deprecation of Version.LUCENE_29, that doesn't seem right.  In fact
I don't think LUCENE_24 should be deprecated, either, since these
constants are used by StandardAnalyzer to state compatibility that's
"equivalent" to index format compability (from our last discussion).

I think deprecation by separate area makes sense?


On Fri, Oct 2, 2009 at 6:41 PM, Uwe Schindler <> wrote:
> When looking for press articles about the release of Lucene 2.9, I found the
> following one from Bernd Fondermann
> @
> Translation with Google Translate:
> ----------------------------------------------------------------------------
> Deprecated
> An index reader is created via the static open () factory method, of which
> there were 2.4 in all nine. Five of them are now deprecated. In 2.9 there
> are now a total of 14 open-overloaded variants, with eight of them but they
> are deprecated. This means that there are even some additions that have been
> directly identified with introduction as deprecated - confusing.
> The constructor-Deprecation orgy goes for the standard Analyzer, one of the
> key classes during indexing and querying further. This class has now no-less
> constructor arguments over what might, perhaps, some downstream libraries
> bring to stumble to instantiate their analyzer on a property, which contains
> the class name dynamically. Instead, an object version must be given to set
> for compatibility with 2.4 or 2.9. Both the VERSION_24 as well as the
> VERSION_29 parameters are deprecated but themselves - very confusing!
> VERSION_CURRENT is the only safe investment in the future, a value which we
> certainly also as assignment in a zero-argument constructor would have
> trusted.
> To write an index we need an index writer instance. Again, the majority of
> the 19 possible constructors are about to be put to retire to.
> ----------------------------------------------------------------------------
> What was going wrong with the open() hell in IR? Very strange, I should have
> looked better.
> By the way: How to proceed with deprecation removal? Case-by-case (e.g.
> start with TS API, then these open() calls, then FSDirectory - to list the
> ones I was involved) or some hyper-patch?
> By the way, here is my talk @ Hadoop GetTogether in Berlin:
> -get-together-berlin
> Uwe
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> eMail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message