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

[Alan Bateman]

On 02/10/2016 09:04, Cédric Champeau wrote:

> As a member of both the Gradle and Groovy teams, I must say I am very 
> worried by this late change in strong encapsulation at runtime. As 
> Jochen explained, it severely broke Gradle and Groovy, but more 
> importantly, it breaks a lot of libraries. And it breaks for things 
> that do _not_ care about modules. They are all running "old fashioned" 
> with good old classpath. I could understand something like that 
> happening as soon as we have one module on classpath, but this is not 
> the case (the only modules are those from the JDK itself).
When you are using the class path then you are on a modular platform so 
there are always modules in the picture. The platform modules do not 
export their internals and so will be problematic for code on the class 
path that relies on being able to access JDK internals. Yes, it is very 
disruptive change but one that just extends the proposal from 2015 - the 
proposal in 2015 attempted to strike a balance but leaves the hole that 
is #AwkwardStrongEncapsulation. To mitigate the impact then there are 
command line options, equivalent attributes for executable JARs, and a 
partial solution for JNLP apps too. It's also possible to use JDK 9 
command line options with JDK 7 and JDK 8 if you are willing to run with 
the option to ignore unrecognized options.

It might be late in JDK 9 to fix this hole but there is still time for 
the important tools and libraries in the eco system to identify and 
address issues. As we've been saying for years, JDK 9 is the first 
release that requires most of the main stream tools and libraries to 
work with us in order to make this release usable. In prior releases 
when updates to the Java Language would have required to IDEs and some 
tools but wouldn't have wide impact on tools. This is the reason for 
early access releases and the ongoing outreach to create awkward of 
issues and impact.

On Groovy then Jochen has brought up issues here several times. I get 
the impression that there is a lot more to this, often it seems like 
issues that should be discussed on mlvm-dev. We have not seen anything 
like these issues with Nashorn (Javascript), it is of course based on 
method handles and a different design.

-Alan