Bug 198967 - [compiler][null] False positives for "null comparison always yields false" after instanceof operation
Summary: [compiler][null] False positives for "null comparison always yields false" af...
Status: RESOLVED DUPLICATE of bug 145202
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.3   Edit
Assignee: Maxime Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-06 13:53 EDT by Daniel Lew CLA
Modified: 2007-09-10 04:09 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Lew CLA 2007-08-06 13:53:25 EDT
Build ID: I20070625-1500

Steps To Reproduce:
1. In Window->Preferences->Java->Compiler->Errors/Warnings->Unnecessary Code->Redundant null checks, set it to warning/error.
2. Try out this class in Eclipse:

public class Test {

	public static void main(String[] args) {
		Object foo = randomObject();
		
		//gives null comparison always yields false warning/error below
		if(!(foo instanceof String) || foo == null) { 
			System.out.println("bar");
		}
	}
	
	public static Object randomObject() {
		if(Math.random() < .5)
			return new String();
		
		return null;
	}
}

3. Observe the warning/error on the "foo == null" check, stating that foo must be null.  This isn't true at all; in fact, an instanceof operation will give false if foo is null.

More information:
Comment 1 Maxime Daniel CLA 2007-08-13 03:19:07 EDT
Reproduced, will investigate.
Comment 2 Maxime Daniel CLA 2007-09-10 04:09:42 EDT
Revisiting.

If foo was null, then foo instanceof String would yield false, !(foo instanceof String) would yield true, and the second member of the || expression would not get evaluated at all. This is reflected by the message, which, for 3.4 M1, states that 'The variable foo cannot be null at that [the comparison] location' (instead of the 'foo must be null' that the bug submitter observed.

Checked 3.3.1 again, which has the same behavior.

I would contend that our current behavior is correct. Which already was the conclusion of bug 145202, of which this one happens to be a duplicate.


*** This bug has been marked as a duplicate of bug 145202 ***