JVM arguments mangled since 1.10 resulting in ClassNotFoundException for PathClassLoader

[baron1405]

Describe the bug
I upgraded the gradle-intellij-plugin in my plugin project from 1.8 to 1.12. Following the upgrade my plugin compiled successfully but failed to run the units tests. A repeatable Java VM initialization error threw a ClassNotFoundException for the PathClassLoader. After an 8 hour journey, I traced the problem to a mangled test invocation command line. The offending portion of the command line was:

--add-opens java.base/java.util=ALL-UNNAMED java.base/jjava.lang=ALL-UNNAMED java.base/java.io=ALL-UNNAMED java.desktop/sun.awt=ALL-UNNAMED java.desktop/java.awt=ALL-UNNAMED java.desktop/javax.swing=ALL-UNNAMED java.sql/java.sql=ALL-UNNAMED java.base/sun.nio.ch=ALL-UNNAMED java.desktop/java.awt.event=ALL-UNNAMED 

Notice how there is a single --add-opens followed by the multiple packages to open. These are JVM arguments I have added in addition to the ones added by the plugin. Notice that the syntax is incorrect. The --add-options does not accept multiple packages, it must be repeated for each package. My code that specified these JVM arguments is:

jvmargs("--add-opens", "java.base/java.util=ALL-UNNAMED")
jvmargs("--add-opens", "java.base/jjava.lang=ALL-UNNAMED")
...

This should result in a command line with multiple --add-opens not just one.

--add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/jjava.lang=ALL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED --add-opens java.desktop/sun.awt=ALL-UNNAMED --add-opens java.desktop/java.awt=ALL-UNNAMED --add-opens java.desktop/javax.swing=ALL-UNNAMED --add-opens java.sql/java.sql=ALL-UNNAMED --add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.desktop/java.awt.event=ALL-UNNAMED 

When I manually edited the command line to insert the missing --add-opens, the tests ran successfully.

I traced the problem to commit 63d42c8 on 10/12/22 by @hsz. In this commit, a call to distinct() is made on the JVM arguments before being returned by Utils.getIdeJvmArgs. The result is that the multiple the --add-opens are collapsed into a single one followed by all the package specifications, which results in the illegal syntax. Unfortunately, the behavior of java under these circumstances appears to be undefined resulting in the erroneous report of a ClassNotFoundException. The date of this change means that it first appeared in version 1.10 of the plugin. This explains why I did not see it in 1.8 but encountered it when I upgraded to 1.12.

It is likely that this bug was not encountered during development and testing of the gradle-intellij-plugin because the plugin code specifies --add-opens using an = sign (e.g. --add-opens=java.base/java.util=ALL-UNNAMED), which would not be affected by the distinct operation. In fact, the workaround until the plugin is fixed is to use the = syntax:

jvmargs("--add-opens=java.base/java.util=ALL-UNNAMED")
jvmargs("--add-opens=java.base/jjava.lang=ALL-UNNAMED")
...

To Reproduce
Add JVM arguments using the non-equal syntax. For example,

jvmargs("--add-opens", "java.base/java.util=ALL-UNNAMED")
jvmargs("--add-opens", "java.base/jjava.lang=ALL-UNNAMED")

and run a plugin unit test. The result should be a ClassNotFoundException.

Expected behavior
The JVM arguments are not mangled by the plugin and the unit tests succeed.

Environment:

• OS: Ubuntu 20.04
• Gradle IntelliJ Plugin Version 1.12
• Gradle Version 7.5.1

[baron1405]

@vicky17d You might find this issue of interest.

[hsz]

Thank you, @baron1405, for all details! I'm now investigating the possibility of reverting the distinct() call as it was introduced to fix #1158 — which I can no longer reproduce.

[hsz]

Fixed, and currently available in 1.13.1-SNAPSHOT.