[GR-47047] native-image swallows runtime arguments

[revintec]

running GraalVM Java version: 20.0.1+9 Enterprise Edition, latest version as of writing
a very simple program that prints main function args

import java.util.*;

class HelloWorld {
    public static void main(String[] args) {
        System.out.println(Arrays.toString(args));
    }
}

when run after compilation
binary a b c outputs [a, b, c] as expected
binary a -Db=1 c outputs [a, c], swallowing the -Db=1 parameter

[fniephaus]

Thanks for filing the ticket, @revintec. I can confirm the behavioral mismatch:

$ java HelloWorld a -Db=1 c
[a, -Db=1, c]
$ ./helloworld a -Db=1 c
[a, c]

I suspect this has to do with the property parser as -Db=1 should set the property b to 1, just like this command would do:

$ java -Db=1 HelloWorld a b c
[a, b, c]

We'll look into this.

[revintec]

@fniephaus thanks for the swift response
I suspect that too, I think helloworld -Db=1 c should set b to 1
but helloworld a -Db=1 should not, matching the JVM behavior

can you point me to the relevant code? I'd like to dig more

[fniephaus]

I think RuntimePropertyParser.java is a good starting point.

I'm not sure the order should play a role here (e.g., helloworld -Db=1 c vs helloworld a -Db=1). May there's a better way to distinguish runtime options from applications arguments (e.g., helloworld -Db=1 -- c).

[revintec]

@fniephaus it's all about java compatibility :)
I think helloworld -Db=1 -- c should be args=["-Db=1","--","c"], the same as java version, instead of args=["c"]

we should support resetting java properties, after all it's a legitimate use-case. there're some options that come to my mind:

1. -Dxxx=yyy other args -> ["other","args"]; -- -Dxxx=yyy other args -> ["-Dxxx=yyy","other","args"]; -- -- -Dxxx=yyy other args -> ["--","-Dxxx=yyy","other","args"]; a -Dxxx=yyy b -> ["a","-Dxxx=yyy","b"] // preferred
2. use environment variables to overwrite properties, don't support -Dxxx=yyy
3. -Dxxx=yyy a -> ["a"]; \-Dxxx=yyy a -> ["-Dxxx=yyy","a"]

[fniephaus]

Ok, so I did some more digging and it seems you can use -H:-ParseRuntimeOptions when building the image to avoid that -Db=1 is being stripped out from the application args and used to set the property.

However, this begs the question: what if users want to set both VM and argument options, possibly with different values, for example -Db=foo to set the property b to foo and an application argument -Db=bar. It's probably hard to change our current default, but we could allow clear separation of VM options and applications args using the -- approach:

./binary <vm options> -- <application args>

For the above example, it would look like this:

./helloworld -Db=foo -- -Db=bar

I will file a feature request for this internally.

[revintec]

@fniephaus
my previous post listed option 1 can solve the problem, as you said, ./helloworld -Db=foo -- -Db=bar

and I'd like to add the following case:

1. any -Db=foo -> any -Dxxx
2. -Db=foo any -> jvm + any
3. -Db=foo -- any -> jvm + any
4. -Db=foo -- -- any -> jvm + -- any
5. -- any -> any
6. -- -- any -> -- any

pseudo code:

int split; String[] jvmArgs, progArgs
for(split = 0; split < args.length && args[split].startsWith("-D"); ++split);
jvmArgs = args[0 until split]
if(split < args.length && args[split] == "--") ++split
progArgs = args[split until args.length]

[fniephaus]

So your refinement is essentially only for the case when -- is not used. I think from a user's perspective, we should actually try and reduce the "magic" or "surprises" for users. Ideally, we'd require a clear split but that's hard due to backwards compatibility. By only adding support for --, we allow users like you to clearly separate VM options from applications args, without having to recompile or break compatibility.

[revintec]

@fniephaus yes, specifically for cases when -- is not used. I think there're 2 advantages:

1. a -Dxx=yy b -> a b is very unintuitive, different from JVM, also different from traditional Unix CLI tools. you can try echo -n b vs echo a -n b; the current SVM implementation may even be considered a BUG

2. if we think about the real use cases, in shell, one often writes ./helloworld $*. currently these program runs fine with grep.sh a b c, but as soon as they changes their arguments to grep.sh a -- b c, the SVM may crash, unrecognizing what JVM flag a is. we shouldn't deprive the users ability to use -- in their own argument list

one may argue that we can change grep.sh to ./helloworld -- $*, but that deprives users of grep.sh to pass-in JVM arguments using grep.sh -Dxx=yy -- a b c. and we sure not want user to always write -- in front of everything, grep.sh -- a b c, grep.sh -- b c d

all in all, please try to be unix compatible, which is also easier to teach and understand, or at least add a -H:+CliUnixArgs flag :) if needed, I can translate my pseudo code to real-code(open a PR

[fniephaus]

the current SVM implementation may even be considered a BUG

Right. The one thing you seem to forget is backwards compatibility. We can't just change something like this from one to the next release. We'd have to provide an opt-in preview option, then flip the default in a later release, and keep the old behavior around for some time.

a -Dxx=yy b -> a b is very unintuitive

So your suggestion is to change the default, so that it accepts VM options until it hits the first non-VM option, and the rest is treated as application arguments? I believe this would look like this:

$ ./helloworld -Xmx4g -Dfoo=bar arg1 arg2 arg3
[arg1, arg2, arg3]
$ ./helloworld -Dfoo=bar arg1 -Xmx4g arg3
[arg1, -Xmx4g, arg3]
$ ./helloworld arg1 -Xmx4g -Dfoo=bar
[arg1, -Xmx4g, -Dfoo=bar]
$ ./helloworld -Xmx4g -Dfoo=bar
[]

[revintec]

@fniephaus thanks for the reply, yes for cases without --. for cases with --, treat -- as a non jvm argument and drop the first encountered --. as for compatibility, a flag(-H:+CliUnixArgs or something similar) as suggested by my previous post should be fine

[revintec]

@fniephaus Hi, is there any update on this issue?