• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

private final method?

 
Ranch Hand
Posts: 2596
Android Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2596
Android Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 -

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).]
 
Ranch Hand
Posts: 464
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2596
Android Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2596
Android Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
My, my, aren't you a big fella. Here, have a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic