External _JAVA_OPTIONS environment variable sourcing for self-contained applications

[Christopher Schnick]

Hey Alan,

in our specific case we are distributing desktop applications to end 
users where we take great care to make them user friendly and easy to 
use. In most instances, the users probably don't even know that our 
application runs on Java. A big part in accomplishing this was the 
introduction of jlink/jpackage. We can just say: Download this 
application, you don't need anything else. If they ask about installing 
Java, we can just say it does not matter what kind of Java you have 
installed and configured on your system because our application is self 
contained. But now it seems like we have to augment this statement by 
saying that it doesn't matter what you have installed unless you have 
set _JAVA_OPTIONS or JAVA_TOOL_OPTIONS, then it might be possible that 
the application will not behave as expected or does not start up at all 
without any error message. And we can't do anything about it, you have 
to ask your IT admin.

As a practical use case, if an office deploys a few legacy Java 8 
applications on their systems that are configured via any environment 
variables to behave uniformly, there is a good chance of an option being 
included in there that is not supported by Java 21. If this is the case, 
then ALL modern self contained graphical Java applications don't even 
start up and don't show an error message. (I just tried, I remember that 
jpackage showed a generic error window some time ago but it does not do 
that for me anymore). If the option is at least recognized but 
completely wrong for the requirements of the application, it will 
quickly error out which isn't much better. This is horrible behavior in 
this use case.

Not every Java application is scalable or configurable one, there are 
cases in which any user configuration does not make sense and is most 
likely unintentional this way. Any possible configuration can be exposed 
by the application itself. All I'm asking for is to consider giving 
developers an option in jlink that is explicitly opt-in to disable this 
environment variable sourcing. That way the original behavior would not 
be changed unless explicitly requested by the developer.

Best
Christopher Schnick

On 04/05/2024 12:41, Alan Bateman wrote:
> On 04/05/2024 01:49, Christopher Schnick wrote:
>> Hello there,
>>
>> I wasn't entirely sure whether this is the correct mailing list for 
>> this, but it was the best match for me skimming through all the 
>> available mailing lists. Feel free to point me to a better suited one 
>> if I'm wrong here.
>>
>> We develop and distribute Java desktop applications to users by 
>> creating standalone application images with jpackage. Everything is 
>> working fine, however there was a recent issue where some users 
>> couldn't get the application to work correctly. After some 
>> investigation, it turned out that the affected users had set the 
>> environment variable _JAVA_OPTIONS with a few JVM arguments, 
>> particularly Xmx parameters that were way too low for our 
>> application. I was quite surprised that these apply to self contained 
>> jpackage applications, because for me this is not in the spirit of an 
>> isolated and self contained application. I was even more surprised 
>> that it overwrote existing arguments as we had our own values for Xmx 
>> set in the application image, but these were ignored in favour of 
>> _JAVA_OPTIONS. And I'm under the impression that this behavior cannot 
>> be disabled. (Please correct me if I'm wrong)
>>
>> While I see that there is definitely some use case for having this 
>> option available to allow users to customize their environment 
>> uniformly, I would say that this causes usually more harm than good 
>> in this case. The cases of unintentional interference are probably 
>> much higher than intentional configuration, which requires specific 
>> application knowledge to work in the first place.
>
> _JAVA_OPTIONS is a legacy environment variable from early JDK 
> releases. Yes, it does append (rather than prepend) so it overrides 
> options. It's not a documented env variable but it it has existed for 
> a long time and people seem to have found it. So great care would be 
> required before changing anything.
>
> The supported/documented environment variables are JAVA_TOOL_OPTIONS 
> and JDK_JAVA_OPTIONS. They prepend so they don't override the options 
> specified on the command line. There are important use-cases. 
> JAVA_TOOL_OPTIONS is documented in the JVMTI spec as a way to insert 
> options to start tool agents (-agentlib or -agentpath). 
> JDK_JAVA_OPTIONS is JDK-specific and has its own section in the java 
> man page. It supports both java launcher options and VM options.  It 
> was an important piece to help the migration from JDK 8 to newer 
> releases for deployments that try to use the same command lines across 
> a broad range of JDK releases.
>
> My guess from reading your mail is that the desktop application 
> doesn't have a console so the "Picked up _JAVA_OPTIONS=<value>" 
> message that is printed is not seen. In server applications the 
> message will typically end up at the top of the application's log file 
> so you can see what has been picked up.
>
> -Alan
>
>