Threads should not be Cloneable

David Holmes David.Holmes at oracle.com
Mon Aug 16 23:49:35 UTC 2010


Joe Darcy said the following on 08/17/10 06:05:
> The general evolution policy of the JDK [1] has long been:
> 
>>    1. Don't break binary compatibility (as defined in the Java 
>> Language Specification).
>>    2. Avoid introducing source incompatibilities.
>>    3. Manage behavioral compatibility changes.
> 
> Per JLSv3 section 13.4.17 "final Methods," [2]
> 
>> Changing an instance method that is not final to be final may break 
>> compatibility with existing binaries that depend on the ability to 
>> override the method.
> 
> Therefore, adding final to Thread's clone method would be a binary 
> incompatible change since any (weird, broken) subclasses which override 
> the clone method would fail to link, which is the definition of binary 
> compatibility.  While there is merit in considering this change, the 
> default position would be to reject the change as going against the 
> general evolution policy.

Fortunately, as Brian stated, compatibility is not an end unto itself 
here and we often do have documented incompatibilities across major 
releases. In this case there is far more harm, in my opinion, leaving 
the possibility of people trying to clone threads than there is in 
breaking a hypothetical program that is unlikely to be functioning 
correctly anyway. Thread should never have been cloneable in any way - 
the fact that this has flown under the radar for so long is a strong 
indicator that nobody actually does this in practice (else they would 
have complained that it didn't work).

David

> -Joe
> 
> [1] 
> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy 
> 
> [2] 
> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.17 
> 
> 
> 
>>
>> Thanks,
>> -Chris.
>>
>> On 15/08/2010 23:22, David Holmes wrote:
>>> Hi Florian,
>>>
>>> Florian Weimer said the following on 08/15/10 21:51:
>>>> * David Holmes:
>>>>> tom.hawtin at oracle.com said the following on 08/14/10 00:12:
>>>>>> On 13/08/2010 14:58, Chris Hegarty wrote:
>>>>>>
>>>>>>> protected final Object clone() throws CloneNotSupportedException {
>>>>>>> throw new CloneNotSupportedException();
>>>>>> The final can (and should, IMO) be removed.
>>>>> Why? What purpose would it serve?
>>>>
>>>> Increased backwards compatibility.
>>>
>>> The only thing this would increase compatibility with is if there exists
>>> already a subclass of Thread that overrides clone() to provide
>>> construction-based cloning**. Are you aware of such a use-case? The
>>> postings to the concurrency-interest mailing list and to here are to
>>> solicit feedback regarding any genuine use-cases for this functionality.
>>> So far there have been (as we expected) zero responses regarding actual
>>> use.
>>>
>>> The 'final' makes it clear that the programmer should just forget about
>>> clone() when it comes to Thread and any of its subclasses. If we remove
>>> the final then we have to provide additional documentation explaining
>>> the limitations that any override of clone() would encounter.
>>>
>>> ** Any usage involving super.clone() is already affected by this change
>>> regardless of 'final'.
>>>
>>> Cheers,
>>> David Holmes
> 



More information about the core-libs-dev mailing list