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
