[
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438532#comment-13438532
]
Uwe Schindler commented on LUCENE-2000:
---------------------------------------
Hi,
in revision 1375428 (trunk) and 1375429 (4.x), I also added a covariant
override for IndexInput.clone(), removing tons of useless casts.
> Use covariant clone() return types
> ----------------------------------
>
> Key: LUCENE-2000
> URL: https://issues.apache.org/jira/browse/LUCENE-2000
> Project: Lucene - Core
> Issue Type: Task
> Components: core/other
> Affects Versions: 3.0
> Reporter: Uwe Schindler
> Assignee: Ryan McKinley
> Priority: Minor
> Fix For: 4.0-ALPHA
>
> Attachments: LUCENE-2000-clone_covariance.patch,
> LUCENE-2000-clone_covariance.patch
>
>
> *Paul Cowan wrote in LUCENE-1257:*
> OK, thought I'd jump in and help out here with one of my Java 5 favourites.
> Haven't seen anyone discuss this, and don't believe any of the patches
> address this, so thought I'd throw a patch out there (against SVN HEAD @
> revision 827821) which uses Java 5 covariant return types for (almost) all of
> the Object#clone() implementations in core.
> i.e. this:
> public Object clone() {
> changes to:
> public SpanNotQuery clone() {
> which lets us get rid of a whole bunch of now-unnecessary casts, so e.g.
> if (clone == null) clone = (SpanNotQuery) this.clone();
> becomes
> if (clone == null) clone = this.clone();
> Almost everything has been done and all downcasts removed, in core, with the
> exception of
> Some SpanQuery stuff, where it's assumed that it's safe to cast the clone()
> of a SpanQuery to a SpanQuery - this can't be made covariant without
> declaring "abstract SpanQuery clone()" in SpanQuery itself, which breaks
> those SpanQuerys that don't declare their own clone()
> Some IndexReaders, e.g. DirectoryReader - we can't be more specific than
> changing .clone() to return IndexReader, because it returns the result of
> IndexReader.clone(boolean). We could use covariant types for THAT, which
> would work fine, but that didn't follow the pattern of the others so that
> could be a later commit.
> Two changes were also made in contrib/, where not making the changes would
> have broken code by trying to widen IndexInput#clone() back out to returning
> Object, which is not permitted. contrib/ was otherwise left untouched.
> Let me know what you think, or if you have any other questions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
