Community
Participate
Working Groups
import org.eclipse.jdt.annotation.Nullable; public class NullAnnotationTestCase { void case2(@Nullable String license) { boolean haveLicense = (license != null && !license.isEmpty()); if (haveLicense) { license.toString(); } } } Now, the line inside the if results in warning "Potential null pointer access: The variable license may be null at this location". Expected result: no warning. In this form the logic is the same, but the error message goes away: void case2(@Nullable String license) { if ((license != null && !license.isEmpty())) { license.toString(); } } Unfortunately in our case the code needs the boolean variable elsewhere, too, so it's not practical to refactor all the conditions straight to the if statements.
A slightly different case, but I think it boils down to the same problem: Produces warning: void case3(@Nullable Date date, List<String> strings) { for (String string : strings) { boolean dateOk = (date != null); if (!dateOk) { continue; } date.toString(); } } Again, if I embed the condition to the if statement, the problem goes away: void case3(@Nullable Date date, List<String> strings) { for (String string : strings) { if (!(date != null)) { continue; } date.toString(); } }
This RFE is a member of a group of existing requests marked as [correlation]: https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=[correlation]&classification=Eclipse&query_format=advanced&short_desc_type=allwordssubstr&component=Core&product=JDT&list_id=7605356 It is a known limitation of the existing analysis that it cannot track the correlation between local variables, like: "I know that when (haveLicense==true) then also (license!=null)". Adding correlation analysis would be a complex task, with significant impact on compiler performance. I don't have a strategy how to make both ends meet.
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 ***