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

[Dalibor Topic]

Thanks for the explanation, David. That doesn't sound much more risky than what we already do today in getenv. 

Cheers,
Dalibor

--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214<tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

> On 15. May 2017, at 07:14, David Holmes <david.holmes at oracle.com> wrote:
> 
> Re-sending to core-libs-dev
> 
>> On 13/05/2017 5:56 PM, David Holmes wrote:
>> Hi Dalibor,
>> 
>>> On 12/05/2017 11:28 PM, dalibor topic wrote:
>>>> On 11.05.2017 18:29, Cédric Champeau wrote:
>>>> 
>>>> 
>>>>    Unfortunately, they are not safely mutable in multi-threaded
>>>>    programs on many operating system/libc combinations.
>>>> 
>>>> But the problem is less about mutating, that it is about reading: the VM
>>>> returns wrong values at some point, because it _assumes_ that the
>>>> environment variables are not mutated.
>>> 
>>> Right. Assuming that another thread could be simultaneously writing to
>>> the same data structure holding environment variables (char **), reading
>>> itself becomes problematic at such points in time, as you might read a
>>> temporarily corrupted data structure.
>>> 
>>> I guess the question underneath is if there is a safe point in time when
>>> reading the data could be preformed and no concurrent write from JNI
>>> code corrupting the data when it's partially read is possible.
>> 
>> I'm afraid no such safe point guarantee exists at all - even for the
>> initial reading of the process environment on the first call to System
>> getenv(). There could always potentially be some JNI, or other native
>> in-process code, mutating the environ char** at the same time as we
>> first read it in the JVM.
>> 
>> But we're not trying to protect against random concurrent updates in the
>> current scenario, things are more structured:
>> - request comes in with data that says to update certain env vars
>> - JNI code updates the env vars
>> - the daemon's java code (currently) causes the System.getenv map to be
>> updated
>> - the "client" code is executed and reads the env var and sees the right
>> value
>> 
>> There would have to be a caveat on System.getenv(true) if we went that
>> path, that it is up to the user to ensure it is called in as safe a
>> manner as possible having regard to any concurrent updates in their
>> application code and how the environment is managed on a given platform.
>> 
>> Cheers,
>> David
>> -----
>> 
>>> cheers,
>>> dalibor topic