[External] : Re: Why do we need .ref class for primtive class ?

[Brian Goetz]

For a B3 class, .ref *is* indicated by an L type:

     void m(Point p) { }      // (QPoint;)V
     void m(Point.ref p) { }  // (LPoint;)V



On 1/6/2022 5:08 PM, forax at univ-mlv.fr wrote:
> Let me re-phrase my question because i've asked the wrong question.
>
> My question is not why do we need .ref in the language but why .ref 
> can not be represented by a L-type in the bytecode instead of a full 
> reified interface/abstract class.
>
> Asking for a .ref is something similar to a boxing, but using 
> checkcast to convert from a QComplex; to a LComplex;
>
> One reason may be that this is not a subtyping relationship but a 
> boxing relationship so it may not work when well we will have fully 
> reified generics.
>
> Rémi
>
> ------------------------------------------------------------------------
>
>     *From: *"Brian Goetz" <brian.goetz at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>, "valhalla-spec-experts"
>     <valhalla-spec-experts at openjdk.java.net>
>     *Sent: *Thursday, January 6, 2022 9:12:21 PM
>     *Subject: *Re: Why do we need .ref class for primtive class ?
>
>     Because the Q is what permits the tearing.
>
>     On 1/6/2022 1:50 PM, Remi Forax wrote:
>
>         It just occurs to me that while ACC_VALUE is a bit that change the runtime semantics,
>         something the VM should take care of, ACC_PRIMITIVE is not a bit that change the
>         runtime semantics, only the javac translation strategy,
>         javac emits Q-types instead of L-type + the Preload attribute.
>
>         If value classes and primitive classes are equivalent at runtime, why do we need to generate the .ref interface/abstract class ?
>         We can use L-type instead.
>
>         Rémi
>
>
>