I don't understand Cloneable

[cody]

why the interface Cloneable doesn't contain any methods? shouldn't it
contain at least the clone() method? instead clone() is a member of object
and has protected access only which makes it unusable from outside.

could somebody please enlighten me about that?

 

[Lothar Kimmeringer]

why the interface Cloneable doesn't contain any methods? shouldn't it
contain at least the clone() method? instead clone() is a member of object
and has protected access only which makes it unusable from outside.

could somebody please enlighten me about that?

It's the same reason, why there is no method in java.io.Serializable.
It's just a "marker" for marking objects to be able to be cloned.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Robert Olofsson]

cody ([email protected]) wrote:
: why the interface Cloneable doesn't contain any methods? shouldn't it
: contain at least the clone() method? instead clone() is a member of object
: and has protected access only which makes it unusable from outside.

No, when overloading methods you may make them more public that is
private->protected or public is fine, protected->public is also fine.
So that clone is unusable is not true.

/robo

 

[Tim Tyler]

: On Sat, 16 Aug 2003 20:33:49 +0200, cody wrote:

:> why the interface Cloneable doesn't contain any methods? shouldn't it
:> contain at least the clone() method? instead clone() is a member of object
:> and has protected access only which makes it unusable from outside.
:>
:> could somebody please enlighten me about that?

: It's the same reason, why there is no method in java.io.Serializable.
: It's just a "marker" for marking objects to be able to be cloned.

Serializable has specific support from the JVM. It has no associated
method that must be implemented.

Cloneable is different:

``If you've read the item about cloning in my book, especially if you
read between the lines, you will know that I think clone is deeply
broken. There are a few design flaws, the biggest of which is that the
Cloneable interface does not have a clone method. And that means it
simply doesn't work [...]''

It's a shame that Cloneable is broken, but it happens. The original Java
APIs were done very quickly under a tight deadline to meet a closing
market window. The original Java team did an incredible job, but not
all of the APIs are perfect. Cloneable is a weak spot, and I think
people should be aware of its limitations.''

- A Conversation with Josh Bloch http://www.artima.com/intv/bloch13.html

 

[Roedy Green]

why the interface Cloneable doesn't contain any methods? shouldn't it
contain at least the clone() method? instead clone() is a member of object
and has protected access only which makes it unusable from outside.

could somebody please enlighten me about that?

see http://mindprod.com/jgloss/clone.html

Your question may be really be of the form, "I understand how it
works, but WHY did they do that?".

clone is a native method. It is not something you cannot easily write
yourself. Therefore it had to be built into Object. Yet they did not
want people cloning ALL objects willy nilly. They wanted to give the
programmer control over when clone made sense.

The way it is, you can redefine clone to leave out some fields, do a
deep copy of some fields, create a unique serial number ...

 

[xarax]

It's the same reason, why there is no method in java.io.Serializable.
It's just a "marker" for marking objects to be able to be cloned.


Regards, Lothar

The cloning process looks at the inheritance hierarchy to
find the parent classes that implement Cloneable. Those
classes are eligible for cloning. Otherwise, the parent
class is ineligible for cloning. See the details about
how the cloning process figures out all of this. The
interface is an important marker for the process. Putting
the clone() method in the interface would force public
accessibility to that method, which is not an intended
effect of marking a class as Cloneable.

 

[Chris Smith]

in .NET the interface ICloneable contains the object Clone() method as one
would expect,
additionally the class object has a protected method object MemberwiseCopy()
which creates a bitwise clone of the object. i think this is more logically
and better than the solution in java.

I agree.

but the big question is how do i create a copy ctor without copying each
member manually? clone() is useless here.

Copy constructors are inherently flawed anyway, so there's no real point
in worrying about this. As confusing and strange as clone() is, at
least it works in the presence of inheritance.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dale King]

: Putting the clone() method in the interface would force public
: accessibility to that method, which is not an intended
: effect of marking a class as Cloneable.

