On 18/05/2017 5:46 PM, Kirk Pepperdine wrote:
On May 18, 2017, at 6:15 AM, David Holmes <david.hol...@oracle.com> wrote:
On 18/05/2017 2:36 AM, Martin Buchholz wrote:
Stop trying to add APIs to mutate environment variables. It's not going
to happen!
Not sure who or what you are directing this at Martin. Certainly I'm not
suggesting any API to mutate environment variables. This is about an API to
re-read an already potentially mutated external environment.
There is no known way to mutate environment variables in a
multithreaded Unix process without risk of native crashes (and I have
worn the hat of poor support engineer trying to diagnose SEGV in
getenv). IIRC we made the decision 13 years ago to cache the
environment on first access, and that was before the thread-unsafety of
putenv was fully appreciated.
Yes, Java still has a serious startup performance problem; that should
be attacked more directly.
?? Not sure what startup has to do with the topic here.
The reason to use a daemon is to avoid multiple starts of a JVM in-between
steps in a build.
Yes, though I've been looking at this from the actual API proposal
perspective, not the "how can we avoid the need for this API" perspective.
It is a great idea but the proposed implementation is at issue because it
requires a highly questionable API be added to the JDK.
I'm quite surprised by some of the reactions here. Given the read-once
nature of System.getenv was never documented I expected most people to
be surprised that it took a snapshot-on-first-use, and that reading the
actual process environment at the time System.getenv was called would be
the natural expectation as to how this API works.
Cheers,
David
Kind regards,
Kirk
