Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
MIME-Version: 1.0
Date: Fri, 29 May 2015 11:04:12 +1000
Message-ID: 
 <CADuAvzdC=uLM_3trfZoQC5HKJoeK7sVA+OmUUyoiv+Hdq_Y49w@mail.gmail.com>
Subject: Specifying a Version vs. not specifying a Version
From: Trejkaz <trejkaz@trypticon.org>
To: Lucene Users Mailing List <java-user@lucene.apache.org>
Content-Type: text/plain; charset=UTF-8

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