RFR [XXS]: 8242000: clean up list of environment variables printed in hs_err file

[David Holmes]

Hi Matthias,

On 2/04/2020 8:59 pm, Baesken, Matthias wrote:
> Hi David ,
> 
> new  webrev  :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8242000.1/
> 
> 
> I looked at the other env variables listed.
> The ones from the "All platforms",  "AIX"  and "Windows"  sections have to stay .

Agreed.

It would be clearer to me (not that I'm asking you to do this) if we 
actually split these up into three semantic sections:

1. Env vars defined by the JDK that can be used to affect the behaviour 
of the JDK - e.g. the JAVA_* and CLASSPATH vars

2. Env vars defined for the system that will affect how the system 
operates in relation to the JDK e.g. LIBPATH, LD_LIBRARY_PATH, 
LD_PRELOAD, LANG etc.

3. Informational env vars that might be useful to see: USERNAME, HOSTTYPE

> I am not sure about Mac, maybe some Mac expert could comment.

I've no idea either, so fine with them staying.

> In the Linux/Solaris/BSD   section ,
>    "HOSTTYPE", "OSTYPE", "ARCH", "MACHTYPE",
> have only limited use from what I see  ,  but you find them usually  in the shell and they describe the system  a bit more.
> So I would keep  them  .

These are harmless to print and informational but I think we already 
report that information via uname. Possibly of interest if the env vars 
don't match what uname shows.

> Regarding JRE_HOME I opened
> 
> https://bugs.openjdk.java.net/browse/JDK-8242034
> 
> Remove JRE_HOME references

Thanks for doing that.

This change seems fine to me as-is.

David

> Best regards, Matthias
> 
> 
> 
> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Donnerstag, 2. April 2020 12:19
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR [XXS]: 8242000: clean up list of environment variables printed in hs_err file
> 
> On 2/04/2020 8:11 pm, Baesken, Matthias wrote:
>> Hi David ,
>>
>> I think  "JAVA_COMPILER" is no longer needed,
>>    (see a remark here that it was used to configure the JIT compiler  https://www.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ibm.sqlr.doc/ids_sqr_280.htm
>>    but I cannot  find this any more in the current jdk/jdk codebase).
> 
> JAVA_COMPILER usage is ancient, back in 1.1 and 1.2 days IIRC :)
> 
>> Regarding JRE_HOME - I find  still some references in the source code, but not many .
>> Could it be that some installers / tools outside the JDK still set/use it ?
>>
>> jdk/src/hotspot/share/jfr/dcmd/jfrDcmds.cpp
>> 345 _settings("settings", "Settings file(s), e.g. profile or default. See JRE_HOME/lib/jfr", "STRING SET", false),
>>
>> jdk/src/hotspot/share/utilities/vmError.cpp
>> 83 "JAVA_HOME", "JRE_HOME", "JAVA_TOOL_OPTIONS", "_JAVA_OPTIONS", "CLASSPATH",
>>
>> /openjdk-jdk/src/java.base/share/man/java.1
>> 1813 \f[CB]JRE_HOME/lib/jfr\f[R].
> 
> These uses are just commentary, I would suggest removing JRE_HOME and
> file a RFE for JFR to cleanup its references to JRE_HOME in jfrDcmds.cpp
> and the java command manpage.
> 
> But again these are just two more that I looked at in more depth. There
> may be others that need removing too.
> 
> Cheers,
> David
> -----
> 
>