Open com.sun.tools.javac modules on JDK 16+

[tisonkun]

This is an attempt to fix #834.

The solution is pointed out from google/google-java-format#612 (comment).

I'm new to this community and I'm glad to know how to move forward this effort.

[tisonkun]

cc @nedtwigg

[nedtwigg]

This needs an entry in each of the three CHANGES.md (root and plugin-maven/plugin-gradle).

If I understand correctly, the intent of this change is that users won't have to add the --add-opens commands most of the time? Have you been able to confirm this on your machine in an integration test?

[tisonkun]

@nedtwigg comments addressed. I'd like to know how to apply a local plugin jar so that I can verify with the SNAPSHOT on my projects - I'm working on this issue because I don't want my project contains a JDK16+ workaround gradle.properties file, which will fail JDK8 build.

[tisonkun]

OK. I've checked that this patch work for my project by publishToMavenLocal and running spotlessCheck with JDK17 without the workaround.

I'm glad to add an integration test if I learn how to. Or you may verify by yourself since I think if we workaround a JDK limitation, it should be straightforward and it's hard to me to construct such a test.

[nedtwigg]

Thanks!

[nedtwigg]

Released in plugin-gradle 6.7.0 and plugin-maven 2.22.6.

[tisonkun]

@nedtwigg sorry that I miss a local commit that we should get unsafe from reflection otherwise it will throw exceptions.

[catostrophe]

Does it fix the same issue with palantir-java-format?

[nedtwigg]

Re: palantir-java-format

• Not fixed in plugin-gradle 6.7.1 and plugin-maven 2.22.7.
• Yes fixed in plugin-gradle 6.7.2 and plugin-maven 2.22.8

[davidburstrom]

@nedtwigg This fix has an interesting side-effect that can cause apparent flakiness: Since the modules are opened for the VM as a whole, this means that any other plugin that runs GJF in the same VM piggy-backs on this solution, iff Spotless gets to run first. I've just been scratching my head as to why one invocation of Gradle works but not the other. It could be worth looking into closing the modules after use.

[tisonkun]

@davidburstrom Can you provide a reproduce here? I'm curious how an extra opened module hurts?

[taofik69]

BarreraVIP Rabu, 01 Maret 2023, 04:16PM +08:00 dari tison ***@***.***>:

…

@davidburstrom Can you provide a reproduce here? I'm curious how an extra opened module hurts? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[davidburstrom]

@tisonkun I don't have a public reproducer at hand, but consider this:

You have a custom Task that invokes GJF, for the sake of it called myGJF.
You have Spotless applied with GJF, which creates a Task called spotlessJavaApply.
With a new Gradle daemon, you execute ./gradlew spotlessJavaApply and then ./gradlew myGJF, which succeeds.
After stopping the Gradle daemon, you execute ./gradlew myGJF which fails, because the workaround in the PR hasn't been applied in the VM yet.

It hurts because hermeticity and reproducibility has been broken.

[tisonkun]

@davidburstrom I get your point now. Basically, I ever thought of just fixing the issue in GJF upstream and all downstreams need not to do any trick. But it seems the upstream is relatively inactive so I fix my case here.

You may try to pick related changes to the upstream and remove this trick :)

[taofik69]

Thank's boss

[davidburstrom]

Technically speaking, it would be the same issue upstream too: Any other library X that require the same compiler modules to be exported would work if GJF has been executed in the same VM and vice versa. It'd be better if the open was matched with a corresponding close when GJF is done, which obviously requires reference counting and would still be susceptible to race conditions (the library X would work only when GJF is executing).