Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » Null analysis - unexpected warnings on final field
Null analysis - unexpected warnings on final field [message #1050677] Sat, 27 April 2013 15:18 Go to next message
Tom van den Bege is currently offline Tom van den BegeFriend
Messages: 9
Registered: July 2009
Junior Member
I have enabled annotation-based null analysis, and installed the experimental null annotations for fields.

public final class MyClass {
	private final String foo;
	
	public MyClass(@NonNull String bar) {
		foo = bar;
	}
	
 	public final @NonNull String getFoo() {
		return foo;
	}
}


I'm getting a compiler warning on "return foo": unchecked conversion to conform to @NonNull String.

The documentation of the experimental null annotations for fields states Quote:
Any final field that is directly initialized to a value that is statically known to be non-null is considered as effectively non-null, even if no @NonNull annotation is attached.


This is interpreted by me as it would specifically prevent the above warning. Is there a specific reason why this warning is generated?


Re: Null analysis - unexpected warnings on final field [message #1050812 is a reply to message #1050677] Sat, 27 April 2013 20:10 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1034
Registered: July 2009
Senior Member
I'm sorry, the documentation is actually out-dated in this regard.

We had significant amount of discussion in and around https://bugs.eclipse.org/237236.
A specific eye-opener for me was the example in https://bugs.eclipse.org/370787#c3 which shows that Java's concept of flow analysis for final fields is incomplete: it is possible to write legal Java code that would access a final field before its initialization. Using the same flow analysis to determine non-null fields would have the same flaw, which doesn't sound like a very compelling story to me.

Another difficulty is the necessity of merging analysis results from *all* constructors of a class.

We concluded that for the time being it's far easier to explicitly mark those fields as @NonNull rather than hoping the compiler could figure this out automatically.

Thanks for bringing this up, I've made a note in the wiki page.
Stephan
Previous Topic: database code& console
Next Topic:Cup/ lex Extension
Goto Forum:
  


Current Time: Mon Nov 24 07:02:31 GMT 2014

Powered by FUDForum. Page generated in 0.16980 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software