最终修饰符的意外行为

发布于 2024-11-27 02:47:41 字数 925 浏览 1 评论 0 原文

这是我的代码,

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" ) ;
    }
}

我发现无论有或没有 A1.A11 中的最终 mdifer,程序都会编译并运行。

我可以理解,如果没有final修饰符,A1.A12可以看到并因此覆盖fun方法。它是私有的,但它们位于同一类,因此不存在可见性问题。

我不明白为什么它与 Final 修饰符一起使用。是否应该禁止 A1.A12 中的覆盖?

这是带有最终修饰符的程序的输出

java alpha/A1
A11:    HelloHello

如果它只是忽略其他有趣的方法那么

  1. 编译器不会抱怨超级引用
  2. A11 不会出现在输出中

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

不忘初心 2024-12-04 02:47:41

您的方法是私有的

将它们的可见性更改为受保护以查看预期的行为,也就是说,仅当方法受保护、公共或默认可见性时,甚至存在重写的概念

做这样的事情——

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" ) ;
    }
}

现在会抛出编译时异常

fun(java.lang.String) in A1.A12 cannot override fun(java.lang.String) in A1.A11; overridden method is final

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
累赘 2024-12-04 02:47:41

对于 publicprotected 和包私有/默认访问方法,final 确实可以防止方法被重写。

但是,所有 private 方法都是“非虚拟”的,因此实际上是最终的。超类中的私有方法对派生类没有影响。您没有重写,只是忽略了基类中的方法。

JVM 所基于的第一版 Java 语言规范没有内部类或嵌套类,因此可以专门处理 private 方法。该语言的后续版本主要围绕 JVM 进行。

在字节码术语中,使用 private 方法rel="nofollow">invokespecial 而不是 invokevirtual

不同包中默认的访问/包私有final方法也是相互独立的。在同一个包内可以相互覆盖,而 final 会有所不同。在不同的包中,匹配的方法不会相互覆盖。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文