Threads should not be Cloneable

Jeroen Frijters jeroen at
Tue Aug 17 04:11:58 UTC 2010

David Holmes wrote:
> 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).

I really don't understand your position. It clearly doesn't make sense to call Object.clone() on a Thread, but you can have a perfectly safe clone() on a Thread subclass:

public final MyCloneableThread extends Thread {
  public Object clone() {
    return new MyCloneableThread();

On the other hand, there is no reason to make clone() in Thread final other than some vague notion that you want to prevent people from writing new code like the above, but given that Java is an "old" and stable platform that argument doesn't carry much weight either.

BTW, from a security standpoint, overriding clone doesn't help. An attacker can simply create a Thread subclass that doesn't have the ACC_SUPER flag set and that class will be able to call Object.clone() just fine.


More information about the core-libs-dev mailing list