[
https://issues.apache.org/jira/browse/LUCENE-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099317#comment-13099317
]
Uwe Schindler commented on LUCENE-3420:
---------------------------------------
Most of this is explained in the related issues to LUCENE-2389.
For analyzers enforcing finalness prevents errors in handling the two different
tokenStream() methods (for reuse and not reuse). Also the problems in Lucene
2.9 to make the new TokenStream API backwards compatible (the famous
"sophisticated backwards layer") lead to enforcing finalness for this API using
the decorator pattern. With this assertion we found lots of bugs even in Lucene
code that were caused by overriding methods to change behaviour that should
never be done in that way for decorator APIs.
And this is NOT a HARD error. No production system is broken by that, as
assertions are generally only enabled for testing. So the assertion failure
simply tells your test system that you have to fix your code. In production
without assertions, your code will still work. So where is the problem?
If you enable assertions on a production system you will see *significant*
performance problems!!!
> 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: [email protected]
For additional commands, e-mail: [email protected]
