Well, possibly I'm mistaken, but it seems that this affects non-static fields
too. Please see
http://www.nabble.com/ThreadLocal-in-SegmentReader-to18306230.html where the
use case is described in the details.
In short: it seems that the scope of ThreadLocals does not matter. What
really matters is
Or we could leave termText() deprecated, add term() which does the
same thing sub-optimally (ie, always creates new String from the
byte[]), and in the javadocs for termText() state that you can migrate
either term() (if you really want a String and you understand the
performance cost of
This would be better, especially when we get to Java 5, with covariant
returns. Then we could also rename termBuffer() to term() (or just leave
it :).
DM
Michael McCandless wrote:
Or we could leave termText() deprecated, add term() which does the
same thing sub-optimally (ie, always creates
Michael McCandless wrote:
But, in TokenFilter, next() should be deprecated, IMHO.
I think this is a good idea. After all if people don't want to bother
using the passed in Token, they are still allowed to return a new
one.
I'm looking into the deprecation of TokenStream.next(). I ha
DM Smith <[EMAIL PROTECTED]> wrote:
> On Jul 11, 2008, at 9:42 PM, Hiroaki Kawai wrote:
>
> > Another suggestion from me:
> > How about making token object as an singleton?
>
> Would that work for a multi-threaded application?
Of cource. We should make that thread local singleton.
> >
> >
> >
You are mistaken - Yonik's comment in that thread is correct
(although it is not just at table resize - any time a ThreadLocal is
added, and any time the ThreadLocal is not found in its direct hash
it might clear entries).
The ThreadLocals map only has a WeakReference to the ThreadLocal, so
