Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: Would probably be difficult to reproduce.. the stacktrace is provided.. More information: The issue is persistent, restarting Eclipse does not help. Stacktrace: Description Resource Path Location Type Internal compiler error java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.missingTypeInMethod(ProblemReporter.java:4925) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:470) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:387) at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:882) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:444) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:191) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1096) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1184) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:535) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:743) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at java.lang.Thread.run(Unknown Source) HistoryFormPage.java com.wgo.preciseLite.ui/src/main/java/com/wgo/precise/client/ui/view/editor/history line 0 Java Problem
Looks like a dup of bug 250297. Closing as a dup of bug 250297. *** This bug has been marked as a duplicate of bug 250297 ***
The same error also occurs on Solaris 10/Sparc64/GTK, Eclipse 3.4.2, Build M20090211-1700. Is it then a duplicate?
Probably not. Reopening. A reproducable test case is required for further investigation. Do you get it when you just recompile com.wgo.preciseLite.ui/src/main/java/com/wgo/precise/client/ui/view/editor/history/HistoryFormPage.java ?
The version set for the original problem confused me. Since another issue with the same stack trace was fixed for 3.4.2, I believed this was a dup.
On WinXP (x86), M20080911-1700, 3.4.1, the NPE is the only error being reported. On Solaris10/Sparc64/GTK, M20090211-1700, 3.4.2, the NPE is one of many compiler errors, which sounds similar to bug 250297. As this is a Solaris version of M20090211-1700/3.4.2, could it be that it has older plugins of the JDT? I'll try to update Eclipse to 3.4.2 on my XP box later today and see if the problem is still present.
You can check the version of jdt/core in the about dialog>Plugins tabs. Bug 250297 is supposed to be fixed for all versions > v_925. It would be good to get a test case for further investigation.
I have now updated to latest Eclipse on my WinXP box, Ganymede SR2, 3.4.2, M20090211-1700 and the problem is still present. The version of org.eclipse.jdt.core is 3.4.4.v_894_R34x both on my WinXP and Solaris/Sparc installation. Does this mean the fix is not included for Eclipse 3.4.2 after all, or am I looking at the wrong plugin?
The fix for bug 250297 seems to be released in 3.4.2. So you might have a different problem. It is not because the stack trace is the same that the problem is the same. Would it be possible to get a test case to find out what is going on ? Without a test case, it won't be possible to investigate it.
Created attachment 129360 [details] Error log from eclipse I do not have a test case yet. The class causing the error is however printed in the log. Could this be used to reproduce it?
I'll see what I can do with the source in the .log file.
Do you have compile errors in the code?
Yes, I just managed to work around it.. I deleted the class and found compilation errors in other classes. I fixed these and restored the HistoryFormPage class, and now it works. The HistoryFormPage class used some of the other classes which had compilation errors. The compilation errors in the other classes was caused by an incorrect import statement. A class had changed its package (intentionally). This triggered the compilation errors, but when the compiler throws an NPE, instead of showing all errors, it was difficult to know. I can try to describe what I did when the dependent class changed path/package if you have difficulties reproducing the bug?
(In reply to comment #12) > The compilation errors in the other classes was caused by an incorrect import > statement. A class had changed its package (intentionally). This triggered the > compilation errors, but when the compiler throws an NPE, instead of showing all > errors, it was difficult to know. In order to reproduce it, I would need to have the same compile errors in other classes. This is why the problem occurred initially. > I can try to describe what I did when the dependent class changed path/package > if you have difficulties reproducing the bug? Please. I need exact steps to reproduce. So far, I don't get the problem. Thanks.
I need to use case that you have with all other errors as well. They are the cause of the failure in the class reported in the .log file. Please provide the test case if you want a quick fix for this issue. Thanks. Setting target milestone to 3.5M7 relying on getting the test case soon.
Removing target milestone. No test case provided so far. A workaround exists. Reducing severity. No further investigation will occur without a test case that contains all the compile errors before the workaround has been applied. If I am not aware of what errors have been fixed, there is no way I can fix this case.
To be clear, I need to know what compile errors you have in comment 12, before you fixed them by removing the class and added it back. They are the cause of the failure in the class contained in the .log file.
Petter, would it be possible to get the requested information, please ? The sooner, the better for a fix in M7.
Too late for 3.5. Might be investigated once the requested information is provided.
Closing as WORKSFORME. Please reopen if you can provide steps to reproduce this issue.
Verified for 3.6M3
