Community
Participate
Working Groups
Using Eclipse 3.2/M6. Given the following Java class: public class Test { private Object getObject() { return "Hello World"; } public void foo() { Object o = getObject(); boolean legal = o != null; if (legal == false) return; String s = o.toString(); // WARNING: "The variable o may be null" System.out.println(s); } } The "Java > Compiler > Errors/Warnings" preference for "Null reference" is being somewhat over zealous, issuing the warning, "The variable o may be null". While clearly the use the word "may" indicates possibilities, it is rather unfortunate that the JDT cannot detect this usage pattern. Of course, for this simply test case it would be fine to fold the validation into the "if" statement, but for many real applications where validation is more complicated the use of temporary variables is useful. Sadly, as it works today I think many people would choose to disable this feature due to the large number of false positives.
Compared to bug 129907, this case introduces two extra difficulties: - the boolean variable legal is not final, which means that changes to its relationship to o null status should be tracked; - the expression that guards o being null is composite (even if it is a simple composite in this case). Hence the case would call for a more general variables correlation analysis than what we can do with the current technology. Not in 3.2.
Fair enough. I guess I'll either change my coding style or adust my preferences. Thanks for considering this one.
Reopening as P5 (since RESOLVED LATER is deprecated).
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 ***
