Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33193 > unrolled thread

Why it necessary to implement clonealbe interface?

Back to article view | Back to comp.lang.java.programmer

Contents

  Why it necessary to implement clonealbe interface? Xue Feng <xf.lotus@yahoo.com> - 2015-11-24 23:28 +0800
    Re: Why it necessary to implement clonealbe interface? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-24 11:03 -0500
      Re: Why it necessary to implement clonealbe interface? Arne Vajhøj <arne@vajhoej.dk> - 2015-11-24 19:49 -0500
        Re: Why it necessary to implement clonealbe interface? Eric Douglas <e.d.programmer@gmail.com> - 2015-11-25 11:01 -0800
          Re: Why it necessary to implement clonealbe interface? Arne Vajhøj <arne@vajhoej.dk> - 2015-11-25 16:41 -0500
    Re: Why it necessary to implement clonealbe interface? Lew <lewbloch@gmail.com> - 2015-11-29 23:00 -0800

#33193 — Why it necessary to implement clonealbe interface?

A class has to implement cloneable interface, otherwise its object can 
not be cloned. IMO, it is enough that a class clone itself by inheriting 
the clone method from Object class. It is somewaht reduntant to 
implement cloneable interface. Actually, there is nothing in cloneable 
interface. Namely, it is defined as follows:

interface cloneable {
}

I wonder the reason for this design. Any explanation? Thanks.

[toc] | [next] | [standalone]

#33194

On 11/24/2015 10:28 AM, Xue Feng wrote:
> A class has to implement cloneable interface, otherwise its object can
> not be cloned. IMO, it is enough that a class clone itself by inheriting
> the clone method from Object class. It is somewaht reduntant to
> implement cloneable interface. Actually, there is nothing in cloneable
> interface. Namely, it is defined as follows:
>
> interface cloneable {
> }
>
> I wonder the reason for this design. Any explanation? Thanks.

     Object's clone() is a protected method, so it can be called only
from a subclass of Object.  Since every class descends from Object
this may not seem like much of a restriction, but it is: If classes
X and Y both inherit clone() from object, then X's clone() and Y's
clone() are also protected.  X can call its own clone() and can call
Object's clone(), but it cannot call Y's clone -- because Y's clone()
is protected, and X is not a subclass of Y.  Similarly, Y can call
its own clone() and Object's clone(), but cannot call X's clone().
So, mere inheritance of the clone() method is not enough to make it
usable outside one branch of the inheritance tree.

     Also, Object's clone() throws CloneNotSupportedException if the
object being cloned is of a non-Cloneable class.  The Cloneable
interface is a "marker," a notification that the class has provided
for its own cloning.  (The "marker interface" pattern is unusual, and
some would even call it an anti-pattern, but cloning is an unusual
operation to begin with.)  By implementing Cloneable, a class announces
to Java: "I have decided what it means to make a `clone' of my objects,
and have made arrangements to create such clones."  Usually, the
arrangements involve overriding the inherited clone() so as to do
some class-specific things; the class might also choose to make its
overriding clone() method public.

     There's a good explanation of Cloneable -- advantages, drawbacks,
and gotchas -- in "Effective Java" by Bloch, a book I feel every
serious Java programmer should own or at least study.  I strongly
suggest you obtain a copy, and believe you will find it highly valuable.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33196

On 11/24/2015 11:03 AM, Eric Sosman wrote:
> On 11/24/2015 10:28 AM, Xue Feng wrote:
>> A class has to implement cloneable interface, otherwise its object can
>> not be cloned. IMO, it is enough that a class clone itself by inheriting
>> the clone method from Object class. It is somewaht reduntant to
>> implement cloneable interface. Actually, there is nothing in cloneable
>> interface. Namely, it is defined as follows:
>>
>> interface cloneable {
>> }
>>
>> I wonder the reason for this design. Any explanation? Thanks.
>
>      Object's clone() is a protected method, so it can be called only
> from a subclass of Object.  Since every class descends from Object
> this may not seem like much of a restriction, but it is: If classes
> X and Y both inherit clone() from object, then X's clone() and Y's
> clone() are also protected.  X can call its own clone() and can call
> Object's clone(), but it cannot call Y's clone -- because Y's clone()
> is protected, and X is not a subclass of Y.  Similarly, Y can call
> its own clone() and Object's clone(), but cannot call X's clone().
> So, mere inheritance of the clone() method is not enough to make it
> usable outside one branch of the inheritance tree.
>
>      Also, Object's clone() throws CloneNotSupportedException if the
> object being cloned is of a non-Cloneable class.  The Cloneable
> interface is a "marker," a notification that the class has provided
> for its own cloning.  (The "marker interface" pattern is unusual, and
> some would even call it an anti-pattern, but cloning is an unusual
> operation to begin with.)  By implementing Cloneable, a class announces
> to Java: "I have decided what it means to make a `clone' of my objects,
> and have made arrangements to create such clones."  Usually, the
> arrangements involve overriding the inherited clone() so as to do
> some class-specific things; the class might also choose to make its
> overriding clone() method public.

