Getting a live view of environment variables (Gradle and JDK 9)
Chris Hegarty
chris.hegarty at oracle.com
Thu May 18 08:25:42 UTC 2017
> On 18 May 2017, at 09:07, David Holmes <david.holmes at oracle.com> wrote:
>> ...
>> 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.
Agreed. To make sure that the spec aspect of this doesn’t fall through
the cracks, I filed 8180592 [1] to track it.
To help move the discussion forward, I think it would be useful to at least
have an idea with a rough prototype of an API to refresh might look like.
To that end, I put together the following webrev:
http://cr.openjdk.java.net/~chegar/refreshEnv/
-Chris.
[1] https://bugs.openjdk.java.net/browse/JDK-8180592
More information about the core-libs-dev
mailing list