Review Request JDK-8201793: (ref) Reference object should not support cloning

[mandy chung]

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.chung at 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