Environment variables truth source of the JVM (and how to mutate it)

Dalibor Topic dalibor.topic at oracle.com
Wed May 10 14:39:23 UTC 2017

Yeah, you should not mutate the environment variables of any multi threaded application once it's running. I don't recall if the result was undefined or unspecified behavior, but it was unreliable behavior in any case.

Dalibor Topić 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214<tel:+494089091214> | Mobile: +491737185961

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

> On 10. May 2017, at 15:32, Remi Forax <forax at univ-mlv.fr> wrote:
> Hi Pierre,
> it's more a question for the core-dev mailing list.
> The trick shown by Heinz does not work anymore with jdk 9.
> You can not mutate the environment variables of jdk,
> But you can send a new environment each time you create a new process,
> Using ProcessBuilder.environment().
> cheers,
> Rémi
> ----- Mail original -----
>> De: pierre at 2bst.fr
>> À: discuss at openjdk.java.net
>> Envoyé: Mercredi 10 Mai 2017 13:55:23
>> Objet: Environment variables truth source of the JVM (and how to mutate it)
>> Hi, I've been trying to understand how the JVM accesses environment
>> variables and how they can be mutated.
>> I sent an email on this list few minutes ago but it appears to be
>> ill-formatted and hardly legible. Sorry for double post: I resend it
>> with better formatting hopefully.
>> For this I've made some assumptions and I would like to know if they're
>> correct, could you help me on this?
>> 1) It appears that the JVM gets a copy of its process environment
>> variables and store them in static final fields
>> theUnmodifiableEnvironment and theEnvironment of class
>> java.lang.ProcessEnvironment.
>> - My assumption is: these fields are the "truth source" about
>>   environment variables inside the JVM and any attempt to access some of
>>   them will end up in a lookup of this fields.
>> - I have a question about this: why two final fields instead of only
>>   one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst
>>   theEnvironment is for env of current process (which could be changed
>>   with Process.exec(String[] cmdarray, String[] envp, File dir))?
>> 2) There is a subtle way to mutate them in Sun JDK (see
>> http://www.javaspecialists.eu/archive/Issue161.html).
>> - My assumption is: These fields are passed to all new JVM threads, so
>>   mutating them (as ugly as it can sound) will be JVM-wide and will
>>   result in all thread getting mutated env as their environment
>>   variables.
>> - Sensitive question: is this enforced? System.getenv() appears to
>>   correctly returns mutated env, can I deduce all new threads in the JVM
>>   will get mutated values?
>> - Another sensitive question: as these fields are static final, can I
>>   deduce all threads in the JVM will get mutated values, not only new
>>   ones?
>> It would be my pleasure to provide further details ifneedsbe. Just let
>> me know if some of the above assumptions are incorrect! Again, please
>> forgive that double post.
>> Yours faithfully,
>> p2b

More information about the discuss mailing list