<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<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>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> hotspot-dev <hotspot-dev-retn@openjdk.org> on behalf of Christopher Schnick <crschnick@xpipe.io><br>
<b>Sent:</b> May 10, 2024 3:42 AM<br>
<b>To:</b> David Holmes <david.holmes@oracle.com><br>
<b>Cc:</b> hotspot-dev@openjdk.org <hotspot-dev@openjdk.org><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 crschnick@xpipe.io. Learn why this is important at
<a href="https://aka.ms/LearnAboutSenderIdentification">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>
</body>
</html>