Re: TeamCity back on track
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
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
- Mail original - > De: "Jochen Theodorou" <blackd...@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
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 <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.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
Ok, thanks for confirming this. On Sun, Sep 18, 2016 at 8:18 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > > -- > > *De: *"Guillaume Laforge" <glafo...@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" <blackd...@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
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" <blackd...@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
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" <cedric.champ...@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 < fo...@univ-mlv.fr > : >>> 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.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.champ...@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.(JavaMethod.java:34) >>>> [1
Re: TeamCity back on track
> 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.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.champ...@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.(JavaMethod.java:34) >> [12:00:28][Gradle failure report] at >> org.gradle.internal.reflect.JavaMethod.(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.(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" < blackd...@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
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.(JavaMethod.java:34) [12:00:28][Gradle failure report] at org.gradle.internal.reflect.JavaMethod.(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.(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" <blackd...@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
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" <blackd...@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
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
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
