This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Typical Cloneable implementation offends my delicate sensibilities Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Typical Cloneable implementation offends my delicate sensibilities" Watch "Typical Cloneable implementation offends my delicate sensibilities" New topic
Author

Typical Cloneable implementation offends my delicate sensibilities

Krep Lock
Ranch Hand

Joined: Sep 19, 2006
Posts: 43
I'm missing something on the following typical implementation of Cloneable's clone method:



Line 17 is my problem. The confusion is: why does the clone method get to directly set the bell instance variable of the copy even while it is private? Shouldn't it be forced to use a mutator method like everyone else? Is this a Cloneable-breaks-the-rules thing or am I missing something in plain sight?
pete stein
Bartender

Joined: Feb 23, 2007
Posts: 1561
From as I understand it, since copy is a Cat object, then Cat class can deal directly with its methods and fields, even the private ones. It's the same for when you want to do an equals(...) override: The current object has the ability to directly see and manipulate the object passed as a paramter (if it's the same type).
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

Or in other words, in Java, "private" applies at the class level, not at the object level.


[Jess in Action][AskingGoodQuestions]
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
However it's also true that clone() breaks several rules. In particular, the clone() method in Object (which is the one you get when you access super.clone() here) is quite capable of copying private fields from any object in any class - provided that class implements Cloneable. This despite the face that it's a method of class Object, which should (in theory) have no access to private fields of other classes. Except that Java's creators decided to bend/break the rules here. They can do that.

This means that line 17 is completely unnecessary. The "bell" field was already copied by super.clone(). No need to copy it again.

But if, for some reason, you do find it necessary to access a private field of an instance of a given class, from a different instance of the same class... you can do that. Because that's how "private" has always been defined, in Java. Private to the class, not private to an instance. As EFH said.
Krep Lock
Ranch Hand

Joined: Sep 19, 2006
Posts: 43
Wow, I had no idea.

Thanks for the answers.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19541
    
  16

One note: don't return null when you catch those CloneNotSupportedExceptions. Since your classes implement Cloneable that exception should never occur, so it's a better idea to throw an error:
That's how Sun does it as well.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Typical Cloneable implementation offends my delicate sensibilities
 
Similar Threads
Doubt with Overriding concept in Java
Cloneable and deep copy.
Same old question about clone(). How ???
Object cast in Prototype pattern
I am getting clone() has protected access in java.lang.Object