JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500)

[Alan Bateman]

On 02/10/2016 10:20, Jochen Theodorou wrote:

>
> 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?
java.lang.System doesn't define a method that is the equivalent of 
setenv(3). That seems to what the stackoverflow post is about. All I can 
suggest is bring up the topic on core-libs-dev. I don't wish to get into 
the discussion here on whether it's a good idea or not to add such a 
method. Also with Project Panama looking good then one has to wonder if 
it make sense to add methods like this.

On the Process API then just to say that it has been updated 
significantly for Java SE 9 to support managing of child processes (and 
trees of processes). Details in JEP 102. This might not be exactly what 
you are looking for here but I just mention that the API has been 
updated to address many long standing shortcomings.

Do you know anything about the ClassLoader::getPackages issue? Is this a 
case where the (new) public getDefinedPackages returns the Packages that 
Gradle is looking for?

-Alan