I wish there would just be one (int) or maximum 2 (int.Box)...

In MVT, there were separate carrier types (Q and L) for values and references.

Oh right, well that clears that up.

and

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:

https://stackoverflow.com/a/5086340

> [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.)

[0] http://mail.openjdk.java.net/pipermail/valhalla-spec-observe...