[GR-39407] Add an env variable like `JAVA_TOOL_OPTIONS`

[dmikusa]

Feature request

Please include the following information:

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

When running apps with a JVM, you have the option to set flags for the JVM (like -Xmx) through the JAVA_TOOL_OPTIONS env variable. This is handy in environments where it's not practical or possible to manipulate the process arguments.

Given that you can feed in some GC configuration parameters as process arguments, https://www.graalvm.org/22.1/reference-manual/native-image/MemoryManagement/, it would be convenient if you could do this through an env variable as well.

Describe the solution you'd like.

I can understand not wanting to support JAVA_TOOL_OPTIONS in GraalVM as it might be confusing or get misused. It would be helpful if we could have a differently named environment variable that functions in the same way. For example, NATIVE_IMAGE_OPTIONS or GRAALVM_OPTIONS.

Describe who do you think will benefit the most.
GraalVM users & developers of libraries and frameworks which depend on GraalVM.

My personal use case is the latter. I work on the Paketo Buildpacks project and we integrate GraalVM into buildpacks. It is tricky and less flexible for our users to set arguments than env variables.

Describe alternatives you've considered.

You can set flags as arguments to the process, but this isn't as flexible and causes issues for Cloud-Native buildpack users.

Additional context.

N/A

Express whether you'd like to help contributing this feature

No

[fniephaus]

Hi @dmikusa, while we understand why you'd want this, we share your concerns regarding misuse. Providing the same functionality under a different name won't prevent this. However, maybe #5473 will make it easier to pass in additional arguments from the outside.

[dmikusa]

Providing the same functionality under a different name won't prevent this.

I respectfully disagree. The misuse or perhaps accidental misuse is a better way to describe the concern, comes from the fact that someone would set JAVA_TOOL_OPTIONS and entries in said env variable expecting or assuming it to work in the same way that it works with a JVM. Since that does not happen, that would be accidental misuse.

If you change the name of this environment variable then a user must know the name of the environment to add settings through it. To me, that is a user acknowledging the difference, and if they put incorrect settings into a differently named environment variable that is just wrong and the user's fault. A tool can never fully prevent users from making poor choices and incorrectly using the tool.

Not having this on the other hand makes it considerably harder in some environments to pass configuration settings through to the process.

However, maybe #5473 will make it easier to pass in additional arguments from the outside.

I read through this but I'm not seeing how that would help me pass settings through to the process. Can you expand on your suggestion please?

[fniephaus]

Not having this on the other hand makes it considerably harder in some environments to pass configuration settings through to the process.

That, however, is the point. If the environment can change the configuration arbitrarily, we're going to have a hard time reproducing and debugging problems.

I read through this but I'm not seeing how that would help me pass settings through to the process. Can you expand on your suggestion please?

These bundles are self-contained and provide everything needed to generate a native executable. This includes sources/jars, dependencies, and command-line flags. This means that you can inject options when creating the bundle.

[dmikusa]

Not having this on the other hand makes it considerably harder in some environments to pass configuration settings through to the process.

That, however, is the point. If the environment can change the configuration arbitrarily, we're going to have a hard time reproducing and debugging problems.

I agree that it's one more place where a user can change inputs to a program and hence possibly impact the execution of that program, but it's permissible to pass additional configuration as arguments to the program already, why is doing it via env variables that different? You already need to know the user's arguments, so the question when troubleshooting an issue just becomes "Did you set any arguments or pass flags through the environment?".

For what it's worth, the JVM handles this by logging the flags it finds when they are set through the env. That seems perfectly reasonable here as well.

Environment variable configuration is quite popular. Spring Boot allows one to do this, among other configuration options. It's also popular in container-based deployments (i.e. Docker & K8s) because it is an easy way to pass in configuration. There are also popular tools like direnv that help manage configuration through env variables. Supporting this option would make it easier to run native-image binaries in all of these situations, not just with buildpacks.

I read through this but I'm not seeing how that would help me pass settings through to the process. Can you expand on your suggestion please?

These bundles are self-contained and provide everything needed to generate a native executable. This includes sources/jars, dependencies, and command-line flags. This means that you can inject options when creating the bundle.

OK, I think I'm following now. I could see that technically solving the issue, but I don't think it would be generally acceptable for our users, especially production containers.

1. I think we'd get pushback from users on the fact that it includes source code. Most of our users do not want source code to be in the final image. I don't fully agree but I often see people wanting basically the opposite, i.e. something as obtuse as possible. Just passing along observations but I believe the thought process is that if a container is compromised, they don't want someone to be able to easily see the code that's running.
2. There's a very strong demand for containers that are as small as possible. We get complaints when there's an extra 20 or 30M we could trim. I don't think users will want to include all of the source and dependencies because this is going to make the container size go up quite a bit.

[fniephaus]

May I suggest you join the next Native Image Committer and Community Meeting (I believe the next one is this Thursday) and add this to the agenda?

[dmikusa]

I appreciate the invite, but that would be during my workday and I don't think I could get away to join a meeting.

Anyway, I wanted to represent the use case as well as possible. I think I've done that on this thread. If this use case can be accommodated it would be appreciated, if not, I understand as well. I appreciate your time & explaining your concerns with the request. Thanks

[n3ziniuka5]

I came across this issue when I was building both native and non-native versions of images for my project. It would be great if there was a consistent way to pass java options to both of these images. JAVA_TOOL_OPTIONS is mentioned here, but JDK_JAVA_OPTIONS might be a more suitable choice for this.

I tried doing this within my docker image, for example with ENTRYPOINT exec /opt/app $JDK_JAVA_OPTIONS, but this only works in shell form ENTRYPOINT and I am using distroless as the base which doesn't have a shell. So that's why it would be great to have this built-in.

[fniephaus]

Good news: we have added support for a NATIVE_IMAGE_OPTIONS environment variable, which will ship with GraalVM for JDK 22.