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
Email with No Subject
unsubscribe This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
unsubscribe
unsubscribe
Re: TeamCity back on track
- Mail original - > De: "Jochen Theodorou" > À: 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 : > On 18.09.2016 15:03, Remi Forax wrote: > >> >> >> >> >> *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.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 > >
dispatched can't find a method, offers the very same one?!?
Hello there,
does anybody understand how the following code:
===
package cz.ocs.model
class DatabaseContextDelegate extends ERXDatabaseContextDelegate {
NSDictionary databaseContextShouldUpdateCurrentSnapshot(EODatabaseContext
dbCtxt, NSDictionary dic, NSDictionary dic2, EOGlobalID gid, EODatabaseChannel
dbChannel) {
for (def cl=dic.getClass();cl;cl=cl.getSuperclass()) println "DIC
inheritance: $cl"
for (def cl=gid.getClass();cl;cl=cl.getSuperclass()) println "GID
inheritance: $cl"
def
nd=super.databaseContextShouldUpdateCurrentSnapshot(dbCtxt,dic,dic2,gid,dbChannel)
// this is line 57
...
===
could yield the result of
===
DIC inheritance: class com.webobjects.eocontrol._EOMutableKnownKeyDictionary
DIC inheritance: class com.webobjects.foundation.NSMutableDictionary
DIC inheritance: class com.webobjects.foundation.NSDictionary
DIC inheritance: class java.lang.Object
GID inheritance: class com.webobjects.eocontrol._EOIntegralKeyGlobalID
GID inheritance: class com.webobjects.eocontrol.EOKeyGlobalID
GID inheritance: class com.webobjects.eocontrol.EOGlobalID
GID inheritance: class java.lang.Object
groovy.lang.MissingMethodException: No signature of method:
cz.ocs.model.DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot()
is applicable for argument types: (com.webobjects.eoaccess.EODatabaseContext,
com.webobjects.eocontrol._EOMutableKnownKeyDictionary,
com.webobjects.eocontrol._EOMutableKnownKeyDictionary,
com.webobjects.eocontrol._EOIntegralKeyGlobalID,
com.webobjects.eoaccess.EODatabaseChannel) values:
[com.webobjects.eoaccess.EODatabaseContext@22680f52,
[creator_id:, ...], ...]
Possible solutions:
databaseContextShouldUpdateCurrentSnapshot(com.webobjects.eoaccess.EODatabaseContext,
com.webobjects.foundation.NSDictionary,
com.webobjects.foundation.NSDictionary, com.webobjects.eocontrol.EOGlobalID,
com.webobjects.eoaccess.EODatabaseChannel)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:58)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:134)
at
cz.ocs.model.DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot(DatabaseContextDelegate.groovy:57)
...
===
? I must say I am sort of outta ideas, for
(a) I can't see why no signature of
“cz.ocs.model.DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot”
-- it should be searched for in the superclass (“ERXDatabaseContextDelegate”),
should it not?
(b) how on earth can it complain that the method does not exist and at the same
moment as a possible solution offer it, with a proper signature (this is why I
log out those inheritances to be sure)?
Thanks,
OC
