Getting a live view of environment variables (Gradle and JDK 9)
forax at univ-mlv.fr
Wed May 17 10:45:36 UTC 2017
What i really like in Java is the diversity of options.
We are discussing here to add or not a way to get the live environment in a Java process,
at the same time on hotspot-compiler-dev Yasumasa posts a message with a set of examples that shows how to do any C syscalls from Java using JVMCI (and Panama is not far away)
and since a long time, people can use JNR to access to a POSIX API from Java .
So knowing that, do we really need to have getenv/putenv/setenv in the JDK API ?
----- Mail original -----
> De: "Cédric Champeau" <cedric.champeau at gmail.com>
> À: "dalibor topic" <dalibor.topic at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 17 Mai 2017 09:21:33
> Objet: Re: Getting a live view of environment variables (Gradle and JDK 9)
>>> 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