[EXTERNAL] Re: External _JAVA_OPTIONS environment variable sourcing for self-contained applications

[Bruno Borges]

Java runtime sharing (among multiple applications in the same environment) has become less and less important, and I think that is what those environment variables were meant for, to ensure any JVM would start with values from these env vars.

But deployment models have certainly evolved:


  *
More than half of Java applications in the Cloud are deployed as containers (see New Relic report from 2023).
  *
Java applications deployed to Virtual Machines tend to have exclusivity over the VM resources. Example: big data solutions are pushed to VMs dedicated to them.
  *
Developers tend to have multiple JDKs installed these days, from 8 all the way to 21. Expecting flags in those environment variables to work consistently across all versions is unrealistic.
  *
Some developer tools have been shipping their own java runtimes for quite some time already (e.g. JetBrains and Eclipse IDEs).

I do like Christopher's suggestion of an option in the JVM to disable environment variable sourcing of _JAVA_OPTIONS and JAVA_TOOL_OPTIONS. It gives back control to the application developer on how the runtime should behave, especially in the scenario of Java desktop applications, and it would align with the intents of jlink/jpackage.


________________________________
From: hotspot-dev <hotspot-dev-retn at openjdk.org> on behalf of Christopher Schnick <crschnick at xpipe.io>
Sent: May 10, 2024 3:42 AM
To: David Holmes <david.holmes at oracle.com>
Cc: hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
Subject: [EXTERNAL] Re: External _JAVA_OPTIONS environment variable sourcing for self-contained applications

[You don't often get email from crschnick at xpipe.io. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

 From my perspective, it doesn't really matter which environment
variable you're talking about. Even if there are small differences in
which order they apply, they generally all cause the issue of a global
configuration interfering with a local isolated self contained runtime
image. So _JAVA_OPTIONS and JAVA_TOOL_OPTIONS cause the same problems,
with only minor differences.

In practice, global environment variables are intended for things like
Java 8 applications that run via a globally installed JRE. The huge
issue is that there is a chance of an option being included in there
that is not supported by more recent JVMs like one for Java 21. If this
is the case, then ALL self contained graphical Java applications don't
even start up due to an unrecognized option and don't show an error
message (If you are running a console based application, then it prints
something but for desktop applications there is nothing). As of right
now, there is no possibility of running a global JRE/JDK configured with
certain environment variable options on the same system as a self
contained Java application created with the available JDK tools if the
options are not exactly compatible. That problem is especially relevant
when running JVMs from different vendors for different applications as
they differentiate themselves through options. One incompatible option
is all it takes for nothing to run anymore.

There are multiple different possibilities that I can think of to
somehow improve this situation:

- Give developers the option to unset these variables in the
automatically generated launcher script for jlink. Technically one can
modify the launcher script manually, but since it is automatically
generated in the beginning, it would be nicer if jlink could do that
automatically. Also give developers the option to do the same thing in
the generated native jpackage launcher executable. There's currently no
other way in jpackage to set any environment variables.

- Add some form of JVM option to disable environment variable sourcing
for other JVM options. That way this option could be passed in jlink and
jpackage, not requiring any modifications to the jlink and jpackage
tools. This would also be a good solution. Such an option would also be
useful for quick debugging in other cases.

On 10/05/2024 01:47, David Holmes wrote:
> On 9/05/2024 5:40 pm, Alan Bateman wrote:
>> On 09/05/2024 08:03, David Holmes wrote:
>>>
>>> How does such a jpackaged application actually launch/load the JVM?
>>> I'm wondering if there is a way to insert a new "shell" environment
>>> to launch the JVM without having those env vars present ... though I
>>> guess there may be other env vars that your application still needs.
>>
>> For modular applications, there is a jlink option to generate a
>> launcher (script) for the application. That's a potential place to
>> unset environment variables that shouldn't be inherited.  It may not
>> help here as it sounds like this is an application image produced by
>> jpackage with a native launcher, and the warning message is hidden as
>> there is no console (I assume).
>>
>> I think we should consider deprecating and eventually removing
>> _JAVA_OPTIONS. It's always been problematic that it appends rather
>> than prepend and it has issues in areas such as quoting. When
>> JDK_JAVA_OPTIONS was added then we had hoped that developers would
>> move from the undocumented env variable. The new env variable fixes a
>> bunch of things in the areas of quoting, arg files, works with
>> launcher options, and it of course prepends so it doesn't override
>> options.
>
> I think overriding options was a feature of `_JAVA_OPTIONS` not a bug
> - at least at the time. :) But deployment models have evolved (to a
> point where I don't even know/understand how things get deployed these
> days and who has control of the command-line and/or the env!).
> Deprecation may be a reasonable thing but doesn't help the current
> situation.
>
> David
>
>> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240510/eb9475cd/attachment-0001.htm>