Lombok访问jdk.compiler的内部包与Java-16不兼容

更新：

Lombok v1.18.20 支持 JDK 16 开箱即用。

在同一线程中，其中一位维护者还写道：

我们有一些鲜为人知的漏洞，可以用来弥补一些差距。同时，我们将开始研究 gradle 和 maven 插件，这将是一个长期修复。

您在最新的 JDK-16 版本中看到的例外是因为JEP 396: Strongly Encapsulate JDK Internals by Default。Lombok 正在使用反射访问内部 JDK API，在以前的 Java 版本中，这会导致警告消息，现在会导致硬错误。

通常，通过--add-opens=<module>/<package>=<accessing module>在运行java. 在这种情况下，这些指令需要传递给java调用javac. 这可以通过前缀传递给选项来完成javac用-J，这将代替它传递给底层的JVM。

使用 Maven，我能够使用以下编译器插件配置使其工作：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.1</version>
    <configuration>
        <source>16</source>
        <target>16</target>
        <!--                    <release>16</release>-->
        <fork>true</fork>
        <compilerArgs>
            <arg>--enable-preview</arg>
            <arg>-Xlint:all</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>
            <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED</arg>
        </compilerArgs>
        <!--for unmappable characters in classes-->
        <encoding>UTF-8</encoding>
        <showDeprecation>true</showDeprecation>
        <showWarnings>true</showWarnings>
        <!--for lombok annotations to resolve-->
        <!--contradictory to maven, intelliJ fails with this-->
        <annotationProcessorPaths>
            <path>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>1.18.16</version>
            </path>
        </annotationProcessorPaths>
    </configuration>
</plugin>

使用<compilerArgs>配置中的元素传递所需选项的位置。

请注意，我-J在选项前面添加了为了将它们传递给正在运行的 JVM javac，而不是javac选项。

在--add-opens问题中列出的指令之上，还有一个：

-J--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED

也需要。

<fork>true</fork>还需要，因为否则-J选项将被忽略（从 的输出判断mvn clean install -X）。查看 Maven 文档，在使用时似乎随时都需要设置fork为：true<compilerArgs>

https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs

<compilerArgs>如果fork设置为 ，则设置要传递给编译器的参数true。

• It’s funny, how it always escalates the same way. *JDK issues a warning* → “but it still works”, some years later: *JDK produces an error* → “but I can make it work with an option”, yet another years later *hack stops working completely* → “why are they suddenly break compatibility?”
• Yeah, we definitely reached warning fatigue for illegal access warnings. I blame both sides - library authors by continuing to use that, and OpenJDK by not looking for why people requires it. I still don't know of a supported replacement for `java.io.Console.cs`. But the same thing is exposed as shared secret - because some other part of OpenJDK depends on it.