Java 类文件上的 ACC_SUPER 访问标志的用途是什么？

Question

invokespecial JVM 指令用于在创建新对象时调用初始化方法 ()。指令的描述表明（但没有澄清）是否调用超类的构造函数或当前类的构造函数的决定取决于在指令中设置的 ACC_SUPER 标志的状态。 class 文件。

来自 Sun JVM 规范：

接下来，除非满足以下所有条件，否则将选择调用已解析的方法：

• 为当前类设置 ACC_SUPER 标志（请参见表 4.1“类访问和属性修饰符”）。

-- 来源 (invokespecial 操作码定义）

ACC_SUPER 标志的设置指示 Java 虚拟机要表达其 invokespecial 指令的两种替代语义中的哪一种； ACC_SUPER 标志的存在是为了向后兼容 Sun 的旧版 Java 编程语言编译器所编译的代码。 Java 虚拟机的所有新实现都应该实现本规范中记录的 invokespecial 语义。所有新的 Java 虚拟机指令集编译器都应该设置 ACC_SUPER 标志。 Sun 的较旧编译器生成未设置 ACC_SUPER 的 ClassFile 标志。 Sun 较旧的 Java 虚拟机实现会忽略该标志（如果已设置）。

-- 源 (ClassFile< /code> 格式）

定义指出该标志是为了向后兼容旧编译器。然而，它与 Sun 较旧的 Java 虚拟机实现在设置时忽略该标志相矛盾。

该标志是否仍与 invokespecial 操作码一起使用？据我所知，它似乎没有任何目的，而且我找不到任何资源来表明它曾经有过目的。

谢谢。

Answer 1

引入 ACC_SUPER 是为了纠正调用超级方法的问题。 ACC_SUPER 标志将一个类标记为针对操作码 183 指令的更改语义进行编译的。它的用途与类文件版本号的用途类似，因为它允许 JVM 检测某个类是否是针对该指令的较旧或较新语义进行编译的。 Java 1.0.2 没有设置并忽略 ACC_SUPER，而 Java 1.1 及更高版本总是设置 ACC_SUPER。

在 Java 1.1 之前，操作码 183 的字节码指令（现在称为 invokespecial）被称为 invokenonvirtual，并且具有部分不同的规范。每当必须在没有虚拟方法查找的情况下调用实例方法时，就会使用它。私有方法、实例初始值设定项（构造函数）以及在 super 上实现方法调用就是这种情况。但后一种情况导致了类库不断发展的问题。

字节码中的方法引用 (CONSTANT_Methodref_info) 不仅定义了方法的名称、参数和返回类型，还定义了它所属的类。操作码 183 获取这样一个方法引用参数，旨在直接从指定类调用引用的方法，而无需进一步查找。在调用 super 的情况下，编译器有责任解析实现此方法的最接近的超类，并在字节代码中生成对其的引用。

从 Java 1.1 开始，它被更改为基本上忽略 CONSTANT_Methodref_info 中引用的类，而是在 JVM 中查找具有给定方法名称和签名的最接近的超级方法。这通常在类加载时或在指令执行或第一次 JIT 编译之前完成。

以下是为什么需要进行此更改的示例。在 Java 1.0.2 中，AWT 类 Container 和 Component 是这样定义的：

class Component
{
    public void paint( Graphics g ) {}
}

class Container extends Component
{
    // inherits paint from Component but doesn't override it
}

在 Java 1.1 中，类 Container 被更改为拥有自己的实现paint 的：

class Container extends Component
{
    public void paint( Graphics g ) {/*...*/}
}

现在，当您有 Container 的直接或间接子类调用 super.paint(g) 并将其编译为1.0.2 它生成了Component.paint 的 invokenonvirtual 指令，因为这是第一个具有此方法的父级。但是，如果您在也具有 Container.paint 的 JVM 上使用此编译类，它仍然会调用 Component.paint，这不是您所期望的。

另一方面，当您编译 1.1 的类并在 1.0.2 JVM 上执行它时，它会抛出 AbstractMethodError ，或者对于那个时代的 VM 来说更有可能只是崩溃。为了避免崩溃，您必须编写 ((Component)super).paint(g) 并使用 1.1 编译器对其进行编译，才能在任一虚拟机中获得所需的行为。这将设置 ACC_SUPER 但仍生成调用 Component.paint 的指令。 1.0.2 VM 会忽略 ACC_SUPER 并直接调用 Component.paint ，这很好，而 1.1 VM 会找到 ACC_SUPER 集，从而自行进行查找，这将使其调用 Container。 Paint 即使字节码方法引用是 Component.paint。

您可以在 ikvm.net 博客上的这篇旧帖子。

Answer 2

自 Java 8 以来，ACC_SUPER 标志没有执行任何操作。

根据 JEP 草案：更好定义的 JVM类文件验证：

将不再指定 ACC_SUPER 标志，该标志自 Java 8 起无效。

虽然我还没有找到一个简洁、易于链接的权威来源，但似乎该功能在 Java 8 之前已在 Java 7 安全更新中被删除。