Community
Participate
Working Groups
Running Eclipse build 200405140800, org.eclipse.jdt.core 3.0.0.cheetah05. The attached 6 classes fail to compile with error: Bound mismatch: The type ADXP is not a valid substitute for the bounded parameter <T extends ANY> of the type LIST<T> AD.java JavaSigBug/src/demo line 3 May 18, 2004 3:40:40 PM Under JDK 1.5.0 beta, they compile fine. Thanks.
Created attachment 10814 [details] Source code to demonstrate the problem
For convenience, here are the same 6 source files as in ZIP attachment, but in text: ----------------------------------------------- package demo; public interface ANY {} ----------------------------------------------- package demo; public interface BL extends ANY {} ----------------------------------------------- package demo; public interface LIST<T extends ANY> extends ANY {} ----------------------------------------------- package demo; public interface BIN extends LIST<BL> {} ----------------------------------------------- package demo; public interface ADXP extends BIN {} ----------------------------------------------- package demo; public interface AD extends LIST<ADXP> {} -----------------------------------------------
I am rather getting the following exception. java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.implementsInterface (ReferenceBinding.java:443) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.isCompatibleWith (ReferenceBinding.java:507) at org.eclipse.jdt.internal.compiler.lookup.TypeVariableBinding.boundCheck (TypeVariableBinding.java:54) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internal ResolveType(ParameterizedSingleTypeReference.java:117) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.resolveT ype(ParameterizedSingleTypeReference.java:157) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType (TypeReference.java:93) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype (ClassScope.java:898) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperInterfaces (ClassScope.java:679) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy (ClassScope.java:733) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierar chy(CompilationUnitScope.java:236) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings (LookupEnvironment.java:177) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile (Compiler.java:305) at org.eclipse.jdt.internal.compiler.Compiler.compile (Compiler.java:319) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile (AbstractImageBuilder.java:209) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile (AbstractImageBuilder.java:159) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build (IncrementalImageBuilder.java:113) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas (JavaBuilder.java:223) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build (JavaBuilder.java:151) at org.eclipse.core.internal.events.BuildManager$2.run (BuildManager.java:532) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:608) at org.eclipse.core.runtime.Platform.run(Platform.java:758) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:148) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:225) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:178) at org.eclipse.core.internal.events.BuildManager$1.run (BuildManager.java:205) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:608) at org.eclipse.core.runtime.Platform.run(Platform.java:758) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:208) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:244) at org.eclipse.core.internal.events.BuildManager.build (BuildManager.java:273) at org.eclipse.core.internal.resources.Workspace.build (Workspace.java:198) at org.eclipse.ui.actions.GlobalBuildAction$1.run (GlobalBuildAction.java:182) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:66) It occurs due to the fact that a bound check is performed as part of supertype resolution.
Looks like supertype resolution shouldn't eagerly do the bound check, and should check it after the fact. Regression test added: GenericTypeTes#test203
Right, I was intermittently getting that NullPointerException as well. It would disappear if I moved ANY.java to a different package, refreshed the project, then moved it back and refreshed again. Then the exception I mentioned originally (Bound mismatch) would appear. Thanks.
Re: comment#4. I investigated deferring the bound check for supertype references, but this is quite tricky, because need to handle qualified parameterized types which would need to re-process them entirely after the fact. I now rather think all the supertype hierarchies (for types and for the variables) should be bound at the same time, which would require to intertwin these even more.
Is there a workaround availible?
Kinda. Modify/save classes that have compile errors. This will make eclipse recompile just these classes while using existing definition of their parents.
Hmmmm. I've tried every modification I can think of. I have 2 classes: public class ConstrainedProperty<T extends ConstrainedProperty> public class Validation<C extends ConstrainedProperty> and the error I get is: Bound mismatch: The type C is not a valid substitute for the bounded parameter <T extends ConstrainedProperty> of the type Constrained<T>
Don't know if I've changed something or something has changed in latest cheetahs, but my "workaround" does not work any more. Can't do anything until there is a fix or workaround for this bug :-(
We're working on it. It would help (if you have not already), if you could paste in your testcase... to make sure we fix all the cases & not just one. This problem is very order dependent. Some of the testcases in this PR compile fine if the classes are compiled in a different order.
Created attachment 12912 [details] tree.zip Attached *zip* file contains six classes that demonstrate "my" instance of the problem. AbstractList<ListItem> does not compile if I do full rebuild of the project. The problem seems to be triggered by presence of two subclasses of AbstractList<ListItem> (OrderedList and ItemizedList). Everything compiles fine if I delete either of the two subclasses. PS: as a very ugly workaround I hacked the compiler to report all bound mismatch problems (including legitimate ones) as warnings.
*** Bug 64467 has been marked as a duplicate of this bug. ***
*** Bug 65523 has been marked as a duplicate of this bug. ***
*** Bug 69195 has been marked as a duplicate of this bug. ***
Fixed in HEAD. test203
I still have exactly the same behavoir as described in "duplicated?" bug 64467, with exactly the same stack trace as in comment#3. Tested with latest sources from HEAD at 30.07.2004. Who can reopen this bug or may be bug 64467? Thanks, Andrei.
Andrei, please paste in the source for your testcase... preferably in its simplest form that shows the problem.
Created attachment 13803 [details] Test case for bugs 62822 / 64467 To Kent - her it comes - as described earlier, the same error with latest sources from HEAD (tested against revision from 06.08.2004). Committed testcase is a small part of "FindBugs" framework. Small part of trace: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.implementsInterface(ReferenceBinding.java:446) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.isCompatibleWith(ReferenceBinding.java:510) at org.eclipse.jdt.internal.compiler.lookup.TypeVariableBinding.boundCheck(TypeVariableBinding.java:56) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internalResolveType(ParameterizedSingleTypeReference.java:144)
Added additional tests 280-283 for this last case & released fixes into HEAD.
Verified in I200409212000.
