On 4/27/18 3:35 AM, Paul Sandoz wrote:
Hi Mandy,
This looks reasonable. I suspect external subtypes of the j.l.ref types are
extremely rare (grep code reports no derived types) and of those it would
likely be even rarer for those subtypes to implement Cloneable, and for that
functionality to operate reliably.
Thanks for the review.
Subtypes of java.lang.ref.SoftReference and WeakReference is not
uncommon (JDK has plenty of such subtypes). I guess grep code may show
the result of a specific JDK release and reports no derived types. I do
think it's extremely rare for those subtypes to implement Cloneable. So
this change should have low compatibility risk.
Mandy
Paul.
On Apr 26, 2018, at 7:16 AM, mandy chung <mandy.ch...@oracle.com> wrote:
The semantics of cloning a Reference object is not clearly defined. In
addition, it is questionable whether it can be meaningfully supported in
particular with concurrent reference processing.
The reachability state of a Reference object may change during GC reference
processing. The referent may have been cleared when it reaches its reachability
state. In addition, it may be enqueued or pending for enqueuing. Cloning a
Reference object with a referent that is unreachable but not yet cleared might
mean to resurrect the referent. A cloned enqueued Reference object will never
be enqueued. A Reference object cannot be meaningfully cloned.
We propose Reference::clone to throw CloneNotSupportedException. To clone a
Reference object, it should create a new instance via its constructor.
CSR: https://bugs.openjdk.java.net/browse/JDK-8202260
Webrev:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/
Mandy
