Unexpected Behavior wrt the final modifier
Asked Answered
L

2

2

This is my code

package alpha ;

class A1
{
    static class A11
    {
        private
            final // WHAT IS THE EFFECT OF THIS MODIFIER?
            void fun ( String caller )
            {
                System . out . println ( "A11:\t" + caller ) ;
            }
    }

    static class A12 extends A11
    {
        private void fun ( String caller )
        {
            super . fun ( caller + caller ) ;
        }
    }

    public static void main ( String [ ] args )
    {
        A12 a12 = new A12 ( ) ;
        a12 . fun ( "Hello" ) ;
    }
}

I have found that with or without the final mdifer in A1.A11 the program compiles and runs.

I can understand that without the final modifier, A1.A12 can see and thus override the fun method. It is private but they are in the same class so there is no visibility issue.

I can not understand why it works with the final modifier. Should not the overriding in A1.A12 be prohibited?

This is the output of the program with the final modifer in place

java alpha/A1
A11:    HelloHello

If it was simply ignoring the other fun method then

  1. would not the compiler have complained about the super reference
  2. the A11 would not be in the output
Lazy answered 28/7, 2011 at 18:3 Comment(5)
Are you sure? Maybe your compiler is acting strange. final makes a variable non-modifiable and prevents subclassing. Not sure how it affects methods.Counteroffensive
This is how it affects methods: renaud.waldura.com/doc/java/final-keyword.shtml#methodsSiemens
@Ryan It prevents overriding.Esbensen
@Etienne Ok, that's what I thought... but then the OP is weird. Which IDE and which JDK are you using?Counteroffensive
@Ryan I am not using an IDE. I am using javac 1.6.0_20Lazy
M
7

Your methods are private.

Change their visibility to protected to see expected behavior, that is, only when the method is protected, public or default visibility, the concept of overriding even exists.

Doing something like this --

class A1
{
    static class A11
    {
        public
            final // WHAT IS THE EFFECT OF THIS MODIFIER?
            void fun ( String caller )
            {
                System . out . println ( "A11:\t" + caller ) ;
            }
    }

    static class A12 extends A11
    {
        public void fun ( String caller )
        {
            super . fun ( caller + caller ) ;
        }
    }

    public static void main ( String [ ] args )
    {
        A12 a12 = new A12 ( ) ;
        a12 . fun ( "Hello" ) ;
    }
}

will now throw the compile-time exception

fun(java.lang.String) in A1.A12 cannot override fun(java.lang.String) in A1.A11; overridden method is final
Misdeed answered 28/7, 2011 at 18:7 Comment(5)
"Package private" methods can also override for classes in the same package. That is an analogous situation to private methods in the same outer class. Java does behave oddly.Lapsus
I accept that the concept of overriding does not exist for private methods. The private methods of classes nested in the same top-level class are visible to each other. Thus the subclass method can see the superclass method (through super). It appears as if there is overriding but there is not.Lazy
@Kai. "visible to each other" = the private methods in A11 can be invoked in A12. They are not only in the same file but also in the same class. This is my understanding.Lazy
@Lazy -- You're right. I will just link you to another discussion on SO on this very topic.#663559Misdeed
@Kai Thnx 4 the link. It sure is strange behavior, but I see it is legal and required by spec.Lazy
L
2

For public, protected and package private/default access methods, final does indeed prevent a method being overridden.

However, all private methods are "non-virtual", so effectively final. A private method in a superclass makes no difference to the derived class. You aren't overriding, it's just that the method in the base class is ignored.

First edition Java Language Spec which the JVM is based around had no inner or nested classes, so private methods could be dealt with specially. Later versions of the language are bent around the JVM.

In bytecode terms, private methods are called with the invokespecial instead of invokevirtual.

Default access/package private final methods in different packages are also independent of one another. Within the same package can override one another and final makes a difference. In different packages, the matching methods do not override one another.

Lapsus answered 28/7, 2011 at 18:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.