JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods (original) (raw)
Joe Darcy joe.darcy at oracle.com
Mon Jan 30 17:10:42 UTC 2012
- Previous message: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods
- Next message: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 01/29/2012 10:52 PM, Rémi Forax wrote:
On 01/30/2012 04:58 AM, Joe Darcy wrote:
Hello,
As an indirect outgrowth of warnings cleanup day, various categories of warnings can be eliminated by in the use of Cloneable types by overriding the Object clone() method inherited from java.lang.Object with a covariant override such as MyType clone() Please review my changes for 7140820 Add covariant overrides to Collections clone methods http://cr.openjdk.java.net/~darcy/7140820.0/ which add such covariant override clone methods to collections and a few other classes in java.util. Doing a full JDK build with these changes, I've also made alterations to other classes to remove now superfuous casts (casts which are a javac lint warning!) and some unneeded @SuppressWarnings annotations. I also cleaned up a few rawtypes warnings while in editing files in java.util. (Note that the old specListeners method in EventRequestSpecList.java was much buggy; it cast an ArrayList from runtime.specListeners to a Vector.) Thanks, -Joe WTF ! while it's maybe a binary compatible change, I haven't take a look to all modified classes to be sure it's not a source compatible change.
Adding the covariant override is a binary compatible change because there would be a bridge method providing the original "Object clone()" signature.
People had created class that inherits from ArrayList and override clone, while it's not a good practice, there is a lot of code from pre-1.5 days that does exactly that, this change will simply break all those codes.
sigh
Yes, I didn't fully consider the source compatibility implications given that these types can be subclasses; I'll look this over some more.
(This was meant to be part of a larger effort to review of potentially overridable clone methods in the JDK. I wrote an annotation processor to look over the code base to find potential classes to upgrade; I can refine the processor to look for classes that don't override clone and are also final or effectively final, having no accessible constructors.)
Thanks Remi,
-Joe
- Previous message: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods
- Next message: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]