Non-overridable methods

[Manish Hatwalne]

Which of these are the non-overridable methods -
(Select 3 options)
a) public final void m1()
b) public static void m1()
c) public static final void m1()
d) public abstract void m1()
e) private void m1()
correct given answers are a), b) and c)
I am wondering why e) has been ruled out as compared to b and c. As it is static methods (final or non-final) can only be hidden in the subclasses, whereas private methods are supposed to be implicitly final. I think a c and e should be the right choice. Can somebody explain?
TIA,
- Manish

[Kaspar Dahlqvist]

Hello!
Well, as far as I know, overriding only applies to objects. This rules out all static methods, as these are class methods and not instance methods.
Concerning choice e), I think it is possible to argue that this choice is not "non-overridable", but only not possible to override due to the access modifier private.
But this is only a hunch. I really think this is a bad question, if it isn't equipped with a vivid explanation and justification of the right answers.
Hope this helps!
/Kaspar

[Rob Ross]

private methods aren't inherited. If they're not inherited, they can't be overridden. If you define a method with the same name in your subclass, that's a new method, not an overriden version of the private superclass method.
The question does seem a little vague, but the other 3 answers are more certainly correct. It's true you can't override a private method. Does that make it non-overridable though? I guess it depends on how you interpret the question.
[ March 08, 2002: Message edited by: Rob Ross ]

[Manish Hatwalne]

I agree with you both, in fact the only perfect answer is a), but question says you need 3 answers. The statement "private methods are implicitly final" is staright from JLS, so it does make sense. I am not too sure abt the question wording though, let me see if I can get the actual question, which is from JQPlus, but unfortunately I don't have its number, so don't know how to locate it.
TIA,
- Manish

[Manish Hatwalne]

OK. Here it is -
Question ID :970935900390
Which of the following method definitions will prevent overriding of that method?
Choose all 3 correct answers
a) public final void method m1()
b) public static void method m1()
c) public static final method void m1()
d) public abstract void method m1()
e) private void method m1()
Correct answer - a, b and c
Explanation -
Very Similar question has been asked in SCJP2
Keep in mind though that static methods and private methods are not overridden, they are shadowed.
Can somebody elaborate with details please.
TIA,
- Manish

[Corey McGlone]

Okay, if someone asked me this question, I'd choose A, B, C, and E. Only D is an overridable method. I'll give my reasoning and people can feel free to bicker with me about it.
You can't override A because of the keyword final.
B and C are static methods and therefore can not be overridden. Method overriding implies dynamic method lookup during runtime. This does not occur for static methods. If you declare a static method with the same name in a subclass, you shadow the method from the parent class, it is not overridden.
D is, of course, an overridable method. In fact, it must, at some point be overridden because of the fact that it is abstract.
E can not be overridden because it is not inherited. Private members are not inherited by a subclass, so how can a subclass override a method which it can't see in it's parent?
Anyway, that's what I think.
Corey

[Valentin Crettaz]

Completely in phase with you Corey...
The problem with answer e is that the "non-overridable" requirement is not clear...
Of course a private method is not overridable, but you can still declare a method with the same signature in the subclass, but the superclass method is not overridden since it is not even visible in the subclass.
Paul,
if you come by, please enlighten us. Don't you think that the question needs rephrasing?
Moreover, the explanation is definitely not clear at all. How come "private methods are shadowed" since they are not even visible
[ March 08, 2002: Message edited by: Valentin Crettaz ]

[Corey McGlone]

While thinking about this, I've come up with a question of my own.
As static methods can't be overridden, what good is the keyword final on a static method?
The following method daclaration is legal:

public static final void main(String[] args)

But how does that differ from this, if at all?

public static void main(String[] args)

Thanks,
Corey

[Valentin Crettaz]

well if you put final in the superclass static method then you cannot hide it in the suubclass:
try this:

class A {
    public static final void main(String args[]){}
}
public class B extends A{
    public static void main(String args[]){}
}

