overriding private methods

[Mike Gershman]

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

[Stefan Guilhen]

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

[Edwin Dalorzo]

Private methods are final by default, for that same reason they cannot be abstract.

[Mike Gershman]

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]

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

public final int FOO = 1;

and

private int BAR = 2;

are compile-time constants, but

public int BAZ = 3;

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 ]

[Animesh Shrivastava]

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]

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:

        class T
{
    private final String s;
 
    private void printS()
    {
System.out.println(s);
    }
 
    T(String s)
    {
this.s = s;
    }
 
    public static void main(String[] args)
    {
new T("main").m();
    }
 
    private void m()
    {
new T("m")
{
void method()
{
printS();
}
}.method();
    }
}

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

[Jim Yingst]

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]

In Tony's example it is also instructive to leave printS() as private and then call super.printS() in the anonymous subclass.

[Mike Gershman]

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:

class AA { 
private final void m() {} 
}
class BB extends AA {
int m() { return 5; }
}

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]

Tony, can you elaborate you sample code a bit? I did not quite get it yet.

[osman cinar eren]

Hi Tony,

I also need some more explanation on your code.

thanks in advamnce.
best regards.

[Tony Morris]

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]

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.