Bug 248916

Summary: [compiler][null] Potential null pointer access on second block of code
Product: [Eclipse Project] JDT Reporter: utilisateur_768
Component: CoreAssignee: Ayushman Jain <amj87.iitr>
Status: VERIFIED INVALID QA Contact:
Severity: normal    
Priority: P3 CC: Olivier_Thomann
Version: 3.4.1   
Target Milestone: 3.6 M5   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
The java file which show the weird warning none

Description utilisateur_768 CLA 2008-09-29 06:12:13 EDT
Build id: M20080911-1700

On the attached java file, there one final local which is marked as "Potential null pointer access". The odd thing is that it is only showed on the second block of code, not on the first one. The 2 blocks are almost identical so it looks like a bug.
Comment 1 utilisateur_768 CLA 2008-09-29 06:14:55 EDT
Created attachment 113717 [details]
The java file which show the weird warning

You can uncomment the second block of code to test the behaviour
Comment 2 utilisateur_768 CLA 2008-09-30 04:35:00 EDT
This is because of the first "mi.setEnabled(n != null);". The null analysis of the actionListeners should not use the outer code between them; but i'm no JLS expert.
Comment 3 Ayushman Jain CLA 2009-12-15 06:18:50 EST
final N n = n_;                // 1
		
		mi = new JMenuItem(L._("T1"));
		mi.addActionListener(new ActionListener() {
			public void actionPerformed(ActionEvent e) {
				String titre = JOptionPane.showInputDialog(parent, L._("Text1") + " :");
				if (titre != null && titre.length() > 0)
					getModele().i(N.titre(titre), n, n.get5());   // 4
			}
		});
		mi.setEnabled(n != null);           // 2
		popup.add(mi);

		// +++
		mi = new JMenuItem(L._("T2"));
		mi.addActionListener(new ActionListener() {
			public void actionPerformed(ActionEvent e) {
				String texte = JOptionPane.showInputDialog(parent, L._("Text2") + " :");
				if (texte != null && texte.length() > 0)
					getModele().i(N.t1(texte), n, n.get5());   // 3
			}
		});

This is not really a bug. On line commented as 1, the compiler marks n as assigned to an unknown value ( it could be either null , or non null depending on runtime). When the user checks n against null in line commented as 2, the compiler considers it as tainted, and marks it maybe null. This is the reason for the potential null warning on line commented as 3. Although the same kind of call was done on line commented as 4, no warning was given here as until here the variable 'n' hadn't been tainted by the user. Change line 1 and initialise n using a constructor, and the warning goes away - because now the compiler is sure that we started out with n as surely non null.

This is just a conservative way of flagging potential null references, and is OK IMO.
Comment 4 Ayushman Jain CLA 2009-12-23 01:22:15 EST
I intend to close the bug as invalid. If i'm missing something here, please point it out. Thanks.
Comment 5 Ayushman Jain CLA 2010-01-08 08:22:51 EST
Closing as INVALID.
Comment 6 Olivier Thomann CLA 2010-01-25 14:21:45 EST
Verified for 3.6M5 using I20100125-0800