Community
Participate
Working Groups
Eclipse is marking a number of classes (all derived in a chain) by underlining the class name in red. On MouseOver the box reads "The hierarchy or type XXX is inconsistent" (where XXX is the class). However the classes themselves are not marked in the package explorer (no red x's on the classes or the packages). Further the classes seem to work fine. I have no idea what is causing the error message but either eclipse is in error or the message should really be a warning (since the .java files still compile). This behavior has been observered on Mac OS and Windows (I can't comment on the other platforms).
Can you provide a testcase which would reproduce this ?
Thank you for your quick response (and sorry for my slow response - its been a bad week). Unfortunately, are code base is quite large and we are not ready to release it (although we do plan on open sourcing it when we are done). Can you tell me what the error is supposed to mean? (ie when the error is supposed to be generated?) Maybe I can try to replicate the error after knowing what is supposed to be happening and looking at our code.
Inconsistent hierarchies are diagnosed when some superclass/superinterface links are not resolvable. Could be a classpath problem ?
Hmm. Currently the class that exhibits this problem is in the same package as its parent. If I put the class in another package and import the origional package the problem disappears. I still can't figure out what it is about this class in particular that is cuasing the problem (but I'm looking).
Could you attach this testcase for investigation ?
Any chance one of the supertypes is a secondary type? ie. is it a non-public type B defined in another file A.java such as: p1/A.java package p1; class B {} If so try moving the type B to its own file named p1/B.java.
>Any chance one of the supertypes is a secondary type? Unfortunatly not. I've been trying to replicate the problem in simpler code but I can't seem to do it. The classes look like this. package p1 public abstract class A package p2 public interface B
I'm not sure why but my submission was cut off. Here is the rest of the the classes. package P1 imports P2.* public class C extends a implements b package P1 public class D extends C "D" is the one that gets underlined in red and the error message. When I've replicated the sturcture I don't get any error message. I've been trying to find the root by removing methods from our code but I havne't been able to figure it out yet.
So how many types are there in the problematic hierarchy? Are there any secondary types or member types in the hierarchy? Are all the types public & located in their own files? If you copy the types into a separate project (in the same source folders, packages, files), is the problem reproduceable?
Eitan: Can you provide any other info?
Please reopen when you can provide more information.
I'm still trying to replicate the problem on something other than our entire code base. Thanks for your contimuned interest/atttention.
Ok, I figured it out -FINALLY. The problem arises when a class uses a derived class internally. It sounds fishy but it is allowed by Java (at least it compiles and runs) Eclipse underlines any derived class in red (but doesn't mark the class with a "x") Here is a code snippet that replicates the problem. Class B is the one with the erroneous red underline. --- public class ClassA { public ClassA() { } private class ClassC extends ClassB { } } public class ClassB extends ClassA { public ClassB(){} }
Found the problem... thanks Eitan. Here's a stack trace: Thread [org.eclipse.jdt.internal.ui.text.JavaReconciler] (Suspended (breakpoint at line 221 in LookupEnvironment)) LookupEnvironment.completeTypeBindings(CompilationUnitDeclaration, boolean) line: 221 CompilationUnitProblemFinder.accept(ISourceType[], PackageBinding) line: 109 LookupEnvironment.askForType(PackageBinding, char[]) line: 106 PackageBinding.getTypeOrPackage(char[]) line: 173 CompilationUnitScope(Scope).getTypeOrPackage(char[], int) line: 1321 ClassScope.findSupertype(TypeReference) line: 789 ClassScope.connectSuperclass() line: 582 ClassScope.connectTypeHierarchy() line: 675 CompilationUnitScope.connectTypeHierarchy() line: 252 LookupEnvironment.completeTypeBindings() line: 170 CompilationUnitProblemFinder(Compiler).resolve(CompilationUnitDeclaration, ICompilationUnit, boolean, boolean, boolean) line: 583 CompilationUnitProblemFinder.process(CompilationUnitDeclaration, ICompilationUnit, IProblemRequestor, IProgressMonitor) line: 219 WorkingCopy.generateInfos(OpenableElementInfo, IProgressMonitor, Map, IResource) line: 174 LookupEnvironment.completeTypeBindings(CompilationUnitDeclaration, boolean) is being called when it shouldn't... this is the method comment: /* * Used by other compiler tools which do not start by calling completeTypeBindings(). * * 1. Connect the type hierarchy for the type bindings created for parsedUnits. * 2. Create the field bindings * 3. Create the method bindings */ We end up trying to connect the hierarchy of type A & as a result its member type C WHILE we are in the middle of connecting the hierarchy of type B. This does not happen during a normal compile loop since we do not connect the member types of type A until type B is finished. CompilationUnitProblemFinder.accept should instead call LookupEnvironment.completeTypeBindings(CompilationUnitDeclaration parsedUnit) since CompilationUnitProblemFinder.process calls LookupEnvironment.completeTypeBindings(). I released this change. There are 15 other senders that should be double checked to see if they're also 'broken' (such as the MatchLocator)... moving to Jerome.
This was taken care of a while ago.
Verified.
