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

[Maurizio Cimadamore]

You are right about the fact that the original example erroneously pass 
in JDK 7 - this has been fixed in the JDK 8 repo. I.e. your code doesn't 
compile (regardless of Clazz/Itf) with JDK 8.

Maurizio

On 17/01/13 10:36, Werner Dietl wrote:
> Thanks for the quick reply, Maurizio!
>
> On Thu, Jan 17, 2013 at 2:24 AM, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> 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.
> I'm not quite sure I understand your explanation. You are saying that
> the attached program should fail, right?
> However, compiling it with javac 1.7.0_09 works and executes correctly.
>
> Your explanation makes sense when the anonymous inner class
> instantiation is changed to "new Itf() {", where I get the same error
> message from Eclipse and javac 1.7.0.
>
>
>> 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);
> Unfortunately, we cannot do this in Resolve line 760, because method
> "report" that is being called is from an anonymous inner class.
> Renaming the method would solve this.
>
> cu, WMD.
>
>
>> 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.
>>>
>
>