• 02 Jan, 2026 *

The Java Language Specification sometimes uses invocation in the context of a type. That was surprising enough to me that I searched the specification to see if, for example, "invocation of Class" is defined anywhere in the specification. It is not.

It is however used in the generics tutorial, written by Gilad Bracha, one of the architects of Java’s generics, where it is written that an "invocation of a generic type is generally known [sic] as a parameterized type."

An invocation of a method is the act of replacing the method’s (named) parameters with actual arguments. Just so, an invocation of a type is the act of replacing the type’s "formal" (type) parameters with "actual" (type) arguments. (The word "formal" does not seem to add any information above and beyond that already conveyed by "parameter", but it is widely used in conjunction with it. The same sort of thing seems to be true of "actual". These terms are sometimes shortened to "formals" and "actuals" in other readings and literature.)

Since an "invocation" of a "generic type" (a type with formal parameters) is "generally known" as a "parameterized type", then presumably parameterization is, somewhat oddly, the act of supplying (actual) arguments for (formal) parameters, further confusing the often conflated definitions of parameters and arguments.

Where this gets especially murky is in a declaration such as Box<T>. What is T? On the one hand, it is the (formal) type parameter declared by Box. On the other hand, it seems that it must somehow also be the (actual) type argument that parameterizes Box. (Recall that since Box<T> is a parameterized type, then it is also a type invocation (assuming that "generally known as" is symmetric), and a type invocation is the supplying of an (actual) argument for a (formal) parameter, so T must also represent a type argument—in this case a type variable.)

This explains, in part, the confusion in the java.lang.reflect.* classes around TypeVariable. TypeVariable clumsily serves two masters: it is both a representation of the (formal) type parameter (it has a name and a namespace which was grafted on in Java 5), and a representation of the (actual) type argument (it has bounds).

The Java language model (the javax.lang.model.* classes) handles this a little better, but also has some confusion. T seen through a formal parameter lens is represented by the TypeParameterElement interface (it has a name, like all Element subtypes, and a namespace). But unlike java.lang.reflect.TypeVariable it has an explicit reference to its (definitionally nameless) underlying type, which is guaranteed to be a javax.lang.model.type.TypeVariable. (However, somewhat confusingly, it also has a getBounds() method, which would seem to be unnecessary, since it seems to be some sort of convenience method layered on top of javax.lang.model.type.TypeVariable#getUpperBound().)