Run task builds command with unwanted arguments

[cosmiczoo]

For my modular openJFX programs, the Gradle run task constructs a long command like that below. Looking in detail at the command constructed, I see it includes the bolded text a second time at the end after some java command line options. As a consequence, the text that follows the bolded text is passed to the application as arguments. The program does not and should not recognise these arguments.

The first thing to note is the problem does not show itself when I build for the classpath by deleting solely the module-info.java file.

If I try out the command in a Terminal deleting just the bolded text, the application starts without arguments and launches the JavaFX Application threads correctly. Similarly, if the application ignores all command line arguments, the JavaFX program works correctly despite arguments.

This behaviour applies to both Gradle 6.7 and Gradle 7.2.
I am using JDK 11 on openSuse.

Test Program

Here's my simple JavaFX Gradle program that expresses the problem.
gradle-problem-demo
The repository is public and you may copy the program if it would help solve this problem. You may adopt all or part of this program into Gradle tests. It is the purpose for which I wrote it.

I ran the program in a terminal/console (eliminating my IDE)

prompt> export JAVA_HOME=/usr/java/jdk-11
prompt> ./gradlew -i -x check -x test run

The command generated

I laid out the offending command nicely below and bolded the substring that was added twice:

/usr/java/jdk-11/bin/java
--add-modules javafx.controls,javafx.fxml,javafx.graphics
--module-path /home/emma/NetBeansProjects/Demo/build/libs/Demo.jar
:/home/emma/.gradle/caches/modules-2/files-2.1/org.openjfx/javafx-fxml/16/c7147c450773c3d4fd038ac9d1a6fdebbc3c11e0/javafx-fxml-16-linux.jar
:/home/emma/.gradle/caches/modules-2/files-2.1/org.openjfx/javafx-controls/16/116b127e512d23ddb84c62017c256e7f67f5b9eb/javafx-controls-16-linux.jar
:/home/emma/.gradle/caches/modules-2/files-2.1/org.openjfx/javafx-graphics/16/1bf2fd9f083daa2f492c4c58c4f7d5acb6f4b7d/javafx-graphics-16-linux.jar
:/home/emma/.gradle/caches/modules-2/files-2.1/org.openjfx/javafx-base/16/7d6b85ec89e99ea40c2a63bb1f23d43e05cd2557/javafx-base-16-linux.jar
--patch-module Demo=/home/emma/NetBeansProjects/Demo/build/resources/main
--module Demo/Demo.Main
-Dfile.encoding=UTF-8 -Duser.country=GB -Duser.language=en -Duser.variant
--module Demo/Demo.Main

[siordache]

This is a long-standing issue for which I wasn't able to find a proper solution. An early attempt to fix it uses reflection and works only for Gradle 6.5 or earlier. Another ugly pull request attempts to fix the issue for newer Gradle versions but it actually works only for Gradle 6.6. That's why I decided to not merge it.

Using reflection to hack into Gradle's internals is not the way to go. I feel that there should be a cleaner solution but I couldn't find it. I put the "help wanted" label on this issue and I would be very grateful to anyone who can provide a pull request.

[cosmiczoo]

Serban Thank you for confirming it's a known issue. I would like to help diagnose the problem if I can. Do you think walking through the construction of the command, through the various projects (e.g. Application plugin / JavaExec()) would help to identify a solution? I highlighted the first occurrence of --modules because I reckoned that was the cause and the smallest change to make the command work I could see. Was that occurrence added somewhere in the Application plugin? I'm not very familiar with the code unfortunately so would benefit from knowing where to look. Scan reading the #153 without really understanding it, I get the impression it was modifying a command prepared earlier. Is there reluctance from any quarter to modify the code that produced the starting command? I don't see modules going away any time soon. Changing the Application plugin (assuming that is where the command is first assembled) to make it do the right thing for modular builds seems more robust and easier to maintain over the long term. When I get some time I will study the pull request to see if I can see another approach.

…

On Sun, 12 Sep 2021, 16:39 Serban Iordache, ***@***.***> wrote: This is a long-standing issue for which I wasn't able to find a proper solution. An early attempt to fix it <#153> uses reflection and works only for Gradle 6.5 or earlier. Another ugly pull request <#168> attempts to fix the issue for newer Gradle versions but it actually works only for Gradle 6.6. That's why I decided to not merge it. Using reflection to hack into Gradle's internals is not the way to go. I feel that there should be a cleaner solution but I couldn't find it. I put the "help wanted" label on this issue and I would be very grateful to anyone who can provide a pull request. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#205 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKOBMYMDOQ5HGOXLMYMSAGTUBTCUTANCNFSM5D3PHHCQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[siordache]

Thank you so much for offering to look into this issue. I had started to write you a message explaining the interplay between the gradle-modules-plugin and the Application plugin. About 15 minutes into this I realized that there is actually a simple way to fix this issue for Gradle 6.4 and later versions. (With older versions the reflection-based workaround is still needed.) It's quite embarrassing that I didn't think about it before.

The fix is now included in version 1.8.10 of the plugin. In your Gradle script you need to apply the gradle-modules-plugin before the javafxplugin (otherwise an older version of the gradle-modules-plugin will be used):

plugins {
    id 'java'
    id 'application'
    id 'org.javamodularity.moduleplugin' version '1.8.10'    
    id 'org.openjfx.javafxplugin' version '0.0.10'
    ...
}    

Please let me know if this fix works for you.

[cosmiczoo]

It works, well done! Moreover, the command generated is nowhere near as long as before. It now looks right and reasonable to me. Thank you. You have solved the problem about which I raised the issue. Would you like me to do anything on the Issue Tracker?

…

On Wed, 15 Sept 2021 at 16:36, Serban Iordache ***@***.***> wrote: Thank you so much for offering to look into this issue. I had started to write you a message explaining the interplay between the gradle-modules-plugin and the Application plugin. About 15 minutes into this I realized that there is actually a simple way to fix this issue for Gradle 6.4 and later versions. (With older versions the reflection-based workaround is still needed.) It's quite embarrassing that I didn't think about it before. The fix is now included in version 1.8.10 of the plugin. In your Gradle script you need to apply the gradle-modules-plugin before the javafxplugin (otherwise an older version of the gradle-modules-plugin will be used): plugins { id 'java' id 'application' id 'org.javamodularity.moduleplugin' version '1.8.10' id 'org.openjfx.javafxplugin' version '0.0.10' ... } Please let me know if this fix works for you. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#205 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKOBMYM7JKEWS4OZALDFM4TUCC4QTANCNFSM5D3PHHCQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[siordache]

Thanks, Emma! I will close the issue now. Don't hesitate to reopen it if I missed something.