Chapter 6. Reification

The Oxford English Dictionary defines reify thus: "To convert mentally into a thing; to materialize." A plainer word with the same meaning is thingify. In computing, reification has come to mean an explicit representation of a typethat is, run-time type information. In Java, arrays reify information about their component types, while generic types do not reify information about their type parameters.

The previous chapter was, in a sense, about the advantages of not reifying parameter types. Legacy code makes no distinction between List<Integer> and List<String> and List<List<String>>, so not reifying parameter types is essential to easing evolution and promoting compatibility between legacy code and new code.

But now the time has come to pay the piper. Reification plays a critical role in certain aspects of Java, and the absence of reification that is beneficial for evolution also necessarily leads to some rough edges. This chapter warns you of the limitations and describes some workarounds. The chapter deals almost entirely with things you might wish you didn't need to knowand, indeed, if you never use generic types in casts, instance tests, exceptions, or arrays then you are unlikely to need the material covered here.

We begin with a precise definition of what it means for a type in Java to be reifiable. We then consider corner cases related to reification, including instance tests and casts, exceptions, and arrays. The fit between arrays and generics is the worst rough corner in the language, and we encapsulate how to avoid the worst pitfalls with the Principle of Truth in Advertising and the Principle of Indecent Exposure.