Getting a live view of environment variables (Gradle and JDK 9)

David Holmes david.holmes at
Thu May 18 08:07:00 UTC 2017

On 18/05/2017 5:46 PM, Kirk Pepperdine wrote:
>> On May 18, 2017, at 6:15 AM, David Holmes <david.holmes at> wrote:
>> On 18/05/2017 2:36 AM, Martin Buchholz wrote:
>>> Stop trying to add APIs to mutate environment variables.  It's not going
>>> to happen!
>> Not sure who or what you are directing this at Martin. Certainly I'm not suggesting any API to mutate environment variables. This is about an API to re-read an already potentially mutated external environment.
>>> There is no known way to mutate environment variables in a
>>> multithreaded Unix process without risk of native crashes (and I have
>>> worn the hat of poor support engineer trying to diagnose SEGV in
>>> getenv).  IIRC we made the decision 13 years ago to cache the
>>> environment on first access, and that was before the thread-unsafety of
>>> putenv was fully appreciated.
>>> Yes, Java still has a serious startup performance problem; that should
>>> be attacked more directly.
>> ?? Not sure what startup has to do with the topic here.
> The reason to use a daemon is to avoid multiple starts of a JVM in-between steps in a build.

Yes, though I've been looking at this from the actual API proposal 
perspective, not the "how can we avoid the need for this API" perspective.

> It is a great idea but the proposed implementation is at issue because it requires a highly questionable API be added to the JDK.

I'm quite surprised by some of the reactions here. Given the read-once 
nature of System.getenv was never documented I expected most people to 
be surprised that it took a snapshot-on-first-use, and that reading the 
actual process environment at the time System.getenv was called would be 
the natural expectation as to how this API works.


> Kind regards,
> Kirk

More information about the core-libs-dev mailing list