=> Compilation error

[Corey McGlone]

Indeed, you're right again, Val. (I'm so surprised...really, I am. :roll: )
It didn't make much sense to me that this would cause a compiler error as I always thought that the keyword final referred only to method overriding, so I purused the JLS for a little while. It didn't take long to find §8.4.3.3 final Methods:

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.

So, with the use of the keyword final, you are no longer allowed to declare a method of the same name in the subclass, even if the method is static.
To go along with my previous point that private methods are not inherited, I tried this:

class Parent
{
   private final void foo() {}
}
 
public class Child extends Parent
{
   public void foo() {}
}

This code compiles perfectly as we are not overriding or overshadowing the method Parent.foo because that method is not even visible to the class Child.
Thanks, Val.
Corey

[Valentin Crettaz]

Moreover,
From 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.

[Corey McGlone]

Hmm...I'm going to split hairs here for a minute, but I'm sure you're all used to this by now...
Why are private methods considered "implicitly final?"
From section 8.4.3.3 final Methods of the JLS, the final keyword is used to prevent any subclass of overriding or overshadowing a method.
However, a private method is not visible in a child method, so it can't possibly be overridden or overshadowed. Therefore, the implication that the method is private seems meaningless.
The JLS goes on to give a code example showing that, when code that invokes a final method is compiled, the contents of that method can be "inlined" into the bytecode. After this is done, further optimizations might be performed.
Is this potential for optimization the reason for making private methods implicity final? I can see no other reason.
Thanks,
Corey

[Rob Ross]

My gut feeling is that the final keyword *really* means that the compiler will generate bytecode for static binding. Any place you see final , access to that member is determined at compile time. Because of this, I think that private members use this mechanism to create static bindings at compile time. The fact that the accessibility is private has the additional affect of reducing the visibility of the method to other classes; but I think it's because it's implicitly final is why it's a static binding call.
At least, this is my understanding so far about how the compiler deals with this.

[Brian Lugo]

Check out this link, this topic was apparently discussed before:
http://www.javaranch.com/maha/Discussions/Language_Fundamentals/difference_between_static_and_final_method_-_JavaRanch_Big_Moose_Saloon.htm
Brian

[Manish Hatwalne]

I agree with Corey's First post completely, even I am most likely to choose a,b,c and e. But if this question shows up in the exam and if I have to choose only 3 options, I am most likely to go for a,c and e. In fact this is the first time I have got something incorrect in Overriding / Overloading and I am confused. Regarding static final, Val has already explained it. As for -

Originally posted by Corey McGlone:
Hmm...I'm going to split hairs here for a minute, but I'm sure you're all used to this by now...
Why are private methods considered "implicitly final?"

Have a look at this dicussion that we had some time ago.
In fact consider this very interesting case where an inner class extends the outer class, and outer class has a private method -
private void m1()
in this case also the method is not inherited in the inner class, though it is accessible in the inner class. i.e. direct call to m1() is allowed by the compiler but a call like innerClass.this.m1() is a compile time error. All the more reason for considering a private method a better candidate for non-overridable methods.

- Manish

[Manish Hatwalne]

I did get an answer to this one from JQPlus ppl at jdiscuss forum, but I am not really convinced by the answer. Can somebody tell me what am I missing?
Here is the answer to my post -
http://www.jdiscuss.com/Enthuse/jsp/ViewPosts.jsp?forumid=6&topicid=6
TIA,
- Manish

[Valentin Crettaz]

Actually, Jignesh Malavia gives very good comment on this issue.
Now, if we think about what we read, it becomes pretty obvious that a,b and c are the correct answers. Here are my thoughts:
As stated by Jignesh, a and c are final so it is clear that they are part of the answer. d is abstract which rules it out of the answer.
The competition now is between b and e. And since the question explicitely mentions the terms "non-overridable methods", the choice could only be b because static methods can be hidden (by static methods) but not overridden (by instance methods). So we can say that method b is non-overridable (but it is hidable).
As for e, let's have a look at JLS 8.4.6.3 Requirements in Overriding and Hiding

