[
https://issues.apache.org/jira/browse/LUCENE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1678:
---------------------------------------
Attachment: LUCENE-1678.patch
OK, inspired by Uwe's persistence on LUCENE-1693, I realized one clean
way to fix the back-compat break here is by using reflection when
creating the Analyzer as to whether the class overrides the
tokenStream method. Then, in reusableTokenStream we forcefully
fallback to tokenStream, if it does.
Attached patch, with a test case showing the issue, implements this
approach, and it works well. With this approach there's no reason to
deprecate tokenStream.
> 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
>
> Attachments: LUCENE-1678.patch
>
>
> 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
