JEP: Extending generics to support primitive type arguments

[Paul Benedict]

Brian,

I'll start by saying this field of research is well out of my purview, but
hopefully I am communicating something useful at a high-level. In summary,
I tend to believe that the specialization of primitives should be done
rather transparently and OOP should be the favored paradigm. By that, I
mean that T<int> is really an expression for a "value based object"
singleton. For example, no matter how many T<int> are referenced, they all
refer to the same singleton instance. Existing parametrized classes assume
working with T>=Object and continue to do so. My goal, as such, is to take
away the problems that would exist if T could be an object or a primitive;
I prefer an answer where that dichotomy does not exist. As a happy
consequence, the problem of "assignment to null" also goes away since we
would continue to deal with an object (or something object-ish) in Java.

I start my introducing new specialized singletons primitive wrappers.
All the singleton classes are like Enum, in which only the JVM can
instantiate them. There is no language or runtime behavior to make your own
instance. Notwithstanding the names, let's pretend this:

T<byte> => T<SingletonByte>
T<short> => T<SingletonShort>
T<int> => T<SingletonInteger>
T<long> => T<SingletonLong>
T<float> => T<SingletonFloat>
T<double> => T<SingletonDouble>
T<boolean> => T<SingletonBoolean>
T<char> => T<SingletonChar>

Unlike today's java.lang wrappers, these classes do not contain any
instance state. They do not have an internal reference to the "value" they
represent. That's because, as singletons often do, the state information is
going to be passed around in method calls. Being a "value based object",
the only state such a being has is the value itself. So how does the
singleton know what value it is operating on? The value is going to be
masqueraded as the "this" pointer for instance operations.

[I am unsure at this point how the "this" pointer should be encoded. For
values <=32 bits, the "this" pointer could be byte/short/int/char itself;
otherwise perhaps it could be a pointer into the stack where the value
resides. I don't have an answer right now, but I sense the latter should be
preferred.

For this piece of code:
Box<int> box = new Box<int>(100);

I don't know how to write the above in bytecode, but Box receives a
SingletonInteger through a pointer that leads to the value of "100" --
either directly or through some internal data structure that the JVM knows
about. JVM internals are beyond me but I hope you get the point.

If anything I said has merit, hopefully all "value based objects" could be
represented in the same manner. That is, there is no instantiation, there
is no state, and it's all pointer based references to the value. As this is
likely to be full of holes, I hope others can contribute and build upon and
correct this.

Cheers,
Paul