Community
Participate
Working Groups
Null reference analysis falsely states that on the final line of the following method (the return) "The variable editor may be null". This is not true as if editor was null then offset would be null and hence the method would have already returned before reaching that statement. private AST getEditorAST(Editor editor) { Integer offset = editor == null ? null : editor.getCaretOffset(); if (offset == null) { return null; } return editor.getAST(offset); } If you replace the ternary with a simple: if (editor == null) { return null; } Then the warning goes away. Rather oddly, if you have add this whilst also keeping the ternary then you get two warnings. One saying 'editor' in the ternary line cannot be null as it has already been checked against null, and one saying the 'editor' in the return line could be null.
This is a case in which you want one variable (offset) non null status to imply a non null status for another variable (editor). We have made no attempt yet to tackle such function in a systematic way.
We do not plan any general variables correlation mechanism in 3.2 timeframe. If this pattern is super frequent, we may consider a dedicated pattern, along similar lines as those described in bug 125319. Some constraints would be added though (aka editor would have to be final). Is this something you use frequently?
(In reply to comment #2) Well this is generally the method we have adopted for condensing tests for null into as few statements as possible. It seems wrong to have for example: ... child = parent.getChild(); if(child == null) return; sibling = child.getNextSibling(); if(sibling == null) return; goal = sibling.getNextSibling(); if(goal == null) return; ... When you can do this with ternary as: ... child = parent.getChild(); sibling = child == null ? null : child.getNextSibling(); goal = sibling == null ? null : sibling.getNextSibling(); if(goal == null) return; ... Can you suggest a better Java programming approach? Otherwise, it would seem a sensible case to add.
(In reply to comment #3) I would consider like the following if you don't need the side effects on siblings and goal when then happen to be null: ... if ((child = parent.getChild()) != null && (sibling = child.getNextSibling()) != null && (goal = sibling.getNextSibling()) != null) { // do something to goal return goal; } return null; This is compact and efficient.
Created attachment 39166 [details] Tentative fix + tests This patch: - changes the states definitions for the null analysis (adds three); - recodes transitions accordingly; - augments functional tests for the null reference analysis; - reorganizes (radically) implementation tests for the null reference analysis.
Comment on attachment 39166 [details] Tentative fix + tests DO NOT USE: attached the patch to the wrong bug (127570).
Post 3.2.
*** Bug 180925 has been marked as a duplicate of this bug. ***
Reopening as P5 (since RESOLVED LATER is deprecated).
Bulk closing all compiler bugs tagged [null][correlation], because we have no plans to add such a feature: it would be a tremendous implementation effort, beyond our current man power, and may be impossible to achieve within the desired performance bounds. If s.o. has a viable strategy or even implementation for such a feature, I'm all ears.
Verified for 4.7 M1
I created a new umbrella RFE outlining what would be needed to address this issue. *** This bug has been marked as a duplicate of bug 538421 ***
