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

Bug 333562

Summary:	Invalid "Potential null pointer access" warning message
Product:	[Eclipse Project] JDT	Reporter:	Mohsen Saboorian <mohsens>
Component:	Core	Assignee:	Ayushman Jain <amj87.iitr>
Status:	VERIFIED INVALID	QA Contact:
Severity:	normal
Priority:	P3	CC:	Olivier_Thomann, srikanth_sankaran, stephan.herrmann
Version:	3.6.1
Target Milestone:	3.7 M5
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Mohsen Saboorian

2011-01-05 07:06:32 EST

Eclipse 3.6.1 gives invalid null warning for the following test case:

public class NullWarning {
    public static void someMethod(String param1) {
        boolean b = (param1 == null);
        if (b) {
            // do something
        }

        // this line gives incorrect warning:
        // Potential null pointer access: The variable param1 may be null at this location
        param1.trim();
    }
}



-- Configuration Details --
Product: Eclipse 1.3.1.20100913-1228 (org.eclipse.epp.package.jee.product)
Installed Features:
 org.eclipse.jdt 3.6.1.r361_v20100714-0800-7z8XFUSFLFlmgLc5z-Bvrt8-HVkH

Comment 1 Stephan Herrmann

2011-01-05 17:43:51 EST

The check (param1 == null) tells the compiler that the developer
expects both null and non-null values. So any dereference of param1
after this check is flagged as a potential null dereference.

If the check is only for robustness and null is actually not expected
here, then perhaps an assert is a better way to reflect your intention.

Once bug 186342 is released you may even avoid the check altogether 
by declaring the parameter as "@NonNull String param1".

Comment 2 Mohsen Saboorian

2011-01-06 00:32:50 EST

How about this:
        int b = param1 == null ? 1 : 2;

        if (StringUtils.isNotBlank(param1) {
                param1.trim();
        }
        
I still receive that warning even when I used a method which checks for nullity. I believe this is raised because JDT is not inspecting methods recursively. (and this is quite reasonable) Is this the right behavior based on Java compiler spec, or is a JDT-specific warning?

Thanks,
Mohsen

Comment 3 Ayushman Jain

2011-01-06 01:08:29 EST

(In reply to comment #2)
> How about this:
>         int b = param1 == null ? 1 : 2;
> 
>         if (StringUtils.isNotBlank(param1) {
>                 param1.trim();
>         }
> 
> I still receive that warning even when I used a method which checks for
> nullity. I believe this is raised because JDT is not inspecting methods
> recursively. (and this is quite reasonable) Is this the right behavior based on
> Java compiler spec, or is a JDT-specific warning?
> 
> Thanks,
> Mohsen

This is purely a JDT-specific warning. We currently dont do inter-procedural analysis, so passing a variable as a parameter to a method call makes no difference in our analysis. As Stephan already pointed out,fix for bug 186342 will make it convenient to specify null status of variables using annotations.

I intend to close this as INVALID.

Comment 4 Mohsen Saboorian

2011-01-06 01:21:41 EST

> This is purely a JDT-specific warning. We currently dont do inter-procedural
> analysis, so passing a variable as a parameter to a method call makes no
> difference in our analysis. As Stephan already pointed out,fix for bug 186342
> will make it convenient to specify null status of variables using annotations.
> 
> I intend to close this as INVALID.

Thanks for your explanation. Feel free to mark it INVALID.

Comment 5 Ayushman Jain

2011-01-06 01:25:38 EST

Comment 6 Srikanth Sankaran

2011-01-25 03:30:33 EST

Verified for 3.7 M5