Java Generics and Collections, 2nd Edition

Chapter 18. Design Retrospective

At the start of Chapter 17, we noted that the Java community’s long experience with the Collections Framework provides the opportunity to derive some practical lessons in how to use it. This chapter uses that experience for a different purpose: to review some of the design decisions and trade-offs that shaped the Collections Framework at its inception and have continued to influence its evolution ever since.

Fundamental Issues in the Collections Framework Design

The Java Collections API Design FAQ, written in 1998, when the framework was first published, begins with this question:

Why don’t you support immutability directly in the core collection interfaces so that you can do away with optional operations (and UnsupportedOperationException)?

and answers it in this way:

This is the most controversial design decision in the whole API. Clearly, static (compile time) type checking is highly desirable, and is the norm in Java. We would have supported it if we believed it were feasible…​

Over twenty-five years later, the first sentence is still undoubtedly true. A review of the proposal for the second edition of this book can stand for many comments on this decision:

Even the modest additions, such as immutable collections, are hamstrung by the requirement to implement the mutation methods of the Collections APIs—and just throwing UnsupportedOperationException is a horrible hack, to put it politely. The immutability of Java’s new collections is not ...