Community
Participate
Working Groups
The following class causes an internal compiler error to be thrown if this is the only source file in a Java project. Does not occur on 3.1.*. package nl.timeware; import static nl.timeware.SomeClass.SomeEnum.*; abstract public class SomeClass<T> extends Object { public enum SomeEnum { A; }; } Internal compiler error java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding at org.eclipse.jdt.internal.compiler.lookup.Scope.findMemberType(Scope.java:961) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2359) at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2080) at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding (SingleTypeReference.java:44) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType (TypeReference.java:153) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:110) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1084) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:804) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:929) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy (CompilationUnitScope.java:288) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings (LookupEnvironment.java:198) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile (Compiler.java:383) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:300) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:217) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:237) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:56) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:249) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:174) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Another interesting case along the same lines: package p2; import static p2.SomeClass.SomeMember.*; abstract class SomeClass<T> extends M { static class SomeMember { static class M {} } }
Released in HEAD for 3.3 M1 Added GenericTypeTest #1021
*** Bug 151410 has been marked as a duplicate of this bug. ***
Philippe, I've released the fix in R3_2_maintenance as it was really annoying for some 3.2 users (see blocker bug 151410).
Added GenericTypeTest#1021c
*** Bug 152202 has been marked as a duplicate of this bug. ***
Verified for 3.3 M1 using build I20060807-0010.
Released for 3.2.1
Why isn't the fix simply to implement #isHierarchyBeingConnected() on ParameterizedTypeBinding to do: public boolean isHierarchyBeingConnected() { return this.type.isHierarchyBeingConnected(); } This would address all references to #isHierarchyBeingConnected()
Note that fix is a change done in Scope.findMemberType(char[], ReferenceBinding). To see it, compare Scope.java version 1.279.2.2 (v_672_R32x) and 1.279.2.3 (v_673_R32x)...
There are only 2 other references to #isHierarchyBeingConnected() and neither can be to a ParameterizedType so it won't make a difference. And its not the call to isHierarchyBeingConnected() that is affected by the change, its the cast to the SourceTypeBinding on the next line that cannot take the currentType.
Ok, good then.
Verified for 3.2.1 using build M20060908-1655.