[non-308] Scoping problem with Resolve and javac 6 vs. 7 vs. Eclipse

[Maurizio Cimadamore]

Hi Werner,
this behavior is correct, method lookup begins by choosing the class in 
which to search the method. Such a class is the class defining at least 
a method with the same name as the one to be found, starting from the 
innermost class. If no match is found, the search continue in the next 
enclosing scope. Here you have that the class to search for 'foo' is the 
inner class, as the inner class has a member method named 'foo'. 
Unfortunately, the inner class' foo method is not the one you want to call.

To solve the problem, note that you can always access the enclosing 
class version of the method by doing this:

ScopingBug.this.foo(s, 5);

I hope this helps.

Maurizio

On 17/01/13 10:16, Werner Dietl wrote:
> Since pulling in the latest jdk8/tl changesets, I'm having a build
> problem in Eclipse in javac.comp.Resolve line 760.
> The command-line build succeeds, which made me curious.
>
> I reduced the issue to the attached file.
>
> With a javac 1.6.0_24 compiler I get:
>
> ScopingBug.java:18: cannot find symbol
> symbol: method foo(java.lang.String,int)
>
> With javac 1.7.0_09 this compiles and runs. The test could be
> minimized some more to only illustrate the scoping problem; I expanded
> it to make it executable and the compiled program runs correctly.
>
> The Eclipse 3.7.2 compiler in 1.7 compliance level raises an "not
> applicable" error for the call of foo.
>
> Is this a known issue for javac 6 and Eclipse? Or is javac 7 wrong?
>
> The work-around is easy: don't do the ugly overloading. Could we apply
> such a workaround in Resolve to make my Eclipse-build happy?
>
> To make the example even more interesting, change line 15 to:
>
>          Itf i = new Itf() {
>
> that is, instead of using the class Clazz use the interface Itf.
> I would have assumed that this doesn't make a difference. However, now
> javac 7 fails with the same error as Eclipse:
>
> ScopingBug.java:18: error: method foo in class <anonymous Itf> cannot
> be applied to given types;
>                  foo(s, 5);
>                  ^
>    required: String
>    found: String,int
>    reason: actual and formal argument lists differ in length
>
> Is this behavior intended?
>
> Thanks,
> cu, WMD.
>