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

[Werner Dietl]

>>> 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?

langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java line
761 in TL (line 760 in type-annotations).
The call to "report" is of the same form as the ScopingBug example or not?
The call is forbidden for me in Eclipse and it sounds like Eclipse's
behavior is correct in this case.

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.
>>>>>>
>>>>
>>
>>
>



-- 
http://www.google.com/profiles/wdietl