JEP update: Classes for the Basic Primitives

[Kevin Bourrillion]

On Thu, Feb 10, 2022 at 4:25 AM Brian Goetz <brian.goetz at oracle.com> wrote:

I think this is a useful exercise anyway, though; we have stumbled over
> type-vs-class in a lot of places already with respect to B3, and int has
> similar problems; most uses of `int` are types, but there's also
> `int.class`, which means ... something.  What exactly?
>

We *would* normally get 2 types called `Integer` and `Integer.ref`, but
INSERT MAGIC HERE we make them come out as `int` and `Integer` instead for
compatibility. So `int.class` is just what *would* have been
`Integer.class` normally. The reason every other appearance of `int` is a
type is that the other forms of "class usage, not type usage" listed on
page 179 of JLS v17 ... all just don't happen to really apply.

(Actually it seems like that list will have to be broken up now, huh?)



>   And how does that differ from Point.class / Point.ref.class /
> Point.class.noNotThatClassTheOtherClass() ?
>

I realize you're not necessarily asking that question in this thread, but I
want to walk through how I would respond to it anyway.

First here is what I already take to be true now:

The `java.lang.Class` type doesn't precisely represent a class, but an
erased type (let's forget about `void.class`). The relationship from erased
type to class is "1 to 0..1", so for any `j.l.Class` instance that does
have a related class, that instance can go ahead and represent the class
too (e.g. iterate over its methods). But the 8 "basic" primitive types
don't have a class, and array types partly pretend to be classes, but this
is okay.

For starters this seems friendly to the arrival of Point. The relationship
becomes "1..2 to 0..1", which could break some program assumptions, but it
*basically* keeps working the same. I assume that Point.ref.class will have
a modified name in some way, and some boolean method will address
the distinction between the two, but they'll otherwise be identical.
They'll even be tied together; e.g. use reflection to modify a field in
one, it's magically changed on the other too. The mental model here is "one
class, two Classes" and while that's a bit unfortunate, again, Class
already doesn't really mean the same thing as class as it is.


* I assume the reason "the JVM type Qjava/lang/Double cannot be encoded
> with a Class object" is because the distinction between it and D is
> intentional implementation detail.
>
> Worse :(   The J and D carriers use two slots, so even if we wanted to
> abstract over the primitive carriers, this is kind of a dead end.  The
> java/lang/Double class allows us to encode List<double> with a class that
> carries a double but fits in one slot.
>

But... to be clear... it *is *also intentional implementation detail,
right? In the programming model a user can't care about the distinction?

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20220211/e46248b3/attachment.htm>