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

[Jochen Theodorou]

On 02.10.2016 12:12, Alan Bateman wrote:
> On 02/10/2016 10:20, Jochen Theodorou wrote:
> [...] 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.

Project Panama is going to be in JDK9? That is new to me. But even if, 
it makes no major difference, since everything you could have done 
there, you could have done with JNI/JNA and you will still need platform 
specific code for that... unless you use a more independent library, 
which then has to be added in different versions for multiple platforms 
again.

But yes, I too suggest the gradle people bring that to core-lib-dev

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

for setting environment variables JEP 102 does not look useful. You can 
applaud the effort for fixing many long standing issues, but if you need 
a certain feature and it becomes "disabled" without having a replacement 
at hand... well you are not in the mood to applaud then. I am sure the 
Gradle people will solve all those problems with one hack or another. It 
just means 3.0 and 3.1 will no longer be jdk9 ready people will have to 
wait for 3.2 or even 3.3

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

hmm... if I look at 
https://github.com/gradle/gradle/blob/master/subprojects/base-services/src/main/java/org/gradle/internal/classloader/MultiParentClassLoader.java 
and I imagine one parent being a MultiParentClassLoader... 
getDefinedPackages is final, so you cannot do what they did for 
getPackages, unless you do it from outside. And for that you need to 
know about multiple parents... I don´t know if it is working well enough 
for Gradle, but no, getDefinedPackages is no suitable replacement for 
getPackages at all if you have to consider multiparent class loaders.

bye Jochen