Re: Gradle not working on Jigsaw

[Alan Bateman]

On 21/10/2016 10:08, Jochen Theodorou wrote:


:

And another example...

Module A:
package a
class X {
   protected void foo(){}
}

unnamed Module:
package u
class Y extends X{
   public void bar(){ foo() }
}

How am I supposed to realize the call to foo using a runtime based on 
classic reflection? I have only one chance, and that is to have the 
actual Method.invokeMethod call at the callsite of foo(). If I do not 
do that, I have other frames in between and then @CallerSensitive will 
see the "wrong" intermediate frames and assume the call is not made 
from a class that actually has access. So I have about 5 frames of my 
runtime that will be in the way to realize this call.
For this scenario, assuming a.X is public and module A exports a, then 
code in u.Y should be able to invoke foo with an invokevirtual or core 
reflection. If you have intermediate frames and the immediate caller of 
foo is not in package a or a subtype of X then the access check will 
fail, we don't need modules in the picture to demonstrate that. If I 
read your mails correctly then you've been using setAccessible to 
suppress the access check so that the Method::invoke doesn't fail. This 
can't work with "strong" modules (mostly JDK modules at this time), it 
will continue to work with modules that choose to open/expose packages 
for this type of access.


I'm not sure what to say except that mlvm-dev is usually good for 
advice, in this case alternatives using method handles. You may be able 
to get advice on the method reselection issue there. I see Andrew Dinn 
has brought up agents and they do have the capability to update module A 
to open package a to the module with the caller frame. Injecting code 
into A to coerce it to open the package to your module will do the same, 
as would injecting code into A that gives you a Lookup object with the 
lookup modes you need.


well, we changed it exactly because the bulk variant is faster. It 
might be not much difference. Bunt if you have to create a few 
thousand meta classes, it makes a difference. And as stated above, a 
@CS variant will get us nowhere. I don't know why all the JDK people 
seem to think that @CS saves the world...
Core reflection has always been @CS, I don't see how this could be 
changed now. In other areas then we do need to reduce the number of @CS 
method over time. In previous mails then you've brought up 
java.sql.DriverManager, that is one example where there is effort to try 
to address this (very difficult to change it due to compatibility 
concerns and could take a number of major releases to eventually remove 
it completely).


-Alan

RE: Gradle not working on Jigsaw

[Stephen Felts]

It's possible to work around the gradle error below by adding
--add-exports-private=java.base/java.io=ALL-UNNAMED to _JAVA_OPTIONS.

It's unfortunate that javac doesn't recognize this option because up until now 
I had been using one jdk9args file for both java and javac.

The next one that I ran into was a pattern match that needed 
java.base/java.util.regex.
So the number of these add-exports-private depends on what gradle/groovy code 
you have in your projects and what underlying java packages they reference.
The list that Kevin sent out in his email yesterday is quite different from 
what I need.

I'm also running with the daemon so it seems to need  java.base/sun.net.www 
java.base/sun.net.www.protocol.file java.base/java.lang.invoke.


-Original Message-
From: Stephen Felts 
Sent: Wednesday, October 19, 2016 10:43 PM
To: jigsaw-dev@openjdk.java.net
Subject: Gradle not working on Jigsaw

I have the line

def branch = file('..').name

in build.gradle.

Running 'gradle' on build 140

Jdk-9 - runs fine

JDK-9 Jigsaw gets
* What went wrong:
A problem occurred evaluating root project 'dir'.
> No such property: name for class: java.io.File

To run on Jigsaw, I also need to set _JAVA_OPTIONS to include 
--add-exports-private=java.base/java.lang=ALL-UNNAMED
--add-exports-private=java.base/java.util=ALL-UNNAMED

Re: Gradle not working on Jigsaw

[Andrew Dinn]

On 21/10/16 10:08, Jochen Theodorou wrote:
> I wrote "same class" and thought same class and subclasses... my bad.
> Anyway, I am aware of how it works, the problem is that shi... caller
> sensitivity. If you work with classic reflection and have a central
> space for these kind of actions (for example because that had not really
> been caller sensitive before) you get into trouble now.

  . . .

