Defender-methods: A chance to finally retrofit Cloneable with clone method?

[Joe Darcy]

Hello.

There is a long, sad story behind why Cloneable is only a marker 
interface; IIRC, at least some of that story is recounted in "Effective 
Java."

In any case, I do not expect defenders to be used to retrofit a clone 
method to Cloneable.

-Joe

On 8/8/2011 10:53 AM, Paul Benedict wrote:
> I think you should avoid the Cloneable interface at all costs. It was
> a bad idea from the beginning. I don't think it's possible force a
> universal definition on cloning onto application developers (there are
> too many differing needs), which is probably why this interface is
> hardly used.
>
> On Mon, Aug 8, 2011 at 12:15 PM, Gernot Neppert<mcnepp02 at googlemail.com>  wrote:
>> I was wondering whether it would be possible to retrofit the interface
>> java.lang.Cloneable with a public clone method, now that
>> defender-methods will be available.
>> Even after living without a standard cloning mechanism im Java for 10+
>> years, I'd still love to have one!
>>
>> For the default implementation, I can see the following choices:
>>
>> 1. Invoke the built-in cloning mechanism through Object.clone(). Since a
>> static defender method could not directly invoke Object.clone through
>> its argument, it would have to be either native or delegate to some kind
>> of  native "System.systemClone" method to achive this.
>>
>> 2. Throw CloneNotSupportedException.
>>
>> 3. Throw UnsupportedOperationException.
>>
>> 4. Return the object itself (shallow clone).
>>
>> Personally, I think 2.) would be by far the worst choice, because it
>> would make it necessary for the interface to declare the checked
>> CloneNotSupportedException, somehow negating the whole purpose of having
>> a clone method in an interface at all!
>>
>> What do the experts think?
>>
>>