[EXTERNAL] Re: External _JAVA_OPTIONS environment variable sourcing for self-contained applications

[David Holmes]

On 30/05/2024 3:51 pm, Christopher Schnick wrote:
> Alright I see your points. I can definitely crosspost this thread to the 
> core libs mailing list.
> 
> The only case in which I see this still being mainly a hotspot issue is 
> if there is more global configuration creeping into runtime images apart 
> from environment variables. Is there any other global configuration data 
> always sourced that I'm not aware of like registry values, Java Control 
> Panel settings (is that even still around?), other global configuration 
> files, etc.?

At the hotspot-level options come from 4 sources:
- the "command-line" as encoded in the args structure passed to 
JNI_CreateJavaVM
- options embedded in the image from jlink
- options from the JAVA_TOOL_OPTIONS env var
- options from the _JAVA_OPTIONS env var

The "command-line" is controlled by the launcher, so potentially a 
launcher could include additional options that it acquires from 
arbitrary places (like registries or the file system). But I am not 
aware of the standard launcher doing that.

Any source of options could provide the -XX:Flags=flags-file option to 
read further options from a file (which gets processed first).

David
-----

> On 30/05/2024 06:30, David Holmes wrote:
>> On 29/05/2024 8:05 pm, Andrew Haley wrote:
>>> On 5/29/24 09:23, Christopher Schnick wrote:
>>>  > 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.
>>>
>>> I don't think there were many that would pass a compatibility and
>>> specification review. "Give developers the option to unset these
>>> variables in the automatically generated launcher script for jlink"
>>> might well be OK, though. It'd be worth a try.
>>
>> I also think this is something that we should see about fixing in 
>> jlink, such that the problematic env-vars are omitted. I'm less 
>> inclined to support the suggestion that a new flag be added to hotspot 
>> that tells it to ignore the env vars, as you will need to add it in 
>> jlink anyway.
>>
>> But again I am not familiar with jlink and the jlink developers do not 
>> generally hang out on hotspot-dev. So I would suggest filing a JBS 
>> issue against jlink or starting a discussion on ... core-libs-dev?
>>
>> David
>>