[ https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241417#comment-13241417 ]
Michael McCandless commented on LUCENE-2000: -------------------------------------------- Thanks Ryan! > Use covariant clone() return types > ---------------------------------- > > Key: LUCENE-2000 > URL: https://issues.apache.org/jira/browse/LUCENE-2000 > Project: Lucene - Java > Issue Type: Task > Components: core/other > Affects Versions: 3.0 > Reporter: Uwe Schindler > Assignee: Ryan McKinley > Priority: Minor > Fix For: 4.0 > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org