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

Cédric Champeau cedric.champeau at
Wed May 17 07:21:33 UTC 2017

>> I disagree, this would be totally expected behavior. The daemon and this
>> process would run in different shells and I am unaware of any daemon
>> process that auto-magically reconfigures it’s self to adapt to any other
>> arbitrary shell’s changed environment variables.
The thing is that the daemon is an "implementation detail". The user
doesn't even need to know there's one. It's here for performance reasons.
If we could get the same level of performance, and startup time, right from
the process start, there wouldn't be any need for a daemon. But the truth
is different: with classloading, in-memory dependency management caches,
and the JIT, the daemon is required. So imagine the surprise if a user just
does a "cd subproject" and start Gradle, and we spawn a new daemon, just
because the "PWD" environment variable has changed. It doesn't make sense.
Also it can lead to surprising behaviors: if you run 2 builds concurrently
(this happens, yes, we have thousands of users so all scenarios exist in
the wild), then depending on whether the daemon was busy when you start the
build, you would get different environment variables: the busy one would
get the environment variables when it was started, and the fresh one to run
the 2d build would get the refreshed ones, because started at a different
point in time.

Another scenario: one might think (we do) that it's better to use project
properties than environment variables to communicate runtime specific
configuration. But the reality is always more complex. For example, our
build scripts may require calling a Perl library at some point (imagine,
for example, calling FlameGraph). If that library is configured through
environment variables (say, it requires FLAMEGRAPH_HOME to be set), then
it's better to check beforehand if the environment variable is set, rather
than executing the build and failing when we try to call it. So, the build
script needs to check that this environment variable is set. If we don't
propagage the client environment variables to the daemon, then 2 things

1. the check to verify that the environment variable is set would fail,
even if it has been set in the CLI
2. we wouldn't be able to set the environment variables of the forked
process running Perl to the appropriate set of variables

More information about the core-libs-dev mailing list