<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.<br>
<br>
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.<br>
<br>
Best<br>
Christopher Schnick</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/05/2024 18:40, Bruno Borges
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:MN0PR21MB3750252C5CB0E76C87616A6385E72@MN0PR21MB3750.namprd21.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
But deployment models have certainly evolved:</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<ul
data-editing-info="{"orderedStyleType":1,"unorderedStyleType":2}"
style="margin-top: 0px; margin-bottom: 0px;">
<li
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); list-style-type: "- ";">
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
More than half of Java applications in the Cloud are
deployed as containers (see New Relic report from 2023).</div>
</li>
<li
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); list-style-type: "- ";">
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
</li>
<li
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); list-style-type: "- ";">
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
</li>
<li
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); list-style-type: "- ";">
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Some developer tools have been shipping their own java
runtimes for quite some time already (e.g. JetBrains and
Eclipse IDEs).</div>
</li>
</ul>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
hotspot-dev <a class="moz-txt-link-rfc2396E" href="mailto:hotspot-dev-retn@openjdk.org"><hotspot-dev-retn@openjdk.org></a> on behalf of
Christopher Schnick <a class="moz-txt-link-rfc2396E" href="mailto:crschnick@xpipe.io"><crschnick@xpipe.io></a><br>
<b>Sent:</b> May 10, 2024 3:42 AM<br>
<b>To:</b> David Holmes <a class="moz-txt-link-rfc2396E" href="mailto:david.holmes@oracle.com"><david.holmes@oracle.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:hotspot-dev@openjdk.org">hotspot-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:hotspot-dev@openjdk.org"><hotspot-dev@openjdk.org></a><br>
<b>Subject:</b> [EXTERNAL] Re: External _JAVA_OPTIONS
environment variable sourcing for self-contained applications</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span
style="font-size:11pt;">
<div class="PlainText">[You don't often get email from
<a class="moz-txt-link-abbreviated" href="mailto:crschnick@xpipe.io">crschnick@xpipe.io</a>. Learn why this is important at
<a href="https://aka.ms/LearnAboutSenderIdentification"
moz-do-not-send="true" class="moz-txt-link-freetext">https://aka.ms/LearnAboutSenderIdentification</a>
]<br>
<br>
From my perspective, it doesn't really matter which
environment<br>
variable you're talking about. Even if there are small
differences in<br>
which order they apply, they generally all cause the issue
of a global<br>
configuration interfering with a local isolated self
contained runtime<br>
image. So _JAVA_OPTIONS and JAVA_TOOL_OPTIONS cause the
same problems,<br>
with only minor differences.<br>
<br>
In practice, global environment variables are intended for
things like<br>
Java 8 applications that run via a globally installed JRE.
The huge<br>
issue is that there is a chance of an option being
included in there<br>
that is not supported by more recent JVMs like one for
Java 21. If this<br>
is the case, then ALL self contained graphical Java
applications don't<br>
even start up due to an unrecognized option and don't show
an error<br>
message (If you are running a console based application,
then it prints<br>
something but for desktop applications there is nothing).
As of right<br>
now, there is no possibility of running a global JRE/JDK
configured with<br>
certain environment variable options on the same system as
a self<br>
contained Java application created with the available JDK
tools if the<br>
options are not exactly compatible. That problem is
especially relevant<br>
when running JVMs from different vendors for different
applications as<br>
they differentiate themselves through options. One
incompatible option<br>
is all it takes for nothing to run anymore.<br>
<br>
There are multiple different possibilities that I can
think of to<br>
somehow improve this situation:<br>
<br>
- Give developers the option to unset these variables in
the<br>
automatically generated launcher script for jlink.
Technically one can<br>
modify the launcher script manually, but since it is
automatically<br>
generated in the beginning, it would be nicer if jlink
could do that<br>
automatically. Also give developers the option to do the
same thing in<br>
the generated native jpackage launcher executable. There's
currently no<br>
other way in jpackage to set any environment variables.<br>
<br>
- Add some form of JVM option to disable environment
variable sourcing<br>
for other JVM options. That way this option could be
passed in jlink and<br>
jpackage, not requiring any modifications to the jlink and
jpackage<br>
tools. This would also be a good solution. Such an option
would also be<br>
useful for quick debugging in other cases.<br>
<br>
On 10/05/2024 01:47, David Holmes wrote:<br>
> On 9/05/2024 5:40 pm, Alan Bateman wrote:<br>
>> On 09/05/2024 08:03, David Holmes wrote:<br>
>>><br>
>>> How does such a jpackaged application
actually launch/load the JVM?<br>
>>> I'm wondering if there is a way to insert a
new "shell" environment<br>
>>> to launch the JVM without having those env
vars present ... though I<br>
>>> guess there may be other env vars that your
application still needs.<br>
>><br>
>> For modular applications, there is a jlink option
to generate a<br>
>> launcher (script) for the application. That's a
potential place to<br>
>> unset environment variables that shouldn't be
inherited. It may not<br>
>> help here as it sounds like this is an
application image produced by<br>
>> jpackage with a native launcher, and the warning
message is hidden as<br>
>> there is no console (I assume).<br>
>><br>
>> I think we should consider deprecating and
eventually removing<br>
>> _JAVA_OPTIONS. It's always been problematic that
it appends rather<br>
>> than prepend and it has issues in areas such as
quoting. When<br>
>> JDK_JAVA_OPTIONS was added then we had hoped that
developers would<br>
>> move from the undocumented env variable. The new
env variable fixes a<br>
>> bunch of things in the areas of quoting, arg
files, works with<br>
>> launcher options, and it of course prepends so it
doesn't override<br>
>> options.<br>
><br>
> I think overriding options was a feature of
`_JAVA_OPTIONS` not a bug<br>
> - at least at the time. :) But deployment models have
evolved (to a<br>
> point where I don't even know/understand how things
get deployed these<br>
> days and who has control of the command-line and/or
the env!).<br>
> Deprecation may be a reasonable thing but doesn't
help the current<br>
> situation.<br>
><br>
> David<br>
><br>
>> -Alan<br>
</div>
</span></font></div>
</blockquote>
</body>
</html>