I had much the same issue to deal with in Byteman. It finesses the
caller-sensitivity problem by creating its own special module layer and
module at runtime and modifying the package the member belongs so it
exports access to the Byteman module. I then inject code into the
Byteman module to enable the required access. See the code for release
4.0.0-BETA0 in byteman-layer.jar and byteman-jigsaw.jar for details (you
can import the code in byteman-layer to do the module create if you want).

My current solution requires an Instrumentation instance to allow the
module export redefine to work and then relies on reflection to do the
access. So, if gradle were to follow this it would have to employ an
agent to acquire an Instrumentation instance.

That said, I am currently looking into the use of Lookups following John
Rose's suggestion:

  https://bugs.openjdk.java.net/browse/JDK-8162494

That looks very promising to me and is probably a much better way
forward than relying on reflection and modifying the module exports
hierarchy. Clearly if you have an agent you can use it to create
whatever lookups you need. However, depending on what John et al comes
up with by way of a privilege model for acquiring lookups it may avoid
the need to have an agent.

regards,


Andrew Dinn
---

Re: Gradle not working on Jigsaw

[Cédric Champeau]

2 things:
- Groovy uses ASM, but it's relocated, and used internally by Groovy.
Groovy will fail if it tries to parse a Java 9 class file, that's for sure.
- Gradle also uses ASM, a different version, that also has the version
parsing problem, but at every place we use ClassReader, we use a wrapper
[1] to workaround this.

There's no relation between the 2: Groovy uses ASM for its own business,
and Gradle too.

[1]
https://github.com/gradle/gradle/blob/d3cb6e9d7e87eb3d98ee23c7c61b644e227f82f3/subprojects/core/src/main/java/org/gradle/util/internal/Java9ClassReader.java#L25-L25


2016-10-20 19:50 GMT+02:00 Stephen Felts <stephen.fe...@oracle.com>:

> I’m not sure that I understand.  I did a jar xf on the class and ran jad
> on it.  Are you saying it’s somehow by-passing this class?
>
>
>
> *From:* Cédric Champeau [mailto:cedric.champ...@gmail.com]
> *Sent:* Thursday, October 20, 2016 1:33 PM
> *To:* Stephen Felts
> *Cc:* jigsaw-dev
> *Subject:* Re: Gradle not working on Jigsaw
>
>
>
> Gradle uses a custom ClassReader on top of the one provided by ASM to fix
> this version issue.
>
>
>
> 2016-10-20 18:38 GMT+02:00 Stephen Felts <stephen.fe...@oracle.com>:
>
> I also note that Gradle 3.0 still has both
>
> lib/asm-all-5.1.jar!org/objectweb/asm/ClassReader.class
>
> and
>
> lib/groovy-all-2.4.7.jar!groovyjarjarasm/asm/ClassReader.class
>
> that fail if the version is > 52.
>
> This isn't related to the failure below but they should be fixed.
>
>
>
> -Original Message-
> From: Stephen Felts
> Sent: Wednesday, October 19, 2016 10:43 PM
> To: jigsaw-dev@openjdk.java.net
> Subject: Gradle not working on Jigsaw
>
> I have the line
>
> def branch = file('..').name
>
> in build.gradle.
>
> Running 'gradle' on build 140
>
> Jdk-9 - runs fine
>
> JDK-9 Jigsaw gets
> * What went wrong:
> A problem occurred evaluating root project 'dir'.
> > No such property: name for class: java.io.File
>
> To run on Jigsaw, I also need to set _JAVA_OPTIONS to include
> --add-exports-private=java.base/java.lang=ALL-UNNAMED
> --add-exports-private=java.base/java.util=ALL-UNNAMED
>
>
>

Re: Gradle not working on Jigsaw

[Cédric Champeau]

Gradle uses a custom ClassReader on top of the one provided by ASM to fix
this version issue.

2016-10-20 18:38 GMT+02:00 Stephen Felts :

