On 17/05/2017 6:21 AM, Martin Buchholz wrote:
On Tue, May 16, 2017 at 12:29 PM, Chris Hegarty <chris.hega...@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
