Value types questions & comments
ali.ebrahimi1781 at gmail.com
Tue Apr 12 21:48:31 UTC 2016
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*
can we say a class List would have multiple *Run Time Constant Pool*
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!
More information about the valhalla-spec-observers