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

Wed May 29 08:23:48 UTC 2024

So is there any update on this? From the existing discussion, it was 
still not apparent whether the hotspot developers consider this being a 
problem that should be fixed properly. There were already a few possible 
solutions proposed in this thread.

If the core hotspot developers are a little bit out of their element 
when it comes to deployment models in practice and how to best approach 
this, I am sure that you can consult with some trusted colleagues that 
deal with this more often and can maybe share their opinion on this.

Best
Christopher Schnick

On 10/05/2024 18:40, Bruno Borges wrote:
> 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/20240529/76f9ca06/attachment-0001.htm>