Community
Participate
Working Groups
Build ID: 3.4.1 Build id: M20080911-1700 This code doesn't compile (OK!) in Eclipse (both 1.5/1.6 compilance level), javac 1.5 and javac 1.6: enum BadEnum { CRAZY(CRAZY); // <-- illegal forward reference reported by all compilers final BadEnum self; private BadEnum(BadEnum self) { this.self = self; } } This is expected behavior. However, the code below compiles in Eclipse(both 1.5/1.6 compilance level) and javac 1.5, but NOT in javac 1.6: enum Impossible { CRAZY(Impossible.CRAZY); // <-- illegal forward reference (javac 1.6 only) final Impossible self; private Impossible(Impossible self) { this.self = self; } } I guess this is a bug in both Eclipse and javac 1.5 compilers, which is fixed only in javac 1.6.
I kind of remember that qualified access was ok, since it would pick a default value if unitialized. Need to check. >I guess this is a bug in both Eclipse and javac 1.5 compilers, which is fixed only in javac 1.6. Did you find a bug reference, this might help in decision.
Indeed enums are a bit special. Similar offending code is tolerated for classes: enum BadEnum { CRAZY(CRAZY), // <-- illegal forward reference reported by all compilers IMPOSSIBLE(BadEnum.IMPOSSIBLE); // <-- illegal forward reference (javac 1.6 only) private BadEnum(BadEnum self) { } } public class X { X x1 = new X(x1);//1 - WRONG static X X2 = new X(X.X2);//2 - OK X x3 = new X(this.x3);//3 - OK X(X x) { } } class Y extends X { X x1 = new X(x1);//4 - WRONG static X X2 = new X(Y.X2);//5 - OK X x3 = new X(this.x3);//6 - OK Y(Y y) { super(y); } }
I guess it can be http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6424491 but I don't know sure. I've just found a bug in my code, wondered why it is not rejected by compiler (final enum value will be null with the "bad" code, which is clearly not intendend to be), then I've compared different compilers and saw that sun's 1.6 javac does it "the right way" I would expect as a user, but Eclipse doesn't. Because both 1.5 javac and Eclipse does the "wrong thing", I've marked this as a [1.6] level issue (to keep ECJ compatibility with 1.5 javac).
Created attachment 118059 [details] Proposed patch
The fix is also enabled in 1.5 compliant mode, since this is just a plain bug, which they only addressed from 1.6 on.
Created attachment 118188 [details] Better patch
Released for 3.5M4. Fixed
Created attachment 118206 [details] Proposed patch for 3.4
Candidating for 3.4.2. Symptoms are bad. We incorrectly accept invalid code, and the fix is quite simple (need one more check for subsequent bindings in qualified name reference). The patch also improves slightly the error message error position (on the offending portion of the qualified name).
Naive question: is there a risk that fieldBinding.original().declaringClass can be null?
If we hadn't resolved the fieldBinding we would have bailed out before that point.
+1 for 3.4.2
Verified for 3.5M4 using I20081209-0100
Verified for 3.4.2 using M20090127-1710
*** Bug 265307 has been marked as a duplicate of this bug. ***
*** Bug 275736 has been marked as a duplicate of this bug. ***
