Community
Participate
Working Groups
I20070502-0010 Got this once after opening an editor on JUnit4TestListener for the first time. Could not reproduce, also not after restart. !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jdt.ui". !STACK 0 java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.LocalVariableBinding.computeUniqueKey(LocalVariableBinding.java:68) at org.eclipse.jdt.internal.compiler.lookup.Binding.computeUniqueKey(Binding.java:55) at org.eclipse.jdt.core.dom.VariableBinding.getKey(VariableBinding.java:143) at org.eclipse.jdt.core.dom.DefaultBindingResolver.resolveVariable(DefaultBindingResolver.java:1609) at org.eclipse.jdt.core.dom.VariableDeclaration.resolveBinding(VariableDeclaration.java:194) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:786) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:443) at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:179) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2661) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1248) at org.eclipse.jdt.core.dom.AST.convertCompilationUnit(AST.java:278) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:207) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:720) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:780) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1169) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:101) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:82) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.initialReconcile(JavaReconcilingStrategy.java:176) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.initialReconcile(CompositeReconcilingStrategy.java:114) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.initialReconcile(JavaCompositeReconcilingStrategy.java:122) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:103) at org.eclipse.jdt.internal.ui.text.JavaReconciler.initialProcess(JavaReconciler.java:347) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:170)
The only way to get this is to ask the key of an method argument that has no declaring scope. This would mean that the bind(..) method has never been called for it. Looking at the code I don't see obvious cause of this problem. Maybe a concurrent issue.
I got a couple of these in my log as well. On the class EclipseTestRunner. It had some errors so I clicked on the error in the Problem view and it opened the editor and put this stack in my log file.
Sorry, should have mentioned that I am using I20070503-1400.
Got a test case from DJ. Will see what I can do.
I could not reproduce it with DJ's workspace. I'll investigate oin DJ's machine tomorrow.
This happens because the project's compiler settings are using the workspace default settings (1.5 in this case since DJ runs using a 1.5 VM) and the execution environment is set to 1.4. If the workspace default JRE is a 1.4 JRE, you get a warning in the "Installed JRE" tab that says that the current JRE cannot comply with the workspace's defaults. This should actually be an error. If you have these settings and you check out "org.eclipse.test" out of CVS, you end up with a project that has a 1.4 JRE on the classpath and its compiler settings set to 1.5. This can then lead to add kind of errors like this NPE. Wassim, would it be possible that on the check out PDE is setting the project's specific compiler settings according to the Execution Environment set for the project and this even if the default JRE of the workspace matches the Execution environment used for the project? In this case, it would set the compiler settings for the project instead of keeping the workspace defaults. The user must not end up in this inconsistent environment. This is extremely error prone.
Set severity to major as this NPE is related to some inconsistencies in the project's settings that can be quite bad.
See also bug 176516 (JDT/UI: Compiler Compliance should follow Execution Environment)
Olivier, I am not sure if you are asking me a question or asking me to do something, but, in any event, here is the current behaviour: PDE does not automatically update the project's compiler settings - although Philippe wants us to start (bug 159547). The only time we play with project settings is via explicit actions: 1. PDE Tools > Update Classpath OR 2. the 'update classpath' link in the Execution Environments section on the Overview page of the plug-in manifest editor.
I think bug 159547 and bug 176516 are the keys of this issue. Even if we could protect ourselves with a null check in order not to get the NPE, we should not end up in this situation. When the user sets its execution environment (EE) to be 1.4 (and he/she is running Eclipse on a 1.5 VM), the compiler settings of the project (Java project or Plugin) must be changed to be consistent with the desired EE otherwise for sure the user will have compile errors issues or runtime issues. It doesn't make sense to allow project's compiler settings to be 1.5 (or to remain 1.5 since these are the workspace's defaults) and the EE to be set to 1.4. This is clearly not what the user wanted to do. "Update classpath" sets the compiler settings according to the EE value. This should be run if the project's compiler settings are inconsistent with its EE. And it should be run automatically. The user should not need to do it as changing the EE should have been enough. From my point of view, these two bugs are "must-fix" bugs for 3.3 or we will get lots of bug reports relative to this inconsistency.
Created attachment 66705 [details] Proposed fix Add a null check.
Jérôme, please review.
Could you please write a regression test ?
Also the null check should have a comment pointing to this bug
Created attachment 66863 [details] Updated patch with a comment
Created attachment 66864 [details] Regression test Without the patch, the NPE is thrown on the DOM/AST creation. I already released the two binaries files required for the regression test since they cannot be included in the patch.
Released for 3.3RC1. Regression test added in org.eclipse.jdt.core.tests.dom.ASTConverter15Test#test0273
Verified for 3.3 RC1 using I20070515-0010
