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

pierre@2bst.fr pierre at 2bst.fr
Wed May 10 13:30:03 UTC 2017


Hi, I've been trying to understand how the JVM accesses environment
variables and how they can be mutated.

I sent an email about this list few hours ago on the general-purpose
discuss mailing-list but it appears it would be better posted herein.

For this I've made some assumptions and I would like to know if
they'recorrect, 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!

Yours faithfully,

p2b


More information about the core-libs-dev mailing list