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

Uwe Schindler commented on LUCENE-3420:
---------------------------------------

The problem behind the checks is that they are done by the class TokenStream, 
so even if you disable assertions for your own class this will still fail as 
soon as you enable assertions for the lucene package.

If you want to enable assertions for Lucene but disable assertions in your own 
code, the ctor should check the actual assertion status of the subclass using 
Class.desiredAssertionStatus() and not throw AssertionFailedError, as this 
would affect a class for which assertions are not enabled. Patch is easy.

The same applies for Analyzer.

In another issue (sorry, I don't find it, the JIRA search is dumb - oh f*ck 
it's Lucene! - maybe it was on mailing list), Shai Erea suggested to do the 
assertion check only for org.apache.lucene and org.apache.solr packages. There 
is already a patch somewhere - if I could find the issue.

> assertion derived class modifier from parent class silently breaks backward 
> compatibility
> -----------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3420
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3420
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: core/index
>    Affects Versions: 3.3
>            Reporter: John Wang
>
> after upgrading to lucene 3.1+, I see this in my log:
> java.lang.AssertionError: TokenStream implementation classes or at least 
> their incrementToken() implementation must be final
>         at 
> org.apache.lucene.analysis.TokenStream.assertFinal(TokenStream.java:117)
>         at org.apache.lucene.analysis.TokenStream.<init>(TokenStream.java:92)
> Turns out I derived TokenStream and my class was not declared final.
> This silently breaks backward compatibility via reflection, scary...
> I think doing this sort of check is fine, but throwing an 
> java.lang.AssertionError in this case is too stringent. 
> This is a style check against lucene clients, a error log would be fine, but 
> throwing an Error is too much.
> See constructor implementation for: 
> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/analysis/TokenStream.java?view=markup

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to