[FEATURE] Make Lombok compatible with JDK 16

[ilgrosso]

After JDK 16 has started the rampdown phase, we could not get Lombok working any more.

The exception reported by Maven compiler is:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project syncope-wa-starter: Fatal error compiling: java.lang.IllegalAccessError: 
class lombok.javac.apt.LombokProcessor (in unnamed module @0x3af91e7e) cannot access class
com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler
does not export com.sun.tools.javac.processing to unnamed module @0x3af91e7e -> [Help 1]

No issues with earlier JDK 16 releases.

[Rawi01]

I think the reason why it doesn't work anymore is that they added JEP 396. Adding --illegal-access=permit should fix the problem.

[randakar]

We're going to need a better fix for the long term though. They are removing the option to access these classes for a reason, and at some point it may stop working entirely.

…

On Tue, Dec 15, 2020, 16:36 Rawi01 ***@***.***> wrote: I think the reason why it doesn't work anymore is that they added JEP 396 <https://openjdk.java.net/jeps/396>. Adding --illegal-access=permit should fix the problem. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2681 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABIERMCDDFPWDOHLDIEGL3SU567BANCNFSM4U4HKVVQ> .

[rspilker]

We probably need to document all the add-opens the users need to add.

https://github.com/rzwitserloot/lombok/blob/f17dd036384242971546bc443749ad527b8cd21c/docker/ant/files/jdk-13/classpath/build.xml#L13-L23

[JornVernee]

For anyone using Maven, I was able to make it work with the following compiler plugin configuration:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.1</version>
    <configuration>
        <source>16</source>
        <target>16</target>
        <fork>true</fork>
        <compilerArgs>
            <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>
        <annotationProcessorPaths>
            <path>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>1.18.16</version>
            </path>
        </annotationProcessorPaths>
    </configuration>
</plugin>

Note that <fork>true</fork> is needed, otherwise Maven seems to (silently) ignore the -J options when invoking the compiler. Looks like jdk.compiler/com.sun.tools.javac.jvm also needs to be exported on top of what @rspilker linked.

[rzwitserloot]

Reproduced with jdk16ea on x64 mac.

[rzwitserloot]

We've found a solution that does not require all million users to add all these add-opens to their build scripts. We'll release it in time for the OpenJDK 16 release (In March 2021).

[namannigam]

@rzwitserloot that's good news. just curious though, if there is an open pull request for these changes?

[rspilker]

@namannigam No, there isn't. We'll explain the reasons in this issue once jdk16 has been officially released. Please don't speculate.

[jpg1024]

Is there a solution to this problem?

I have a maven project on IntelliJ IDEA that needs to be run through tomcat. But when I run it, a similar error is prompted:

java: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in unnamed module @0xddf172a) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @0xddf172a

The environment I use:

1. Java JDK 16
2. IntelliJ IDEA 2020.3.2
3. Apache Maven 3.6.3
4. Lombok 1.18.19

thanks.

[namannigam]

@pruidong the temporary solution is mentioned under #2681 (comment)

[jpg1024]

@namannigam thanks.

I found a better way to add to the Windows system environment variables:

Name:

_JAVA_OPTIONS

value:

--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED --add- opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED --add-opens=jdk. compiler/com.sun.tools.javac.model=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-opens=jdk.compiler/com. sun.tools.javac.processing=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools. javac.util=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED

[drmaniac]

We've found a solution that does not require all million users to add all these add-opens to their build scripts. We'll release it in time for the OpenJDK 16 release (In March 2021).

I'm very excited to see what this solution looks like. I wonder why this is why such a secret is made.

[rzwitserloot]

@pruidong Our fix for jdk16 should also take care of that.

We held it back just in case us publishing this causes a chain of events that ends up removing this convenient workaround from the GA of JDK16. Given that GA is in about 10 days, I think we're good to go and will soon commit our patch to master publicly.

[pron]

As an OpenJDK developer, let me explain that we’ve intentionally decided (after a lot of debate) to leave some well-known loopholes in to give libraries more time to gradually prepare for the new reality, and explain it, and why it is absolutely essential, to their users. Those loopholes are scheduled for gradual removal, one at a time, starting with JDK 17, as 16 already has the first step of encapsulation. Publishing exploits won’t make them stay or be removed any sooner or later; their removal will not be hastened or postponed. They are being removed according to schedule, and there will be a few months’ notice before each. I would recommended library authors use that time to prepare themselves and their users for this better but different environment.

In a few words, the strategy is this: use of JDK internals by libraries is tolerated as long as they notify the user that they’re doing so with add-opens. This is because such libraries become tied to JDK versions, and so must be vigilant when updating, and their users need to be aware of maintenance issues libraries might impose on them (there are also security issues when it comes to libraries that do this at runtime). So, you can do what you like, but if you impose a potential maintenance burden on your users, you must let them know about it. When all loopholes are closed, libraries will need to decide whether to not use internals or acclimate their users to add-opens. In some months there will be no way — using Unsafe, attach, native code etc. — to hack JDK internals without express approval of the application.

Of course, this is not an issue for applications, that should embed their own runtime and launcher with whatever flags they like (or, when it comes to build time tools, you can create a Maven plugin that does that). The point is that introducing maintenance (and/or security) burden will not be possible without the user knowing about it and taking some action to explicitly allow it — by using a specific executable, a specific plugin, or adding flags. When users understand that this is necessary, they tend to be very accommodating.