> I also note that Gradle 3.0 still has both
>
> lib/asm-all-5.1.jar!org/objectweb/asm/ClassReader.class
>
> and
>
> lib/groovy-all-2.4.7.jar!groovyjarjarasm/asm/ClassReader.class
>
> that fail if the version is > 52.
>
> This isn't related to the failure below but they should be fixed.
>
>
> -Original Message-
> From: Stephen Felts
> Sent: Wednesday, October 19, 2016 10:43 PM
> To: jigsaw-dev@openjdk.java.net
> Subject: Gradle not working on Jigsaw
>
> I have the line
>
> def branch = file('..').name
>
> in build.gradle.
>
> Running 'gradle' on build 140
>
> Jdk-9 - runs fine
>
> JDK-9 Jigsaw gets
> * What went wrong:
> A problem occurred evaluating root project 'dir'.
> > No such property: name for class: java.io.File
>
> To run on Jigsaw, I also need to set _JAVA_OPTIONS to include
> --add-exports-private=java.base/java.lang=ALL-UNNAMED
> --add-exports-private=java.base/java.util=ALL-UNNAMED
>
>

RE: Gradle not working on Jigsaw

[Stephen Felts]

I also note that Gradle 3.0 still has both

lib/asm-all-5.1.jar!org/objectweb/asm/ClassReader.class

and

lib/groovy-all-2.4.7.jar!groovyjarjarasm/asm/ClassReader.class

that fail if the version is > 52.

This isn't related to the failure below but they should be fixed.


-Original Message-
From: Stephen Felts 
Sent: Wednesday, October 19, 2016 10:43 PM
To: jigsaw-dev@openjdk.java.net
Subject: Gradle not working on Jigsaw

I have the line

def branch = file('..').name

in build.gradle.

Running 'gradle' on build 140

Jdk-9 - runs fine

JDK-9 Jigsaw gets
* What went wrong:
A problem occurred evaluating root project 'dir'.
> No such property: name for class: java.io.File

To run on Jigsaw, I also need to set _JAVA_OPTIONS to include 
--add-exports-private=java.base/java.lang=ALL-UNNAMED
--add-exports-private=java.base/java.util=ALL-UNNAMED

Re: Gradle not working on Jigsaw

[Kevin Rushforth]

I realized after reading Alan's email more closely that an important 
difference between his usage and my test yesterday is that he used 
_JAVA_OPTIONS whereas I was trying it with just JAVA_OPTS (the latter is 
recognized and used by gradle, but the former applies to all exec'ed 
java/javac commands even if gradle doesn't pass them along).


Starting with the following:

export _JAVA_OPTIONS="-Dsun.reflect.debugModuleAccessChecks=true 
--add-exports-private=java.base/java.lang=ALL-UNNAMED 
--add-exports-private=java.base/java.util=ALL-UNNAMED"


I was then able to see the other IllegalAccessExceptions and get much 
farther in my build. I ended up needing all of these:


export _JAVA_OPTIONS="-Dsun.reflect.debugModuleAccessChecks=true 
--add-exports-private=java.base/java.lang=ALL-UNNAMED 
--add-exports-private=java.base/java.util=ALL-UNNAMED 
--add-exports-private=java.base/java.lang.invoke=ALL-UNNAMED 
--add-exports-private=java.base/java.io=ALL-UNNAMED 
--add-exports-private=java.base/java.util.concurrent=ALL-UNNAMED 
--add-exports-private=java.base/java.text=ALL-UNNAMED


That was enough to get past compiling buildSrc and start compiling the 
javafx.* modules.


I then ran into an unrelated compilation error that I can reproduce 
outside of gradle.


-- Kevin



Jochen Theodorou wrote:



On 20.10.2016 10:19, Alan Bateman wrote:
[...]

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 still wish you had at least not included protected members. Sure, 
protected is not public and protected is always a pain in the butt, I 
still fail to comprehend the logic that a class can extend a class 
from another module and then use the protected methods of the super 
class, but setAccessible is not allowed to be used to gain access to 
it from anywhere but that same class.


[...]

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


could be Groovy 2.4.7, that kind of error is fixed in  2.4.8... once 
it is released, which we are currently working on. Because 2.4.7 
assumes either all of the class can be made accessible or none. And 
that is not true with #AwkwardStrongEncapsulation anymore. Which also 
means meta class creation will take a lot longer, since we now cannot 
use the array-taking setAccessible method in all cases anymore. Would 
have been nice to have a version of setAccessible that just makes 
accessible what is allowed and maybe reports back for those that are 
not allowed.


As for discussion about Gradle with #AwkwardStrongEncapsulation I have 
not seen any public discussion about this at gradle yet.


bye Jochen

Re: Gradle not working on Jigsaw

[Alan Bateman]

On 20/10/2016 15:27, Stephen Felts wrote:


:
Jython seems to be doing a setAccessible on a lot of methods.  It catches 
SecurityException and ignores it.  Of course, JDK9 throws a different exception 
so the code is broken.
Further, the new exception is JDK9 only so the code needs to change to catch 
and ignore RuntimeException.


Comment from Jython:
Set public methods on package protected classes accessible so
that reflected calls to the method in subclasses of the
package protected class will succeed. Yes, it's convoluted.
Yeah, it seems to be hacking into a few sun.* classes during startup 
(only seen with -Dsun.reflect.debugModuleAccessChecks=true) but it seems 
to continue without side effect after that.


java.lang.reflect.InaccessibleObjectException: Unable to make public 
abstract java.io.FileDescriptor sun.nio.ch.SelChImpl.getFD() accessible: 
module java.base does not "exports sun.nio.ch" to unnamed module @31dadd46
at 
java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:198)
at 
java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192)

