lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: CloseableThreadLocal does not allow a null object?
Date Thu, 13 Aug 2009 12:20:24 GMT
Let's just allow null?  Can you open an issue?

Mike

On Thu, Aug 13, 2009 at 6:18 AM, Shai Erera<serera@gmail.com> wrote:
> Hi
>
> I have an Analyzer which is given a Config object and when tokenStream or
> reusableTokenStream is called, it generates a TokenStream based on the
> Config settings. I also have a setConfig method on that Analyzer. setConfig
> calls setPreviousTokenStream(null) so that next time reusableTokenStream is
> called, it will generate a new one, based on the new Config.
>
> Before CloseableThreadLocal, this worked just fine. But now it fails on
> CTL's assert that the object held by the WeakReference is not null, w/ a
> comment "this cannot be null because we set it ...".
>
> I don't have access to tokenStreams member since it's private, therefore I
> can't just tokenStream = new CloseableThreadLocal(). Why doesn't
> CloseableThreadLocal allow for null objects? ThreadLocal allows it. Also, I
> think CTL is not consistent, since when I call set(null) it allows the call,
> but get() throws an exception.
>
> I can overcome this by setting a new object which its tokenizer and
> tokensteam members are null, and check those instead of the object returned
> from get(). But I don't think CTL should forbid null, or at least make sure
> a null cannot be set.
>
> What do you think?
>
> Shai
>

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


Mime
View raw message