lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Commented: (LUCENE-438) add Token.setTermText(), remove final
Date Fri, 23 Sep 2005 13:21:30 GMT
    [ ] 

Yonik Seeley commented on LUCENE-438:

> Could you not achieve this communication using ThreadLocals? 
Yes, but it would make me queasy :-)
Performance would also be less than desirable because you would have to stick every token
in a HashMap in that thread local and then retrieve them again in the next TokenFilter.

> Do we know what the performance cost is of making Token non-final?
That is the key question.  There is no reason not to make it non-final if there isn't a performance

In my general experience with recent hotspot JVMs, final on classes almost never make a difference.
 "final" applied to variables, however, can still make a big difference.  I think the JVMs
can tell if there are any loaded subclasses, and if not, treat it as final.

In the context of indexing, I couldn't detect any difference in speed.  I'll try and isolate
it more.

> add Token.setTermText(), remove final
> -------------------------------------
>          Key: LUCENE-438
>          URL:
>      Project: Lucene - Java
>         Type: Improvement
>     Versions: CVS Nightly - Specify date in submission
>     Reporter: Yonik Seeley
>     Priority: Minor
>  Attachments: yonik_Token.txt
> The Token class should be more friendly to classes not in it's package:
>   1) add setTermText()
>   2) remove final from class and toString()
>   3) add clone()
> Support for (1):
>   TokenFilters in the same package as Token are able to do things like 
>    "t.termText = t.termText.toLowerCase();" which is more efficient, but more importantly
less error prone.  Without the ability to change *only* the term text, a new Token must be
created, and one must remember to set all the properties correctly.  This exact issue caused
this bug:
> Support for (2):
>   Removing final allows one to subclass Token.  I didn't see any performance impact after
removing final.
> I can go into more detail on why I want to subclass Token if anyone is interested.
> Support for (3):
>   - support for a synonym TokenFilter, where one needs to make two tokens from one (same
args that support (1), and esp important if instance is a subclass of Token).

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message