groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <>
Subject Re: TeamCity back on track
Date Wed, 21 Sep 2016 06:56:56 GMT
> De: "Cédric Champeau" <>
> À:
> 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 freeze, 
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 < > :

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

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

>>> *De: *"Cédric Champeau" < >
>>> *À: *
>>> *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(
>>> at
>>> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(
>>> at
>>> java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(
>>> at
>>> java.base/ java.lang.reflect.Ac
>>> cessibleObject.slowCheckMemberAccess(
>>> at
>>> java.base/ java.lang.reflect.Ac
>>> cessibleObject.checkAccess(
>>> at java.base/ java.lang.reflect.Me thod.invoke(
>>> at
>>> org.gradle.internal.reflect.JavaMethod.invoke(

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

View raw message