Preparing to Repair Gradle's Malformed Module Main-Class Command Line

[Plugins]

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.buckley at oracle.com>
Date: Wed, October 16, 2019 3:30 pm
To: jigsaw-dev at 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»
> 
> ----
>