Java 密封类 permits 泛型错误解析

本文深入探讨了Java密封类在`permits`子句中使用泛型类型参数时引发的编译错误。核心问题在于Java语言规范规定`permits`子句只能列出类型名称，而非包含泛型参数的完整类类型。文章通过示例代码展示了错误场景及正确的语法，并解释了为何不同Java编译器（如`ecj`与`javac`）在此问题上表现不一致，强调了遵循JLS规范和使用`javac`进行最终编译的重要性，以确保代码的正确性和兼容性。

深入理解 Java 密封类 permits 子句的泛型使用规范

Java 17 引入的密封类（Sealed Classes）特性，为开发者提供了更细粒度的类型层级控制，允许我们明确指定一个类或接口可以有哪些直接子类或实现类。这通过 permits 子句来实现。然而，在实际使用中，尤其当密封类与泛型结合时，开发者可能会遇到一个常见的编译错误，即在 permits 子句中错误地使用了泛型类型参数。本文将详细解析这一问题，并提供正确的解决方案。

密封类与 permits 子句简介

密封类通过 sealed 关键字声明，并通过 permits 关键字指定其允许的直接子类。例如：

public sealed abstract class Shape permits Circle, Rectangle {
    // ...
}

public final class Circle extends Shape {
    // ...
}

public final class Rectangle extends Shape {
    // ...
}

这种机制有助于构建更健壮的代数数据类型（ADT），并提升编译器对类型穷尽性检查的能力。

泛型密封类中的编译错误示例

考虑一个泛型抽象密封类 APath，它有两个泛型嵌套子类 LastWildcard 和 WholeWildcard。初次尝试可能如下编写：

public sealed abstract class APath permits APath.LastWildcard, APath.WholeWildcard {
    protected final List dirs;

    public final class LastWildcard extends APath {
        // ...
    }

    public final class WholeWildcard extends APath {
        // ...
    }
}

当使用 Maven 配合 maven-compiler-plugin 进行编译时，可能会遇到类似以下的错误信息：

[ERROR] /D:/Experiment/src/main/java/prefile/pref/APath.java:[13,52] '{' expected
[ERROR] /D:/Experiment/src/main/java/prefile/pref/APath.java:[15,25] class, interface, enum, or record expected
...

错误信息通常指向 permits 子句中泛型类型参数的位置，例如 APath.LastWildcard 中的 。

错误根源：Java 语言规范的规定

这个编译错误并非偶然，而是严格遵循 Java 语言规范（JLS）的结果。根据 JLS 关于密封类 permits 子句的规定（例如 JLS SE 19, Chapter 8.1.1.2. Sealed Classes），permits 子句中列出的必须是类型名称（TypeName），而不是类类型（ClassType）。

• 类型名称（TypeName）：指的是类的简单名称或完全限定名称，不包含任何泛型类型参数。例如 APath.LastWildcard。
• 类类型（ClassType）：指的是包含泛型类型参数的完整类型表达式。例如 APath.LastWildcard。

因此，在 permits 子句中，我们不能指定带有泛型参数的类，即使这些子类本身是泛型的，或者它们继承自一个泛型父类。permits 子句只关心子类的“身份”或“名称”，而不关心其具体的泛型实例化。

正确的 permits 子句写法

要解决上述编译错误，只需从 permits 子句中移除泛型类型参数。正确的代码示例如下：

public sealed abstract class APath permits APath.LastWildcard, APath.WholeWildcard {
    protected final List dirs;

    public final class LastWildcard extends APath {
        // ...
    }

    public final class WholeWildcard extends APath {
        // ...
    }
}

通过将 APath.LastWildcard 修改为 APath.LastWildcard，以及 APath.WholeWildcard 修改为 APath.WholeWildcard，代码将能够顺利通过 javac 编译。

编译器差异：ecj 与 javac

值得注意的是，在某些集成开发环境（IDE）如 Eclipse 或基于 Eclipse LSP 的 VSCode 中，可能并不会立即显示此编译错误。这是因为这些 IDE 通常使用 Eclipse Compiler for Java (ecj) 进行实时编译和错误检查，而 Maven 构建则默认使用 JDK 自带的 javac 编译器。

• ecj (Eclipse Compiler for Java)：它是一个独立的 Java 编译器实现，有时在某些语言特性的实现上可能与 javac 存在细微差异，或者对新特性的支持更新速度不同。在本例中，ecj 可能对 permits 子句中的泛型参数表现出更宽松的解析，从而没有报错。
• javac (Standard JDK Compiler)：它是 Java 官方提供的标准编译器，严格遵循 Java 语言规范。因此，当 javac 遇到不符合 JLS 规定的语法时，就会抛出编译错误。

这种差异解释了为何代码在 IDE 中看起来正常，但在 Maven 构建时却失败。始终以 javac 的编译结果为准，因为它代表了 Java 语言规范的权威解释。

总结与注意事项

1. 遵循 JLS 规范：在密封类的 permits 子句中，只能列出子类的类型名称（TypeName），即不带泛型参数的类名。
2. 移除泛型参数：如果子类是泛型的，或者其父类是泛型的，在 permits 子句中列出子类时，请移除所有泛型类型参数。
3. 以 javac 为准：当 IDE 的实时编译结果与 Maven 构建的 javac 编译结果不一致时，应始终信任 javac 的输出，并根据其报错进行修正。这确保了代码的规范性、可移植性和在不同环境下的兼容性。
4. Maven 配置：确保 pom.xml 中 maven.compiler.source 和 maven.compiler.target 配置为 Java 17 或更高版本，以正确支持密封类特性。

通过理解和遵循这些规范，开发者可以避免在 Java 密封类与泛型结合使用时遇到的常见编译问题，从而更有效地利用这一强大的语言特性。