Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <2018738175.1244632687337.JavaMail.jira@brutus>
Date: Wed, 10 Jun 2009 04:18:07 -0700 (PDT)
From: "Michael McCandless (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1678) Deprecate Analyzer.tokenStream
In-Reply-To: <92755049.1244565787514.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718032#action_12718032 ] 

Michael McCandless commented on LUCENE-1678:
--------------------------------------------

bq. The sane/smart way is to do it on a case by case basis.

Right, and the huge periodic discussions on back-compat do soften
"our" stance on these.  For example LUCENE-1542 was just such a case,
where we chose to simply fix the [rather nasty] bug at the expense of
possible apps relying on the broken behavior.

LUCENE-1679 is another (rather trivial) example, where we plan to
change certain fields in WildcardTermEnum to be final.


> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org