Re: Two methods, same signature, different return types

Perhaps this is not a part of JLS at all. Java 1.5 introduced a new
BRIDGE access modifier. Perhaps the Java compiler will just ignore all
methods marked with that? The only mention of bridge methods is in
section 15.12.4 in Discussion. I think it is not considered a part of
Java language, but just an implementation detail.

Jevgeni Kabanov

On Sun, Aug 17, 2008 at 11:42 PM, Attila Szegedi <[email protected]> wrote:
> 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(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>

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

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