Community
Participate
Working Groups
Build Identifier: M20100909-0800 The following code first checks for null and then does auto-unboxing on the same variable. If I remove the while or do the unboxing by hand, no warnings are generated. Integer value = System.currentTimeMillis() > 0 ? null : 1; while (true) { System.out.println(value != null && value == 1); } Reproducible: Always Steps to Reproduce: 1. Paste the code from the detials field into any java method. 2. Set the Errors/Warnings Potential null pointer access to Warning 3. Compile your code You will get warning.
Created attachment 238138 [details] Code demonstrating different cases I cannot reproduce the problem as it is in comment #0 with 20130614-0229. However changing the code slightly by using Boolean instead of Integer and removing the comparison where the warning occurs, leads to the same problem: Boolean value = System.currentTimeMillis() > 0 ? null : true; while (true) { System.out.println(value != null && value); } I made some experiments (see attached code): * Same code with (wL) or without loop (nL) * Same code with (wB) or without "break;" (nB) directly after the println * Same code with value set to the return value of some method returning Boolean (wM) instead of the System.currentTimeMillis thing (nM) Here are the results (X=warning, -=no warning): | nL | wL | | wB | nB --- ---- ---- ---- nM | X | - | X --- ---- ---- ---- wM | - | - | X Changing the expression in the println to "…&& value==1" results in no warning in any case. Note that this issue is now more problematic as enabling annotation-based null analysis automatically sets the "Potential null pointer access" to error by default. So instead of just a "unnecessary warning" this results in a false positive error.
I was going to report almost exactly the same case, but I found this bug and I think it's highly related. Namely it also fails on 'if' statement as in this code sample: Boolean foo = System.currentTimeMillis() % 2 == 0 ? null : true; if (foo != null && ~foo~) { } where foo variable surrounded with '~' shows the problematic case. The exact error message is: 'Potential null pointer access: This expression of type Boolean may be null but requires auto-unboxing'. If you change code to: Boolean foo = System.currentTimeMillis() % 2 == 0 ? null : true; if (foo != null && foo.booleanValue()) { } the warning/error is gone and everything looks fine. So it looks like auto-unboxing is not taken into account if there is previous not-null check. I'm using Kepler SR1, build ID 20130919-0819.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I can no longer reproduce any of the examples in the comments with the current version of Eclipse (2019-09 - build id 20190917-1200). It is not "my" bug, but I assume it can be closed now.
