private final method?

[Manish Hatwalne]

Consider this from JLS
JLS 8.4.3.3 final Methods -
"A private method and all methods declared in a final class (�8.1.1.2) are implicitly final, because it is impossible to override them. It is permitted but not required for the declarations of such methods to redundantly include the final keyword. " (verbatim)
AFAIK, it is not possible to override a final method, but a non-private final method is always inherited and are accessible in the subclass. As for private methods, they are not accessible in the subclass, and it is possible to have another method in the subclass with same signature. I understand, it is NOT possible to override in this case.
In this case, how correct is it to say that a private method is implicitly final? Shouldn't it be treated be treated differently, without any reference to "final" modifier, because it does not seem to follow "characteristics" of a final method.
I am quite confused, can someone clarify?
TIA,
- Manish

[Jose Botella]

From the same place in the JLS where you quoted:
"A method can be declared final to prevent subclasses from overriding or hiding it. It is a compile-time error to attempt to override or hide a final method."
Thus the point in a final method is that can't be changed by any subclasses: It is the last version of it, it doesn't need any more overriding (refinement) in the subclasses. You can't replace it by other via hidding or overwriding methods in the subclass because is the "final" version. You have to use it as it's.
While a private method it doesn't appear in the subclasses so it can't be hidden or overriden. In that way is implicitely final.

[Manish Hatwalne]

Originally posted by Jose Botella:
From the same place in the JLS where you quoted:
"A method can be declared final to prevent subclasses from overriding or hiding it. It is a compile-time error to attempt to override or hide a final method."
Thus the point in a final method is that can't be changed by any subclasses: It is the last version of it, it doesn't need any more overriding (refinement) in the subclasses. You can't replace it by other via hidding or overwriding methods in the subclass because is the "final" version. You have to use it as it's.
While a private method it doesn't appear in the subclasses so it can't be hidden or overriden. In that way is implicitely final.

I agree with the fact you *can not* have overriding with private methods, there's absolutely no confusion abt it.
My doubt is in case of private methods, in the subclass you can have another method with same signature (with different or same access modifier) having totally different functionality/implementation. The assumption that final method is the "final" version of the method, and you have to use it as it is is defeated here. The subclass doesn't know abt this method, and there is no way one can force the subclass to use the "final" version of private method as it is, so treating private as implicit final somehow seems inappropriate.
Consider multilevel inheritance as shown below -

<font size="+0">
class PrivateFinalLevel_0
{
private final void foo()
{
System.out.println("Inside level_0 private final foo()");
}
public final void foo1()
{
System.out.println("Inside level_0 public final foo1()");
}
}
class  PrivateFinalLevel_1 extends PrivateFinalLevel_0
{
public void foo()  //no error, obviously
{
System.out.println("Inside level_1 foo()");
System.out.println("I don't know a thing abt private final of super class");
}
// will give error if you try to include this
/*
public void foo1()
{
System.out.println("Inside level_1 public foo1()");
}
*/
}
class  PrivateFinalLevel_2 extends PrivateFinalLevel_0
{
public static void main(String args[])
{
PrivateFinalLevel_2 pf = new PrivateFinalLevel_2();
pf.foo1();
                pf.foo();
}
public void foo()
{
System.out.println("Inside level_2 foo()");
System.out.println("Nor do I!!!");
}
}

This problem is well exemplified in the example above, a public final is used as it is in all 3 classes; while a private final belongs to PrivateFinalLevel_0 class, any subclassses can have method with same signature with any desired functionality w/o a problem. A purpose of having final method so that "all" its subclasses will have same implementation of it is defeated here.
I know, there has to be some sense in saying this(JLS), but somehow I don't seem to get it. In a nutshell, my confusion/objection is regarding treating private as an implicit final method, while it doesn't seem to have same behaviour as final.
Still confused,
- Manish

[This message has been edited by Manish Hatwalne (edited October 19, 2001).]

[Ragu Sivaraman]

Good point Manish and good example too
From Jose's comment:
While a private method it doesn't appear in the subclasses so it can't be hidden or overriden. In that way is implicitely final
So private final void foo()
final modifier is redundant becoz all private methods are implicitly final
so when you define another method in your subclass
public(or whatever) void foo() there is no correlation betn this method and foo() defined in your superclass. So in no way you are defeating the ability of not subclassing a final method
In otherwords (private plays the primary role as an modifier than a final).. Similar anology would be
interface II {
public abstract void m(); //public abstract are unnecessary
//but compiler wont complain or care
}
Does that help you?
Ragu

[Manish Hatwalne]

Originally posted by Ragu Sivaraman:
Good point Manish and good example too
From Jose's comment:
While a private method it doesn't appear in the subclasses so it can't be hidden or overriden. In that way is implicitely final
So private final void foo()
final modifier is redundant becoz all private methods are implicitly final
so when you define another method in your subclass
public(or whatever) void foo() there is no correlation betn this method and foo() defined in your superclass. So in no way you are defeating the ability of not subclassing a final method
In otherwords (private plays the primary role as an modifier than a final).. Similar anology would be
interface II {
public abstract void m(); //public abstract are unnecessary
//but compiler wont complain or care
}
Does that help you?
Ragu

Hmmm, (???)
I think I didn't make myself clear earlier.
I understand that there's never gonna be any relation betn private method of base class and its subclasses.
I have no objection abt its implicit nature, what bothers me is treating it as final (implicit or explicit, irrespective!!)
Is "non-overridable" (if there's any such word) the only distinguishable characteristic of a final method? I believe not, non-private final methods are inheritted in the subclasses, and can be used as they are. private methods *are* different.
In fact before reading this in JLS, I always treated them (final and private) as two separate things -
1) private - exists only in the class in which it is defined. period.
2) final - (a) no overriding, (b) subclasses must use the version provided by the base (super) class, if at all they need to use it.
It's JLS which got me confused
- Manish

[This message has been edited by Manish Hatwalne (edited October 20, 2001).]

[Jose Botella]

Hi Manish
I think that all of us have had this doubt when reading the JLS.
The confusion stems from attributing the characteristic of inheritance to a final method. But this is not what the JLS tell us about final. Just think of a final method as one that if inherited it can not be modified. Don't think a final method should always be inherited and then can't be modified.
JLS could have helped a bit more here.

[Manish Hatwalne]

Originally posted by Jose Botella:
The confusion stems from attributing the characteristic of inheritance to a final method. But this is not what the JLS tell us about final. Just think of a final method as one that if inherited it can not be modified. Don't think a final method should always be inherited and then can't be modified.
JLS could have helped a bit more here.

Purrrrrrfect !!!
Yep, the inheritance of final method should be attributed to its access modifier.
I knew, there was a catch somewhere, but couldn't find it. Thanx a ton Jose, you are a great help!
Regards,
- Manish