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

[David Holmes]

On 17/05/2017 6:21 AM, Martin Buchholz wrote:
> On Tue, May 16, 2017 at 12:29 PM, Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
>
>>
>> Re-reading/refreshing the env variables has come up before, in other
>> contexts. As David pointed out [1], re-reading introduces no more risk than
>> is already there ( if specified correctly ).
>>
>
> Adding a Java API for re-reading would be really weird because there would
> be no Java API for writing

I don't see that as weird. We don't want an API for writing because 
writing from Java is a bad idea. The API for re-reading is a concession 
that in reality the process environment can change outside of the JVMs 
control. I view it as part of the process meta-data, for which we only 
provide read APIs in Java.

> and there's no way on a Unix system to write at
> all without introducing a risk of SEGV.

But the reality is that it is a technique that people use and have used 
for years without harm. Are they doing the "wrong thing"? - probably. 
But I have some sympathy to Gradle's predicament given:

a) Java never documented that getenv took an immutable snapshot
b) The env that is read depends on when the first call to getenv occurs 
(there is an 8u bug where an app suddenly started failing because JDK 
code started using getenv internally and so took the snapshot much earlier!)
c) this has only stopped working because of Jigsaw's strong 
encapsulation enforcement

As I said previously any such API must come with a very strong caveat 
that it is a "use at own risk" API. I know that doesn't sound very 
Java-ish, but getenv by its nature is not very Java-ish IMHO.

David
-----

>
>> -Chris.
>>
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-
>> May/047668.html