Value types questions & comments

[Ali Ebrahimi]

Hi

On Wed, Apr 13, 2016 at 1:21 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> > I would assume we're not actually changing anything about primitive
> boxing, here...?
>
> So, this is rife with tradeoffs….
>
> The legacy boxes are inferior to the new boxes, for a number of reasons.
> The association between QComplex; and LComplex; is mechanical and simple,
> whereas the association between int and Integer is ad-hoc and complex.  And
> since the new boxes are new, they can be defined from the get-go to have
> relaxed identity semantics, enabling optimizations and defending against
> possible bugs (e.g., they could throw when synchronized upon.)  Whereas its
> valid now to synchronize on a j.l.Integer, and existing code does this
> (shame, shame), meaning that we can’t necessarily take liberties with the
> identity of the box for optimization purposes.
>
> So it would be great if we could get away with having new mechanically
> generated primitve box classes, and deprecate Integer, but I have deep
> doubts we’ll be able to get away with that.  So, probably right that we’re
> stuck with primitive boxing mostly as is.
>
> >
> > We have classes at the source level — this will probably expand to
> include value types.  We have class files — this will probably similarly
> expand.  I don’t think these will be controversial.  But I think we need to
> call the runtime entities something else — like TYPE and TYPE MIRROR.  The
> meaning of “class” is already too overloaded.  Again, though, the game here
> is to frame the old reality as a lower-dimensional projection of the new
> reality, and this doesn’t seem impossible.
> >
> > "Is a class from the source/bytecode perspective, isn't a class from the
> runtime perspective" is worth shooting for, but it seems difficult to even
> get it down to something that simple. I mean, at runtime this is still a
> thing that gets loaded and initialized by a class loader, yes? I fear we
> will never find a clean way to address this.
>
> One terminology we’ve been experimenting with is having “class” and
> “species” (think back to middle school: kingdom, phylum, class, order,
> family, genus, species.)  List is a class; List<int> and List<erased> are
> species of List.  Similarly, the boxed projection and the value projection
> of Complex are both species of class Complex.
>
> Not clear whether this is the right terminology, but it gives users a way
> to to keep thinking that List is a class, while recognizing that the beasts
> List<int> and List<erased> are at the same time both of class List and also
> of different species.

By assuming, we able to reduce specialization to* Constant Pool*
specialization,
can we say a class List would have multiple *Run Time Constant Pool*
in Valhalla
JVM.
So, can we say List<int> and List<erased> are at the same time both of
class List and have different *Constant Pool.*
This is so ideal!

-- 

Best Regards,
Ali Ebrahimi