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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Plugins
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»

----
Reply | Threaded
Open this post in threaded view
|

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

Alex Buckley
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»
>
> ----
>
Reply | Threaded
Open this post in threaded view
|

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

Plugins
In reply to this post by 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 <[hidden email]>
Date: Wed, October 16, 2019 3:30 pm
To: [hidden email]

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»
>
> ----
>