Community
Participate
Working Groups
Just synchronized my workspace when this happend. Besides the error in the log, there is a compile error in org.eclipse.rap.examples.pages.Elements in line 0 telling me the same. -- Error Details -- Date: Wed Sep 01 03:26:24 CEST 2010 Message: Errors running builder 'Java Builder' on project 'org.eclipse.rap.examples.pages'. Severity: Error Product: Eclipse SDK 3.7.0.v201008262000 (org.eclipse.sdk.ide) Plugin: org.eclipse.jdt.core Session Data: eclipse.buildId=N20100826-2000 java.version=1.6.0_20 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Framework arguments: -server -showLocation Command-line arguments: -os linux -ws gtk -arch x86 -server -showLocation Exception Stack Trace: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.flow.FlowContext.checkExceptionHandlers(FlowContext.java:152) at org.eclipse.jdt.internal.compiler.flow.InitializationFlowContext.checkInitializerExceptions(InitializationFlowContext.java:46) at org.eclipse.jdt.internal.compiler.ast.Clinit.analyseCode(Clinit.java:81) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.internalAnalyseCode(TypeDeclaration.java:687) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.analyseCode(TypeDeclaration.java:253) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.analyseCode(CompilationUnitDeclaration.java:111) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:765) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at java.lang.Thread.run(Thread.java:619)
Created attachment 177903 [details] project Attached the project in question
This is a consequence of the fix for bug 321926. Ayushman, please follow up.
Created attachment 177905 [details] Simplified test case
Created attachment 177909 [details] Untested patch Some parameters that are irrelevant to org.eclipse.jdt.internal.compiler.flow.ExceptionHandlingFlowContext.recordHandlingException(ReferenceBinding, UnconditionalFlowInfo, TypeBinding, ASTNode, boolean) are relevant to org.eclipse.jdt.internal.compiler.flow.InitializationFlowContext.recordHandlingException(ReferenceBinding, UnconditionalFlowInfo, TypeBinding, ASTNode, boolean) It is really the former call that we care about, but it was an oversight to not have recognized that calls can dispatch to the latter. It also errorneous to call the latter in the loop back context as this can double report problems with unhandled exceptions. Ayush, this patch is not tested and can be cleaner perhaps. Please take a look.
Smaller test case: import java.io.*; public class X { static { try { while(true) { if (true) throw new NumberFormatException(); else throw new IOException(); } } catch(IOException e ) { // empty } } }
Created attachment 177930 [details] Cleaner patch + junit - under test
As an aside, it looks a bit odd that InitializationFlowContext extends ExceptionHandlingFlowContext - I am not sure there isn't an abstraction problem here -- Ignoring this issue for now.
All tests pass, Ayush, please review. TIA.
Created attachment 177955 [details] Much simpler patch - under test A much simpler patch per Ayush's suggestion. We discussed the earlier patch and while it concluded it would work properly, we also felt it is needlessly complicated. Since all we want to do is to update the entry flow information for catch blocks to reflect the flow data at the end of the loop, we need to record only those exceptions that have a catch block - this simply eliminates the calls to org.eclipse.jdt.internal.compiler.flow.InitializationFlowContext.recordHandlingException(ReferenceBinding, UnconditionalFlowInfo, TypeBinding, ASTNode, boolean) from ever happening again eliminating the possibility of the NPE.
(In reply to comment #9) > Created an attachment (id=177955) [details] > Much simpler patch - under test All tests pass. Ayush please take a look.
Looks good.
Released in HEAD for 3.7 M2. Olivier, the patch is extremely simple, if we have a chance, we should deliver this for 3.6.1, do you agree ?
(In reply to comment #12) > Released in HEAD for 3.7 M2. > Olivier, the patch is extremely simple, if we have a chance, we should > deliver this for 3.6.1, do you agree ? We have no choice as this is a regression over 3.6. The fix for 321926 created this problem and since this fix is in 3.6.1 we also must release this one to get back to normal. Daniel, we need PMC approval. This is the NPE I was referring to at the arch call this morning.
>We have no choice as this is a regression over 3.6. I agree, this is a must fix. +1 for 3.6.1 RC3.
Reopen to close as RESOLVED for 3.6.1.
Released for 3.6.1. Same patch.
Verified for 3.6.1 using build M20100901-1310.
Thanks guys!
Verified for 3.7M2 using I20100914-0100
