aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes overriding private methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "overriding private methods" Watch "overriding private methods" New topic
Author

overriding private methods

Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
In Sahir's TestCafe mock exam (section 2 question 4), the following answer is marked as not true:
A private method can never be overridden to become public.

I think it is true. What do you think?

JLS 8.4.6.3:
a private method cannot be hidden or overridden in the technical sense of those terms


Mike Gershman
SCJP 1.4, SCWCD in process
Stefan Guilhen
Ranch Hand

Joined: Jul 31, 2004
Posts: 61
Hi Mike,

I am with you. Private methods cannot be overriden because, well, they are not inherited by subclasses. So there is no way for a subclass to override a private method of the superclass.

Cheers,
Stefan


SCJP 1.4, SCBCD 1.3<br />IBM 141, 484, 486
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
Private methods are final by default, for that same reason they cannot be abstract.
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
Private methods are final by default

I saw that statement before, but a private method lets you put a method with the same signature in a subclass while a final method prevents that.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
If you explicitly declare a method both public and final, then nothing prevent you from creating a method in a subclass with the same signature as the private final method in the superclass. You aren't overriding it though, because the subclass knows nothing at all about the private method in the superclass. The subclass method could specify a new return type, or throw new checked exceptions not allowed by the superclass method. It doesn't matter, because the two methods have absolutely nothing to do with each other. At all. The fact that the superclass method is final is irrelevant to the subclass method.

So why then does the Java Language Specification say that "A private method and all methods declared in a final class are implicitly final"? Being final may be irrelevant when you're trying to override a private method, but it still may be significant for other things.

[Note (added later) - the following section is wrong, based on some sloppy thinking on my part. I'd delete it, but then Tony's subsequent post wouldn't make sense. So - please ignore the following except to understand what Tony's talking about.]

For example, the JLS gives rules about compile-time constant expressions which depend in part on whether or not a field is final. So it can become significant to know that

and

are compile-time constants, but

is not.

This probably won't affect anyone's life as much as rules about overriding do - I can't imagine it would be on the exam, for example. But it may help explain why JLS2 8.4.4.3 is worded the way it is.
[ January 23, 2005: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Animesh Shrivastava
Ranch Hand

Joined: Jul 19, 2004
Posts: 298
Yeah u all right, there can be a question like this on SCJP(tricky i suppose ):
public class StrBuf {

public static void main(String[] args) {
StrBuf stB = new ExtStrBuf();
stB.callMe("Ani");
}
private void callMe(String s) {
System.out.println("hi String superclass");
}
}

class ExtStrBuf extends StrBuf {
void callMe(String a) {
System.out.println("hii String subclass");
}
}
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
There are quite a few errors in this thread that I feel compelled to repair them:

a) a private method cannot be overridden (see below).
b) private methods are NOT "final by default". A quick test case can prove this using reflection.
c) private int BAR = 2;
This is NOT a compile-time constant.
The access modifier on a field has no effect on whether it is evaluated at compile-time. JLS 15.28 for more information.

Here's some fun that should clear up your issues:



What is the output?
Now change the access modifier on the method printS().


Tony Morris
Java Q&A (FAQ, Trivia)
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
c) private int BAR = 2;
This is NOT a compile-time constant.


True, I slipped up there. JLS 8.4.4.3 refers to methods; I erroneously applied it to a field. And a moment's thought reveals other problems - obviously, private fields are mutable; we do it all the time with public setters to private fields. Duh. I've edited my previous post accordingly.

a) a private method cannot be overridden (see below).

I agree.

b) private methods are NOT "final by default". A quick test case can prove this using reflection.

Interesting - you're right about what reflection says here, at least with the JDK's I've tried. And yet the JLS very clearly states otherwise, as I cited above. Guess this is another example where Sun hasn't ironed out all the details yet. :roll: I see that the proposed JLS3 beta modifies the wording slightly: "A private method and all methods declared immediately within a final class behave as if they were final, since it is impossible to override them". Hmm, that doesn't seem to change the meaning substantially. I suppose "behaves as if final" is a little more vague than "is implicitly final", maybe that gives some wiggle room. Not enough though, in my opinion. Reflection gives different results for a private final method than it does for a private method - thus, the behavior is not the same for both, and is inconsistent with either spec (JLS2 or 3). Maybe if we make some noise about it we can get them to either amend the spec, or fix the bug in their implementation. Unlikely I suppose, but you never know...
[ January 23, 2005: Message edited by: Jim Yingst ]
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
In Tony's example it is also instructive to leave printS() as private and then call super.printS() in the anonymous subclass.


Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
There is a similarity and a distinction between a private non-final method and a final non-private method. In both cases, a subclass cannot override the method.

A subclass can contain a method with the same signature as that of its superclass's private non-final method. The subclass method will only be accessable at the subclass level and below.

A subclass cannot contain a method with the same signature as that of its superclass's final non-private method.

It is obviously impossible to override methods in a final class, since there are no subclasses in which to put overriding methods.

This leaves private final methods. This code compiles:

Take out private and it does not compile (Java 1.5).
Take out final and it compiles.
Take out private final and it does not compile (different return types).
Richard Vagner
Ranch Hand

Joined: Jun 26, 2001
Posts: 107
Tony, can you elaborate you sample code a bit? I did not quite get it yet.
osman cinar eren
Ranch Hand

Joined: Jan 25, 2005
Posts: 78
Hi Tony,

I also need some more explanation on your code.

thanks in advamnce.
best regards.


SCJP/SCWCD
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
This code is indisputable proof that a private method cannot be overridden, despite any efforts to explain away otherwise (which occurs sometimes).
If I tried to explain it on a forum, I'd probably confuse the majority of readers, since it is best explained by the output (as well as the output that differs when the access modifier is altered on the printS method).

I suggest you run it, then change the modifier and run it again, and attempt to follow the path of execution, which is where you will discover that the private method is not overridden. If you have any specific questions, post them here.
osman cinar eren
Ranch Hand

Joined: Jan 25, 2005
Posts: 78
hi,

thanks for the reply. what i cannot understand is anonymous class extends class "T". But it can call a private method of its superclass. I am confused there.

so your explanation is needed.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: overriding private methods