You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Guillaume Laforge <gl...@gmail.com> on 2016/09/17 16:12:26 UTC
TeamCity back on track
Hi there,
Quick heads-up on continuous integration on TeamCity.
The builds were stuck for a while because of some Gradle bug when Gradle is
run in parallel and corrupts the cache, or when Gradle crashes not cleaning
caches and lock files... something along those lines. Would have been good
to have the Gradle boys look into this probably, as there might be
something to be fixed.
Builds were failing with a message like this:
org.gradle.cache.internal.LockTimeoutException: Timeout waiting to lock
Plugin Resolution Cache
(/var/teamcity/.gradle/caches/3.0/plugin-resolution). It is currently in
use by another Gradle instance.
I logged into the machine and wiped the caches, to clean those caches &
locks.
And now Jochen is launching the builds manually to see if everything comes
back as it should.
TeamCity should be fully back!
Guillaume
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: TeamCity back on track
Posted by Guillaume Laforge <gl...@gmail.com>.
Ok, thanks for confirming this.
On Sun, Sep 18, 2016 at 8:18 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
>
> ------------------------------
>
> *De: *"Guillaume Laforge" <gl...@gmail.com>
> *À: *dev@groovy.apache.org
> *Envoyé: *Dimanche 18 Septembre 2016 20:11:20
> *Objet: *Re: TeamCity back on track
>
> But we'll face it at some point when this change becomes integrated in the
> version we can download from java.net, right?
>
>
> yes,
> note that there are still discussions in the Expert Group (that's one of
> the reasons the jdk9 release was delayed) so everything is not settle but i
> don't see the stronger encapsulation being something rejected.
>
> cheers,
> Rémi
>
>
>
> On Sun, Sep 18, 2016 at 7:56 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
>> Your code should work with the jdk-9 build
>> https://jdk9.java.net/download/
>> because this version doesn't integrate the change that enable 'stronger'
>> encapsulation.
>>
>> Rémi
>>
>> ----- Mail original -----
>> > De: "Jochen Theodorou" <bl...@gmx.org>
>> > À: dev@groovy.apache.org
>> > Envoyé: Dimanche 18 Septembre 2016 19:09:13
>> > Objet: Re: TeamCity back on track
>>
>> > On 18.09.2016 15:03, Remi Forax wrote:
>> > [...]
>> >> 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.
>> >>
>> >> For your specific bug, you can use ClassLoader.getDefinedPackages() or
>> >> classloader.getUnamedModule().getPackages() instead.
>> >
>> > too bad, we just got the build before that successfully run our build
>> > and I fear that we will now have new problems. The code that uses
>> > setAccessible in Groovy is now pretty flexible when it comes
>> > setAccessible, but still... well right now we have to see for a new
>> > gradle fix
>> >
>> > bye Jochen
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: TeamCity back on track
Posted by Remi Forax <fo...@univ-mlv.fr>.
> De: "Guillaume Laforge" <gl...@gmail.com>
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 20:11:20
> Objet: Re: TeamCity back on track
> But we'll face it at some point when this change becomes integrated in the
> version we can download from java.net , right?
yes,
note that there are still discussions in the Expert Group (that's one of the reasons the jdk9 release was delayed) so everything is not settle but i don't see the stronger encapsulation being something rejected.
cheers,
Rémi
> On Sun, Sep 18, 2016 at 7:56 PM, Remi Forax < forax@univ-mlv.fr > wrote:
>> Your code should work with the jdk-9 build
>> https://jdk9.java.net/download/
>> because this version doesn't integrate the change that enable 'stronger'
>> encapsulation.
>> Rémi
>> ----- Mail original -----
>> > De: "Jochen Theodorou" < blackdrag@gmx.org >
>> > À: dev@groovy.apache.org
>> > Envoyé: Dimanche 18 Septembre 2016 19:09:13
>> > Objet: Re: TeamCity back on track
>> > On 18.09.2016 15:03, Remi Forax wrote:
>> > [...]
>> >> 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.
>> >> For your specific bug, you can use ClassLoader.getDefinedPackages() or
>> >> classloader.getUnamedModule().getPackages() instead.
>> > too bad, we just got the build before that successfully run our build
>> > and I fear that we will now have new problems. The code that uses
>> > setAccessible in Groovy is now pretty flexible when it comes
>> > setAccessible, but still... well right now we have to see for a new
>> > gradle fix
>> > bye Jochen
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
> Blog: http://glaforge.appspot.com/
> Social: @glaforge / Google+
Re: TeamCity back on track
Posted by Remi Forax <fo...@univ-mlv.fr>.
The real question is why Gradle want to modify the environment of the current process given that ProcessBuilder::environment() exists.
Rémi
> De: "Remi Forax" <fo...@univ-mlv.fr>
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 16:59:32
> Objet: Re: TeamCity back on track
> It's a feature,
> so you can easily detect sofwares that try to do reflection using setAccessible,
> i.e. violates the VM access rules to, by example, get access to a security
> token,
> what is not known is which part of the JDK should allow this kind of reflection
> (think things like sun.misc.Unsafe.theUnsafe).
> It works like with the exports feature, you can use the command line flag
> --add-exports-private which works like --add-exports
> Rémi
>> De: "Cédric Champeau" <ce...@gmail.com>
>> À: dev@groovy.apache.org
>> Envoyé: Dimanche 18 Septembre 2016 15:13:17
>> Objet: Re: TeamCity back on track
>> Thanks but I'm afraid it won't allow me to boot Gradle either. Even after trying
>> `getDefinedPackages` instead, I only reach another error of this kind:
>> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make private
>> final java.util.Map java.util.Collections$UnmodifiableMap.m accessible: module
>> java.base does not "exports private java.util" to unnamed module @6da21078
>> at
>> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
>> at
>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
>> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:171)
>> at java.base/java.lang.reflect.Field.setAccessible(Field.java:165)
>> at
>> net.rubygrapefruit.platform.internal.WrapperProcess.getEnv(WrapperProcess.java:110)
>> Is this "feature/bug" going to be fixed? Is there any way to disable that
>> behavior?
>> 2016-09-18 15:03 GMT+02:00 Remi Forax < forax@univ-mlv.fr > :
>>>> De: "Cédric Champeau" < cedric.champeau@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.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:359)
>>>> at
>>>> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:351)
>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:529)
>>>> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:77)
>>>> Which is f* annoying.
>>> Sorry,wrong stacktrace.
>>> 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.
>>> For your specific bug, you can use ClassLoader.getDefinedPackages() or
>>> classloader.getUnamedModule().getPackages() instead.
>>> Rémi
>>>> 2016-09-18 13:46 GMT+02:00 Cédric Champeau < cedric.champeau@gmail.com > :
>>>>> This seems to be a new error, I've never seen it before with Gradle 3.0+. It
>>>>> says:
>>>>> [Gradle failure report] Caused by:
>>>>> java.lang.reflect.InaccessibleObjectException: Unable to make protected
>>>>> java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module
>>>>> java.base does not "exports private java.lang" to unnamed module @6ca18a14
>>>>> [12:00:28][Gradle failure report] at
>>>>> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
>>>>> [12:00:28][Gradle failure report] at
>>>>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
>>>>> [12:00:28][Gradle failure report] at
>>>>> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192)
>>>>> [12:00:28][Gradle failure report] at
>>>>> java.base/java.lang.reflect.Method.setAccessible(Method.java:186)
>>>>> [12:00:28][Gradle failure report] at
>>>>> org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:34)
>>>>> [12:00:28][Gradle failure report] at
>>>>> org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:38)
>>>>> [12:00:28][Gradle failure report] at
>>>>> org.gradle.internal.reflect.JavaReflectionUtil.method(JavaReflectionUtil.java:224)
>>>>> [12:00:28][Gradle failure report] at
>>>>> org.gradle.internal.classloader.FilteringClassLoader.<clinit>(FilteringClassLoader.java:49)
>>>>> Which doesn't seem to be URLClassLoader related.
>>>>> 2016-09-18 13:11 GMT+02:00 Remi Forax < forax@univ-mlv.fr > :
>>>>>> Gradle thinks it can hack the classpath by seeing the application classloader as
>>>>>> an URLClassLoader.
>>>>>> The application classloader is now something that loads modules, so it's not a
>>>>>> subclass of URLClassLoader anymore.
>>>>>> Rémi
>>>>>> ----- Mail original -----
>>>>>> > De: "Jochen Theodorou" < blackdrag@gmx.org >
>>>>>> > À: dev@groovy.apache.org
>>>>>> > Envoyé: Dimanche 18 Septembre 2016 12:31:56
>>>>>> > Objet: Re: TeamCity back on track
>>>>>> > On 18.09.2016 10:47, Cédric Champeau wrote:
>>>>>> >> I just installed Jigsaw b136. Let me know if it helps.
>>>>>> > looks like gradle has a problem with this one as well
>>>>>> > bye Jochen
Re: TeamCity back on track
Posted by Guillaume Laforge <gl...@gmail.com>.
But we'll face it at some point when this change becomes integrated in the
version we can download from java.net, right?
On Sun, Sep 18, 2016 at 7:56 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
> Your code should work with the jdk-9 build
> https://jdk9.java.net/download/
> because this version doesn't integrate the change that enable 'stronger'
> encapsulation.
>
> Rémi
>
> ----- Mail original -----
> > De: "Jochen Theodorou" <bl...@gmx.org>
> > À: dev@groovy.apache.org
> > Envoyé: Dimanche 18 Septembre 2016 19:09:13
> > Objet: Re: TeamCity back on track
>
> > On 18.09.2016 15:03, Remi Forax wrote:
> > [...]
> >> 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.
> >>
> >> For your specific bug, you can use ClassLoader.getDefinedPackages() or
> >> classloader.getUnamedModule().getPackages() instead.
> >
> > too bad, we just got the build before that successfully run our build
> > and I fear that we will now have new problems. The code that uses
> > setAccessible in Groovy is now pretty flexible when it comes
> > setAccessible, but still... well right now we have to see for a new
> > gradle fix
> >
> > bye Jochen
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: TeamCity back on track
Posted by Remi Forax <fo...@univ-mlv.fr>.
Your code should work with the jdk-9 build
https://jdk9.java.net/download/
because this version doesn't integrate the change that enable 'stronger' encapsulation.
Rémi
----- Mail original -----
> De: "Jochen Theodorou" <bl...@gmx.org>
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 19:09:13
> Objet: Re: TeamCity back on track
> On 18.09.2016 15:03, Remi Forax wrote:
> [...]
>> 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.
>>
>> For your specific bug, you can use ClassLoader.getDefinedPackages() or
>> classloader.getUnamedModule().getPackages() instead.
>
> too bad, we just got the build before that successfully run our build
> and I fear that we will now have new problems. The code that uses
> setAccessible in Groovy is now pretty flexible when it comes
> setAccessible, but still... well right now we have to see for a new
> gradle fix
>
> bye Jochen
Re: TeamCity back on track
Posted by Remi Forax <fo...@univ-mlv.fr>.
It's a feature,
so you can easily detect sofwares that try to do reflection using setAccessible, i.e. violates the VM access rules to, by example, get access to a security token,
what is not known is which part of the JDK should allow this kind of reflection (think things like sun.misc.Unsafe.theUnsafe).
It works like with the exports feature, you can use the command line flag --add-exports-private which works like --add-exports
Rémi
> De: "Cédric Champeau" <ce...@gmail.com>
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 15:13:17
> Objet: Re: TeamCity back on track
> Thanks but I'm afraid it won't allow me to boot Gradle either. Even after trying
> `getDefinedPackages` instead, I only reach another error of this kind:
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make private
> final java.util.Map java.util.Collections$UnmodifiableMap.m accessible: module
> java.base does not "exports private java.util" to unnamed module @6da21078
> at
> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:171)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:165)
> at
> net.rubygrapefruit.platform.internal.WrapperProcess.getEnv(WrapperProcess.java:110)
> Is this "feature/bug" going to be fixed? Is there any way to disable that
> behavior?
> 2016-09-18 15:03 GMT+02:00 Remi Forax < forax@univ-mlv.fr > :
>>> De: "Cédric Champeau" < cedric.champeau@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.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:359)
>>> at
>>> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:351)
>>> at java.base/java.lang.reflect.Method.invoke(Method.java:529)
>>> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:77)
>>> Which is f* annoying.
>> Sorry,wrong stacktrace.
>> 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.
>> For your specific bug, you can use ClassLoader.getDefinedPackages() or
>> classloader.getUnamedModule().getPackages() instead.
>> Rémi
>>> 2016-09-18 13:46 GMT+02:00 Cédric Champeau < cedric.champeau@gmail.com > :
>>>> This seems to be a new error, I've never seen it before with Gradle 3.0+. It
>>>> says:
>>>> [Gradle failure report] Caused by:
>>>> java.lang.reflect.InaccessibleObjectException: Unable to make protected
>>>> java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module
>>>> java.base does not "exports private java.lang" to unnamed module @6ca18a14
>>>> [12:00:28][Gradle failure report] at
>>>> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
>>>> [12:00:28][Gradle failure report] at
>>>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
>>>> [12:00:28][Gradle failure report] at
>>>> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192)
>>>> [12:00:28][Gradle failure report] at
>>>> java.base/java.lang.reflect.Method.setAccessible(Method.java:186)
>>>> [12:00:28][Gradle failure report] at
>>>> org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:34)
>>>> [12:00:28][Gradle failure report] at
>>>> org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:38)
>>>> [12:00:28][Gradle failure report] at
>>>> org.gradle.internal.reflect.JavaReflectionUtil.method(JavaReflectionUtil.java:224)
>>>> [12:00:28][Gradle failure report] at
>>>> org.gradle.internal.classloader.FilteringClassLoader.<clinit>(FilteringClassLoader.java:49)
>>>> Which doesn't seem to be URLClassLoader related.
>>>> 2016-09-18 13:11 GMT+02:00 Remi Forax < forax@univ-mlv.fr > :
>>>>> Gradle thinks it can hack the classpath by seeing the application classloader as
>>>>> an URLClassLoader.
>>>>> The application classloader is now something that loads modules, so it's not a
>>>>> subclass of URLClassLoader anymore.
>>>>> Rémi
>>>>> ----- Mail original -----
>>>>> > De: "Jochen Theodorou" < blackdrag@gmx.org >
>>>>> > À: dev@groovy.apache.org
>>>>> > Envoyé: Dimanche 18 Septembre 2016 12:31:56
>>>>> > Objet: Re: TeamCity back on track
>>>>> > On 18.09.2016 10:47, Cédric Champeau wrote:
>>>>> >> I just installed Jigsaw b136. Let me know if it helps.
>>>>> > looks like gradle has a problem with this one as well
>>>>> > bye Jochen
Re: TeamCity back on track
Posted by Remi Forax <fo...@univ-mlv.fr>.
----- Mail original -----
> De: "Jochen Theodorou" <bl...@gmx.org>
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 21:14:51
> Objet: Re: TeamCity back on track
[...]
>
> 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
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000390.html
>
>> 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.
yes
>
> bye Jochen
Rémi
Re: TeamCity back on track
Posted by Cédric Champeau <ce...@gmail.com>.
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.
>
I understand the temptation to enforce encapsulation as much as possible
too, but the thing here is that I can hardly imagine the consequences of
such a decision. That you prevent calling `setAccessible` on non exported
packages make sense, but forbidding it on visible classes seem to go a bit
too far. It is, more or less, removing setAccessible altogether. It is
today very hard to evaluate the consequences of doing this. It could very
well kill Groovy too. And working with -add-exports is not a long term
solution (we know it's temporary until everything is a module).
The risk of such a decision is also that migrating to JDK 9 becomes too
painful, and people do not upgrade at all. We're trying to make it easier,
with Gradle, to do so, but there's nothing we can help for "runtime magic".
Re: TeamCity back on track
Posted by Remi Forax <fo...@univ-mlv.fr>.
> De: "Cédric Champeau" <ce...@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.
yes,
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.
regards,
Rémi
> 2016-09-18 21:14 GMT+02:00 Jochen Theodorou < blackdrag@gmx.org > :
>> On 18.09.2016 15:03, Remi Forax wrote:
>>> ------------------------------------------------------------------------
>>> *De: *"Cédric Champeau" < cedric.champeau@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
Re: TeamCity back on track
Posted by Cédric Champeau <ce...@gmail.com>.
Thanks but I'm afraid it won't allow me to boot Gradle either. Even after
trying `getDefinedPackages` instead, I only reach another error of this
kind:
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
private final java.util.Map java.util.Collections$UnmodifiableMap.m
accessible: module java.base does not "exports private java.util" to
unnamed module @6da21078
at
java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
at
java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:171)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:165)
at
net.rubygrapefruit.platform.internal.WrapperProcess.getEnv(WrapperProcess.java:110)
Is this "feature/bug" going to be fixed? Is there any way to disable that
behavior?
2016-09-18 15:03 GMT+02:00 Remi Forax <fo...@univ-mlv.fr>:
>
>
> ------------------------------
>
> *De: *"Cédric Champeau" <ce...@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.AccessibleObject.
> slowCheckMemberAccess(AccessibleObject.java:359)
> at java.base/java.lang.reflect.AccessibleObject.checkAccess(
> AccessibleObject.java:351)
> at java.base/java.lang.reflect.Method.invoke(Method.java:529)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.
> java:77)
>
> Which is f* annoying.
>
>
> Sorry,wrong stacktrace.
>
> 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.
>
> For your specific bug, you can use ClassLoader.getDefinedPackages() or
> classloader.getUnamedModule().getPackages() instead.
>
> Rémi
>
>
>
> 2016-09-18 13:46 GMT+02:00 Cédric Champeau <ce...@gmail.com>:
>
>> This seems to be a new error, I've never seen it before with Gradle 3.0+.
>> It says:
>> [Gradle failure report] Caused by: java.lang.reflect.InaccessibleObjectException:
>> Unable to make protected java.lang.Package[] java.lang.ClassLoader.getPackages()
>> accessible: module java.base does not "exports private java.lang" to
>> unnamed module @6ca18a14
>> [12:00:28][Gradle failure report] at java.base/jdk.internal.
>> reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
>> [12:00:28][Gradle failure report] at java.base/java.lang.reflect.
>> AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
>> [12:00:28][Gradle failure report] at java.base/java.lang.reflect.
>> Method.checkCanSetAccessible(Method.java:192)
>> [12:00:28][Gradle failure report] at java.base/java.lang.reflect.
>> Method.setAccessible(Method.java:186)
>> [12:00:28][Gradle failure report] at org.gradle.internal.reflect.
>> JavaMethod.<init>(JavaMethod.java:34)
>> [12:00:28][Gradle failure report] at org.gradle.internal.reflect.
>> JavaMethod.<init>(JavaMethod.java:38)
>> [12:00:28][Gradle failure report] at org.gradle.internal.reflect.
>> JavaReflectionUtil.method(JavaReflectionUtil.java:224)
>> [12:00:28][Gradle failure report] at org.gradle.internal.classloader.
>> FilteringClassLoader.<clinit>(FilteringClassLoader.java:49)
>>
>> Which doesn't seem to be URLClassLoader related.
>>
>> 2016-09-18 13:11 GMT+02:00 Remi Forax <fo...@univ-mlv.fr>:
>>
>>> Gradle thinks it can hack the classpath by seeing the application
>>> classloader as an URLClassLoader.
>>> The application classloader is now something that loads modules, so it's
>>> not a subclass of URLClassLoader anymore.
>>>
>>> Rémi
>>>
>>> ----- Mail original -----
>>> > De: "Jochen Theodorou" <bl...@gmx.org>
>>> > À: dev@groovy.apache.org
>>> > Envoyé: Dimanche 18 Septembre 2016 12:31:56
>>> > Objet: Re: TeamCity back on track
>>>
>>> > On 18.09.2016 10:47, Cédric Champeau wrote:
>>> >> I just installed Jigsaw b136. Let me know if it helps.
>>> >
>>> > looks like gradle has a problem with this one as well
>>> >
>>> > bye Jochen
>>>
>>
>>
>
Re: TeamCity back on track
Posted by Jochen Theodorou <bl...@gmx.org>.
On 18.09.2016 15:03, Remi Forax wrote:
[...]
> 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.
>
> For your specific bug, you can use ClassLoader.getDefinedPackages() or
> classloader.getUnamedModule().getPackages() instead.
too bad, we just got the build before that successfully run our build
and I fear that we will now have new problems. The code that uses
setAccessible in Groovy is now pretty flexible when it comes
setAccessible, but still... well right now we have to see for a new
gradle fix
bye Jochen
Re: TeamCity back on track
Posted by Jochen Theodorou <bl...@gmx.org>.
On 21.09.2016 00:20, C�dric Champeau wrote:
> 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. 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.
a workaround would be to use "--add-exports-private
java.base/java.lang=ALL-UNNAMED" That should make the build work
again... but of course it does not really solve the problem. And I
actually do not think that switches like that are good for gradle, if
that means I will run later my own programs with those switches enabled
only from the build... because in the deployed state I will not have
them set and then things break apart.
bye Jochen
Re: TeamCity back on track
Posted by Cédric Champeau <ce...@gmail.com>.
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.
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.
2016-09-18 21:14 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:
> On 18.09.2016 15:03, Remi Forax wrote:
>
>>
>>
>> ------------------------------------------------------------------------
>>
>> *De: *"Cédric Champeau" <ce...@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.throwIllegalAccess
>> Exception(Reflection.java:405)
>> at
>> java.base/jdk.internal.reflect.Reflection.throwIllegalAccess
>> Exception(Reflection.java:396)
>> at
>> java.base/jdk.internal.reflect.Reflection.ensureMemberAccess
>> (Reflection.java:98)
>> at
>> java.base/java.lang.reflect.AccessibleObject.slowCheckMember
>> Access(AccessibleObject.java:359)
>> at
>> java.base/java.lang.reflect.AccessibleObject.checkAccess(Acc
>> essibleObject.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
>
>
Re: TeamCity back on track
Posted by Jochen Theodorou <bl...@gmx.org>.
On 18.09.2016 15:03, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
> *De: *"C�dric Champeau" <ce...@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.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:359)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:351)
> at java.base/java.lang.reflect.Method.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
Re: TeamCity back on track
Posted by Remi Forax <fo...@univ-mlv.fr>.
> De: "Cédric Champeau" <ce...@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.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:359)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:351)
> at java.base/java.lang.reflect.Method.invoke(Method.java:529)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:77)
> Which is f* annoying.
Sorry,wrong stacktrace.
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.
For your specific bug, you can use ClassLoader.getDefinedPackages() or classloader.getUnamedModule().getPackages() instead.
Rémi
> 2016-09-18 13:46 GMT+02:00 Cédric Champeau < cedric.champeau@gmail.com > :
>> This seems to be a new error, I've never seen it before with Gradle 3.0+. It
>> says:
>> [Gradle failure report] Caused by:
>> java.lang.reflect.InaccessibleObjectException: Unable to make protected
>> java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module
>> java.base does not "exports private java.lang" to unnamed module @6ca18a14
>> [12:00:28][Gradle failure report] at
>> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
>> [12:00:28][Gradle failure report] at
>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
>> [12:00:28][Gradle failure report] at
>> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192)
>> [12:00:28][Gradle failure report] at
>> java.base/java.lang.reflect.Method.setAccessible(Method.java:186)
>> [12:00:28][Gradle failure report] at
>> org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:34)
>> [12:00:28][Gradle failure report] at
>> org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:38)
>> [12:00:28][Gradle failure report] at
>> org.gradle.internal.reflect.JavaReflectionUtil.method(JavaReflectionUtil.java:224)
>> [12:00:28][Gradle failure report] at
>> org.gradle.internal.classloader.FilteringClassLoader.<clinit>(FilteringClassLoader.java:49)
>> Which doesn't seem to be URLClassLoader related.
>> 2016-09-18 13:11 GMT+02:00 Remi Forax < forax@univ-mlv.fr > :
>>> Gradle thinks it can hack the classpath by seeing the application classloader as
>>> an URLClassLoader.
>>> The application classloader is now something that loads modules, so it's not a
>>> subclass of URLClassLoader anymore.
>>> Rémi
>>> ----- Mail original -----
>>> > De: "Jochen Theodorou" < blackdrag@gmx.org >
>>> > À: dev@groovy.apache.org
>>> > Envoyé: Dimanche 18 Septembre 2016 12:31:56
>>> > Objet: Re: TeamCity back on track
>>> > On 18.09.2016 10:47, Cédric Champeau wrote:
>>> >> I just installed Jigsaw b136. Let me know if it helps.
>>> > looks like gradle has a problem with this one as well
>>> > bye Jochen
Re: TeamCity back on track
Posted by Cédric Champeau <ce...@gmail.com>.
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.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:359)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:351)
at java.base/java.lang.reflect.Method.invoke(Method.java:529)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:77)
Which is f* annoying.
2016-09-18 13:46 GMT+02:00 Cédric Champeau <ce...@gmail.com>:
> This seems to be a new error, I've never seen it before with Gradle 3.0+.
> It says:
>
> [Gradle failure report] Caused by: java.lang.reflect.InaccessibleObjectException:
> Unable to make protected java.lang.Package[] java.lang.ClassLoader.getPackages()
> accessible: module java.base does not "exports private java.lang" to
> unnamed module @6ca18a14
> [12:00:28][Gradle failure report] at java.base/jdk.internal.
> reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
> [12:00:28][Gradle failure report] at java.base/java.lang.reflect.
> AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
> [12:00:28][Gradle failure report] at java.base/java.lang.reflect.
> Method.checkCanSetAccessible(Method.java:192)
> [12:00:28][Gradle failure report] at java.base/java.lang.reflect.
> Method.setAccessible(Method.java:186)
> [12:00:28][Gradle failure report] at org.gradle.internal.reflect.
> JavaMethod.<init>(JavaMethod.java:34)
> [12:00:28][Gradle failure report] at org.gradle.internal.reflect.
> JavaMethod.<init>(JavaMethod.java:38)
> [12:00:28][Gradle failure report] at org.gradle.internal.reflect.
> JavaReflectionUtil.method(JavaReflectionUtil.java:224)
> [12:00:28][Gradle failure report] at org.gradle.internal.classloader.
> FilteringClassLoader.<clinit>(FilteringClassLoader.java:49)
>
> Which doesn't seem to be URLClassLoader related.
>
> 2016-09-18 13:11 GMT+02:00 Remi Forax <fo...@univ-mlv.fr>:
>
>> Gradle thinks it can hack the classpath by seeing the application
>> classloader as an URLClassLoader.
>> The application classloader is now something that loads modules, so it's
>> not a subclass of URLClassLoader anymore.
>>
>> Rémi
>>
>> ----- Mail original -----
>> > De: "Jochen Theodorou" <bl...@gmx.org>
>> > À: dev@groovy.apache.org
>> > Envoyé: Dimanche 18 Septembre 2016 12:31:56
>> > Objet: Re: TeamCity back on track
>>
>> > On 18.09.2016 10:47, Cédric Champeau wrote:
>> >> I just installed Jigsaw b136. Let me know if it helps.
>> >
>> > looks like gradle has a problem with this one as well
>> >
>> > bye Jochen
>>
>
>
Re: TeamCity back on track
Posted by Cédric Champeau <ce...@gmail.com>.
This seems to be a new error, I've never seen it before with Gradle 3.0+.
It says:
[Gradle failure report] Caused by:
java.lang.reflect.InaccessibleObjectException: Unable to make protected
java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module
java.base does not "exports private java.lang" to unnamed module @6ca18a14
[12:00:28][Gradle failure report] at
java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
[12:00:28][Gradle failure report] at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
[12:00:28][Gradle failure report] at
java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192)
[12:00:28][Gradle failure report] at
java.base/java.lang.reflect.Method.setAccessible(Method.java:186)
[12:00:28][Gradle failure report] at
org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:34)
[12:00:28][Gradle failure report] at
org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:38)
[12:00:28][Gradle failure report] at
org.gradle.internal.reflect.JavaReflectionUtil.method(JavaReflectionUtil.java:224)
[12:00:28][Gradle failure report] at
org.gradle.internal.classloader.FilteringClassLoader.<clinit>(FilteringClassLoader.java:49)
Which doesn't seem to be URLClassLoader related.
2016-09-18 13:11 GMT+02:00 Remi Forax <fo...@univ-mlv.fr>:
> Gradle thinks it can hack the classpath by seeing the application
> classloader as an URLClassLoader.
> The application classloader is now something that loads modules, so it's
> not a subclass of URLClassLoader anymore.
>
> Rémi
>
> ----- Mail original -----
> > De: "Jochen Theodorou" <bl...@gmx.org>
> > À: dev@groovy.apache.org
> > Envoyé: Dimanche 18 Septembre 2016 12:31:56
> > Objet: Re: TeamCity back on track
>
> > On 18.09.2016 10:47, Cédric Champeau wrote:
> >> I just installed Jigsaw b136. Let me know if it helps.
> >
> > looks like gradle has a problem with this one as well
> >
> > bye Jochen
>
Re: TeamCity back on track
Posted by Remi Forax <fo...@univ-mlv.fr>.
Gradle thinks it can hack the classpath by seeing the application classloader as an URLClassLoader.
The application classloader is now something that loads modules, so it's not a subclass of URLClassLoader anymore.
Rémi
----- Mail original -----
> De: "Jochen Theodorou" <bl...@gmx.org>
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 12:31:56
> Objet: Re: TeamCity back on track
> On 18.09.2016 10:47, Cédric Champeau wrote:
>> I just installed Jigsaw b136. Let me know if it helps.
>
> looks like gradle has a problem with this one as well
>
> bye Jochen
Re: TeamCity back on track
Posted by Jochen Theodorou <bl...@gmx.org>.
On 18.09.2016 10:47, C�dric Champeau wrote:
> I just installed Jigsaw b136. Let me know if it helps.
looks like gradle has a problem with this one as well
bye Jochen
Re: TeamCity back on track
Posted by Cédric Champeau <ce...@gmail.com>.
I just installed Jigsaw b136. Let me know if it helps.
2016-09-18 9:48 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:
> On 18.09.2016 06:59, John Wagenleitner wrote:
> [...]
>
>> Thanks Guillaume and Jochen. It's good to see green again. :-)
>>
>
> now only the JDK9 builds are failing. At least for one of them I know it
> is because the version of jdk9 is too old. The JDK9 snapshot is failing
> with this:
>
> [22:28:52][Step 2/3] Error occurred during initialization of VM
>> [22:28:52][Step 2/3] java.lang.ClassCastException:
>> jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base)
>> cannot be cast to java.net.URLClassLoader (in module: java.base)
>> [22:28:52][Step 2/3] at worker.org.gradle.process.inte
>> rnal.worker.child.BootstrapSecurityManager.checkPermission(B
>> ootstrapSecurityManager.java:60)
>> [22:28:52][Step 2/3] at java.lang.SecurityManager.chec
>> kPropertyAccess(java.base@9-internal/SecurityManager.java:1292)
>> [22:28:52][Step 2/3] at java.lang.System.getProperty(j
>> ava.base@9-internal/System.java:761)
>> [22:28:52][Step 2/3] at java.lang.ClassLoader.initSyst
>> emClassLoader(java.base@9-internal/ClassLoader.java:1709)
>> [22:28:52][Step 2/3] at java.lang.System.initPhase3(ja
>> va.base@9-internal/System.java:1979)
>>
>
> Which means a bug in gradle to me.
>
> bye Jochen
>
Re: TeamCity back on track
Posted by Jochen Theodorou <bl...@gmx.org>.
On 18.09.2016 06:59, John Wagenleitner wrote:
[...]
> Thanks Guillaume and Jochen. It's good to see green again. :-)
now only the JDK9 builds are failing. At least for one of them I know it
is because the version of jdk9 is too old. The JDK9 snapshot is failing
with this:
> [22:28:52][Step 2/3] Error occurred during initialization of VM
> [22:28:52][Step 2/3] java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: java.base)
> [22:28:52][Step 2/3] at worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager.checkPermission(BootstrapSecurityManager.java:60)
> [22:28:52][Step 2/3] at java.lang.SecurityManager.checkPropertyAccess(java.base@9-internal/SecurityManager.java:1292)
> [22:28:52][Step 2/3] at java.lang.System.getProperty(java.base@9-internal/System.java:761)
> [22:28:52][Step 2/3] at java.lang.ClassLoader.initSystemClassLoader(java.base@9-internal/ClassLoader.java:1709)
> [22:28:52][Step 2/3] at java.lang.System.initPhase3(java.base@9-internal/System.java:1979)
Which means a bug in gradle to me.
bye Jochen
Re: TeamCity back on track
Posted by John Wagenleitner <jo...@gmail.com>.
On Sat, Sep 17, 2016 at 9:12 AM, Guillaume Laforge <gl...@gmail.com>
wrote:
> Hi there,
>
> Quick heads-up on continuous integration on TeamCity.
>
> The builds were stuck for a while because of some Gradle bug when Gradle
> is run in parallel and corrupts the cache, or when Gradle crashes not
> cleaning caches and lock files... something along those lines. Would have
> been good to have the Gradle boys look into this probably, as there might
> be something to be fixed.
>
> Builds were failing with a message like this:
> org.gradle.cache.internal.LockTimeoutException: Timeout waiting to lock
> Plugin Resolution Cache (/var/teamcity/.gradle/caches/3.0/plugin-resolution).
> It is currently in use by another Gradle instance.
>
> I logged into the machine and wiped the caches, to clean those caches &
> locks.
> And now Jochen is launching the builds manually to see if everything comes
> back as it should.
>
> TeamCity should be fully back!
>
>
Thanks Guillaume and Jochen. It's good to see green again. :-)