Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 229267

Summary: [compiler][null][correlation] nullpointer check fails within "?" operator statement
Product: [Eclipse Project] JDT Reporter: AndiSmirre <andi>
Component: CoreAssignee: Ayushman Jain <amj87.iitr>
Status: CLOSED DUPLICATE QA Contact:
Severity: enhancement    
Priority: P5 CC: martinae, nikolaymetchev, Olivier_Thomann, stephan.herrmann
Version: 3.4Keywords: helpwanted
Target Milestone: 4.7 M1   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description AndiSmirre CLA 2008-04-29 06:53:11 EDT
Build ID: I20070621-1340

Steps To Reproduce:
View the following code with enabled potential nullpointer access check:

      Object test = null;
      boolean isNull = test == null;
      Object hallo = isNull ? "is null" : test.toString();
      System.out.println(hallo); // "is null"


More information:
      As you can see, the else operator of the "?" statement 
      marks the variable "test" to be a potential nullpointer
      access. But this is not possible, as the nullpointer access
      has been checked in the previous line and it is prevented 
      by the "?" operator.
Comment 1 Maxime Daniel CLA 2008-04-29 08:29:10 EDT
Thanks for the test case.

This pertains to the realm of variables correlation (isNull protects test here), for which we have no firm plans as of today. Lowering priority accordingly.
Comment 2 Nikolay Metchev CLA 2013-06-20 06:26:18 EDT
I have a slightly different example. using the Nullable annotation.
I am not sure if the bug fix will be the same:
--------------------------------------
import javax.annotation.Nullable;

public class Bug {
  @Nullable
  private String a;
  
  String m() {
    return (a == null) ? "a" : a.toString();
  }
}
Comment 3 Stephan Herrmann CLA 2016-06-28 17:18:25 EDT
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.
Comment 4 Jay Arthanareeswaran CLA 2016-08-03 07:58:35 EDT
Verified for 4.7 M1.
Comment 5 Stephan Herrmann CLA 2018-08-30 10:35:06 EDT
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 ***