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

[Kirk Pepperdine]

Hi Cedric,

I understand what you are trying to do, it is my opinion that you are trying to do this in a completely unexpected way. That the environment variables in the JVM are read only once is an issue in that a nohup should refresh them That all the code in the JVM may (or may not) react to this change is another question. In your case I believe you have painted yourself into a corner by assuming the JVM would be able to read and write shell environment variables. To back off of this assumption 
In this case you will need the client to inform the server of it’s environment and then one possibility is to fork the server with the new variables.

Shells are isolated for a reason. IMHO, changing the JVM to write environment variables based on settings in another shell is a potential security issue.

Kind regards,
Kirk

> On May 17, 2017, at 4:21 PM, Cédric Champeau <cedric.champeau at gmail.com> wrote:
> 
>> 
>> 
>>> 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
> happen:
> 
> 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