File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
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 Java Interview Guide this week in the Jobs Discussion 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

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

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

Joined: Jul 08, 2003
Posts: 24199

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: 3028
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

Joined: Oct 27, 2005
Posts: 20279

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.

How To Ask Questions How To Answer Questions
I agree. Here's the link:
subject: Typical Cloneable implementation offends my delicate sensibilities
It's not a secret anymore!