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

[Cédric Champeau]

Hi folks,

Let me resurrect this thread now that Java 9 is out (congrats to the
team!). We still have the problem, and actually some users complained about
the poor performance of Gradle under JDK 9, and it turned out to be exactly
the problem I mentioned in this thread. Now with JDK 9, everytime an
environment variable is mutated we have no choice but spawning a new
daemon, which kills performance (as well as leaves idle ones in memory
until we decide we can discard them).

We have 2 options that seem reasonable:

1. an API in 18.3 which would let us refresh the environment variables,
even if inherently unsafe (we can take the risk, if the Javadocs explains
that if you're really unlucky calling such a method could kill your VM).
2. we change the way Gradle works and force explicit declaration of all
environment variables a user script can use. Then, we would only spawn a
new VM if the current daemon environment variables do not match those
required found by the client.

But before implementing this (2) we'd like to know if others have the
problem (I feel like we're not the only ones), and if the JDK team here is
willing to provide an API for us.

Thanks a lot!

2017-05-18 10:25 GMT+02:00 Chris Hegarty <chris.hegarty at oracle.com>:

>
> > 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