Bug 317858 - Eclipse isn't accessing the correct field/class - causes compile error
Summary: Eclipse isn't accessing the correct field/class - causes compile error
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.7 M1   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-24 12:49 EDT by 00jt CLA
Modified: 2010-08-03 08:35 EDT (History)
2 users (show)

See Also:


Attachments
Patch under consideration. (7.96 KB, patch)
2010-06-28 23:53 EDT, Srikanth Sankaran CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description 00jt CLA 2010-06-24 12:49:26 EDT
Build Identifier: M20100211-1343

If a class "A" has a public static class "B" as well as a private field "B", and then a class in another package tries to use "A.B" - Eclipse tries to access the private field.

Small example code:

-------------------------
package p1;

public class Main {

    public static void main(String[] args) {
        System.out.println( "value =  " + p2.A.B.length);
    }   
}
--------------
package p2;

public class A {

    public final static class B {
        public final static String length = "very long";
    }
    private  int [] B = new int[5];    
}
-------------------

This code works from command line.. as well as another IDE, but Eclipse doesn't work.

I currently don't know of a work-around.

Reproducible: Always

Steps to Reproduce:
1. (see example code in details)
Comment 1 Olivier Thomann CLA 2010-06-24 13:51:03 EDT
javac 1.6 compiles this code fine and the Eclipse compiler is failing.
Srikanth, please investigate.

The workaround would be to name to private field with a different name :-).
Comment 2 00jt CLA 2010-06-24 14:55:13 EDT
(In reply to comment #1)
> javac 1.6 compiles this code fine and the Eclipse compiler is failing.
> Srikanth, please investigate.
> The workaround would be to name to private field with a different name :-).

Well, of course that would work. :-p

I'm just saying that if my code used someone else's poorly written Jar, then eclipse wouldn't run it. 

Another IDE lets me undo "compile on save".. and then it simply uses javac 1.6
instead of the IDE's compiler.
Comment 3 00jt CLA 2010-06-24 15:22:23 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > javac 1.6 compiles this code fine and the Eclipse compiler is failing.
> > Srikanth, please investigate.
> > The workaround would be to name to private field with a different name :-).
> Well, of course that would work. :-p
> I'm just saying that if my code used someone else's poorly written Jar, then
> eclipse wouldn't run it. 
> Another IDE lets me undo "compile on save".. and then it simply uses javac 1.6
> instead of the IDE's compiler.

