Gradle not working on Jigsaw

[Cédric Champeau]

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