Name: nt126004 Date: 04/23/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

A DESCRIPTION OF THE PROBLEM :
I've run in to this before, and it's really annoying me. I
found some threads on Usenet from people with simlar issues,
and I think it's time to fix it.

The problem is this: it is bad design that the language
doesn't include some way of knowing that an object has a
public clone() method. I've see people complaining of the
issue with Shape. I'm very currently dealing with it with
Collection and Set.

Now, I agree that there are good reasons for having clone()
be protected, and even good reasons for not having Cloneable
include a public clone method. HOWEVER, it is also very
true that you should NOT have to deal with specific
implementations of interfaces in order to know that it has a
public clone method.

Let us take Set, for example. It doesn't have a public
clone method. That's fine, it makes sense. Maybe you have
a multi-tiered Set that is storing its data elsewhere where
clone() would be difficult (or some other esoteric reason).
 However, if I am using Sets, and I want to create a copy, I
shouldn't have as my only two options to create, say, a
HashSet with the Collection-arg constructor; or, to test to
see if the set is one which I already know has a public
clone so I can use it. Why? The constructor that takes a
Collection is inefficient. And maybe the method I'm writing
will get passed yet another implementation of Set that also
has an efficient clone method, but that I wasn't expecting
when I wrote the method.

Solution? The next version of the API should include this
interface:

public interface PublicCloneable extends Cloneable
{
  public Object clone();
}

And *every* *single* class in the java. javax. hierarchies
that has a public clone() method should implement that
interface. Then, at least, we could use the (often more
efficient) clone methods when they apply and we could have
some test to find out when they *do* apply, and we could
still program to interfaces instead of having to face the
bad choice between breaking our model or being inefficient.
 This shouldn't cause any problems with any of the existing
code-base out there either. It should be VERY easy to
change the language to work in this manner.

This bug can be reproduced always.
(Review ID: 145430)
======================================================================