Re: TeamCity back on track

[Guillaume Laforge]

Ok, thanks for confirming this.

On Sun, Sep 18, 2016 at 8:18 PM, Remi Forax  wrote:

>
>
> --
>
> *De: *"Guillaume Laforge" 
> *À: *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  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" 
>> > À: 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+
> 
>
>


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

[Guillaume Laforge]

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  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" 
> > À: 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

[Remi Forax]

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" 
> À: 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)
 [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 

Re: TeamCity back on track

[Remi Forax]

> De: "Cédric Champeau" 
> À: 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: Latest documentation not showing up

[Guillaume Laforge]

Oh nice find!
Thanks!

On Sun, Sep 18, 2016 at 2:24 PM, Cédric Champeau 
wrote:

> Fixed. The CI build that explodes the documentation was still looking for
> "groovy-docs.zip" instead of "apache-groovy-docs.zip".
>
>
> 2016-09-18 14:19 GMT+02:00 Guillaume Laforge :
>
>> Hi,
>>
>> Any idea why the "latest" documentation online:
>> http://docs.groovy-lang.org/docs/next/html/documentation/
>>
>> isn't showing up the latest bits of doc, for instance the @AutoImplement
>> transformation is not displayed, although it's indeed in master.
>>
>> And when I generate it locally, it's indeed there.
>>
>> Guillaume
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge  / Google+
>> 
>>
>
>


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

[Cédric Champeau]

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 :

> 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" 
> > À: 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

[Remi Forax]

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" 
> À: 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

[Jochen Theodorou]

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

[Jochen Theodorou]

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