Community
Participate
Working Groups
I20100520-1744 1. Enable potential null pointer access compiler warning 2. Given public void test() { Object a= foo() ? null : new Object(); Object b= foo() ? null : new Object(); if (a == null && b == null) { System.out.println("Both are null"); } else if (a != null && b != null) { System.out.println(a.toString() + b.toString()); } else if (a != null) { System.out.println(a.toString()); } else { System.out.println(b.toString()); } } private boolean foo() { return false; } IS: The compiler marks the b in b.toString in the last else clause as potential null pointer access SHOULD: I'm pretty sure b can not be null there, the compiler should report a problem there. Yes, it is not the best code in the world but I think it is not uncommon to write something like this.
I mean of course: SHOULD: I'm pretty sure b can not be null there, the compiler should _NOT_ report a problem there.
(In reply to comment #1) > I mean of course: > SHOULD: I'm pretty sure b can not be null there, the compiler should _NOT_ > report a problem there. This is a part of correlation analysis which we dont currently support. You know that b cannot be null because its nullness is related to that of 'a' here because of the first if clause. So, since in the last else clause a will always be null, and because of the first if clause we know that a and b cant be together null in the last clause. I'll investigate.
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 ***