Threads should not be Cloneable

[Brian Goetz]

Compatibility is not an end unto itself; IMO compatibility with broken 
programs is not something we should spend our effort maintaining.  I'm +1 on 
this change, with final.

On 8/16/2010 5:03 AM, Chris Hegarty wrote:
> Thanks everyone for your very valuable feedback.
>
>  From what I'm reading there doesn't seem to be a problem with defining
> Thread.clone to throw CloneNotSupportedException. OK, that's done. Now
> should it be final?
>
> It appears that there is very little value in making clone non-final.
> Yes, it will increase compatibility, but not in any overly useful way.
> And it seems agreed, previous reason excluded, that the right thing to
> do is to remove any doubt about cloning. In light of that I would like
> to proceed with the change as originally proposed.
>
> 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