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

[Alan Bateman]

On 11/05/2017 08:02, Cédric Champeau wrote:

> Thanks for the answers, folks, but I think they are kind of missing the
> point. The fact is that environment variables *are* mutable. Java happens
> to return an immutable view of the environment variables when the VM was
> started, which is not the reality. We cannot trust what `System.geteenv`
> returns. The Javadocs say "current system environment" but it's just not
> true. The method should be called `getEnvWhenTheVMWasStarted`.
>
> We also have the problem that the environment of the client and the daemon
> differ over time, as I explained in the previous email. And it is pretty
> easy to understand that _when the build runs_, we need to get the
> environment variables of the _client_, not the daemon. Imagine something as
> simple as this:
>
> String toolPath = System.getenv('SOMETOOL_HOME')
>
> and imagine that this code runs in the daemon. When the daemon is started,
> there's absolutely no guarantee that this variable is going to exist.
> However, we know that when we're going to execute the build, this variable
> *has* to be defined. Obviously, it's going to be done from the CLI:
>
> $ export SOMETOOL_HOME = ...
> $ ./gradlew run ---> connects to the daemon, passes environment variables,
> mutates those of the daemon, which then executes the build
>
> Similarly, from a *single* CLI/terminal, it's very common to change the
> values of environment variables (because, hey, they are mutable!):
>
> $ export SOMETOOL_HOME = another path I want to try out
> $ ./gradlew run --> ... must update env vars again
>
One thing that isn't clear to me is what is reading the env variables in 
the build.

If native tools are reading the env variables then the daemon must be 
executing them in a child process, in which case there is no need for 
the env variables to be in the daemon's environment.

On the other hand, maybe you mean tools written in Java that are invoked 
in the same VM as the daemon (you mentioned warm up in your first mail). 
Do these tools have any other way to specify the configuration? Can you 
give specific examples? I'm just wondering if these in-process tools can 
pick up configuration via system properties or their main method.

BTW: The discussion reminds me a bit of jtreg test harness that we use 
for testing the JDK. It maintains a pool of agents VM and will reuse if 
possible. If tests need special options then it may have to startup a 
new agent VM to do the test that needs the special options.

-Alan