Defender-methods: A chance to finally retrofit Cloneable with clone method?
Paul Benedict
pbenedict at apache.org
Mon Aug 8 10:53:27 PDT 2011
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
mailing list