Community
Participate
Working Groups
Eclipse 200412162000 Given these 4 definitions: ======= public interface Ac<S extends St<S,A>,A extends Ac<S,A>> { }; public interface St<S extends St<S,A>,A extends Ac<S,A>> { }; final class CSN<X, Y> extends CSS<X, Y> implements Ac<CSS<X, Y>, CSN<X, Y>> {}; abstract class CSS<X, Y> implements St<CSS<X, Y>, CSN<X, Y>> {}; ======= sun's javac compiles this without error. If all 4 pieces are placed in the same file, Eclipse does NOT complain. If the 4 pieces are placed in their own individual files, Eclipse shows 2 errors: (1) In CSS.java, it says "The hierarchy of the type CSS is inconsistent" (2) In CSN.java, it says "Cycle detected: a cycle exists in the type hierarchy between CSN<X,Y> and CSS<X,Y>"
Actually javac crashes if the types are reordered slightly: interface Ac<S extends St<S,A>,A extends Ac<S,A>> { }; interface St<S extends St<S,A>,A extends Ac<S,A>> { }; abstract class CSS<X, Y> implements St<CSS<X, Y>, CSN<X, Y>> {}; final class CSN<X, Y> extends CSS<X, Y> implements Ac<CSS<X, Y>, CSN<X, Y>> {};
Now I'm up to Eclipse Build I20050111-0800. I still have the same situation as I described before. I tried a single file where CSS is defined before CSN in the same java file, I get the same "hierarchy is inconsistent error." I have reported the javac crash to Sun and it will show up as bug id 6218229. Thanks for noticing that.
This is definitely a borderline cycle case. I can argue that it is and that it isn't. Until there is a better description of what is allowed for type->type variable dependency, we'll leave our current behaviour as is.
These cycle errors were fixed with the fix for bug 96586 *** This bug has been marked as a duplicate of 96586 ***
(I'm back....) First time in a long time, I took the latest version of Eclipse Version: 3.2.0 Build id: I20051215-1506 Given the 4 definitions again: ======= public interface Ac<S extends St<S,A>,A extends Ac<S,A>> { }; public interface St<S extends St<S,A>,A extends Ac<S,A>> { }; final class CSN<X, Y> extends CSS<X, Y> implements Ac<CSS<X, Y>, CSN<X, Y>> {}; abstract class CSS<X, Y> implements St<CSS<X, Y>, CSN<X, Y>> {}; ======= If all 4 pieces are in the same file, Eclipse does not complain. If they are in their separate file, Eclipse is now displaying the error in the file CSN.java: The type CSS<X,Y> is not a valid substitute for the bounded parameter <S extends St<S,A>> of the type Ac<S,A> Now, I think the javac crash issue is STILL not resolved, but I don't think that has bearings on this error message.
Created attachment 36418 [details] Test case that displays "wrong" errors in Eclipse I get the same error in a different (and slightly more complex setting). The interesting thing is I can both crash and not crash the "javac". And even though Eclipse shows errors in the file (red lines under) it actually compiles everything just fine. I will attach the test-files, if they do not compile in Eclipse then edit the files one by one and save them (to force Eclipse to compile in some order that works). What you will notice is that Eclipse claims (in the file TestBaseAB.java) that the casts are illegal, but infact they are not). The casts to the interface TestSubI on the other hand should fail just like it does.
I forgot to explain how I crash javac with the attached example. CRASH(compile all java-files in one go): javac net/gamalocus/test/*.java NOT-CRASH(one by one compilation): find net/gamalocus/test/ | grep java$ | xargs -i javac -Xlint:unchecked {}
Created attachment 36472 [details] An other example of a super-class being ignored This example shows how Eclipse misses to see a super-class that can be found from the bound (A extends BaseA) of the generic A. Eclipse does not see that if A extends BaseA and BaseA extends BaseAB then the methods of BaseAB should also be there for A. The funny thing is that the method exist in the auto-completion-dialog, but it instantly gets a red line under it. javac is not too happe with the source, like the previous example one must compile the sourcefiles one by one, and maybe compile them a couple of times to make javac understand that there is no cycles.
Well just thought I should state that I use Eclipse 3.2 on Linux (GTK) Eclipse SDK Version: 3.2.0 Build id: I20060223-1656
A very interesting thing is that these test-cases work very well with Mustang (Java 1.6 beta). It is just not quite the same using ant as the builder, since the problems-view will not be updated accordingly. A thing I noticed is that the autocompletion can actually find inherited methods (even though the problem-view tells me about cycles and about missing inherited methods).
*** Bug 133071 has been marked as a duplicate of this bug. ***
I have also reported the bug at Sun (since JavaCompilerTool and javac cannot handle these "cyclic" references). The bug can be followed here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6404691 But with the javac and JavaCompilerTool-API one can keep trying to compile and eventually it will figure out that there is not cycle.
Well it seems to me that this bug is related to eclipse thinking that if a class has a type-parameter: class A<AA extends A, BB extends B> { } class B<AA extends A, BB extends B> { } Then A is somehow dependant on AA, and B is somehow dependant on BB, which in turn means that there exists a cycle between the pairs: A and BB, B and BB. I have tried to look though the eclipse builder but it's impossible to figure out how these dependencies are calculated. {Side-question: is this bug still being looked at ? I am aware that the bug is agains an old version of eclipse, but it remains even in the nightly builds. The reason I ask is that I will gladly stop my interest in this if I am the only one interested in this bug being killed.}
Bart, your case should be fixed. Added GenericTypeTest 967
Reopened bug 133071 to track the other case. Closing this PR as the cycle and bounds checks are fixed.
Verified for 3.2RC1 with build I20060413-1718
