I don't understand Cloneable

Discussion in 'Java' started by cody, Aug 16, 2003.

  1. cody

    cody Guest

    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?

    --
    cody

    [Freeware, Games and Humor]
    www.deutronium.de.vu || www.deutronium.tk
    cody, Aug 16, 2003
    #1
    1. Advertising

  2. 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.


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

    Always remember: The answer is forty-two, there can only be wrong
    questions!
    Lothar Kimmeringer, Aug 16, 2003
    #2
    1. Advertising

  3. 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.

    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
    Robert Olofsson, Aug 16, 2003
    #3
  4. cody

    Tim Tyler Guest

    Lothar Kimmeringer <> wrote:
    : 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
    --
    __________
    |im |yler http://timtyler.org/
    Tim Tyler, Aug 16, 2003
    #4
  5. cody

    Roedy Green Guest

    On Sat, 16 Aug 2003 20:33:49 +0200, "cody" <> wrote
    or quoted :

    >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 ...



    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Aug 16, 2003
    #5
  6. cody

    xarax Guest

    Lothar Kimmeringer <> wrote in message news:<12t2qdglluh4z$>...
    > 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.
    >
    >
    > 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.
    xarax, Aug 16, 2003
    #6
  7. cody

    Chris Smith Guest

    cody wrote:
    > 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
    Chris Smith, Aug 20, 2003
    #7
  8. cody

    Dale King Guest

    In article <>, says...
    > xarax <> wrote:
    >
    > : 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.
    --
    Dale King
    Dale King, Aug 22, 2003
    #8
  9. cody

    Chris Uppal Guest

    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.

    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
    Chris Uppal, Aug 22, 2003
    #9
  10. cody

    Tim Tyler Guest

    Dale King <> wrote:
    : In article <>, says...
    :> xarax <> wrote:

    :> : 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.
    --
    __________
    |im |yler http://timtyler.org/
    Tim Tyler, Aug 22, 2003
    #10
  11. cody

    Tim Tyler Guest

    Chris Uppal <-this.org> wrote:
    : 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.
    --
    __________
    |im |yler http://timtyler.org/
    Tim Tyler, Aug 22, 2003
    #11
  12. cody

    Chris Uppal Guest

    Tim Tyler wrote:

    > > 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.


    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
    Chris Uppal, Aug 22, 2003
    #12
  13. cody

    Tim Tyler Guest

    Chris Uppal <-this.org> wrote:
    : 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.
    --
    __________
    |im |yler http://timtyler.org/
    Tim Tyler, Aug 22, 2003
    #13
  14. In article <>, Tim Tyler <> wrote:
    >
    >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
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
    Bent C Dalager, Aug 22, 2003
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Malcolm Ryan
    Replies:
    4
    Views:
    930
    Greg Stark
    Feb 1, 2005
  2. Guest

    Cloneable questions

    Guest, Feb 20, 2005, in forum: Java
    Replies:
    3
    Views:
    502
    Thomas B├╝hler
    Feb 21, 2005
  3. Thomas G. Marshall

    Why not cloneable by default?

    Thomas G. Marshall, Mar 19, 2005, in forum: Java
    Replies:
    142
    Views:
    3,363
    Chris Smith
    Apr 11, 2005
  4. Roedy Green

    Cloneable

    Roedy Green, Jul 15, 2005, in forum: Java
    Replies:
    7
    Views:
    2,278
    Thomas G. Marshall
    Jul 16, 2005
  5. Ian Pilcher

    Cloning a Cloneable Map

    Ian Pilcher, Oct 6, 2005, in forum: Java
    Replies:
    3
    Views:
    5,727
    Ian Pilcher
    Oct 6, 2005
Loading...

Share This Page