Explain the 'super type token' (TypeReference) idiom: how does subclassing a generic type let you capture a full generic type at runtime despite erasure?

## The problem it solves Suppose you write a JSON parser and want `parse(json, ???)` to deserialize into a `List<Person>`. You cannot pass `List<Person>.class` — that literal does not exist (erasure). And passing a `List<Person>` *object* tells you nothing at runtime, because the object is erased to `ArrayList`. You need a way to *hand the compiler a generic type and have it preserved to runtime*. The **super type token** (a.k.a. *Gafter's gadget*, after Neal Gafter) does exactly that. ## The mechanism step by step Recall the key fact from the Signature-attribute topic: **the generic type in a *declaration* survives in the class-file `Signature` attribute, and `Class.getGenericSuperclass()` can read it.** A class's `extends Foo<Bar>` clause is such a declaration. 1. Define an abstract generic holder: ```java abstract class TypeRef<T> { private final Type type; protected TypeRef() { Type superclass = getClass().getGenericSuperclass(); // TypeRef<List<String>> this.type = ((ParameterizedType) superclass).getActualTypeArguments()[0]; } public Type getType() { return type; } } ``` 2. The caller instantiates an **anonymous subclass**, baking the desired type into the `extends` clause: ```java TypeRef<List<String>> ref = new TypeRef<List<String>>() {}; ``` The `{}` is essential — it creates a *new subclass* whose superclass is `TypeRef<List<String>>`. That superclass declaration is recorded in the anonymous class's `Signature` attribute. 3. At runtime, `getClass()` on that instance returns the anonymous subclass; `getGenericSuperclass()` returns the `ParameterizedType` `TypeRef<List<String>>`; `getActualTypeArguments()[0]` is the `Type` for `List<String>` — a `ParameterizedType` whose raw type is `List` and whose argument is `String`. The **whole** generic type, nested arguments and all, is recovered. ## Why the empty braces matter Without `{}` you would have `new TypeRef<List<String>>()` — but `TypeRef` is abstract here, and more importantly *no subclass is created*, so there is no `extends TypeRef<List<String>>` declaration to read. The token works *because of inheritance*: the type argument lives in a subclass's superclass declaration, which is exactly the kind of declaration the Signature attribute preserves. This is the canonical demonstration that **the declaration-vs-value distinction is the whole game** — you smuggle the type into a declaration rather than a value. ## Real-world implementations - **Jackson**: `new TypeReference<List<Person>>(){}` → `mapper.readValue(json, ref)`. - **Gson**: `new TypeToken<List<Person>>(){}.getType()`. - **Guice**: `TypeLiteral<List<Person>>` for binding generic types. - **Spring**: `ParameterizedTypeReference<List<Person>>` for `RestTemplate`/`WebClient` responses. All are the same idiom with different names. ## Limits and pitfalls - It captures **fully reified, concrete** type arguments only. `new TypeRef<List<T>>(){}` where `T` is itself a type variable of the *enclosing* generic method captures a `TypeVariable`, not a concrete type — the concrete `T` is still erased. You must spell out the concrete type at the construction site. - It allocates a small object (the anonymous subclass instance) per token; usually negligible, sometimes cached. - If a bytecode tool strips Signature attributes, the token degrades — `getGenericSuperclass()` falls back to the raw `Class` and the cast to `ParameterizedType` fails. ## The takeaway A super type token is the practical, idiomatic answer to 'how do I pass `List<String>` as a value at runtime?': you cannot pass the *type argument of a value*, so you encode it as the *type argument of a superclass declaration*, where erasure's Signature-attribute retention lets reflection read it back.