Also, if i have a similar bug.. should i post it here, or make another Bug report
Comment 4 Olivier Thomann CLA 2010-06-24 17:19:04 EDT
(In reply to comment #3)
> Also, if i have a similar bug.. should i post it here, or make another Bug
> report
You can always post here. If this is not the same issue, we will put it into its own bug report.
Comment 5 00jt CLA 2010-06-24 20:02:31 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > Also, if i have a similar bug.. should i post it here, or make another Bug
> > report
> You can always post here. If this is not the same issue, we will put it into
> its own bug report.

Ok,

This bug Eclipse also thinks it is importing a class when it shouldn't be (due to obscuring).

I have 2 packages with the following classes:
================================
package p1;

import static p2.OuterClass.Inner;


public class myRunner {

        public static void main(String [] args)
        {
                System.out.println("Value1 = " +          Inner().toString());
                System.out.println("Value2 = " +      new Inner().toString());
        }        
}
------------------------

package p1;

public class Inner {

    public String toString()
    {
         return "The Class -- p1.Inner";
    }

}

-------------------------

package p2;

public class OuterClass {

    public  class Inner{
        @Override
        public String toString()
        {
            return "The Class -- p2.OuterClass.In";
        }
    }
    public static String Inner()
    {
        return  "The Method -- p2.OuterClass.In()";

    }

}
----------------------------------
====================================
Since my import statement is STATIC, then it shouldn't be importing the non-static class with the same name as the STATIC method.

"Value1" should be "The Method -- p2.OuterClass.In()"
and
"Value2" should be "The Class -- p1.Inner"

The problem is that on the line:

    System.out.println("Value2 = " +      new Inner().toString());

It should be invoking the class p1.Inner, but Eclipse thinks it is referring to p1.OuterClass.Inner (which isnt  static and shouldn't be imported)
And "new Inner()" is not a valid way to call an non-static inner Class; (thus the error)
Comment 6 Srikanth Sankaran CLA 2010-06-28 23:53:22 EDT
Created attachment 172983 [details]
Patch under consideration.
Comment 7 Srikanth Sankaran CLA 2010-06-28 23:56:00 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Also, if i have a similar bug.. should i post it here, or make another Bug
> > > report
> > You can always post here. If this is not the same issue, we will put it into
> > its own bug report.
> 
> Ok,
> 
> This bug Eclipse also thinks it is importing a class when it shouldn't be (due
> to obscuring).

Prima facie, it does not look related.

Ayush, please triage this case and see if there is a bug here.
Open a new defect as needed and assign to yourself for
follow up -- Thanks.
Comment 8 Srikanth Sankaran CLA 2010-06-29 01:20:36 EDT
(In reply to comment #6)
> Created an attachment (id=172983) [details]
> Patch under consideration.

Passes all tests. Ayush, please review, Thanks.
Comment 9 00jt CLA 2010-06-29 11:24:27 EDT
(In reply to comment #8)
> (In reply to comment #6)
> > Created an attachment (id=172983) [details] [details]
> > Patch under consideration.
> Passes all tests. Ayush, please review, Thanks.

I got the same bug, abused differently, to actually compile in Eclipse and give a different answer, I thought you might like to see it:


------------------------------------
package p2;

import static p1.Bar.B;
import  p3.Foo.*;

public class OuterTest {

		public static void main(String [] args)
		{
			new OuterTest().beginTest();
     	}
		public void beginTest(){
			System.out.print("1 + 1 =  ");
			if(alwaysTrue()){
				System.out.println("2");
			}
			else{
				System.out.println("3");
			}
		}
		public boolean alwaysTrue(){ // Returns FALSE in Eclipse
			String myB   =        B.class.getCanonicalName();
			String realB = p1.Bar.B.class.getCanonicalName();
			return myB.equals(realB);
		}
}

------------------------------------
package p1;
public class Bar {
	public static class  B{}
	final public static String B = new String("random"); 
}
------------------------------------
package p3;

public class Foo {
	 public class  B {}
}
------------------------------------

Eclipse will print out "1 + 1 = 3"
Comment 10 00jt CLA 2010-06-29 11:30:48 EDT
In the above bug, it appears that in "Bar" the field "B" is obscuring the class with the same name, and then it looks like the import-on-demand from "Foo.*" is shadowing the single-import "Bar.B". Perhaps the JSP is a bit to vague on these corner cases.
Comment 11 Srikanth Sankaran CLA 2010-06-29 22:36:10 EDT
(In reply to comment #7)

> Ayush, please triage this case and see if there is a bug here.
> Open a new defect as needed and assign to yourself for
> follow up -- Thanks.

I have raised bug 318401 to track the imports shadowing issue
and copied the relevant test cases and comments from here to
there. Folks, over to bug 318401 for any discussions related
to imports, please -- Thanks!
Comment 12 Ayushman Jain CLA 2010-07-05 08:25:32 EDT
(In reply to comment #8)
> (In reply to comment #6)
> > Created an attachment (id=172983) [details] [details]
> > Patch under consideration.
> 
> Passes all tests. Ayush, please review, Thanks.

Patch looks good.
Comment 13 Srikanth Sankaran CLA 2010-07-05 10:23:01 EDT
Released in HEAD for 3.7 M1.
Comment 14 Ayushman Jain CLA 2010-08-03 08:35:53 EDT
Verified for 3.7M1 using build I20100802-1800.