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

[David Holmes]

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.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
>> 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