To this excellent explanation I would just like to add that
today (today as in last decade) instead of a marker interfaces
one would usually use an annotation. But Cloneable goes back
to Java 1.0.

Arne

[toc] | [prev] | [next] | [standalone]

#33198

On Tuesday, November 24, 2015 at 7:50:28 PM UTC-5, Arne Vajhøj wrote:
> On 11/24/2015 11:03 AM, Eric Sosman wrote:
> > On 11/24/2015 10:28 AM, Xue Feng wrote:
> >> A class has to implement cloneable interface, otherwise its object can
> >> not be cloned. IMO, it is enough that a class clone itself by inheriting
> >> the clone method from Object class. It is somewaht reduntant to
> >> implement cloneable interface. Actually, there is nothing in cloneable
> >> interface. Namely, it is defined as follows:
> >>
> >> interface cloneable {
> >> }
> >>
> >> I wonder the reason for this design. Any explanation? Thanks.
> >
> >      Object's clone() is a protected method, so it can be called only
> > from a subclass of Object.  Since every class descends from Object
> > this may not seem like much of a restriction, but it is: If classes
> > X and Y both inherit clone() from object, then X's clone() and Y's
> > clone() are also protected.  X can call its own clone() and can call
> > Object's clone(), but it cannot call Y's clone -- because Y's clone()
> > is protected, and X is not a subclass of Y.  Similarly, Y can call
> > its own clone() and Object's clone(), but cannot call X's clone().
> > So, mere inheritance of the clone() method is not enough to make it
> > usable outside one branch of the inheritance tree.
> >
> >      Also, Object's clone() throws CloneNotSupportedException if the
> > object being cloned is of a non-Cloneable class.  The Cloneable
> > interface is a "marker," a notification that the class has provided
> > for its own cloning.  (The "marker interface" pattern is unusual, and
> > some would even call it an anti-pattern, but cloning is an unusual
> > operation to begin with.)  By implementing Cloneable, a class announces
> > to Java: "I have decided what it means to make a `clone' of my objects,
> > and have made arrangements to create such clones."  Usually, the
> > arrangements involve overriding the inherited clone() so as to do
> > some class-specific things; the class might also choose to make its
> > overriding clone() method public.
> 
> To this excellent explanation I would just like to add that
> today (today as in last decade) instead of a marker interfaces
> one would usually use an annotation. But Cloneable goes back
> to Java 1.0.
> 
> Arne

So you think it does just look stupid because it was written into Java 1.0?
My only other thought for wanting an interface class was to say whether or not you want your cloneable object to return the condition
if (myObject instanceof Cloneable) {

[toc] | [prev] | [next] | [standalone]

#33201

On 11/25/2015 2:01 PM, Eric Douglas wrote:
> On Tuesday, November 24, 2015 at 7:50:28 PM UTC-5, Arne Vajhøj wrote:
>> To this excellent explanation I would just like to add that
>> today (today as in last decade) instead of a marker interfaces
>> one would usually use an annotation. But Cloneable goes back
>> to Java 1.0.
>
> So you think it does just look stupid because it was written into Java 1.0?

I think it looks the way it does because that was the only way in
Java 1.0-1.4 and that it would have been made differently in Java 1.5-.

Nothing stupid really.

> My only other thought for wanting an interface class was to say whether or not you want your cloneable object to return the condition
> if (myObject instanceof Cloneable) {

With annotation you would use:

if(myObject.getClass().getAnnotation(Cloneable.class) != null) {

That in itself does not look like an improvement.

But first it uses the mechanism intended for such thing:
- interfaces specify what methods implementing classes must have
- annotations provide meta-data about class (and other)

It is meta-data not required methods that we need here.

And secondly it provides additional capabilities.

One could define an mode attribute so you could use:

@Cloneable(mode=CloneMode.SHALLOW)

and:

@Cloneable(mode=CloneMode.DEEP)

and access it from the processing code.

Arne

[toc] | [prev] | [next] | [standalone]

#33241

Xue Feng wrote:
> A class has to implement cloneable interface, otherwise its object can 
> not be cloned. IMO, it is enough that a class clone itself by inheriting 
> the clone method from Object class. It is somewaht reduntant to 
> implement cloneable interface. Actually, there is nothing in cloneable 
> interface. Namely, it is defined as follows:
> 
> interface cloneable {
> }
> 
> I wonder the reason for this design. Any explanation? Thanks.

There is no 'cloneable' interface in the standard Java API.

The reason for the requirements of 'Cloneable' that are similar to your question is to prevent cloning except where it's actually wanted, but have the mechanism in place from the very root of the object hierarchy so it is available for such use.

-- 
Lew

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web