The fate of int, int.ref, and Integer

[Kevin Bourrillion]

Just want to record in *this* thread that the new thread "Evolving the
wrapper classes
<https://mail.openjdk.java.net/pipermail/valhalla-spec-observers/2020-June/001275.html>"
is easing some of my confusion and some of my concerns; anyone coming
across this should probably go there now.

On Sat, Jun 6, 2020 at 12:10 PM John Rose <john.r.rose at oracle.com> wrote:

> On Jun 5, 2020, at 5:43 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>
> The move of saying `Integer` *is* `int.ref` makes these problems go away.
> This seems too good to pass up preemptively.
>
>
> I agree.  And this leads us into a maze of twisty passages.
> Full of uninsulated electrified wires and third rails to avoid.
>
> One tactic I like to get through the maze is to find a way to
> add some ad hoc polymorphism to Integer, while keeping it
> sealed up as a final class, like today.  It seems to need to cover
> both good old identity objects (like new Integer(42)) and also
> new inline objects ((Integer)42, boxed as before, but via a new
> subtype relation).  This means there are two object types
> floating around, identity-Integer and int, plus an API type,
> Integer-as-super.  I think the notion of species (as a finer
> grained subdivision of types, under class) can be used to
> create the necessary distinctions, without introducing
> a lot of new types, and breaking reflection.
>
> In the spirit of brainstorming, here are more details on
> such a path, a that might lead us through the maze.
>
> Given this:
>
> int.ref id = new Integer(42);  //identity object
> int.val x = id;
> int.val y = 42;
> int.ref z = y;
>
> …we could choose to arrange things so that all of
> x, y, z are inline objects (true “ints”), while id retains
> its special flavor.  Also, Object.getClass could report
> Integer.class for *all* of those values (even y).  This
> could be justified by revealing “int” as, not a class,
> but a *species* of Integer.  So that Object.getSpecies
> would report the further details:  For id it is the
> the version of Integer which holds identity (which
> doesn’t need a name I suppose) and for x/y/z it
> reports the species reflector for int.
>
> If we further use a muddied java.lang.Class to
> continue to represent non-classes like “int”,
> we have to double down on the idea of a “crass”,
> or “runtime class-like type”.  In that case we can
> have getSpecies return a crass, and then:
>
> assert 42.getClass() == Integer.class;
> assert 42.getSpecies() == int.class;
> assert new Integer(42).getSpecies() == (something else);
>
>
>
>
>

-- 
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/20200617/7ef00bf6/attachment.htm>