Bugzilla – Full Text Bug Listing
| Summary: | [null][correlation] Invalid 'Potential null pointer access: The variable bar may be null at this location' | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Etienne Reichenbach <etienner> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | garydgregory, sebastian.zarnekow, shankhba, stephan.herrmann |
| Version: | 4.2.1 | Keywords: | helpwanted |
| Target Milestone: | 4.7 M1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
1 I get a false "Potential null pointer access":
2
3 private void foo(boolean bool) {
4 Integer bar= null;
5 if (bool) {
6 bar= bar(); // just a method returning an Integer
7 if (bar == null) {
8 return;
9 }
10 }
11
12 if (bool) {
13 System.out.println(bar.byteValue());
14 }
15
16
17 }
The warning is at line 13...
I understand your surprise, but the observed behavior is actually as I'd expect:
First, in the general case where there could be more statements between the two
if-statements - the value of bool could change from false to true, which means
we could enter the second then-branch without touching the first then-branch,
thus seeing bar in its initial state being null. -> To see that bar cannot be null
the compiler would need to know that bool doesn't change its value between the
two ifs. However, we have no analysis for this (unless you'd declare bool as final).
Second, and more importantly, the compiler has no capabilities to do correlation
analysis, but that's what we'd need here: to work with the knowledge that
*if* bool is true *then* bar is not-null
By contrast we only see that bar is not-null on one branch and null on the other, but
in line 12 we no longer know about the conditions leading to one branch or the other.
-> I'll mark this bug with [correlation] in case some time in the future somebody
is going to work on such correlation analysis. Until then there's nothing we can do.
However, for now I suggest you add just one line before line 13 to tell the compiler
what you found out by careful (human) analysis:
assert bar != null;
For this to have an effect please enable the option
"Include 'assert' in null analysis"
With this the compiler can leverage your insights and continue from there without
giving the warning you know to be useless.
Stefan, you mean the value of the parameter 'bool' changes without an assignment in the method? (In reply to comment #3) > Stefan, you mean the value of the parameter 'bool' changes without an > assignment in the method? I certainly didn't mean that :) (In reply to comment #2) > First, in the general case where there could be more statements between the > two if-statements - the value of bool could change from false to true Anything unclear? For non-final variables the analysis simply has no notion of "var x has not changes since statement y", hence the two evaluations of 'bool' don't indicate identical values - to the null analysis. Thanks for the answer Stephan. Looking forward that someone implements the correlation analysis :-) Meanwhile I'm totally happy with the assert workaround. To people wondering how to enable the "Include 'assert' in null analysis": go to Preferences->Java->Compiler->Error/Warnings there you find the "Include 'assert' in null analysis" checkbox IMO, this should be fixed since all vars involved are final:
1 private void test(final String s) {
2 final boolean b = s != null;
3 final int x = b ? s.length() : 22;
// ...
}
Warning in line 3: Potential null pointer access: The variable s may be null at this location.
But s CANNOT be assigned at all.
I am on 4.5.1 BTW. (In reply to Gary D. Gregory from comment #6) > IMO, this should be fixed since all vars involved are final: Feel free to propose a patch. For fairness: the reason why we have implemented no correlation analysis is: complexity. So far we have no infrastructure for any of this. To make things worse: any infrastructure for correlation analysis would have to be integrated with a pretty tricky encoding of null-related flow information. I'd be happy to give some initial pointers, though, if someone would like to experiment towards this enhancement. Bulk closing all compiler bugs tagged [null][correlation], because we have no plans to add such a feature: it would be a tremendous implementation effort, beyond our current man power, and may be impossible to achieve within the desired performance bounds. If s.o. has a viable strategy or even implementation for such a feature, I'm all ears. Verified for 4.7 M1. I created a new umbrella RFE outlining what would be needed to address this issue. *** This bug has been marked as a duplicate of bug 538421 *** |
I get a false "Potential null pointer access": private void foo(boolean bool) { Integer bar= null; if (bool) { bar= bar(); // just a method returning an Integer if (bar == null) { return; } } if (bool) { System.out.println(bar.byteValue()); } }