Evolving the wrapper classes

[forax at univ-mlv.fr]

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 19 Juin 2020 22:16:48
> Objet: Re: Evolving the wrapper classes

>> On Jun 19, 2020, at 1:51 PM, forax at univ-mlv.fr wrote:
>> 
>> covariant return type
>>  interface I {
>>     int foo();
>>  }
>>  interface J {
>>     Object foo();
>>  }
>>  class A implements I, J {
>>    int foo();
>>  }
>> 
>> with I.java compiled a long time ago.
> 
> Nothing in this proposal changes how these classes are compiled. The following
> methods will exist:
> 
> I.foo()I
> J.foo()Ljava/lang/Object;
> A.foo()I
> A.foo()Ljava/lang/Object; // bridge
> 
> I think you may be mixed up thinking that we'll sometimes translate 'int' in a
> descriptor to 'Ljava/lang/Integer$val;', but that's not the case. 'I' is
> preferred wherever possible.

If the VM see I as a subtype of Object, there is no need for a Ljava/lang/Integer$val; at all, it's better to have aload/astore/etc to work on I directly.

Rémi