lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Updated: (LUCENE-1678) Deprecate Analyzer.tokenStream
Date Mon, 13 Jul 2009 11:13:14 GMT


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:
>             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:
> 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:
For additional commands, e-mail:

View raw message