Thanks for replying Alex, > „...How do you specify the traditional `java -jar > myapp.jar` to the `run` task? If it's by setting `jvmArgs` then > presumably the same problem occurs of stray arguments being passed to > the main class?..“
The traditional `java -jar myapp.jar` setting is the same for both cases. But, oddly enough, from what I've observed, if Gradle detects it's just a „traditional“ run, it will prepend everything _before_ the main class. I mentioned that here [1]: >> The peculiar thing about it, is Gradle does add those >> exact same properties to the beginning of the command >> line when they detect it's a regular --classpath command >> and not a --module-path command. Go figure! I'm relatively new to Gradle. But I'm finding that it's full of magical little surprises like that :) > BTW your module path doesn't need to spell out the JAR file. Just > `build/libs` is enough for the Java compiler and the Java runtime to > find `my.module`. A module path option should be orders of magnitude > shorter than a class path option! Awesome tip! Thanks Alex. That's two awesome tips I learned today. TIL also about the (*) for class path elements: >> „...As a special convenience, a class path element that contains >> a base name of an asterisk (*) is considered equivalent to specifying >> a list of all the files in the directory with the extension .jar or .JAR. >> A Java program can’t tell the difference between the two invocations. >> For example, if the directory mydir contains a.jar and b.JAR, then the >> class path element mydir/* is expanded to A.jar:b.JAR, except that the >> order of JAR files is unspecified...“ ---- [1] http://bit.ly/ArgsHmmm ---- -------- Original Message -------- Subject: Re: Preparing to Repair Gradle's Malformed Module Main-Class Command Line From: Alex Buckley <alex.buck...@oracle.com> Date: Wed, October 16, 2019 3:30 pm To: jigsaw-dev@openjdk.java.net I was going to ask if setting `jvmArgs` in the `run` task is the right way to configure Gradle, but I see it's done here: https://guides.gradle.org/building-java-9-modules/#modify_the_code_run_code_task_to_use_modules Setting aside `-m`: How do you specify the traditional `java -jar myapp.jar` to the `run` task? If it's by setting `jvmArgs` then presumably the same problem occurs of stray arguments being passed to the main class? BTW your module path doesn't need to spell out the JAR file. Just `build/libs` is enough for the Java compiler and the Java runtime to find `my.module`. A module path option should be orders of magnitude shorter than a class path option! Alex On 10/16/2019 3:03 PM, Plugins wrote: > Hi all, > > > Please review this issue [1]? It reports a defect in the Gradle build > tool's current construction of malformed java command lines that are > intended to execute a Main-Class of a JPMS module. > > At first I thought the bug reported there was in either the Dropwizard > application framework I was using at the time, or in the CLI parser > utility (argparse4j) Dropwizard uses under the hood. > > I am now convinced — by diagnosis done by those two projects' > maintainers — that the command line construction bug is definitely in > Gradle's court. > > I'd like to request from the list you all's take on this. Please? I have > been experimenting with a solution that works so far. But any insight or > suggestions anybody here can offer would be muy appreciado! TIA. > > ---- > > [1] http://bit.ly/Issue10825 «Refactor > JvmOptions.getAllImmutableJvmArgs() to support executing the main class > in a JPMS module» > > ---- >
