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.
The following code (of course a non-sense example, but I guess it is the simplest show case) incorrectly reports an unnecessary test for null hint for someValue; so developers might be lead to remove the null check even though it's necessary: private Integer nullMethod () { return null; } private void test () { Integer someValue = false ? 0 : nullMethod (); if (someValue == null) { throw new NullPointerException (); } }
reproducible
Well, actually, I'd say the warning is correct: "someValue" cannot be null at that place, as the type of "false ? 0 : nullMethod ()" is "int", not "Integer" and so if "nullMethod()" returns null, the NPE will be thrown inside this exception. If the execution ever goes to the if statement, the someValue variable will contain the outcome of Integer.valueOf, and so won't ever be null. I'd separate this into two parts: -a warning should be reported at the place Integer is converted to int if it is detectable that the Integer may be null (which, currently, is unfortunately not detectable in the case). -suppressing the latter warning if it is provable the execution will never reach the given point. A somewhat corner case-y situation, and may not be easy to do, so I'll see when I'll actually get to that.
Hi Jan, yes, sorry, you are right. I wasn't aware that the return type of the statement "false ? 0 : nullMethod ()" is int and not Integer even though the return type of nullMethod () is Integer. So in this case this is not a bug. And, if I write "false ? (Integer) 0 : nullMethod ()" instead, the warning correctly disappears as the return type then changes to Integer. Thanks for the clarification.
The defect from the original code sample was 'solved' by fix for issue #225970 -- the code pattern "if foo == null -> throw exception" is recognized as a precondition check and is not reported as possible unneeded check. However the NPECheck hint still fails to report Integer someValue = false ? 0 : null; as possible NPE. The same for method calls annotated by @CheckForNull etc.
Linking to an umbrella issue
OK, unboxing in conditional checked. Instead of the using horrible type matrix fom JLS I rely on that if the TypeMirror for ? operator is a primitive, unboxing is run on non-primitive operand. Fixed in experimental implementation, fix will be committed with umbrella issue close.