Note that a private method cannot be hidden or overridden in the technical sense of those terms. This means that a subclass can declare a method with the same signature as a private method in one of its superclasses, and there is no requirement that the return type or throws clause of such a method bear any relationship to those of the private method in the superclass.

Well, I agree it is not more clear than before because of that "in the technical sense of those terms". But, the thing I want to put forward is that if you have e (an instance method) in a superclass, then you can have an instance method with the same signature in the subclass without getting compiler errors. But if you have b (a class method) in the superclass, then you cannot have an instance method with the same signature (static is not part of the signature!) in the subclass since instance method cannot override static methods. (and static methods cannot hide instance methods).
It all comes down to the right use of the terminology, I guess... I hope this helps.
[ March 17, 2002: Message edited by: Valentin Crettaz ]

[Manish Hatwalne]

Hmmmm,
Makes sense, I'll remember that
Regards,
- Manish

[Manish Hatwalne]

OK I managed to find a sort of counter argument -
I believe the real test of Overriding is invoking the method of appropriate subclass using base class object reference depending on the actual type of the object at runtime. If I have a code like this -

class Base
{
      private void aMethod()
      {
            // do something
      }
      
     public static void aStaticMethod()
     {
            // do something
     }
}
class Sub extends Base
{
      public void aMethod()
      {
             // do something
      }
     public static void aStaticMethod()
     {
            // do something
     }
}

With this code if you have call like objBase.aMethod() it will be a compile time error. As compared to objBase.aMethod() which not only compiles but also invokes base class implementation of the method, making private a better candidate for "Non-Overridable methods". Do I have a valid point here?
TIA,
- Manish
[ March 22, 2002: Message edited by: Manish Hatwalne ]

[Valentin Crettaz]

With this code if you have call like objBase.aMethod() it will be a compile time error. As compared to objBase.aMethod() which not only compiles but also invokes base class implementation of the method, making private a better candidate for "Non-Overridable methods". Do I have a valid point here?
This is not clear at all... First you say objBase.aMethod() will yield a compiler error and then it compiles fine bla bla bla...
Could you please explain further or correct the above explanations? Thanks

[Manish Hatwalne]

Originally posted by Valentin Crettaz:
With this code if you have call like objBase.aMethod() it will be a compile time error. As compared to objBase.aMethod() which not only compiles but also invokes base class implementation of the method, making private a better candidate for "Non-Overridable methods". Do I have a valid point here?
This is not clear at all... First you say objBase.aMethod() will yield a compiler error and then it compiles fine bla bla bla...
Could you please explain further or correct the above explanations? Thanks

OOOOOOOOOOOOOOOOps
What I meant was -
With this code if you have call like objBase.aMethod() it will be a compile time error. As compared to objBase.aStaticMethod() which not only compiles but also invokes base class implementation of the method, making private a better candidate for "Non-Overridable methods". Do I have a valid point here?
Thanks,
- Manish

[Valentin Crettaz]

Beside some typos (static must come before void, and Class must be class), there are 3 cases depending on how you declare objBase:
1. Base objBase = new Base();
objBase.aMethod();//does not compile
objBase.aStaticMethod();//OK
2. Base objBase = new Sub();
objBase.aMethod();//does not compile
objBase.aStaticMethod();//OK
3. Sub objBase = new Sub();
objBase.aMethod();//OK
objBase.aStaticMethod();//OK
Cases 1 and 2 show that you cannot access a private method but do not show that private methods cannot be overridden in the subclass. The compiler does not object to the fact that the subclass has a method with the same signature as a private superclass method !!! it objects to the fact that your code is trying to invoke a method that cannot be accessed. This is different!

[Manish Hatwalne]

Ok. I have corrected the typos, thanks.
I was referring to case 2.
Hmm, I can see your point.
Thanks again,
- Manish