Having Box-es (legacy java.lang.Integer), Lox-es (new lightweight value boxes) and Pox-es (primitive wrapper value classes) and primitives (int-s) would complicate the understanding...
I wish there would just be one (int) or maximum 2 (int.Box)...
In value-capable modules, the class-file descriptor language is extended to include Q-types, which directly denote unboxed value types. The descriptor syntax is “QBinaryName;”, where BinaryName is the internal form of the VCC name. (The internal form substitutes slashes for dots.) In fact, the class name must be that of the value type derived from a value-capable class.
By comparison, a standard reference type descriptor is called an L-type. For a value-capable class C, we may speak of both the Q-type and the L-type of C. Note that usage of L-types is not correlated in any way with usage of Q-types. For example, they can appear together in method types, in arbitrary mixtures.
See also the JVM bytecode standard, which has the following "things", that explain the "L" part:
> [0] Logically speaking, we have two things we want to do, and
that unfolds to a choice between three "worlds" of up to four
distinct kinds: L/Q/U/R. L is always present because it is
a legacy model for reference types. Q is always present
because we know we need (at least sometimes) to make
a syntactic distinction between flattened values and legacy
objects.
> (Why not just always look inside the classfile? Because
the verifier cannot be expected to load a class for every
type it sees, so needs a descriptor kind character from
time to time.)
