External _JAVA_OPTIONS environment variable sourcing for self-contained applications

[David Holmes]

Hi,

On 4/05/2024 10:49 am, 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)

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.

David
-----

> 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.
> 
> If someone has set up a few Java 8 application on their system via 
> normal jars and has configured a few options for them, I don't want them 
> to apply to my application image that runs on Java 21. As the developer, 
> I also don't want the user even having to bother with thinking about 
> this possibility. I also don't even know if the application starts up if 
> the variable contains unrecognized options.  Overall I'm not advocating 
> here to fully remove this behavior, but at least thinking about giving 
> application developers some option to disable external JVM argument 
> sourcing for jlink/jpackage. I hope that this proposal can be considered.
> 
> Best
> Christopher Schnick
>