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

[Remi Forax]

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

cheers,
Rémi

----- Mail original -----
> De: "Kirk Pepperdine" <kirk.pepperdine at gmail.com>
> À: "Mario Torre" <neugens.limasoftware at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> 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 gmail.com> wrote:
>> 
>> 2017-10-12 11:58 GMT+02:00 Cédric Champeau <cedric.champeau at gmail.com>:
>> 
>>> 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