Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.4
-
Fix Version/s: 1.8.5, 2.0-beta-2, 1.7.11
-
Component/s: None
-
Labels:None
-
Environment:OS X (suspected all)
-
Number of attachments :
Description
The following code shows a static field on an interface not initialized at the point when the constructor of an instance of an implementing class is being run.
package ignored.alex.failingcallsite import java.lang.reflect.Field; class FailingCallSiteLocalClass { public static void main(String[] args) { new B() } } interface A { public static X x = new X() { public void foo() {} } } interface X { void foo() } class B implements A { public B() { for (Field f in getClass().getFields()) { println f println f.get(this) } } }
Throws java.lang.IllegalAccessError when x is accessed via f.get(this).
I would expect x to have been initialized by this point. Is there something subtle in when interfaces are initialized?
There is no problem if A is a class extended by B, and more curiously, no problem if x is set equal to a named outer class (e.g. a class X2 implements X).
Activity
Analogous code in Java is fine, happily prints:
public static final ignored.alex.failingcallsite.poj.X ignored.alex.failingcallsite.poj.A.x ignored.alex.failingcallsite.poj.A$1@593d93f4
So suspect you're right, something different in how the OSX JVM does things. 
That puzzles me. I don't understand. The last error you show is the one fixed in the lastest master commit... I tried many JDKs, even managed to test on a JDK 1.5 Apple JDK, but none showed that IAE error 
Ah, all good.
Latest commit 2151e717653113c24f4c1f3e48c4960ee67d01c5 fixes it, it just wasn't in github when I pulled. Maybe some delay before things are shown in the mirror? Sorry for the noise.
FWIW the patch you sent me for AsmClassGenerator (replacing ACC_SUPER with ACC_PUBLIC|ACC_STATIC) makes no apparent difference.
Yep. 
All errors are gone – IAE for $..class, IAE for call site, duplicate class, missing constructor. Have tried several of the failure cases I had, and all are now happy. Strange that it would manifest itself in so many different ways, but all good now.
I have seen various stack traces as I've tested it in various places.
Firstly, in some instances it complains that the constructor A$1(java.lang.Class) cannot be accessed, which makes me suspect inner class issues (e.g.
GROOVY-5109) may be related.Running from the command-line shows the smaller trace:
Finally, it might be useful to note that although this test case fails on all versions tested (1.7.2 through 1.8.4, and 2.0.0-beta1), it was extracted from a more complicated scenario which only started failing in 1.8.2 – was working for many months against 1.8.0-03.