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

[Werner Dietl]

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