lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trejkaz <trej...@trypticon.org>
Subject Specifying a Version vs. not specifying a Version
Date Fri, 29 May 2015 01:04:12 GMT
Hi all.

I know with older Lucene there was a recommendation never to use
Version.CURRENT because it would break backwards compatibility.

So we changed all our code over to call, for instance, new
StandardTokenizer(Version.LUCENE_36, createReader()).

Now StandardTokenizer(Version, Reader) is deprecated and the docs say
to use StandardTokenizer(Reader) instead. But I can't do that, because
that constructor hardcodes Version.LATEST, which will break backwards
compatibility in the future (its Javadoc even confirms that this is
the case.)

So the Javadoc / deprecation is a bit inconsistent.

For consistency, if Version.LATEST is going to have a scary warning
like that on it, *it* should be deprecated. All the constructors which
use it should also be deprecated and the constructors taking an
explicit Version should be undeprecated.

Otherwise, we have to call deprecated constructors and risk that some
well-meaning developer in the future will "helpfully" remove all the
deprecated calls to Lucene, calling the dangerous ones instead.

TX

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message