Community
Participate
Working Groups
After migrating a project to JDK 1.5, which involved introducing generics and enhanced for loops, everything compiles properly except for the class com.additifs.brac.App (see below). If I remove this class, the error occurs on the next one. If I remove all classes from this package, the error transfers to the first class encountered in a subpackage (like a breadth-first search of the package tree structure). The whole exception detail is as follows: Severity Description Resource In Folder Location Creation Time 2 Internal compiler error App.java brac25/src/com/additifs/brac line 0 22 avril 2005 22:50:41 java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.findSuperTypeErasingTo(ReferenceBinding.java:504) at org.eclipse.jdt.internal.compiler.lookup.TypeVariableBinding.boundCheck(TypeVariableBinding.java:90) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:654) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:53) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superclass(BinaryTypeBinding.java:771) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.detectHierarchyCycle(ClassScope.java:956) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.detectHierarchyCycle(ClassScope.java:918) at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:42) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:141) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:104) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1050) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:719) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:856) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:243) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:195) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:307) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:321) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:239) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:189) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:49) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:212) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:140) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:581) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1021) at org.eclipse.core.runtime.Platform.run(Platform.java:757) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:160) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:198) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:227) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1021) at org.eclipse.core.runtime.Platform.run(Platform.java:757) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:230) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:249) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:278) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:139) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:200) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:67) If you need any further information, please feel free to ask me. Thanks...
I am trying to specify 3.1M6 as the target version but the Bugzilla system does not let me do so even though I am the bug submitter. A bug in Bugzilla too?
Some classes specific to my project, generated with a code generation application, are in a Jar archive. The Jar was generated by an Ant script. If I unjar them into a source folder and remove the Jar from the build path, everything works, compiles, and executes properly. There seems to be a clue around the presence of my core files in a Jar...
Please provide steps to reproduce, then reopen.
Created attachment 20396 [details] Test case for reproducing the bug
I just attached a test case for reproducing the bug. It is an Eclipse project you just have to include into an existing workspace. It will not run since several libraries required by some JARs (e.g., Struts) are missing, but it can still compile without errors. In the project, the bugtest.jar and src2 source folder have exactly the same contents. The project is currently configured to include bugtest jar (and exclude src2 folder), which reproduces the bug. If I change it to include the non-JARred src2 folder (and exclude bugtest.jar), the bug does not occur anymore and everthing compiles correctly. By the way, bugtest.jar is a JAR I created manually with the JDK 1.5 jar utility. My previous remark about an Ant script thus does not hold anymore. The dbfw15.jar library is a database framework that makes extensive use of Generics, and bugtest.jar uses the generic classes of this library. In my original project, I saw that if I use non-generic classes in my specific classes JAR (the equivalent of bugtest.jar), even with the same Generics-based dbfw15.jar library, the bug won't occur. Several warnings will be issued, but no errors. This is why I see a clue in the combined use of Generics-based classes in JARs.
Could you please redo the attachment using standard archive file (zip or jar) ? I cannot read it.
Created attachment 20399 [details] Test case, Zip archive instead of 7-Zip Here is a Zip version. My first attachment was in 7-Zip format.
Problems come from the fact that we lazily resolve some binary parameterized type during hierarchy connecting stage. In sources, we do not perform bound checks, in binaries we do them eagerly.
My aggressive take on the problem would be: we stop checking bounds in unresolved types. These can only occur through binaries. In addition to performance gain, I wonder how invalid classfiles could be created with problem parameterized type arguments. Need to double check
Currently, our problem type creation will persist invalid parameterized types: public class X<U extends Exception> { X<String> xs; // --> X<String> } I think we should remove such signatures in this case.
Unclear how we would handle binary compatibility issues (i.e. at some point X<String> was fine, but now it isn't anymore. Binaries could surface that). Please investigate how other compilers are recovering from this.
Everything works fine with the javac compiler provided with JDK 1.5.0_02.
Removed bounds checks in binary resolve. javac does not detect binary incompatibilities which we will fix up with incremental build.
Verified in I20050510-0010
