The fate of int, int.ref, and Integer

Kevin Bourrillion kevinb at
Fri Jun 5 02:00:19 UTC 2020

Hello friends,

A couple thoughts on the fate of the primitives and wrappers.

First, on nomenclature, I think the most useful definitions of what it
means to be an "inline type" are those that reveal the primitives to *already
be* inline types. Java's always had them, but it hasn't had
*user-defined* inline
types, because it hasn't had *inline classes* (and classes are how we
user-define types). That's clean, and it's not even a retcon.

Also on nomenclature, I want to avoid phrases like "you can expand the set
of primitives"; no, I still think that "primitives" should always apply to
the eight *predefined*, irreducible inline types. User-defined inline types
are always composite (how could they not be?).

I approve of the idea of writing etc. files in order to add
methods to `int`, and add interfaces to `int.ref`. It is fine if these
files are essentially "fake" (they don't actually bring the primitives into
existence as other classes do). I think attempts to try to make them look
"real" would mean letting them do things other inline types can't and it
definitely wouldn't seem worth it to me.

What I would explain is "In Java <X, `int` was not a class; it didn't need
to be because it had no members. Now in Java >=X that it has members and
implements `Comparable`, it is a class for that reason, but the type itself
is still predefined with or without that class."

(wart: yeah, arrays have no class, yet sure seem to have members `length`
and `clone` anyway. oh well.)

I also approve of giving the new `int` class everything it needs so that
the `Integer` class becomes obsolete; that is, there would no longer be any
good reason to use it except when forced by legacy code. (Of course,
anything that wants to depend on identity or locking of such an object I
will just declare to be legacy code, so it works!) Really though, don't
bring `getInteger` over when you do.

However, I am highly skeptical of attempts to do anything else beyond that.
I've seen, at least, the allusions to some kind of aliasing between
`int.ref` and `Integer`. That seems unnecessary to me, and more to the
point, I feel that it can only make things more confusing to users; that in
fact it will cause a large share of all the confusion they do feel. So
wait, what IS the wrapper class then? What IS this reference projection
then? I see no benefit to blurring that line, at this point.


Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at

More information about the valhalla-spec-observers mailing list