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

[Werner Dietl]

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 :-)

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