Community
Participate
Working Groups
Build ID: M20070212-1330 Steps To Reproduce: 1. Compile following method in any class 2. Have null reference warning activated 3. you should see a warning on the marked line Obviously the warning is wrong (if a = { "xx", null }, key is not null). If you add a test in the for loop as described, the warning disappears. More information: public void test( String[] a ) { String key = null; // if the following line is replaced by: // for( int i = 0; i < a.length; i++ ) // the warning does not show up. for( int i = 0; ; i++ ) { if( a[ i ] == null ) break; key = a[ i ]; } if( key != null ) // <<< WARNING Here "Key can only be null" { // do something } }
Reproduced with M20070212-1330 and I20070418-1012.
Released new tests NullReferenceTest#418, 462 and 743 as inactive (because they are broken), and 419, 463 and 744 as active. The latter tests show that a break to an explicit label does not raise the unexpected warning. This may lead us to consider what we did for explicit labels for bug 176472 and see what may also apply to default break targets.
Created attachment 68102 [details] Fix + test cases This fix merely amends the initsOnBreak of LoopingContext-s just before doing the same to the initsOnBreak-s of explicit LabelContext-s (for the same LoopingContext). This typically ensures that the inits on a break statement 'see' what happens after them in the loop body, so that a break hit at the Nth iteration, N > 1, gets the result of N - 1 complete iterations plus a partial Nth iteration (whereas we used to only record the part of all iterations that was before the break statement). Patch currently under test.
looks straight forward
Released for 3.4 M2.
*** Bug 198955 has been marked as a duplicate of this bug. ***
Verified for 3.4M2 using I20070917-1800
*** Bug 212283 has been marked as a duplicate of this bug. ***