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

Bug 420691

Summary:	More flexible null analysis for fields in single threaded classes
Product:	[Eclipse Project] JDT	Reporter:	Andrew Eisenberg <andrew.eisenberg>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	stephan.herrmann
Version:	4.3.1
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X
Whiteboard:	stalebug

Description Andrew Eisenberg

2013-10-29 20:24:56 EDT

In the Bug 414191 and Bug 400420 there are descriptions of common coding patterns that are flagged by null analysis as potential problems. I do recognize that the analysis is technically correct.  However, many of the problems that it flags are based on the assumption of multi-threaded code.  Obviously, a compiler can never know whether or not code will be run in a multi-threaded environment.  However, the programmer can.  If the programmer can provide a hint to the compiler that certain blocks of code (or classes or packages) will only be single threaded, could this provide enough knowledge to the compiler to make null field analysis more intuitive?

To be a bit more concrete, consider this code from Bug 414191:

public class FieldTest {

	@Nullable
	private Object lazy;

	public Object getLazy() {
		if(lazy == null) {
			lazy = new Object();
		} else {
		  return lazy.toString(); // Potential null pointer access: The field lazy is declared as @Nullable
		}
		return lazy;
	}
}

Now, consider a ficticious annotation:

@AssumeSingleThreaded(true)
public class FieldTest {

	@Nullable
	private Object lazy;

	public Object getLazy() {
		if(lazy == null) {
			lazy = new Object();
		} else {
		  return lazy.toString();
		}
		return lazy;
	}
}

Could this be enough to ensure that the class has no warnings?

Comment 1 Stephan Herrmann

2013-10-31 19:56:32 EDT

Hi Andrew,

(seeing your example explicitly saying "lazy", may I assume you saw bug 414237?)


If we enter that realm, the question would be: how long would the knowledge from a field null-check survive?

Your examples only contain immediate usage of the knowledge, but we still shouldn't accept:
  
	public Object getLazy() {
		if(lazy == null) {
			lazy = new Object();
		} else {
		  return lazy.toString();
		}
		bar();
		return lazy;
	}
	private bar() { this.lazy = null; }

And even this is unsafe even in single threaded contexts:

	public Object getLazy() {
		if(lazy == null) {
			lazy = new Object();
		} else {
		  return lazy.toString();
		}
		other.zork.lazy = foo.bar;
		return lazy;
	}
(other.zork could point back to this, and foo.bar could be null).
	
I'm asking because I'm not sure that users will understand and accept the remaining limitations due to side effects and aliasing. In fact, the time to live of the information from a null check is not much longer than the crude compromise implemented as "syntactic null analysis for fields".

OIOW: between the existing syntactic null analysis and the proposed @LazyNonNull, would this current proposal show significant additional value not covered by the other two?

Comment 2 Stephan Herrmann

2013-10-31 19:58:44 EDT

Oops, should've put my "destructive" statements inside the else branch. Do you see what I mean?

Comment 3 Andrew Eisenberg

2013-11-01 12:05:10 EDT

One problem is that I am not exactly sure what is covered by "syntactic null analysis" and LazyNonNull. So, maybe my proposal doesn't cover much more than that, but at least the name seems more clear to me.  I'll comment on bug 414237.

ps- yes, the example was lifted directly from Bug 414191.

Comment 4 Eclipse Genie

2020-03-28 12:40:41 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.