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:35:17 UTC 2012
- Previous message: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods
- Next message: hg: jdk8/tl/jdk: 7132378: Race in FutureTask if used with explicit set ( not Runnable )
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 01/30/2012 04:19 AM, Tom Hawtin wrote:
On 30/01/2012 03:58, Joe Darcy wrote:
Object clone()
method inherited from java.lang.Object with a covariant override such as MyType clone() This is, of course, going to break any existing overrides (that aren't making use of covariant return types). This will be why the changes weren't made way back in 1.5.
While this issue may have good technical grounding, there were also many potential changes omitted from JDK 5 due to lack of time, etc.
Other clone implementations are overridden for (mobile code) security reasons. These methods may have the same thing done to them by trusted code outside of the Java library. A better solution to the unchecked casts from clone, is not to clone. Using a constructor gets rid of the problem, and ensures you aren't using some funky (potentially malicious) subclass. - return (Hashtable<String, java.lang.Object>)env.clone(); + return new Hashtable<>(env); Tom
I suppose this depends on what your threat model is. For better or worse, the types in question are Cloneable and should have reasonable clone methods.
-Joe
- Previous message: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods
- Next message: hg: jdk8/tl/jdk: 7132378: Race in FutureTask if used with explicit set ( not Runnable )
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]