Threads should not be Cloneable

[Chris Hegarty]

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