at java.base/java.lang.reflect.Method.setAccessible(Method.java:186)
at jnr.posix.JavaLibCHelper.(JavaLibCHelper.java:92)
at jnr.posix.BaseNativePOSIX.(BaseNativePOSIX.java:37)
at jnr.posix.MacOSPOSIX.(MacOSPOSIX.java:11)
at jnr.posix.POSIXFactory.loadMacOSPOSIX(POSIXFactory.java:99)
at jnr.posix.POSIXFactory.loadNativePOSIX(POSIXFactory.java:66)
at jnr.posix.POSIXFactory.loadPOSIX(POSIXFactory.java:38)
at jnr.posix.LazyPOSIX.loadPOSIX(LazyPOSIX.java:35)
at jnr.posix.LazyPOSIX.posix(LazyPOSIX.java:31)
at jnr.posix.LazyPOSIX.isatty(LazyPOSIX.java:205)
at org.python.core.Py.isInteractive(Py.java:1548)
at org.python.util.jython.run(jython.java:255)
at org.python.util.jython.main(jython.java:142)
java.lang.reflect.InaccessibleObjectException: Unable to make field 
private final java.io.FileDescriptor sun.nio.ch.FileChannelImpl.fd 
accessible: module java.base does not "exports private sun.nio.ch" to 
unnamed module @31dadd46
at 
java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:198)
at 
java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:171)

at java.base/java.lang.reflect.Field.setAccessible(Field.java:165)
at jnr.posix.JavaLibCHelper.(JavaLibCHelper.java:109)
at jnr.posix.BaseNativePOSIX.(BaseNativePOSIX.java:37)
at jnr.posix.MacOSPOSIX.(MacOSPOSIX.java:11)
at jnr.posix.POSIXFactory.loadMacOSPOSIX(POSIXFactory.java:99)
at jnr.posix.POSIXFactory.loadNativePOSIX(POSIXFactory.java:66)
at jnr.posix.POSIXFactory.loadPOSIX(POSIXFactory.java:38)
at jnr.posix.LazyPOSIX.loadPOSIX(LazyPOSIX.java:35)
at jnr.posix.LazyPOSIX.posix(LazyPOSIX.java:31)
at jnr.posix.LazyPOSIX.isatty(LazyPOSIX.java:205)
at org.python.core.Py.isInteractive(Py.java:1548)
at org.python.util.jython.run(jython.java:255)
at org.python.util.jython.main(jython.java:142)

Re: Gradle not working on Jigsaw

[Alan Bateman]

On 20/10/2016 14:48, Jochen Theodorou wrote:


:

