Community
Participate
Working Groups
Build Identifier: Version: Indigo Service Release 1 Build id: 20110916-0149 Reproducible: Always Steps to Reproduce: This is an example test program. The second assert statement unnecessarily produces a warning. If assertions are enabled then the variable in question can't be null. If assertions are disabled then the expression is not evaluated. public class AssertTest { public static void main(String[] args) { int[] ints = null; assert ((ints = getData()) != null); assert (ints.length == 2); // Null pointer access: The variable ints can only be null at this location } private static int[] getData() { int[] data = { 1, 2 }; return data; } }
If there is a variable that is initially null, and then two assert statements, one which assigns a non-null value to the variable, and another that tests it, then the null pointer access analysis does not understand this. It thinks that the second assert statement must be accessing a null pointer, even if the variable was set in the previous assert statement.
The warning disappears if you check the option [x] Include 'assert' in null analysis The idea is that side effects of an assert statement are not considered without this option enabled, because these side effects might be missing at runtime if assertions are disabled. OTOH suppressing all warnings inside assert statements would hide relevant warnings, too. One might argue the example in this bug is a special case, since we are talking about an effect link from an assert to another assert. However, I'm afraid that implementing special treatment for this pattern would likely be very expensive (in terms of added complexity and maybe even performance). Since the mentioned option can be used to silence the warning I'm leaning towards closing as wontfix. I wonder if we could give a hint about the option (quick fix?), but the option affects how the *first* assert is analysed, and at that location we have no warning to offer a quick fix for.
(In reply to comment #2) > I wonder if we could give a hint about the option (quick fix?), > but the option affects how the *first* assert is analysed, and at > that location we have no warning to offer a quick fix for. Note that from M5 onwards all null pointer access warnings are grouped under "Null analysis" in the prefs page. I think this will make it considerably easier for the user to spot that there's a special option to include asserts. +1 to close as wontfix.
No action planned -> closing.
