Chapter 5. Reifiable and Nonreifiable Types
By the time generics were introduced to Java in 2004, eight years after version 1.0 shipped, there were many millions of lines of code already in use in commercial applications. It is a tribute to the design of generics that the introduction was so successful, resulting in gradual generification of all major libraries and most client code within a few years, without major compatibility problems. This achievement is described in the Appendix. The key to its success was erasure, without which Java as we know it today could not exist. Legacy code makes no distinction between List<Integer>, List<String>, and List<List<String>>, so erasing parameter types is essential to easing evolution and promoting compatibility between legacy code and new code. But everything comes at a cost, and in this chapter we must settle our debts.
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 the explicit representation of a type—that is, run-time type information. In Java, a reified array retains information about its component type, whereas a reified generic type does not retain information about its type parameters.
Reification plays a critical role in certain aspects of Java, and its absence from generics, beneficial as that is for evolution, also necessarily leads to some rough edges. This chapter warns you of ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access