Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <340860831.1242985965866.JavaMail.jira@brutus>
Date: Fri, 22 May 2009 02:52:45 -0700 (PDT)
From: "Michael McCandless (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1636) TokenFilters with a null value in
 the constructor fail
In-Reply-To: <552546823.1242287565685.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-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712008#action_12712008 ] 

Michael McCandless commented on LUCENE-1636:
--------------------------------------------

Good questions Uwe!

I tested the back-compat by adding this to TestAnalyzers temporarily
in my local checkout:

{code}
private class TestFilter extends TokenFilter {
  public TestFilter() {
    super(new WhitespaceTokenizer(null));
  }
}

public void testChangeTokenFilterInput() {
  TokenFilter tf = new TestFilter();
  System.out.println("tf.input = " + tf.input);
  tf.input = null;
}
{code}

Then, {{ant test-tag -Dtestcase=TestAnalyzers}} results in:
{code}
[junit] ------------- Standard Output ---------------
[junit] tf.input = (start=0,end=0,term=)
[junit] ------------- ---------------- ---------------
[junit] Testcase: testChangeTokenFilterInput(org.apache.lucene.analysis.TestAnalyzers):	Caused an ERROR
[junit] null
[junit] java.lang.IllegalAccessError
[junit] 	at org.apache.lucene.analysis.TestAnalyzers.testChangeTokenFilterInput(TestAnalyzers.java:143)
{code}

So, 1) it doesn't break JAR drop-in-abilility when one references
input, and 2) indeed at runtime final-ness is enforced by the JRE.  So
I think we should proceed with the change?  It is a back-compat break
for those users who change input after creating a TokenFilter, but
such a use case was not legal usage of the API, and will specifically
not work like it did in the past (so back-compat was already broken,
just in a much more sneaky manner).


> TokenFilters with a null value in the constructor fail
> ------------------------------------------------------
>
>                 Key: LUCENE-1636
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1636
>             Project: Lucene - Java
>          Issue Type: Bug
>    Affects Versions: 2.9
>            Reporter: Wouter Heijke
>            Assignee: Michael McCandless
>             Fix For: 2.9
>
>         Attachments: LUCENE-1636.patch
>
>
> While migrating from 2.4.x to 2.9-dev I found a lot of failing unittests.
> One problem is with TokenFilters that do a super(null) in the constructor.
> I fixed it by changing the constructor to super(new EmptyTokenStream())
> This will cause problems and frustration to others while migrating to 2.9.

-- 
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