Community
Participate
Working Groups
I'm seeing the following NPE in some cases in the 2.0 compiler. It only occurs in a few scenarios, but in those cases it is reproducible (ie, it is not timing related). We are going to need to get a patch for this, if there's anything we can try in the short term then please provide any suggestions. at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java (Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:917) at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding (SingleTypeReference.java:39) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType (TypeReference.java:91) at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve (LocalDeclaration.java:134) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatement s(AbstractMethodDeclaration.java:332) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements (MethodDeclaration.java:68) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve (AbstractMethodDeclaration.java:321) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve (TypeDeclaration.java:908) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve (TypeDeclaration.java:940) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve (CompilationUnitDeclaration.java:235) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:533) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:337) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile (AbstractImageBuilder.java:219) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile (AbstractImageBuilder.java:166) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build (BatchImageBuilder.java:50) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll (JavaBuilder.java:170) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:99) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:392) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:831) at org.eclipse.core.runtime.Platform.run(Platform.java:416) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:120) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:176) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:186) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:146) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:831) at org.eclipse.core.runtime.Platform.run(Platform.java:416) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:160) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:232) at org.eclipse.core.internal.resources.Project.build(Project.java:85) at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.buildProject (BatchExtension.java:526) at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.internalJarProcess (BatchExtension.java:473) at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.runJarDeploy (BatchExtension.java:387) at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.access$100 (BatchExtension.java:102) at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension$RunDeploy.run (BatchExtension.java:232) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1361) at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension$RunDeploy.execute (BatchExtension.java:214) at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.run (BatchExtension.java:177) at com.ibm.etools.ejbdeploy.batch.impl.BatchDeploy.execute(BatchDeploy.java:141) at com.ibm.etools.ejbdeploy.EJBDeploy.execute(EJBDeploy.java:86) at com.ibm.etools.ejbdeploy.EJBDeploy.main(EJBDeploy.java:313)
Sorry, missed the top line - the problem is an NPE java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getType (Scope.java:917) at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding (SingleTypeReference.java:39) ...
Do you have a testcase for reproducing it ?
I spent some time investigating this further, trying to get more details and build a testcase... and I've now come to the conclulsion that it's actually a JDK defect. I won't go through all the details here, but you can close this report, I'll be following up with the JDK team.
Do you mean that some invalid classfiles got compiled against ? Even then, our compiler should not crash like this. Whatever evil code we compile we must behave and trap errors. There has been a number of occasions where we had to be resilient to bogus classfiles appearing in class libraries (from JDKs). In particular, there were cases where the innerclass attributes were completely wrong according to specs, but we have to behave anyway instead of crashing. So I would still like a test case to add protection to our compiler.
I like the principle behind that answer :-) However, in this case, I think there's really nothing you can do. The problem now appears to be not just JDK, but JIT related - and it's an error in the JVM at runtime, it's not just bad input. I don't think it's realistic for you to try and build protection against JIT defects.
Oh I see. I thought this was due to compiling against a bogus JDK class library. Sorry for the confusion, as you said there is little we can do against hostile VMs... Closing.
