This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
public static class Test { @Nullable final Integer i = null; public static void main(String[] args) { Test t = new Test(); if (t.i != null) { t.i.toString(); // false positive here } } }
reproducible
This may be tempting to fix, but it's rather a corner case; if the `t' reference ever escapes from the method and there's a method call in between t.i != null and t.i.toString(), it's not guaranteed that the t.i. value remains the same unless i is final (the invoked method may eventually execute code which has access to t and alters i) I would say it's a rather fragile situation.
> it's not guaranteed that the t.i. value remains the same unless i is final That's why I titled the bug "@Nullable *final* field".
It's probably a separate bug, but interestingly, internal references to `@Nullable` fields get no warnings at all: public class AnotherTest { @Nullable Integer i = 42; String asString() { return i.toString(); // no warning here } }
(In reply to mintern from comment #3) > That's why I titled the bug "@Nullable *final* field". Apologies :) Re. comment #4: check that you have enabled checking for fields for the null dereference hint.
I'm sorry... I'm not seeing anything in Hints related specifically to null field checking. When I search "null", I see: - Unnecessary Throwable.initCause - .equals(null) - Boxed value identity comparison - Null Pointer Dereference All are checked. When I search "field", there are many results, but none of them seem to be related to null. I'm on NetBeans 8.0.2: Product Version: NetBeans IDE 8.0.2 (Build 201408251540) Updates: NetBeans IDE is updated to version NetBeans 8.0.2 Patch 2 Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27 System: Linux version 3.13.0-63-generic running on amd64; UTF-8; en_US (nb) Should I be on the 8.1 Beta? Anyway, the reason I brought that up was in response to your point regarding `t.i != null` followed by `t.i.toString()` not being safe in the face of intermediate calls or concurrent operations. I was checking to see whether the following construct would warn: public class AnotherTest { @Nullable private Integer i = 42; public String asString() { if (i != null) { clearI(); return i.toString(); } return null; } public void clearI() { i = null; } } But I didn't even see a warning for a trivial case, so it was hard to make any kind of point there. ^_^ I guess it comes down to a question of philosophy regarding Hints. Is it better for a Hint to match too often, making it more likely for the programmer to turn off the hint (or omit `@Nullable` field annotations, in this case), or is it better to miss a case that might be a programmer error? My assumption has been that the latter is preferable. If I make a mistake in null-handling, I'm not blaming the IDE. But if my code is correct and I'm having to suppress a bunch of warnings, the hint isn't useful to me.
If you select the Null Pointer dereference, a panel should display on the right, with a checkbox "also warn for fields". The option is by default off as field analysis is just partial yet.
Thank you! After enabling that, I see the following: public class AnotherTest { @Nullable Integer i = 42; public String asStringWarning() { return i.toString(); // warning here } public String asStringNoWarning() { if (i != null) { clearI(); return i.toString(); // no warning here } return "null"; } private void clearI() { i = null; } } This is the behavior I would expect. The Hint is still useful, and I don't really expect NetBeans to be sophisticated enough to catch degenerate cases like this example. My preference would be for external references to a class's field to have the same behavior when giving null hints.