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 [2].
So knowing that, do we really need to have getenv/putenv/setenv in the JDK API ? Rémi [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026232.html [2] https://github.com/jnr/jnr-posix/blob/master/src/main/java/jnr/posix/POSIX.java ----- Mail original ----- > De: "Cédric Champeau" <cedric.champ...@gmail.com> > À: "dalibor topic" <dalibor.to...@oracle.com> > Cc: "core-libs-dev" <core-libs-dev@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 > 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
