Name: rl43681 Date: 10/20/2003


A DESCRIPTION OF THE PROBLEM :
It is sometimes said that CloneNotSupportedException is thrown in classes that ?conditionally? support cloning. In fact, the API docs for the clone() method in Object include the following.
Throws:

"CloneNotSupportedException - if the object's class does not support the Cloneable interface. Subclasses that override the clone method can also throw this exception to indicate that an instance cannot be cloned."

Furthermore, the API docs for CloneNotSupportedException explicitly state:

"Thrown to indicate that the clone method in class Object has been called to clone an object, but that the object's class does not implement the Cloneable interface.

"Applications that override the clone method can also throw this exception to indicate that an object could not or should not be cloned."

Popular literature on the subject reflects theses API docs. For example, the following quote is from The Java Programming Language doubtless has led many other technical writers to say essentially the same thing.

"A class can have one of four different different attitudes toward clone:
 ?
 "Conditionally support clone. Such a class might be a collection class that can be cloned in principle but cannot successfully be cloned unless its contents can be cloned. This kind of class will implement Cloneable, but will let its clone method pass through any CloneNotSupportedException it may receive from other objects it tries to clone?"

Indeed, the classic example of this is an array or other container full of objects that cannot be cloned. If the API docs for a container class specifically state that the clone() method returns a deep copy of the object, then an exception must be thrown if the objects cannot be cloned. This applies equally to other classes that include instances of a container class.

This is a fundamental API design flaw the pervades the Java programming language. It is not unlike FileNotFoundException in that at the very least the exception class in question is misnamed. The difference is that this problem can be solved. An ObjectNotCloneableException exception superclass should be declared in the java.lang package with CloneNotSupportedException and DeepCopyException as subclasses. The latter would be very useful in copy constructors as well, which is yet another reason it should be added to the java.lang package. If an object is not cloneable for any other reason than the inability to make a deep copy, ObjectNotCloneableException can be subclassed. The introduction of these two new exception classes in no way presents a backards compatibility problem. Sun needs only to introduce ?As of the 1.x release...? language to the API docs for the clone() method and the CloneNotSupportedException class.

The reason why this is an API design problem is that classes that would throw the new DeepCopyException do in fact implement Cloneable. The API docs for the clone() method and the CloneNotSupportedException class are clearly self-contradictory in this respect. More fundamentally, these are two very different exceptions. The specific problem is in differentiating subclasses that do not in fact support cloning by unconditionally throwing CloneNotSupportedException in overriding implementations of a public clone() method from a superclass that cannot clone a particular object for whatever reason. Client programmers have no way of differentiating between the two. This is obviously not a pressing problem because Java programmers have not been clamoring for a solution, but it is one that deserves attention.


URL OF FAULTY DOCUMENTATION :
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/CloneNotSupportedException.html
(Review ID: 214543)
======================================================================