This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Why PROTECTED method in class Object? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Why PROTECTED method in class Object?" Watch "Why PROTECTED method in class Object?" New topic
Author

Why PROTECTED method in class Object?

Isaac Han
Greenhorn

Joined: Sep 10, 2005
Posts: 6
I don't know why class Object have two PROTECTED method -- clone() and finalize(). And in JUnit's source code, I notice that kent write :
public class AClass extends Object {}
I really don't understand what diffrient from
public class AClass {}
Any help? Thanks!
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
1. Why is clone protected?

Nobody is going to claim that the design of the cloning mechanism in Java is
perfect (Cloneable? Is that even the correct spelling ), but not all objects
are designed to be cloneable --if method clone were public, then you could apply
it to objects that you didn't intend to:

If you are making a class cloneable, you have the option of changing the access
level of clone to public when you override the method. You also have the option
of losing the "thow CloneNoSupportedException", if that's your design:

So clone is protected because it's up to subclasses to set up the cloning mechanism.


2. Why is finalize protected?

You should never call finalize, other that having a subclass's finalize method
call its superclass's finalize, where protected access works just fine. The garbage collector
may call the finalize method, but it's able to get around the proctected access. Thus
public access is not needed. And as an aside, there are good reasons to avoid overriding
finalize in most cases, anyway.

3. "class AClass extends Object" versus "class AClass"

There is no difference. Some people write "extends Object" as a matter of coding style,
some don't, for the same reason! Take your pick and be consistent.
[ November 01, 2005: Message edited by: Jeff Albrechtsen ]

There is no emoticon for what I am feeling!
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19651
    
  18

finalize() is protected because only the JVM should access it, and it shouldn't be called from any user code. If it's public you could finalize an Object while it is not yet eligible for garbage collection. It is not package visible or private because subclasses should always call super.finalize(). Therefore, only protected will do.

clone() is protected for similar reasons. You cannot just call clone() from other code - if the class is not Cloneable it will go wrong. However, you need access to super.clone() from any subclass. If clone() is supported in a class it will be made public by that class.

I only have one problem with clone() - I think Cloneable should require any interface implementing Cloneable to implement clone() as well. What's the reason for implementing Cloneable if you don't provide a public void clone() anyway? Unless you're using it to clone subclasses only, and want to be able to call super.clone().


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Hi Isaac,

Welcome to JavaRanch!

First, the easy question: there's absolutely no difference between saying that a class "extends Object" or having no extends clause at all. Some people like to include "extends Object" for clarity, and some people include it because they're using an IDE that inserts it automatically. But most people don't use it, and most people don't like it.

Now, the other question: both clone() and finalize() are strange methods, each with a special story. finalize() is intended to be called by the JVM on an object that's about to be garbage collected; no ordinary code should ever call it, except that if you're overriding finalize() (you can do this to add some clean-up code that is called before garbage collection) then you should always call super.finalize(). That's why finalize() is "protected" -- so that subclasses of Object can override it and call it. Otherwise, it could be private. There's no need for it to be public, as no one should ever call it otherwise.

Finally, clone() (which makes a copy of the object) is designed so that a class can prevent anyone from calling it unless the author of that class wants them to. Accordingly, clone() is protected. If the author of a class wants to make clone() publically available, then the author should override clone(), call super.clone(), and make that override public. To make clone() work, by the way, the author also has to declare the class implements the Cloneable interface -- otherwise Object.clone() will refuse to work.


[Jess in Action][AskingGoodQuestions]
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
As long as I was posting a clone method, I should add that in the current
version of Java (1.5), they've adding a contraviance (or is that covariance)
rule, so when you override a method, you can "subtype" the return type:

You can see this is already in effect for some types, like array types:
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Yes, I will claim the cloning facility of Java is perfect.

Please stop making the clone method public. its a facility to provide a class with a bottom up copy of itself. Nothing more nothing less.

If you want to provide to the _public_ a way to get a copy of your object try creating your own method


Again, do not publicize the clone method, use it internally. Thats what I prefer and it removes the confusion people have. It really does not matter so long as you recognize that Cloneable is a facility NOT a simple interface.
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Originally posted by Mr. C Lamont Gilbert:

If you want to provide to the _public_ a way to get a copy of your object try creating your own method


That's fine, too. I see this as a to-mah-to/to-may-to issue. You introduce
getCopy/I reintroduce clone. All I can say is that in the API, they tend
to use clone -- for example, cloning arrays, concrete collections like
ArrayList, Calendar and so on. So there is a pattern if you wish to follow it.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
So CLG, have you noticed that the API for Cloneable specifically recommends making the clone() method public? Doesn't seem "perfect" if the documentation is contrary to what you assert is best practice, does it? The whole thing (implementation and documentation) just seems needlessly convoluted to me. I know how to using cloning in Java correctly; I just wish they'd set it up in a more straightforward manner.
[ November 01, 2005: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Isaac Han
Greenhorn

Joined: Sep 10, 2005
Posts: 6
Thanks all of you.

But, i still puzzle: Object class is the root of ALL classes, So i conclude that there are no difference between "public" and "protectd" in Object class.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37953
    
  22
Not that I know much about clone() . . . .

The difference between public and protected is that protected allows for access from any class in the same package (well, you can't write a new java.lang.Anything class) or from inside a subclass.
So every class can have the statement in, and your class MyClass can have a method like
but the point of being protected means you can't call the super.clone() method from another class in your project.
 
Consider Paul's rocket mass heater.
 
subject: Why PROTECTED method in class Object?
 
Similar Threads
about ==
Can anyone explain executing at runtime vs compile?
newInstance() doubt
Dynamic Method Lookup?
Modifier protected does not hide inherited members to (static) code of superclass package