Community
Participate
Working Groups
If I use "null" a a boolean parameter, the compiler should generate a warning public class NPE_OnBoxing { private interface IValue { boolean isSomething(); } private final IValue m_Value; public NPE_OnBoxing() { m_Value = null; } public boolean isSomething() { return m_Value != null ? m_Value.isSomething() : null; } public static void main(final String [] args) { new NPE_OnBoxing().isSomething(); } } -- Configuration Details -- Product: Eclipse 1.4.0.20110609-1120 (org.eclipse.epp.package.java.product) Installed Features: org.eclipse.jdt 3.7.0.v20110520-0800-7z8gFchFMTdFYKuLqBLqRja9B15B -- Configuration Details -- Product: Eclipse 1.4.0.20110609-1120 (org.eclipse.epp.package.java.product) Installed Features: org.eclipse.jdt 3.7.0.v20110520-0800-7z8gFchFMTdFYKuLqBLqRja9B15B
I can reproduce - investigating.
The compiler actually has all the necessary information regarding the potential NPE, UNBOXING is set and the nullStatus of the expression is POTENTIALLY_UNKNOWN|POTENTIALLY_NULL. However, as of now the compiler performs NPE checks only against local variables, not arbitrary expressions. See also: ((Boolean)null).booleanValue(); (b ? null : Boolean.FALSE).booleanValue(); I suggest to schedule this for M5 so we can first release the work on null annotations and after that do a walk over all situations & expressions that might have slipped our attention so far. Thanks for the report! One point to investigate in the implementation: to correctly handle loops etc. checkNPE() doesn't directly report but records the issue with the current flow context, to be evaluated when the context has been fully analyzed. However, the flow context needs a local var as the point of reference. Thus a naive solution could easily break if the expression contains access to a local var whose null status is different in different iterations of the loop. Will also check for possible connection with bug 331222.
The next patch in bug 186342 will contain a disabled test _test_nonnull_return_009b() that demonstrates a related issue where null-analysis of expressions other than local variables needs to be better integrated with loop-analysis done by FlowContext.
While a quick and dirty fix for the reported scenario would be possible in M5 I'm postponing this for M6 to allow for a more complete fix.
We think for some logistics reasons this is better addressed in early 3.9.
Works with current 4.4M6: - Potential null pointer access: This expression of type Boolean may be null but requires auto-unboxing
(In reply to Jan Hoppe from comment #6) > Works with current 4.4M6: > - Potential null pointer access: This expression of type Boolean may be null > but requires auto-unboxing Thanks for letting us know. I'm reopening just to - activate the junit test - identify the change that has fixed this bug, too.
No fix required for this. The remaining tasks can be done during RC2
(In reply to Stephan Herrmann from comment #7) > I'm reopening just to > - activate the junit test I tried to activate the test, but it appears the second error is no longer thrown and I think that's the right thing to do too?
Test has been released via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=9ad6ec94ea4e76032747dbe19cdfd50d0453e7ee The fix was released via bug 400761 (4.3 M6). *** This bug has been marked as a duplicate of bug 400761 ***
Verified for 4.5 M1 with build I20140804-2000
