On 17/05/2017 8:45 PM, Remi Forax wrote:
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 ?
As long as we have JDK classes that support configuration via
environment variables then yes the JDK needs an API to enable that.
Maybe a version or two after Panama is available we could deprecate it.
David
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
