External _JAVA_OPTIONS environment variable sourcing for self-contained applications

[David Holmes]

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