I still wish you had at least not included protected members. Sure, 
protected is not public and protected is always a pain in the butt, I 
still fail to comprehend the logic that a class can extend a class 
from another module and then use the protected methods of the super 
class, but setAccessible is not allowed to be used to gain access to 
it from anywhere but that same class.
This might appear to be an anomaly but remember you don't have the 
receiver at this point. You could have setAccessible silently fail so 
that the access check happens at newInstance/invoke/get/put but I don't 
see anyone being happy with that. That said, if you are using core 
reflection to access a protected member in the same package or super 
type then you don't need setAccessible in the first place as the access 
check should succeed (there have been issues with protected members that 
Peter has recently fixed in jdk9/dev, I don't know if you've run into that).




could be Groovy 2.4.7, that kind of error is fixed in  2.4.8... once 
it is released, which we are currently working on. Because 2.4.7 
assumes either all of the class can be made accessible or none. And 
that is not true with #AwkwardStrongEncapsulation anymore. Which also 
means meta class creation will take a lot longer, since we now cannot 
use the array-taking setAccessible method in all cases anymore. Would 
have been nice to have a version of setAccessible that just makes 
accessible what is allowed and maybe reports back for those that are 
not allowed.
A trySetAccessible is possible although a @CS variant of accessCheck 
(like in MH.Lookup) might be more general. I think we need to be 
cautious about adding APIs here and so would be interesting to get some 
performance data here (I don't think I've seen the bulk setAccessible 
used very often, it's almost always the instance method).




As for discussion about Gradle with #AwkwardStrongEncapsulation I have 
not seen any public discussion about this at gradle yet.
There is a command-line option to workaround specific usages, I think 
part of the challenge is knowing if all usages have been identified and 
where to put the VM options (gradle.properties for example) but that's a 
discussion for the Gradle forum I guess.


-Alan

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

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

Re: Gradle not working on Jigsaw

[Alan Bateman]

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

Re: Gradle not working on Jigsaw

[Cédric Champeau]

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

2016-10-20 8:57 GMT+02:00 Alan Bateman :

> On 20/10/2016 03:42, Stephen Felts wrote:
>
> I have the line
>>
>> def branch = file('..').name
>>
>> in build.gradle.
>>
>> Running 'gradle' on build 140
>>
>> Jdk-9 - runs fine
>>
>> JDK-9 Jigsaw gets
>> * What went wrong:
>> A problem occurred evaluating root project 'dir'.
>>
>>> No such property: name for class: java.io.File
>>>
>> To run on Jigsaw, I also need to set _JAVA_OPTIONS to include
>> --add-exports-private=java.base/java.lang=ALL-UNNAMED
>> --add-exports-private=java.base/java.util=ALL-UNNAMED
>>
> I can't tell if this is Groovy or Gradle but if you run with
> -Dsun.reflect.debugModuleAccessChecks=true then it might reveal a stack
> trace where the exception (IllegalAccessException or
> InaccessibleObjectException) is caught and lost. There are folks from these
> products on this list and I'm sure they can direct us to the right place to
> submit an issue. There is already GRADLE-3565 [1].
>
> -Alan
>
> [1] https://issues.gradle.org/browse/GRADLE-3565
>

Re: Gradle not working on Jigsaw

[Alan Bateman]

On 20/10/2016 03:42, Stephen Felts wrote:


I have the line

def branch = file('..').name

in build.gradle.

Running 'gradle' on build 140

Jdk-9 - runs fine

JDK-9 Jigsaw gets
* What went wrong:
A problem occurred evaluating root project 'dir'.

No such property: name for class: java.io.File

To run on Jigsaw, I also need to set _JAVA_OPTIONS to include
--add-exports-private=java.base/java.lang=ALL-UNNAMED
--add-exports-private=java.base/java.util=ALL-UNNAMED
I can't tell if this is Groovy or Gradle but if you run with 
-Dsun.reflect.debugModuleAccessChecks=true then it might reveal a stack 
trace where the exception (IllegalAccessException or 
InaccessibleObjectException) is caught and lost. There are folks from 
these products on this list and I'm sure they can direct us to the right 
place to submit an issue. There is already GRADLE-3565 [1].


-Alan

[1] https://issues.gradle.org/browse/GRADLE-3565