看看这个Github项目，尤其是objectHandle变量。这个项目展示了如何实际而准确地在孙子上调用祖父母方法。

以防链接被破坏，下面是代码:

import lombok.val;
import org.junit.Assert;
import org.junit.Test;

import java.lang.invoke.*;

/*
Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
Please don't actually do this... :P
*/
public class ImplLookupTest {
    private MethodHandles.Lookup getImplLookup() throws NoSuchFieldException, IllegalAccessException {
        val field = MethodHandles.Lookup.class.getDeclaredField("IMPL_LOOKUP");
        field.setAccessible(true);
        return (MethodHandles.Lookup) field.get(null);
    }

    @Test
    public void test() throws Throwable {
        val lookup = getImplLookup();
        val baseHandle = lookup.findSpecial(Base.class, "toString",
            MethodType.methodType(String.class),
            Sub.class);
        val objectHandle = lookup.findSpecial(Object.class, "toString",
            MethodType.methodType(String.class),
            // Must use Base.class here for this reference to call Object's toString
            Base.class);
        val sub = new Sub();
        Assert.assertEquals("Sub", sub.toString());
        Assert.assertEquals("Base", baseHandle.invoke(sub));
        Assert.assertEquals(toString(sub), objectHandle.invoke(sub));
    }

    private static String toString(Object o) {
        return o.getClass().getName() + "@" + Integer.toHexString(o.hashCode());
    }

    public class Sub extends Base {
        @Override
        public String toString() {
            return "Sub";
        }
    }

    public class Base {
        @Override
        public String toString() {
            return "Base";
        }
    }
}

编码快乐! !

当你不能改变基类的代码时，调用super.super.method()是有意义的。这通常发生在扩展现有库时。

首先问问自己，为什么要扩展这个类?如果答案是“因为我不能改变它”，那么你可以在你的应用程序中创建确切的包和类，并重写调皮方法或创建委托:

package com.company.application;

public class OneYouWantExtend extends OneThatContainsDesiredMethod {

    // one way is to rewrite method() to call super.method() only or 
    // to doStuff() and then call super.method()

    public void method() {
        if (isDoStuff()) {
            // do stuff
        }
        super.method();
    }

    protected abstract boolean isDoStuff();


    // second way is to define methodDelegate() that will call hidden super.method()

    public void methodDelegate() {
        super.method();
    }
    ...
}

public class OneThatContainsDesiredMethod {

    public void method() {...}
    ...
}

例如，您可以创建org.springframework.test.context.junit4。类SpringJUnit4ClassRunner，所以这个类应该在jar中真正的类之前加载。然后重写方法或构造函数。

注意:这是绝对的黑客，强烈不建议使用，但它是工作!使用这种方法是危险的，因为类装入器可能存在问题。此外，这可能会导致问题，每次您将更新库包含覆盖类。

除了其他人提出的非常好的观点之外，我认为还有另一个原因:如果超类没有超类怎么办?

因为每个类都自然地扩展(至少)Object，所以super.whatever()总是引用超类中的一个方法。但是如果你的类只扩展Object呢?超级指的是什么?该如何处理该行为-编译器错误，空指针，等等?

我认为不允许这样做的主要原因是它违反了封装，但这可能也是一个小原因。

我曾经遇到过这样的情况，即体系结构是在一个公共CustomBaseClass中构建公共功能，该CustomBaseClass代表几个派生类实现。 但是，我们需要规避特定派生类的特定方法的通用逻辑。在这种情况下，我们必须使用super.super.methodX实现。

我们通过在CustomBaseClass中引入一个布尔成员来实现这一点，该成员可用于有选择地推迟自定义实现，并在需要时让位于默认框架实现。

        ...
        FrameworkBaseClass (....) extends...
        {
           methodA(...){...}
           methodB(...){...}
        ...
           methodX(...)
        ...
           methodN(...){...}

        }
        /* CustomBaseClass overrides default framework functionality for benefit of several derived classes.*/
        CustomBaseClass(...) extends FrameworkBaseClass 
        {
        private boolean skipMethodX=false; 
        /* implement accessors isSkipMethodX() and setSkipMethodX(boolean)*/

           methodA(...){...}
           methodB(...){...}
        ...
           methodN(...){...}

           methodX(...){
                  if (isSkipMethodX()) {
                       setSKipMethodX(false);
                       super.methodX(...);
                       return;
                       }
                   ... //common method logic
            }
        }

        DerivedClass1(...) extends CustomBaseClass
        DerivedClass2(...) extends CustomBaseClass 
        ...
        DerivedClassN(...) extends CustomBaseClass...

        DerivedClassX(...) extends CustomBaseClass...
        {
           methodX(...){
                  super.setSKipMethodX(true);
                  super.methodX(...);
                       }
        }

然而，在框架和应用程序中遵循良好的架构原则，我们可以通过使用hasA方法而不是isA方法轻松避免这种情况。但在任何时候，期待设计良好的架构都是不现实的，因此需要摆脱坚实的设计原则，引入像这样的技巧。 这只是我的意见……

我认为这是一个打破继承协议的问题。 通过扩展一个类，你服从/同意它的行为、特征 而当调用super.super.method()时，你想要打破你自己的服从协议。

你不能从超类中挑选。

然而，可能会出现需要调用super.super.method()的情况——在您的代码或继承的代码中，这通常是一个糟糕的设计标志! 如果不能重构超类和超超类(一些遗留代码)，则选择复合而不是继承。 封装破坏是指通过破坏封装的代码@Override一些方法。 标记了设计为不被覆盖的方法 决赛。

我会把超级。如果可能的话，超级方法主体放在另一个方法中

class SuperSuperClass {
    public String toString() {
        return DescribeMe();
    }

    protected String DescribeMe() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    public String toString() {
        return DescribeMe();
    }
}

或者如果你不能改变超超类，你可以试试这个:

class SuperSuperClass {
    public String toString() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return DescribeMe(super.toString());
    }

    protected String DescribeMe(string fromSuper) {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    protected String DescribeMe(string fromSuper) {
        return fromSuper;
    }
}

在这两种情况下，

new ChildClass().toString();

结果变成“我超级超级”