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

[Cédric Champeau]

Yes that's one option. Note that declaring environment variables is not a
small change. It has consequences on the project layout. Typically, if they
need to be in the settings.gradle file, then now the client would have to
compile, parse and potentially partially execute code. Similarly if it's in
the `build.gradle` file or any of its dependents (which is clearly a no go
here). Lighter weight options are to use `gradle.properties` or a new file.
Because, in the end, we want the client to be spawned and disposed as fast
as possible.

2017-10-12 17:59 GMT+02:00 Remi Forax <forax at univ-mlv.fr>:

> 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
>