search

oracle / graal

GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
https://www.graalvm.org
Other
20.4k stars 1.64k forks source link

[GR-57284] `JAVA_TOOL_OPTIONS` environment variable in native executables #9504

Open Mcdostone opened 3 months ago

Mcdostone commented 3 months ago

Feature request

Is your feature request related to a problem? Please describe.

This feature is about run time, not build time. When deploying a java app, we can configure the JVM with the JAVA_TOOL_OPTIONS environment variable or by passing arguments to the command.

In the graalVM world, it is also possible to declare system properties at run time by passing arguments to the native executable: ./my-native-executable -D hello=world. Unfortunately, I was not able to find any similar environment variable as JAVA_TOOL_OPTIONS for native executables.

Describe the solution you'd like.

It would be interesting to define an environment variable that is automatically read by the native executable. I have no inspiration for the name though: GRAALVM_TOOL_OPTIONS="-D hello=world" ./my-native-executable.

Describe who do you think will benefit the most.

This feature could benefit people shipping native executables in containers. Indeed, It is pretty common to configure applications with environment variables.

Describe alternatives you've considered.

So far, the only way to define system properties at run time is to declare them as arguments of the command line:

./my-native-executable \
    -D javax.net.ssl.trustStore=my-truststore.p12 \
    -D javax.net.ssl.trustStoreType=PKCS12 \
    -D javax.net.ssl.trustStorePassword=pass

Additional context.

This issue is related to #4650. The last message of this issue suggests that JAVA_TOOL_OPTIONS should be "compatible" with graalVM. I did some tests with different environment variables here and it's not the case. It might be a normal behavior or a bug, I don't know to be honest.

Why do I suggest this feature? I have a spring boot native executable running on kubernetes. this application needs a specific trust store to communicate with other applications. The trust store is automatically mounted to the pod by kubernetes at boot time, which means I need to configure my application to use it (-Djavax.net.ssl.trustStore).

Express whether you'd like to help contributing this feature

If I could, yes !

fniephaus commented 3 months ago

Hi @Mcdostone, thanks for the feature request! I think it may even make sense to support JAVA_TOOL_OPTIONS in a native executable for compatibility. After all, the native executable should behave the same as the application running on HotSpot. A native executable even includes a JVM (called SubstrateVM).

Note that there already is a NATIVE_IMAGE_OPTIONS env var which you can use to inject arguments into the bin/native-image launcher, but that is for build time.