----- Mail original -----
> De: "daniel smith" <daniel.sm...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Brian Goetz" <brian.go...@oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts@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, fo...@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
