On 02.10.2016 09:53, Alan Bateman wrote:
On 02/10/2016 01:25, Malachi de Ælfweald wrote:
:
This appears to come from a setAccessible from inside getEnv
https://github.com/adammurdoch/native-platform/blob/master/src/main/java/net/rubygrapefruit/platform/internal/WrapperProcess.java#L113
Indeed, as we've said in other mails, this change is going to expose a
lot hacks. In this specific case then System.getenv() is specified to
return an unmodifiable map but a library that Gradle uses seems to want
to hack into the underlying map so that it can modify it. Stack trace
below.
Jochen may be able to find out more about this, maybe there is a
description somewhere on what the real issue is. It might be something
that can be tackled in other ways.
The real issue is probably Gradle trying to "fork" the process to a
running daemon. That includes environment variables for example. Java is
not very "fork"-friendly. Not in the classic posix sense, and not by
passing the execution to an already running daemon either.
Then you find things like this:
http://stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java
And remember, there is no ProcessBuilder, if you delegate execution to a
daemon. Only without the daemon startup times may matter much more. And
even if in JDK9 the JVM starts faster now, that does not mean you get a
ready setup to work in from that point on... not if you have to load
another 10k classes and data structures for example. Gradle is
struggling with this for years already and I am talking about comparing
execution speeds of gradle with something like make or scons, not with
ant, maven or sbt.
So now I would be curious as of what you suggest on how to fix the
issue. I mean even if you start using native code to set the
environment, will the java process notice those changes? There is no
guarantee for that and it may break again even if it works now, right?
bye Jochen
