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

[Cédric Champeau]

2017-05-11 12:50 GMT+02:00 David Holmes <david.holmes at oracle.com>:

> Hi Cedric,
>
> On 11/05/2017 5:02 PM, Cédric Champeau wrote:
>
>> Thanks for the answers, folks, but I think they are kind of missing the
>> point. The fact is that environment variables *are* mutable. Java
>>
>
> Yes they are, provided you do it carefully and don't have to deal with the
> fact that its basically just a malloc'd char* array with no requirements
> for any kind of thread-safety. And given the JVM is multi-threaded almost
> as soon as it is launched we're not off to a great start in terms of safe
> and reliable access to a potentially concurrently mutable environment.


Yes, we are aware of that, and it has never been a problem so far. As I
said the gain overwhelms the risks.

>
>
>>
> Thanks for clarifying the scenario. So IIUC there is a set of env vars
> defined that provide the communication between the client and the daemon.
> The value of those vars in the client are passed to the daemon (via some
> normal IPC mechanism) and then JNI code on the daemon is used to update the
> daemon's process env so that if the Java getenv looked it would see the
> updated value.


Yes, and to be very clear, the problem is code running in the daemon
itself, which can be build scripts, plugins, or code in 3rd party jars used
by the scripts or plugins. When we fork a process we have no such issue.

>
>>
> That may be feasible. I like the idea of getenv(true) to request a refresh
> of the underlying data structure.
>
> Do you think it's something that could be added in JDK 9? It seems to be a
rather limited change, but I understand what "feature freeze" means :) One
could argue that the current behavior of `getenv` is a bug :)


> It isn't a matter of not taking the problem seriously. You've raised an
> issue for discussion and it is being discussed, but it is very late in the
> JDK 9 end game to try and add new APIs. This issue has been known for a
> long time and a Gradle issue was filed last September [1]. There was some
> discussion on jigsaw-dev [2] last October, and Alan even suggested back
> then to raise the "setenv" issue on core-libs-dev.
>
>
Yes and I apologize for that: I've been talking to several people offline
about this problem, but without a proper email to this list, it was just
side discussions I'm afraid. I had other priorities... Anyway, if it is
impossible to get a fix for JDK 9, I'm afraid the only solution for us is
an agent that would rewrite the `System` class...


> Cheers,
> David
>
> [1] https://issues.gradle.org/browse/GRADLE-3565
> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-Octob
> er/009551.html
>
>>
>>
>> 2017-05-11 4:50 GMT+02:00 Martin Buchholz <martinrb at google.com
>> <mailto:martinrb at google.com>>:
>>
>>     Since you're OK with doing brain surgery on the JDK and you control
>>     the entire process, consider controlling your daemon with a bytecode
>>     rewriting agent (e.g. byteman) that changes the definition of
>>     System.getenv etc.
>>
>>     (Whose side are you on Martin?! ...  I confess I also wish for a
>>     faster gradle ...)
>>
>>
>>