[
https://issues.apache.org/jira/browse/LUCENE-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114667#comment-13114667
]
Uwe Schindler commented on LUCENE-3464:
---------------------------------------
We can even do the change in 3.x, if we keep the old method delegating to the
new one. In 3.x we also need some sophisticated VirtualMethod usage then, as we
have to take care of custom IR implementations that may only override the old
one :( - unfortunately, reopen() is not final in IR and uses doReopen, like the
other methods.
reopenIfChanged() - my favourite!
> Rename IndexReader.reopen to make it clear that reopen may not happen
> ---------------------------------------------------------------------
>
> Key: LUCENE-3464
> URL: https://issues.apache.org/jira/browse/LUCENE-3464
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.5, 4.0
>
>
> Spinoff from LUCENE-3454 where Shai noted this inconsistency.
> IR.reopen sounds like an unconditional operation, which has trapped users in
> the past into always closing the old reader instead of only closing it if the
> returned reader is new.
> I think this hidden maybe-ness is trappy and we should rename it
> (maybeReopen? reopenIfNeeded?).
> In addition, instead of returning "this" when the reopen didn't happen, I
> think we should return null to enforce proper usage of the maybe-ness of this
> API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
