Specifying a Version vs. not specifying a Version

[Trejkaz <tr...@trypticon.org>]

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

Re: Specifying a Version vs. not specifying a Version

[Trejkaz <tr...@trypticon.org>]

On Sat, May 30, 2015 at 9:33 AM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> My best understanding based on what I see in the current code, is that if
> you care about backcompat:
>
>  * you must call setVersion() on any *Analyzer* instances you construct
> before using them
>  * you must *not* construct Tokenizers or TokenFilter's directly --
> instead you must use the corrisponding Factory and pass the
> LUCENE_MATCH_VERSION_PARAM to request an instance.
>
> the Analyzers and Factories are now the only things that worry about
> Version semantics, and instantiate diff classes or call diff methods on
> the objects they instantiate, as needed to "best fit" the Version you have
> specified.

Yikes.

Okay, well actually, maybe it isn't all that bad. I guess in the
unlikely event that 5.2.0 changed something in StandardFilter, the
default constructor could be deprecated and changed to delegate to
LUCENE_5_1_0 and the other constructor could be recommended, so
backwards compatibility wouldn't even break in that scenario.

I guess that the only risk would be for someone jumping straight from
something like 3.0 ~ 5.2, where it would go from being default
constructor to default constructor, but with the behaviour differing
between the two.

I hadn't even noticed somehow that the TokenFilterFactory existed now.
That thing is interesting. We have our own similar class hierarchy,
although ours might be different enough that we can't just move
across.

TX

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

Re: Specifying a Version vs. not specifying a Version

[Chris Hostetter <ho...@fucit.org>]

: 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.)

Welcome to the wonderful world of "Lucene Analysis Compatibility 
Post-LUCENE-5859" !

	https://issues.apache.org/jira/browse/LUCENE-5859

If you have a strong stomach, reading that issue might help you understand 
some of the arguments made for/against pruning "Version" from much of the 
analysis APIs -- I can't honestly tell you what the final 
decision/justification for the current state of things is (or even if the 
issue comments reflect it, whatever it was -- or if the final decision was 
made in a diff jira) because I stoped following the issue once I started 
being personally attacked for making technical arguments.


My best understanding based on what I see in the current code, is that if 
you care about backcompat:
 
 * you must call setVersion() on any *Analyzer* instances you construct 
before using them
 * you must *not* construct Tokenizers or TokenFilter's directly -- 
instead you must use the corrisponding Factory and pass the 
LUCENE_MATCH_VERSION_PARAM to request an instance.

the Analyzers and Factories are now the only things that worry about 
Version semantics, and instantiate diff classes or call diff methods on 
the objects they instantiate, as needed to "best fit" the Version you have 
specified.



-Hoss
http://www.lucidworks.com/

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