Stop doing sneaky things :)

[forax]

Gradle that uses your code doesn't work with latest build of jdk9 jigsaw (build 136 on 09-15-2016 ) https://jdk9.java.net/jigsaw/ because trying to to remove the unmodifiableMap wrapper of the return value of System.getEnv() [1] is not allowed with jigsaw.

Basically, you can not use setAccessible on any platform modules (java., jdk.) code anymore.

regards, Rémi

https://github.com/adammurdoch/native-platform/blob/master/src/main/java/net/rubygrapefruit/platform/internal/WrapperProcess.java#L109

[melix]

Hi @forax ,

Do you know of any workaround in JDK 9? Basically the JDK makes immutable something which is inherently mutable (the environment variables), and Gradle needs to set environment variables in the daemon process, corresponding to the client environment. The JDK APIs for process management are pretty weak in this regard.

[sbrannen]

A knowledgeable individual told me the following:

A different way to implement the functionality could be to use ProcessBuilder APIs such as ProcessBuilder#environment -- in order to adjust the environment variables of daemon processes started by Gradle as necessary.

[melix]

As far as I understand ProcessBuilder doesn't solve the problem: it doesn't allow mutating the environment of an existing process, which is what the daemon needs to do.

[sbrannen]

I'm not familiar with the exact desired semantics in this use case, but the Javadoc for ProcessBuilder#environment states the following.

The returned object may be modified using ordinary Map operations. These modifications will be visible to subprocesses started via the start() method. Two ProcessBuilder instances always contain independent process environments, so changes to the returned map will never be reflected in any other ProcessBuilder instance or the values returned by System.getenv.

So that makes it sound like the environment of a process spawned by the daemon can in fact be modified.

At least that's how I interpret the documentation, but I honestly have not tried it out myself.

[melix]

Yeah it is unclear if the modifications are immediately visible to processes (already started), or only to processes started after the modification. But it's an interesting thing to check, it would effectively solve the problem for Java 9.

[sbrannen]

Yeah it is unclear if the modifications are immediately visible to processes (already started), or only to processes started after the modification. But it's an interesting thing to check, it would effectively solve the problem for Java 9.

My sentiments exactly.

[melix]

Dalibor Topic just told me it modifies the subsequent processes, not the current one, so it's not a suitable option...

[sbrannen]

Dalibor Topic just told me it modifies the subsequent processes, not the current one, so it's not a suitable option...

Too bad. 😞

[melix]

Follow up discussion is on core-libs-dev