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

[Maurizio Cimadamore]

On 17/01/13 10:48, Werner Dietl wrote:
> On Thu, Jan 17, 2013 at 2:44 AM, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> 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.
> OK. So that means that the JDK 8 Resolve wouldn't compile with JDK 8 :-)
I don't think so - since the build always use the latest compiler (built 
with a bootstrap javac) to build the compiler bits. Where is the code 
that you are say it shouldn't compile?

Maurizio
> cu, WMD.
>
>
>> 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.
>>>>>
>>>
>
>