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, fo...@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.go...@oracle.com>
*To: *"Remi Forax" <fo...@univ-mlv.fr>, "valhalla-spec-experts"
<valhalla-spec-experts@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
