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

[Cédric Champeau]

Hi Mario,

I'm not suggesting to change the JDK. My original email is about having a
new API to get a live view. Alternatives, like new methods to refresh the
view, are non-breaking (I think). I perfectly understand, and fully
respect, the willingness not to break millions of developers, and that's
not what I'm suggesting.

>
> Regarding your example:
>
> """
> println System.getenv('MY_VAR')
>
> doesn't print "foo" after doing:
>
> MY_VAR=foo gradle printVar
> """
>
> I agree that the environment variables may change during the program
> execution and that perhaps Java may eventually need to reflect that,
> but this example is not really appropriate, the Java process started
> with an environment variable not set, the one that starts with
> MY_VAR=foo is technically a different process...
>

Yes, that's one of our use cases. We mutate the environment variables so
that the process of the daemon sees the new environment variables, as well
as all Java code running there, because that's what users, and tools
executed from Gradle, expect. For forked process we can have our own API
which reads environment variables and passes them to the forked process
(which can itself be a long running process, when we re-use workers). The
issue is mostly with Java code running in the daemon itself (people calling
getenv, be it in a plugin, or in libraries).

So far the only suitable workaround I can think of is an agent that would
rewrite `System.getenv` to call our internal APIs. I'll suggest that in our
next meeting (which is happening 30 mins from now).