Gradle not working on Jigsaw

[Kevin Rushforth]

We use gradle for building JavaFX, so I did some testing earlier in the 
week and found similar issues. I had tried adding 
"--add-exports-private=java.base/java.lang=ALL-UNNAMED" to JAVA_OPTIONS, 
but hadn't run into 
"--add-exports-private=java.base/java.util=ALL-UNNAMED" yet (it died 
before it did anything that hit this).

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

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