Two methods, same signature, different return types

Hi folks,

I'm mildly puzzled by something I came across today. I have a class,
generated by plain javac (1.5.0_13, on Mac OS X) that has two methods
that only differ in their return type. Witness:

public interface BeanTestInterface<T>
{
     T getSomething();
}

public class BeanTest implements BeanTestInterface<Integer>
{
     public Integer getSomething()
     {
         return 42;
     }
}

Compiling and disassembling BeanTest.class using javap shows:

$ javap BeanTest
Compiled from "BeanTest.java"
public class BeanTest extends java.lang.Object implements
BeanTestInterface{
     public BeanTest();
     public java.lang.Integer getSomething();
     public java.lang.Object getSomething();
}

The Object returning is of course synthetic, its code is simply
delegating to the integer version:

public java.lang.Object getSomething();
   Code:
    0:  aload_0
    1:  invokevirtual   #3; //Method getSomething:()Ljava/lang/Integer;
    4:  areturn

I know why the method is emitted -- if some external code invokes
getSomething() through a reference of type BeanTestInterface<T>, i.e.
with

class BeanTestInvoker<T>
{
     BeanTestInterface<T> bti;

    ... bti.getSomething() ...
}

javac can only compile a call the Object returning version. That's
okay. Actually, just now I can't find this part (emitting of the
synthetic method) anywhere in the JLS -- someone care to point out to
me where is it?

What I have trouble understanding is how does it *not* screw up the
overloaded method resolution algorithm specified in JLS 15.2.2 -- with
expression "new BeanTest().getSomething()" I see nothing that would
prevent both methods to be selected as applicable, then both would
wind up being maximally specific as per 15.12.2.5 ("more specific"
doesn't take return type in the consideration), and the compiler would
then have to claim ambiguity as far as I can see. Obviously (and
fortunately) it doesn't -- it invokes the Integer returning version.
But I'd really appreciate if someone would point it out to me what
rule within JLS 15.2.2 allows it to avoid ambiguity in this case.

Thanks,
   Attila.

--
home: http://www.szegedi.org
weblog: http://constc.blogspot.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com