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

[David Holmes]

On 18/05/2017 5:46 PM, Kirk Pepperdine wrote:
>
>> On May 18, 2017, at 6:15 AM, David Holmes <david.holmes at oracle.com> 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.

Cheers,
David

> Kind regards,
> Kirk
>