Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 435570

Summary: [1.8][null] @NonNullByDefault illegally tries to affect "throws E"
Product: [Eclipse Project] JDT Reporter: Stephan Herrmann <stephan.herrmann>
Component: CoreAssignee: Stephan Herrmann <stephan.herrmann>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: chris, kivancmuslu, srikanth_sankaran
Version: 4.4   
Target Milestone: 4.5 M1   
Hardware: PC   
OS: Linux   
Whiteboard:
Bug Depends on:    
Bug Blocks: 438458    

Description Stephan Herrmann CLA 2014-05-22 17:25:08 EDT 
//----
@org.eclipse.jdt.annotation.NonNullByDefault
public class Test<E> {
	void test() throws E {}
}
//----

Error:

	void test() throws E {}
                           ^
Nullness annotations are not applicable at this location
Comment 1 Stephan Herrmann CLA 2014-07-16 13:25:14 EDT 
Example should be:

//----
@org.eclipse.jdt.annotation.NonNullByDefault
public class Test<E extends Exception> {
	void test() throws E {}
}
//----

Now the default clearly applies to the explicit upper bound of E.

Root cause of the bug: this analysis for illegal location of null type annotation uses information from the binding, where it should use information from the AST.
Comment 2 Stephan Herrmann CLA 2014-07-16 13:45:14 EDT 
*** Bug 437050 has been marked as a duplicate of this bug. ***
Comment 3 Stephan Herrmann CLA 2014-07-22 09:48:18 EDT 
I have a fix under test:

By providing a new TypeReference.hasNullTypeAnnotation() we can now query the AST for explicit null type annotations. In particular STB.resolveTypesFor(..) now uses this new query when analysing the method's exceptionTypes.

Other updates along the same lines:
- ReferenceExpression.lhs (if it's a TypeReference)
- AbstractMethodDeclaration.receiver
- InstanceOfExpression
- Argument (as catch argument)
Comment 5 Srikanth Sankaran CLA 2014-08-05 05:17:42 EDT 
Verified for 4.5 M1 using 
Version: Mars (4.5)
Build id: I20140804-2000