[
https://issues.apache.org/jira/browse/LUCENE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718031#action_12718031
]
Michael McCandless commented on LUCENE-1678:
--------------------------------------------
bq. So, given it is already broken, why not fix it the right way?
Because two wrongs don't make a right?
(I assume you're suggesting changing tokenStream to match reusableTokenStream,
ie allowing it to return a reused TokenStream between calls, and then
deprecating reusableTokenStream).
Apps that get multiple TokenStreams from a single Analyzer and then iterate
through them, would silently break, if we up and made this 2nd
non-back-compatible change.
> Deprecate Analyzer.tokenStream
> ------------------------------
>
> Key: LUCENE-1678
> URL: https://issues.apache.org/jira/browse/LUCENE-1678
> Project: Lucene - Java
> Issue Type: Bug
> Components: Analysis
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 2.9
>
>
> The addition of reusableTokenStream to the core analyzers unfortunately broke
> back compat of external subclasses:
>
> http://www.nabble.com/Extending-StandardAnalyzer-considered-harmful-td23863822.html
> On upgrading, such subclasses would silently not be used anymore, since
> Lucene's indexing invokes reusableTokenStream.
> I think we should should at least deprecate Analyzer.tokenStream, today, so
> that users see deprecation warnings if their classes override this method.
> But going forward when we want to change the API of core classes that are
> extended, I think we have to introduce entirely new classes, to keep back
> compatibility.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
