Process custom image classpath after parsing options

[galderz]

Closes #3742

• Custom image classpath processing can be impacted by exclude-config.
• Moved the code out of -jar parsing, to avoid the need for specific parameter order.
• Without this change, --exclude-config needs to be passed before -jar for it to have an effect.
• Added some verbose messages for easier debugging of native-image binary.

[galderz]

The CI failure seems unrelated.

[munishchouhan]

@galderz thanks for your contribution, I have assigned a reviewer to this PR

[olpaw]

Hi @galderz ,

the fact that --exclude-config needs to be passed before -jar is not a bug. It's well documented behaviour:

• See https://www.graalvm.org/reference-manual/native-image/Options The options passed to native-image are evaluated left-to-right. For more information, see Native Image Build Configuration.
• and https://www.graalvm.org/reference-manual/native-image/BuildConfiguration/#order-of-arguments-evaluation

The arguments passed to native-image are evaluated left-to-right. This also
extends to arguments that get passed indirectly via META-INF/native-image
based native image configuration. Suppose you have a JAR file that contains
native-image.properties with Args = -H:Optimize=0. Then by using the
-H:Optimize=2 option after -cp <jar-file> you can override the setting that
comes from the JAR file.

We cannot modify the behaviour for -jar since this would lead to surprising behaviour that conflicts with our left-to-right evaluation policy. Suppose you use -jar foo.jar with a foo.jar that has a META-INF/native-image/native-image.properties embedded that contains

Args = -O0 -H:Name=customImageName

Due to our left-to-right evaluation users are able to override the args coming from that native-image.properties file.
Using native-image -jar foo.jar -O1 -H:Name=lastArgumentWinsImageName works as expected.

Your change would break that behaviour.

[olpaw]

See #3749 (comment)

[munishchouhan]

Closing this PR, If still there is any change is required, please raise a new PR

[galderz]

@olpaw Thanks for the clarification. Are there any tests that verify the behaviour you mention?

[olpaw]

There are no explicit test of this. But our whole way of building images (especially with mx) relies on that.

If you run e.g. mx --extra-image-builder-argument=--verbose --env ce-complete build |& build.log you can observe many instances of build options being overruled by subsequent options (based on the behaviour described in https://www.graalvm.org/reference-manual/native-image/BuildConfiguration/#order-of-arguments-evaluation). Even the fact that --extra-image-builder-argument is useful at all relies on this behaviour.

Also the native-image.properties used around building truffle images relies heavily on this. I.e. overriding the default -Dtruffle.TruffleRuntime=com.oracle.truffle.api.impl.DefaultTruffleRuntime with -Dtruffle.TruffleRuntime=com.oracle.svm.truffle.api.SubstrateTruffleRuntime in lib/svm/macros/truffle/native-image.properties but being able to override that again on command line with placing -Dtruffle.TruffleRuntime=com.oracle.truffle.api.impl.DefaultTruffleRuntime (after the truffle options) for building interpreter-only images.

[sdeleuze]

@olpaw On Spring side, we need to use --exclude-config configured via native-image.properties in the classpath. Due to the ordering behavior, it seems it is not possible. Could you confirm?

If confirmed, I understand we can't change the global behavior of "ordering matters", but could we at least work on a fix for this specific issue to allow --exclude-config after -cp or -jar ?

Happy to create a dedicated issue if that makes sense.

cc @gradinac

[olpaw]

@olpaw On Spring side, we need to use --exclude-config configured via native-image.properties in the classpath. Due to the ordering behavior, it seems it is not possible. Could you confirm?

@sdeleuze, how about creating a subdir that contains native-image.properties and is put on the classpath as the first entry. I.e.

mkdir -p config-only-cp-entry/META-INF/native-image`
echo '--exclude-config ....' >  config-only-cp-entry/META-INF/native-image/native-image.properties

then use

-cp config-only-cp-entry:<other-classpath-entries ...>

Since config-only-cp-entry is the first classpath entry it's native-image.properties will be processed before all others.

[olpaw]

-cp config-only-cp-entry:<other-classpath-entries ...>

Possible also good to know that native-image (other than java) allows you to use -cp and -jar in the same command line invocation (or multiple -cp args in the same invocation). Because of that you could also use:

-cp config-only-cp-entry -cp <other-classpath-entries ...>

[olpaw]

@sdeleuze did the approach I suggested in #3749 (comment) work for you?

[olpaw]

@galderz we could make --exclude-config order independent if we disallow the option to be used anywhere else than command line (i.e. embedding --exclude-config in native-image.properties in META-INF/native-image would be prohibited).

Would this limitation be ok with you? cc @sdeleuze

[galderz]

@olpaw It's been a while since I worked on this, but the change here was no longer necessary once we understood the reason for the limitations. IIRC ordering parameters the expected way was enough.

[sdeleuze]

@olpaw I think for now the plan is to workaround that at Native Build Tools level, see graalvm/native-build-tools#185.

[olpaw]

@sdeleuze FYI I fixed this on master last week (so it will be in 22.2). Now if you use --exclude-config ... on the native-image command line, it will affect all classpath & module-path entries used on the same command line independent from having specified --exclude-config ... before or after -cp/p arguments. See 006c61d

[sdeleuze]

@olpaw Awesome thanks a lot!