That's a generic problem with using Java interfaces - if you
implement them the world and his wife gets to use them - which
is not necessarily what the programmer wants.

Not strictly true. While all members of the interface are public, the
interface itself may not be. It could have package access or if it were
nested can even be private or protected.

 

[Chris Uppal]

Not strictly true. While all members of the interface are public, the
interface itself may not be.

Agreed, and if that's not a clear indication that the spec is misconceived then
I don't know what would be.

IMO the condition *should* be that the members required by an interface must be
at least as accessible as the interface itself.

BTW can anyone remember if the JVM spec mirrors the Java spec in this ?
(Obviously there are no private or protected nested interfaces, but does it
allow package access interfaces to be "satisfied" by package access members ?)

-- chris

 

[Tim Tyler]

: In article <[email protected]>, (e-mail address removed) says...

:> : Putting the clone() method in the interface would force public
:> : accessibility to that method, which is not an intended
:> : effect of marking a class as Cloneable.
:>
:> That's a generic problem with using Java interfaces - if you
:> implement them the world and his wife gets to use them - which
:> is not necessarily what the programmer wants.

: Not strictly true. While all members of the interface are public, the
: interface itself may not be. It could have package access or if it were
: nested can even be private or protected.

Fair enough.

This doesn't help much with the clone problem, though.

The Cloneable interface would /have/ to be public - else
you could not access it at all from most classes. However,
you might not want the clone method to be public - since
you may not want everyone to be able to copy your object.

If that sort of pattern is what you are after, you can't
use a method in a Java interface - because all such
methods are forced to be public.

I reckon this is a generic problem with Java interfaces.

It seems as though you ought to use an interface here -
but there are potentially-undesirable side effects on
the scope of the resulting methods.

 

[Tim Tyler]

: Dale King wrote:

:> > That's a generic problem with using Java interfaces - if you
:> > implement them the world and his wife gets to use them - which
:> > is not necessarily what the programmer wants.
:>
:> Not strictly true. While all members of the interface are public, the
:> interface itself may not be.

: Agreed, and if that's not a clear indication that the spec is
: misconceived then I don't know what would be.

: IMO the condition *should* be that the members required by an interface
: must be at least as accessible as the interface itself.

That wouldn't help with the Cloneable problem. There
we want the inteface to be public - so anyone can use it.

However we don't want to place the burden of making their clone
method public on all the implementors of Cloneable.

So that seems like a case where the member(s) of the interface
ought to be /less/ accessible than the interface itself.

 

[Chris Uppal]

That wouldn't help with the Cloneable problem. There
we want the inteface to be public - so anyone can use it.

Agreed. I was talking about the Java interfaces in general rather than this
specific case.

However we don't want to place the burden of making their clone
method public on all the implementors of Cloneable.

I don't see why not. Few objects *shouldn't* be cloned, so it seems to me that
the facility should be "opt out" not "opt in". E.g. Object.clone() could be
public and throw a CloneNotSupportedException if the class in question
didn't support/allow cloning.

-- chris

 

[Tim Tyler]

: Tim Tyler wrote:

:> However we don't want to place the burden of making their clone
:> method public on all the implementors of Cloneable.

: I don't see why not. [...]

That is the reason that was given as to why Java's designers didn't
put the clone method in the Cloneable interface:

``Putting the clone() method in the interface would force public
accessibility to that method, which is not an intended effect
of marking a class as Cloneable.''

I think that is a reasonable point - you might not want
the clone method exposed in your public API - you
might want to restrict who can make copies your objects.

 

[Bent C Dalager]

I think that is a reasonable point - you might not want
the clone method exposed in your public API - you
might want to restrict who can make copies your objects.

While that is true, I still feel they could have had a PublicClonable
interface for those that _do_ want to expose cloning. This would make
sense for a large number of classes, and would enable people to make
copies of arbitrary clonable objects without serialization or
reflection hacks.

Cheers
Bent D