lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Specifying a Version vs. not specifying a Version
Date Fri, 29 May 2015 23:33:30 GMT

: 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" !

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 


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

View raw message