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

Remi Forax forax at
Thu Oct 12 15:59:06 UTC 2017

Hi Cedric,
I think you should play like the JDK 9 i.e. help users to transition from th old world to the new world where env variables need to be declared explicitly. 
So warn user that the env variables should now be declared explicitly, use an agent to simulate the old getenv+grapefruit, create a Gradle.getenv that verifies that the env variable are explicitly declared and fork if the env variable are not declared.

In two steps:
step 1. write an agent that redefine System.getenv() to run a code before the official code of getenv,
        the code return the patched environment instead, so you can simulate what grapefruit was doing.
        Also emit a warning saying Grade.getenv should be used instead.
        Gradle.getenv is like getenv, but it check that the env variable is explicitly declared (not unlike the module directive uses with the ServiceLoader)
        Detect at runtime if the agent is present, if it's not fork.

step 2. retire the agent and profit


----- Mail original -----
> De: "Kirk Pepperdine" <kirk.pepperdine at>
> À: "Mario Torre" <neugens.limasoftware at>
> Cc: "core-libs-dev" <core-libs-dev at>
> Envoyé: Jeudi 12 Octobre 2017 16:23:22
> Objet: Re: Getting a live view of environment variables (Gradle and JDK 9)

> Hi,
>> On Oct 12, 2017, at 2:54 PM, Mario Torre <neugens.limasoftware at> wrote:
>> 2017-10-12 11:58 GMT+02:00 Cédric Champeau <cedric.champeau at>:
>>> 1. an API in 18.3 which would let us refresh the environment variables,
>>> even if inherently unsafe (we can take the risk, if the Javadocs explains
>>> that if you're really unlucky calling such a method could kill your VM).
>> Being a public API we would expose everyone to this risk, and the API
>> should be supported on all platforms maybe forever. I know other
>> people have different opinion here, but this seems to be high risk,
>> high impact to be worth.
> As I have stated in post postings, this is behavior is unexpected and IMHO
> shouldn’t be supported.
>>> 2. we change the way Gradle works and force explicit declaration of all
>>> environment variables a user script can use. Then, we would only spawn a
>>> new VM if the current daemon environment variables do not match those
>>> required found by the client.
> This describes a more appropriate behavior.
> Kind regards,
> Kirk Pepperdine

More information about the core-libs-dev mailing list