Bug 333562 - Invalid "Potential null pointer access" warning message
Summary: Invalid "Potential null pointer access" warning message
Status: VERIFIED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.6.1   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.7 M5   Edit
Assignee: Ayushman Jain CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-05 07:06 EST by Mohsen Saboorian CLA
Modified: 2011-01-25 03:30 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mohsen Saboorian CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 2011-01-06 01:25:38 EST
.
Comment 6 Srikanth Sankaran CLA 2011-01-25 03:30:33 EST
Verified for 3.7 M5