The fate of int, int.ref, and Integer

John Rose john.r.rose at
Sat Jun 6 19:08:37 UTC 2020

On Jun 5, 2020, at 5:43 AM, Brian Goetz <brian.goetz at> 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);

More information about the valhalla-spec-observers mailing list