[jira] [Commented] (LUCENE-2000) Use covariant clone() return types
[
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241364#comment-13241364
]
Michael McCandless commented on LUCENE-2000:
We now get a bunch of redundant cast warnings from this ... are there plans
to fix that...?
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
[jira] [Commented] (LUCENE-2000) Use covariant clone() return types
[
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241366#comment-13241366
]
Uwe Schindler commented on LUCENE-2000:
---
We should fix this in trunk! I wanted to ask the same question!
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
[jira] [Commented] (LUCENE-2000) Use covariant clone() return types
[
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241413#comment-13241413
]
Ryan McKinley commented on LUCENE-2000:
---
I just checked in a bunch of stuff... kept removing things until:
{code}
ant compile | grep redundant cast
{code}
was empty
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
[jira] [Commented] (LUCENE-2000) Use covariant clone() return types
[
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (LUCENE-2000) Use covariant clone() return types
[
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240763#comment-13240763
]
Uwe Schindler commented on LUCENE-2000:
---
In Lucene trunk we break backwards, be free to change it! I am fine with it.
(this is why I kept it open)
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
Priority: Minor
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
[jira] Commented: (LUCENE-2000) Use covariant clone() return types
[
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844130#action_12844130
]
Earwin Burrfoot commented on LUCENE-2000:
-
I believe we should do this at our next we're breaking backcompat release.
Any compile errors that could bring to clients are fixed like, exceptionally
easy. And the code comes out cleaner - we have way more callees of clone()
than overrides.
Use covariant clone() return types
--
Key: LUCENE-2000
URL: https://issues.apache.org/jira/browse/LUCENE-2000
Project: Lucene - Java
Issue Type: Task
Affects Versions: 3.0
Reporter: Uwe Schindler
Priority: Minor
Attachments: 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.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
