----- 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 21:27:12 > Objet: Re: Evolving the wrapper classes
>> On Jun 19, 2020, at 12:54 PM, Remi Forax <fo...@univ-mlv.fr> wrote: >> >>> Note that [I and [QInteger$val have the exact same layout, so it is really a >>> matter of treating the two type names as referring to the same underlying >>> runtime type. >> >> yes, but at the same time descriptor are matched by name and you need to have >> the proper descriptor when overriding/implementing a method, >> so the strategy of blindly replacing every I by QInteger$val; doesn't really >> work. >> >> Usually the solution is to use bridges but bridges only work with subtyping >> relationship not equivalence relationship (because you can travel in both >> direction). >> I believe we need to bring the forward/bridge-o-matic at the same time we >> retrofit primitive to inline. > > In the VM this is mostly a verification problem: have a > '[Qjava/lang/Integer$val;', need a '[I'? You're good! ("Mostly", because there > is still the matter of ensuring there's a single encoding for both kinds of > objects, or that the instructions are capable of handling two different > encodings.) > > I'm not sure we'd get into any situations where a '([I)V' descriptor needs to > override a '([Qjava/lang/Integer$val)V' descriptor, or vice versa, until we > get > to specialization, 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. > and then I'm not sure this is any different than other forms > of bridging. All existing code will continue to use 'I' in its compiled > descriptors. if everything is compiled at the same time, there is no issue, otherwise you can create a loop. Rémi