Java Generics and Collections
Maurice Naftalin
Philip Wadler
Beijing Cambridge Farnham Kln Sebastopol Tokyo
We dedicate this book to Joyce Naftalin, Lionel Naftalin, Adam Wadler, and Leora Wadler
Maurice Naftalin and Philip Wadler
A Note Regarding Supplemental Files
Supplemental files and examples for this book can be found at http://examples.oreilly.com/9780596527754/. Please use a standard desktop web browser to access these files, as they may not be accessible from all ereader devices.
All code files or examples referenced in the book will be available online. For physical books that ship with an accompanying disc, whenever possible, weve posted all CD/DVD content. Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to .
Preface
Java now supports generics , the most significant change to the language since the addition of inner classes in Java 1.2some would say the most significant change to the language ever.
Say you wish to process lists. Some may be lists of integers, others lists of strings, and yet others lists of lists of strings. In Java before generics this is simple. You can represent all three by the same class, called List
, which has elements of class Object
:
list of integers | List
|
list of strings | List
|
list of lists of strings | List
|
In order to keep the language simple, you are forced to do some of the work yourself: you must keep track of the fact that you have a list of integers (or strings or lists of strings), and when you extract an element from the list you must cast it from Object
back to Integer
(or String
or List
). For instance, the Collections Framework before generics made extensive use of this idiom.
Einstein is reputed to have said, Everything should be as simple as possible but no simpler. And some might say the approach above is too simple. In Java with generics you may distinguish different types of lists:
list of integers | List
|
list of strings | List
|
list of lists of strings | List>
|
Now the compiler keeps track of whether you have a list of integers (or strings or lists of strings), and no explicit cast back to Integer
(or String
or List
) is required. In some ways, this is similar to generics in Ada or templates in C++, but the actual inspiration is parametric polymorphism as found in functional languages such as ML and Haskell.
Part I of this book provides a thorough introduction to generics. We discuss the interactions between generics and subtyping, and how to use wildcards and bounds; we describe techniques for evolving your code; we explain subtleties connected with casts and arrays; we treat advanced topics such as the interaction between generics and security, and how to maintain binary compatibility; and we update common design patterns to exploit generics.
Much has been written on generics, and their introduction into Java has sparked some controversy. Certainly, the design of generics involves swings and roundabouts: making it easy to evolve code requires that objects not reify run-time information describing generic type parameters, but the absence of this information introduces corner cases into operations such as casting and array creation.We present a balanced treatment of generics, explaining how to exploit their strengths and work around their weaknesses.
Part II provides a comprehensive introduction to the Collections Framework. Newton is reputed to have said, If I have seen farther than others, it is because I stand on the shoulders of giants. The best programmers live by this motto, building on existing frameworks and reusable code wherever appropriate. The Java Collections Framework provides reusable interfaces and implementations for a number of common collection types, including lists, sets, queues, and maps. There is also a framework for comparing values, which is useful in sorting or building ordered trees. (Of course, not all programmers exploit reuse. As Hamming said of computer scientists, Instead of standing on each others shoulders, we stand on each others toes.)
Thanks to generics, code using collections is easier to read and the compiler will catch more type errors. Further, collections provide excellent illustrations of the use of generics. One might say that generics and collections were made for each other, and, indeed, ease of use of collections was one of the main reasons for introducing generics in the first place.
Java 5 and 6 not only update the Collections Framework to exploit generics, but also enhance the framework in other ways, introducing interfaces and classes to support concurrency and the new enum
types. We believe that these developments mark the beginning of a shift in programming style, with heavier use of the Collections Framework and, in particular, increased use of collections in favor of arrays. In Part II, we describe the entire framework from first principles in order to help you use collections more effectively, flagging the new features of Java 5 and 6 as we present them.
Following common terminology, we refer to the successive versions of Java as 1.0 up to 1.4 and then 5 and 6. We say Java before generics to refer to Java 1.0 through 1.4, and Java with generics to refer to Java 5 and 6.
The design of generics for Java is influenced by a number of previous proposalsnotably, GJ, by Bracha, Odersky, Stoutamire, and Wadler; the addition of wildcards to GJ, proposed by Igarashi and Viroli; and further development of wildcards, by Torgersen, Hansen, Ernst, von der Ah, Bracha, and Gafter. Design of generics was carried out under the Java Community Process by a team led by Bracha, and including Odersky, Thorup, and Wadler (as parts of JSR 14 and JSR 201). Oderskys GJ compiler is the basis of Suns current javac
compiler.
Obtaining the Example Programs
Some of the example programs in this book are available online at:
If you cant get the examples directly over the Internet but can send and receive email, you can use ftpmail to get them. For help using ftpmail , send an email to
with no subject and the single word help in the body of the message.
How to Contact Us
You can address comments and questions about this book to the publisher:
OReilly Media, Inc. |
1005 Gravenstein Highway North |
Sebastopol, CA 95472 |
(800) 998-9938 (in the United States or Canada) |
(707) 829-0515 (international/local) |
(707) 829-0104 (fax) |
OReilly has a web page for this book, which lists errata and any additional information. You can access this page at:
http://www.oreilly.com/catalog/javagenerics |
To comment or ask technical questions about this book, send email to:
For more information about books, conferences, software, Resource Centers, and the OReilly Network, see the OReilly web site at: