The bottom line is:
> 1) TermDocs has a close method
> 2) anything implimenting TermDocs should be able to trust
that
> close() will be called
> 3) anything iterating over a TermDocs should call close()
>
> ...ergo: TermScorer needs a close() method, right?
There is no memory leak now, and TermDocs.close() is not always
called, so I'd rather conclude that a close() method is not
really
needed.
Seems like the issue here is design integrity.
I'm not even sure what the intended use of close() is on TermDocs. Is it
optional or required? If it's required, implementers of the interface
should be allowed to depend on it being called and any lack of a call is
a latent bug, just waiting for the first TermDocs implementation that
does something in close(). Or it could be optional, perhaps with the
intention that a client might want to call it earlier than the object
will get GCed in order to release resources earlier. Then TermDocs
implementations have to arrange to have resources freed in case close
isn't called, perhaps by having a finalize that calls close a la
FSIndexInput.
Of course, if it never does anything and never will, the method could
just be ditched.
But I'd say it needs to be decided what the proper interpretation is.
The idea that callers will know whether or not to call it (because they
know which concrete class they're using) gives me the heebee jeebees.
Back to design integrity: the issue is it needs to be clear to
everybody. The fact that several people have been looking at this seems
evidence that the current state isn't clear and a change that would keep
others from spending more time on it would be a win.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
