lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
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?

Mike

On Tue, Oct 19, 2010 at 11:10 AM, Shai Erera <serera@gmail.com> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message