> De: "Cédric Champeau" <cedric.champ...@gmail.com>
> À: dev@groovy.apache.org
> Envoyé: Mercredi 21 Septembre 2016 00:20:58
> Objet: Re: TeamCity back on track

> I'm not able to answer the question why Gradle modifies the environment (I'm
> sure it does for good reasons), but we need to make it work on different
> platforms without having to publish a specific version for JDK 9. It's really
> unfortunate such a "feature" landed after the feature freeze.

the release of jdk9 was postponed in part because jigsaw is still not feature 
The rules surrounding setAccessible are hard to get right, we have already 
re-open that issue twice :( 

> Our commitment that Gradle 3 runs on JDK 9 isn't true anymore, and it's hard 
> to
> fix. Especially, the second exception you are seeing comes from a 3rd party
> library. I'm pretty sure we will face tons of those issues, especially in an
> environment where plugins are legion.

The elephant i see is that now that IBM (and Google is around the corner) uses 
the OpenJDK, the OpenJDK implementation becomes the defacto standard so recent 
3rd party libraries tend to use OpenJDK specifics in their implementation. 
Before, it was less an issue because there was multiple implementations of the 
JDK. If we don't do something now, the platform will calcified and we will not 
be able to change anything in the OpenJDK in the future. 
I understand that breaking a 3rd party library doesn't let a lot of option 
apart fixing the library itself or removing the use of it. But the future i see 
if we don't do that now is the death of innovation of the Java platform. 


> 2016-09-18 21:14 GMT+02:00 Jochen Theodorou < blackd...@gmx.org > :

>> On 18.09.2016 15:03, Remi Forax wrote:

>>> ------------------------------------------------------------------------

>>> *De: *"Cédric Champeau" < cedric.champ...@gmail.com >
>>> *À: * dev@groovy.apache.org
>>> *Envoyé: *Dimanche 18 Septembre 2016 14:39:30
>>> *Objet: *Re: TeamCity back on track

>>> I can confirm this is a new error. Gradle 3.0 works with b119, but
>>> not b136. And from what I can see, this is *not* going to be trivial
>>> to fix. Best I could get now is:
>>> Caused by: java.lang.IllegalAccessException: class
>>> org.gradle.internal.reflect.JavaMethod cannot access a member of
>>> class java.lang.ClassLoader (in module java.base) with modifiers
>>> "protected"
>>> at
>>> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:405)
>>> at
>>> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:396)
>>> at
>>> java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:98)
>>> at
>>> java.base/ java.lang.reflect.Ac
>>> cessibleObject.slowCheckMemberAccess(AccessibleObject.java:359)
>>> at
>>> java.base/ java.lang.reflect.Ac
>>> cessibleObject.checkAccess(AccessibleObject.java:351)
>>> at java.base/ java.lang.reflect.Me thod.invoke(Method.java:529)
>>> at
>>> org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:77)

>>> Which is f* annoying.

>> [...]

>>> This one is a new bug/feature,
>>> it's part of what we have called 'stronger' (not strong) encapsulation
>>> i.e. most of the classes of java.* disallow setAccessible, before that
>>> only internal packages were disallowing setAccessible.

>> so setAccessible is forbidden, but a subclass from a different module can 
>> access
>> the method... strange new rules. Anyway... was there a thread on jigsaw-dev
>> about this? I would like to reread the proposal

>>> For your specific bug, you can use ClassLoader.getDefinedPackages() or
>>> classloader.getUnamedModule().getPackages() instead.

>> of course with the disadvantage that these are JDK9 only methods.

>> bye Jochen

Reply via email to