Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 379784 - [compiler] "Method can be static" is not getting reported
Summary: [compiler] "Method can be static" is not getting reported
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.8   Edit
Hardware: PC Windows 7
: P3 minor (vote)
Target Milestone: 4.3 M2   Edit
Assignee: Stephan Herrmann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-17 02:42 EDT by Satyam Kandula CLA
Modified: 2012-09-17 22:49 EDT (History)
2 users (show)

See Also:


Attachments
test & tentative fix (4.68 KB, patch)
2012-05-17 09:49 EDT, Stephan Herrmann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Satyam Kandula CLA 2012-05-17 02:42:36 EDT
This probably is a regression caused by the fix for bug 376550. However, as it erring on the other side of 'not' reporting, this is minor.
###
package pkg1;
import java.util.ArrayList;
import java.util.Collection;
public class CanBeStatic {
    private static Object o = new Object();
    public final Collection<Object> go() {
        return new ArrayList<Object>() {
            {
                add(o);
            }
        };
    }

}
###
go() can be static in this particular case but it is not getting reported. Note that the field 'o' is static here.
Comment 1 Stephan Herrmann CLA 2012-05-17 09:45:39 EDT
It's actually not the access to 'o' that marks the method as cannot-be-static, but the receiver in "add(o)".
To check just replace "add(o)" with "add(null)" and still the compiler thinks that go cannot be static.
Comment 2 Stephan Herrmann CLA 2012-05-17 09:49:44 EDT
Created attachment 215768 [details]
test & tentative fix

This sketch marks how that problem could be solved.
Comment 3 Stephan Herrmann CLA 2012-05-17 11:30:59 EDT
While digging deeper into this (during review of  bug 376550):

To make things clearer for future readers I suggest to rename the argument of BlockScope.resetDeclaringClassMethodStaticFlag(TypeBinding declaringClass):
If I understand correctly, this argument signals the type of which an enclosing instance is required.
With a name like "enclosingInstanceType" it should be clear that MessageSend indeed has to pass "this.actualReceiverType", not "this.binding.declaringClass".
Comment 4 Stephan Herrmann CLA 2012-05-17 11:51:44 EDT
Here's a variant of ProblemTypeAndMethodTest.test376550_5a():

public class X {
   int i1 = 1;
   public void foo(){
   	   class Local{
			int i2 = 1;
       }
       class Local2 extends Local {
			void method2() {
				Local2.this.i2 = 1;
			}
		}
	}
}

The indirection Local2 -> Local shows that identity tests inside resetDeclaringClassMethodStaticFlag() aren't sufficient, but we probably need to check isCompatibleWith().

The above test does not find that foo() can be static because Local != Local2.
Comment 5 Ayushman Jain CLA 2012-05-17 13:33:07 EDT
Stephan, assigning to you since you have a preliminary patch in place. :)
Comment 6 Ayushman Jain CLA 2012-07-25 13:05:41 EDT
Will try and get this into 3.8.1
Comment 7 Srikanth Sankaran CLA 2012-07-26 01:28:28 EDT
Let us target only critical/serious issues for back port. This qualifies
for 4.3 M1.
Comment 8 Ayushman Jain CLA 2012-08-04 12:55:11 EDT
Moving out to 4.3M2 to accommodate other pressing bugs.
Comment 9 Stephan Herrmann CLA 2012-09-16 12:03:38 EDT
Test & fix have been released for 4.3 M2 via commit a5b7766b7751acbd9316d0da24707b07ce3a52af
Comment 10 Srikanth Sankaran CLA 2012-09-17 22:49:52 EDT
Verified for 4.3 M2 using Build id: I20120917-0800