> > > > One thing we are looking at doing as a workaround is to launch gradle with > a pre-Jigsaw enabled JDK (e.g., JDK 8u112 or JDK 9 build 109) and fork/exec > javac, java, javadoc, etc., with the latest jigsaw EA.
Yes, that's the strategy I used for my talk about Jigsaw support in Gradle [1]. > Our build is already set up for this (mostly...we found that a few bugs > have crept in where we use the java on the path and/or specified by > JAVA_HOME instead ot the separate "build JDK", but we're working through > those). I suspect this will work for most things, but likely not for > running unit tests. That's correct. The biggest issue with `--add-exports` and friends is that it "leaks" to the context of compile/test execution. So if an option is required to run Gradle, or a worker it uses, then it would leak into the runtime of the JVM that executes the test. [1] https://melix.github.io/javaone2016-juggling-jigsaw/#/ > > > -- Kevin > > > > Alan Bateman wrote: > >> On 20/10/2016 08:25, Cédric Champeau wrote: >> >> Yes, Gradle, Groovy and other third party libraries Gradle uses are >>> broken since the changes to enforce strong encapsulation at runtime >>> (preventing calls to setAccessible). I already raised the concern here, >>> saying we have no clear idea of the impact of such a change at a larger >>> scale, but it totally broke our efforts, and that's kind of depressing. >>> We'll figure it out, I hope, but unfortunately we have no bandwidth to do >>> it now. We're gladly accepting pull requests, though :) >>> >>> We are in no doubt that changing setAccessible will expose a lot of >> issues with existing code that uses it to get at non-public types/members >> in JDK classes (the rubygrapefruit library that Gradle uses is a good >> example as it seems to use setAccessible to get at the underlying >> collection of an unmodifable collection so that it can modify it). >> >> In the original proposal (2015) then this method was changed so that it >> cannot be used to directly break into non-exported packages (you can't use >> it to get a private types of public types in sun.awt for example). That was >> an attempt to strike a balance and avoid too much disruption but it leaves >> the hole that is #AwkwardStrongEncapsulation. The latest proposal in the >> JSR is an attempt to address that issue but it does impact code that uses >> setAccessible to get at non-public types/members in java.* classes. I >> assume this is what Stephen is running into with his mail but I can't say >> for sure without seeing the exception. >> >> Is the Gradle forum the best place to follow-up on these issues? (I can't >> tell from Stephen's mail if it's Gradle or Groovy here). >> >> -Alan >> >
