/**
* Throws CloneNotSupportedException as a Thread can not be meaningfully
* cloned. Construct a new Thread instead.
*
* @throws CloneNotSupportedException
* always
*/
@Override
protected Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
Thread class documentation says that Thread can not be meaningfully cloned. What does this means?
A thread is closely related to state and mechanisms managed within the jvm, perhaps even also resources tied to the underlying implementation of the operating system.
And so cloning a Thread's state without going through the normal thread startup / shutdown mechanisms would give unpredictable results at best, or a fatal jvm crash at worst.
Given the code you discovered, it's pretty obvious that you're not meant to do this, it's a "bad idea" (tm) ;)
Like the documentation says, it doesn't make sense to clone a thread, if you want another thread you'd create a new one.
If you are in the position of wanting to clone a Thread, that suggests you have extended Thread where you should have implemented Runnable, or else you have otherwise managed to tie your domain objects to Thread somehow. For instance, there is an unfortunate anti-pattern where people create a class that implements Runnable, then create a Thread as an instance member of this class like this:
// Example of anti-pattern, please don't do this!
class MyTask implements Runnable {
private Thread thread;
public void start() {
thread = new Thread(this);
thread.start();
}
public void run() {
// whatever code your task performs
}
}
This is a great example of blindly following best-practices in a way that misses the point entirely. While superficially this follows advice about implementing Runnable rather than subclassing Thread, tying the task to the specific Thread that executes it defeats the purpose of that advice, which is intended to facilitate decoupling the task from how it is executed.
Tasks that need to be run independently or asynchronously shouldn't have to know about Thread, it's better to design them so that they can be run by an executor service instead. There are two interfaces, Runnable and Callable, which are provided in order to allow you to specify tasks in a way that doesn't tie them to a specific means of execution, as opposed to subclassing Thread, where you have tied your task to a specific Thread object. That way you have the freedom to change how they are executed without changing the task, and you also will have the freedom to create tasks that are Cloneable, since no Thread will be involved.
