Confusion with Object class
We all know that all classes implements Object directly or indirectly. That is why we get all public methods available in Object class.
But as the definition says, if our class extends Object class indirectly and we are able to get public methods like notify(), notifyAll() etc why are we unable to get the protected method clone() of this class even our class extends Object class?
I mean to say either both type of methods must not be available or must be available.
Hope I am clear about my issue?
Can any of you guys explain it?
Regards.
[578 byte] By [
Christia] at [2007-11-27 10:49:21]
The point of protected is that protected fields and methods are available only in the definition of sub-classes. So you can use "super.clone();" because that references clone in a superclass of the class you are defining but you can't use "someObject.clone()" because that's trying to reference a protected member of a different class.
In order to make an object Clonable you need to override clone with a public version (which normally calls super.clone())
> We all know that all classes implements Object
> directly or indirectly.
No, they extend it. Object isn't abstract.
> But as the definition says, if our class extends
> Object class indirectly and we are able to get public
> methods like notify(), notifyAll() etc why are we
> unable to get the protected method clone() of this
> class even our class extends Object class?
We can.
class C {
void foo() throws Exception {
clone();
}
}
Compiles fine for me.
> I mean to say either both type of methods must not be
> available or must be available.
Is it possible that you don't quite understand the scope of "protected"?
Hi Christi,
I would love to help but I think I am not getting your question correctly. You might have to explain more.
What do you mean by "unable to get the protected method clone()"? Are you asking that why "clone()" is protected from design point of view?
Regards,
D
Your class needs to implement Cloneable interface.
For example this will throw an exception -
public class TestClone {
void foo() throws Exception {
clone();
}
public static void main(String args[]){
try {
new TestClone().foo();
}catch (Exception ex){
ex.printStackTrace();
}
}
}
This will not -
public class TestClone implements Cloneable{
void foo() throws Exception {
clone();
}
public static void main(String args[]){
try {
new TestClone().foo();
}catch (Exception ex){
ex.printStackTrace();
}
}
}
The Cloneable interface doesn't affect compilation errors. It's just a marker without which calling Object.clone() throws a CloneNotSupportedException.
> The Cloneable interface doesn't affect compilation
> errors. It's just a marker without which calling
> Object.clone() throws a CloneNotSupportedException.
I'm not sure what compilation errors you expected to get rid of using Cloneable interface... Could you elaborate please?
> I'm not sure what compilation errors you expected to
> get rid of using Cloneable interface...
None. He said it won't affect them. And the OP seems to be facing a compilation error - visibility issues usually only arise here, unless there's an inconsistant compilaiton.
Is the compilation error - your assumption ?
It could be a compilation issue or an exception being generated at runtime.
> Your class needs to implement Cloneable interface.
That's not why you can't do something.clone(). It's because clone() is protected. Even if you implement Cloneable, you still can't do something.clone() unless that class makes clone pubilc.
jverda at 2007-7-29 11:18:37 >
> Is the compilation error - your assumption ?
Because he's asking why he can't call a protected method a certain way. That's a compilation issue.
Because Cloneable is a marker interface and doesn't define the clone method, not implementing Cloneable is NOT why he's unable to call clone().
jverda at 2007-7-29 11:18:37 >
If you do read the original post -
are we unable to get the protected method clone() of this class even our class extends Object class?
That's not why you can't do something.clone(). It's because clone() is protected - So thank you for stating the obvious.
Well Rene there are probably a lot of things I agree with you on...
Because he's asking why he can't call a protected method a certain way. That's a compilation issue. - At this point however this is not one of them
> If you do read the original post -
> are we unable to get the protected method clone()
> of this class even our class extends Object
> class?
>
> That's not why you can't do something.clone().
> It's because clone() is protected - So thank you
> for stating the obvious.
If only the latter statement were the reply to the former statement, instead of a different post...
> Well Rene there are probably a lot of things I agree
> with you on...
>
> Because he's asking why he can't call a protected
> method a certain way. That's a compilation issue.
> - At this point however this is not one of them
First, I didn't say that, although something very similar.
Second, please explain to me why the OP talking about methods being "available", inheritance and access modifiers indicates that the correct answer is "implement Cloneable".
Alright you did'nt say that. My mistake.
Well it could be either, that's what I said. How could you get stuck to the issue being a compilation problem only ?
> Well it could be either, that's what I said. How
> could you get stuck to the issue being a compilation
> problem only ?
Did I already mention the OP talking about access modifiers (public works, protected doesn't), inheritance and the "availablity" of methods?
And do you notice that any issues with these could only arise at runtime if you compiled all the code, then change some classes, compile only those and then run that resulting mix? In other words, you have to wantonly break it if you want it to become a runtime problem.
And further, his question was not "why doesn't clone work" but "shouldn't protected methods and public methods both be available".
> If you do read the original post -
> are we unable to get the protected method clone()
> of this class even our class extends Object
> class?
>
> That's not why you can't do something.clone().
> It's because clone() is protected - So thank you
> for stating the obvious.
What do you have a wild hair up your bum about?
He asked why we "can't get " that method, which sounds like a copmile-time issue.
And whether my answer wsa obvious or not is irrelevant. A lot of people (including you, it appeared from your first post) don't understand the "obvious."
You gave an incorrect answer to what I believe the question was. Obvious or not, that warrants correction, so I corrected it.
jverda at 2007-7-29 11:18:42 >
Rene I'm glad that between the two of us at least one of us agrees to your view point.
End of the day I think the O.P is confused about the access modifiers public vs protected and its neither a compile nor a runtime issue.
-Over & Out.
> Well Rene there are probably a lot of things I agree
> with you on...
>
> Because he's asking why he can't call a protected
> method a certain way. That's a compilation issue.
> - At this point however this is not one of them
I said that, not Rene.
So are you saying he's not asking why a protected method can't be called in a certain context? It's possible I misunderstood his question, but that's sure what it looks like to me.
Or are you saying calling protected methods through foo.whatever() vs. super.whatever() is not a compilation issue? If that's what you're saying, you're flat-out wrong.
jverda at 2007-7-29 11:18:42 >
> End of the day I think the O.P is confused about the
> access modifiers public vs protected
Yes.
> and its neither
> a compile nor a runtime issue.
It is exactly a compile-time issue.
jverda at 2007-7-29 11:18:42 >
jverd refer to my previous post. And we both agree that people have not understood the obvious, good for us :-)
> jverd refer to my previous post.
I've read it. What's your point.
jverda at 2007-7-29 11:18:42 >
And we both agree that people have not understood the obvious, good for us :-)
> And we both agree that people have not understood
> the obvious, good for us :-)
Oh, so there is no point. Okay, fair enough.
jverda at 2007-7-29 11:18:42 >
> End of the day I think the O.P is confused about the
> access modifiers public vs protected and its neither
> a compile nor a runtime issue.
public vs. protected is a compile-time issue (in this case, it doesn't appear to me like he's talking about class design) unless you willfully force it to be a runtime fault. If you do that, you know exactly what's wrong and wouldn't have to ask.
public vs. protected is a compile-time issue (in this case, it doesn't appear to me like he's talking about class design) unless you willfully force it to be a runtime fault. If you do that, you know exactly what's wrong and wouldn't have to ask.
Plus you wouldn't have to answer !
