Defender-methods: A chance to finally retrofit Cloneable with clone method?
joe.darcy at oracle.com
Mon Aug 8 11:07:36 PDT 2011
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
In any case, I do not expect defenders to be used to retrofit a clone
method to Cloneable.
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?
More information about the coin-dev