lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Analyzer forcing tokenStream and reusableTokenStream to be final
Date Tue, 19 Oct 2010 16:12:22 GMT
Can't we have only one API?

Call it .tokenStream and it's always reusable?

What breaks?  Remember the re-use is only w/in a thread.  Each thread
gets its own instance.

Apps that for some reason cannot reuse even w/in a thread can always
make a Field w/ the tokenStream pre-set?


On Tue, Oct 19, 2010 at 11:10 AM, Shai Erera <> wrote:
> Hi
> I understand the assertions in Analyzer to enforce 'final' on those methods,
> but I wanted to ask why do we care if a user's code does not declare them
> final? Why fail the tests on it? Can we change the assertion to fail if the
> code from o.a.l?
> The thing is, we run tests w/ -ea to catch all sorts of errors (real errors)
> Lucene may detect. Having some custom analyzers non-final is something we
> may choose to live with, yet our tests keep failing. I don't want to argue
> if we should or shouldn't make them final - just ask why does Lucene code
> cares if the application code may not follow 'best practices'.
> Is there real danger in having my analyzer not declaring these methods final
> - something that can affect Lucene code for example? Or am I only risking my
> code?
> Running w/o -ea is not an option, so please avoid suggesting it :).
> Shai

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

View raw message