Forgot your password?
typodupeerror
Book Reviews Books Media

Java Generics and Collections 278

Posted by samzenpus
from the read-all-about-it dept.
andrew cooke writes "Java 6 was recently released, but many programmers are still exploring the features introduced in Java 5 — probably the most significant changes in the language's twelve year history. Amongst those changes (enumerations, auto-boxing, foreach, varargs) generics was the most far-reaching, introducing generic programming in a simpler, safer way than C++ templates and, unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code." Read on for the rest of Andrew's review.
Java Generics and Collections
author Maurice Naftalin, Philip Wadler
pages 273
publisher O'Reilly Media, Inc.
rating 9/10
reviewer Andrew Cooke
ISBN 978-0-596-52775-4
summary Guide to Java generics; also includes interesting discussion of collection classes.


Given the history of Generic Java, Naftalin and Wadler's Java Generics and Collections has a distinguished pedigree. In this review I'll argue that this is a new classic.

If you're a Java programmer you've probably heard of generics, an extension to the type system that was introduced in Java 5. They give you, as a programmer, a way to write code even when you don't know exactly what classes will be used.

The obvious example is collections — the author of a List class has no idea what type of objects will be stored when the code is used.

Before generics, if you wanted to write code that handled unknown classes you had to use make use of inheritance: write the code as if it would get Objects, and then let the caller cast the result as necessary. Since casts happen at runtime any mistakes may cause a runtime error (a ClassCastException).

Generics fix this. They let you write code in which the classes are named (parameters) and the compiler can then check that the use of these class parameters is consistent in your program. So if you have a List of Foo instances you write List<Foo> and the compiler knows that when you read that list you will receive a Foo, not an Object.

I'll get to the book in a moment, but first a little history. If you know any type theory — particularly as used in functional languages like ML and Haskell — then you'll recognize my quick description above as parametric polymorphism. You'll also know that it is incredibly useful, and wonder how Java programmers could ever have managed without it.

Which explains why Philip Wadler, one of the people responsible for Haskell, was part of a team that wrote GJ (Generic Java), one of the experimental Java mutations (others included PolyJ and Pizza) that, back in the day (late 90s) helped explore how parametric polymorphism could be added to Java, and which formed the basis for the generics introduced in Java 5.

So if you want to understand generics, Wadler is your man. Which, in turn, explains why I jumped at the chance to review O'Reilly's Java Generics and Collections, by Maurice Naftalin and Philip Wadler.

This is a moderately slim book (just under 300 pages). It looks like any other O'Reilly work — the animal is an Alligator this time. It's well organized, easy to read, and has a decent index.

There's an odd discrepancy, though: Wadler is the generics Guru; this is going to be `the generics reference'; generics are sexy (in relative terms — we're talking Java here) and collections are not; the title has "Java Generics" in great big letters with "and Collections" in little tiny ones down in a corner. Yet very nearly half this book is dedicated to collections.

Generics is a great, practical read. It starts simply, introducing a range of new features in Java 5, and then builds rapidly.

If you are completely new to generics, you'll want to read slowly. Everything is here, and it's very clear and friendly, but there are not the chapters of simple, repeated examples you might find in a fatter book. Within just 30 pages you meet pretty much all of generics, including wildcards and constraints.

If that makes your head spin, don't worry. Read on. The next hundred or so pages don't introduce any new syntax, but instead discuss a wide range of related issues. The chapters on Comparisons and Bounds and Declarations contain more examples that will help clarify what generics do. And the following chapters on Evolution, Reification, and Reflection will explain exactly why.

So the first seven chapters introduce generics and then justify the implementation — any programmer that takes the time to understand this will have a very solid base in generics.

There are even some interesting ideas on how Java could have evolved differently — section 6.9 Arrays as a Deprecated Type presents a strong case for removing arrays from the language. It's a tribute to the clarity and depth of this book that the reader is able to follow detailed arguments about language design. Fascinating stuff.

The next two chapters, however, were my favorites. Effective Generics and Design Patterns give sensible, practical advice on using generics in your work, including the best explanation of <X extends Foo<X>> I've seen yet (so if you don't know what I am talking about here, read the book).

(A practical word of advice — if at all possible, use Java 6 with generics. Java 5 has a sneaky bug).

The Collections part of the book was more along O'Reilly's `Nutshell' lines: the different chapters explore different collection types in detail. I must admit that at first I skipped this — it looked like API docs re-hashed to extend the size of the book.

Then I felt bad, because I was supposed to be reviewing this book (full disclosure: if you review a book for Slashdot you get to keep it). And you know what? It turned out to be pretty interesting. I've programmed in Java for (too many) years, and I guess I've not been quite as dedicated to tracking how the library has changed as I should have been — I learned a lot.

Again, a wide range of readers are welcome. This is more than a summary of the Javadocs, ranging from thumbnail sketches of trees and hashtables to a discussion of containers intended for multi-threaded programming.

The way I see it now, this part is a bonus: the first half, on generics, makes this book one of the standards; the second half is an extra treat I'm glad I stumbled across (I guess if you're some kind of weird collection-fetishist maybe it's even worth buying the book for).

I've used generics since the first beta release of Java 5 and had experience with parametric polymorphism in functional languages before that (in other words, I can tell my co- from my contra-variance). So I guess I'm heading towards the more expert end of the spectrum and I was worried I'd find the book boring. It wasn't. After claiming to be expert I don't want to spoil things with evidence that I'm actually stupid, but reading this book cleared up a few `misunderstandings' I'd had. I wish I had read it earlier.

If you're new to generics, and you don't mind thinking, I recommend this book. If you're a Java programmer who's a bit confused by <? super Foo> then this is the book for you.

The only people who shouldn't read this are people new to Java. You need to go elsewhere first. This is not a book for complete beginners. This is a great book in the classic — practical, concise and intelligent — O'Reilly mould.


You can purchase Java Generics and Collections from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Java Generics and Collections

Comments Filter:
  • by Z00L00K (682162) on Monday April 16, 2007 @02:20PM (#18753387) Homepage
    But it can in some cases be tricky when you get a really complex structure of Vectors containing Vectors containing Comparables. Not that it's impossible, but it can be a challenge.

    One thing that I found in Java5 was that it lacked generics for several cases, e.g. Awt/Swing objects that were able to contain Object themselves. Not that it was a big problem, but it wouldn't have been bad to have that support there too...

    Anyway - Generics is one of the best features of added to Java lately. It really helps. How I miss it when I'm programming for J2ME...

    • I've had trouble with generics myself. I don't claim to be a programming superstar though, so I might be overlooking something simple. My problem is that I cannot get a (useful) array out of a vector. No matter what I do, Vector.toArray() will only return an array of Objects. But I don't want Object[], I want something specific. And I thought that is what generics were supposed to do: declare a vector, use generics to tell Java what kind of objects are in it, and get rid of all those nasty casts. Unf
      • by bunratty (545641)
        It's been years since I've written Java, but
        SpecificClass[] sca = scv.toArray(new SpecificClass[0]) [sun.com];
        should do it, right?
      • by twbecker (315312)
        I wouldn't hold your breath if you're waiting for a deprecated class like Vector to get retrofitted with generic methods.
        • by bunratty (545641)
          As I show above, it already has been. In fact, being an AbstractList, it must have generic methods.
          • by twbecker (315312)
            I stand corrected. My intent was more to prod the OP into moving away from using Vectors, but that information is valuable nonetheless.
      • by MCTFB (863774)
        Generally, the way you do this (with or without generics), is to call the toArray(Object[] array) method, rather than the toArray() method.

        Basically, just do this where foo is the type in the array and fooList is your Collection of Foo objects.

        Foo[] foos = new Foo[fooList.size()];
        fooList.toArray(foos);

        The foos array now is populated with the contents of the fooList.

        The toArray() will return an array of type Object, so you will need to use the argument supplied version of the method if you want the compon

    • by roscivs (923777)

      But it can in some cases be tricky when you get a really complex structure of Vectors containing Vectors containing Comparables. Not that it's impossible, but it can be a challenge.

      The problems with Comparables usually come about because of a failure to implement Comparable instead of just implement Comparable. Java typically won't tell you that's the problem, it will steer you off into some other wild goose chase, but if you implement Comparable the challenges typically disappear.

  • by Lockejaw (955650) on Monday April 16, 2007 @02:21PM (#18753389)
    ... was a quick and dirty intro to Java generics. I've had trouble finding that on Sun's site (especially ones with good code examples), but Google returns some good results. Given the availability of free tutorials, I probably wouldn't buy the book just for that.
    That said, this sounds like a good resource on Java Collections in general (though Sun's javadocs are pretty nice themselves), as well as the other features introduced in Java 5. There also seems to be some discussion of more complex generic structures.
    I'm still a bit lukewarm about buying it, but if I were getting back into a lot of Java stuff, I probably would.
  • by Cyberax (705495) on Monday April 16, 2007 @02:25PM (#18753445)
    Java generics are not real generics, then you parametrize a generic class in Java you don't really create a new type. You just attach some information for Java compiler so it can perform automatic casting and save you some typing.

    Java generics don't provide real type safety, for example, you can easily put Strings in List (that's why Collections.checkedCollection kludge was added).

    In C# (or C++), on the other hand, parameterizing a generic type creates a _new_ _type_ which guarantees type safety and allows some quite interesting tricks. For example, in C# generics can be parametrized by primitive types and structs (which don't exist in Java, anyway) so you can have List without overhead of boxing. That's impossible in Java.
    • Re: (Score:3, Informative)

      by Cyberax (705495)
      Sorry, Slashdot ate "<" and ">".

      "you can easily put Strings in List" should be "you can easily put Strings in List<Integer>".

      "so you can have List without overhead of boxing" should be "so you can have List<Integer> without overhead of boxing"
    • by CastrTroy (595695)
      Am I the only one who tries to do away with arrays whenever possible? Sure I use them in some cases, but their limited ability to resize is something I find to be a real issue. With Lists and Generics, I find I'm using Arrays less and less, even in cases where an Array would probably work, just because lists offer so much more functionality.
      • Re: (Score:2, Informative)

        by Radres (776901)
        If you care about memory usage and/or performance, you will try to replace dynamic memory structures like Lists and generics with the much more efficient array where possible. Make sure you understand your app's design and requirements before you go around creating dynamic memory structures everywhere. Memory and performance may not seem like a big concern now, but there will come a time when it becomes important and you will kick yourself for not having learned how to manage it properly.
    • by Jeffrey Baker (6191) on Monday April 16, 2007 @02:45PM (#18753767)
      Sure, Java generics work at compile time instead of runtime. At runtime, you can do whatever you want. But it's still true that Java generics provide a much safer interface which prevents a wide field of bugs, and which makes code much more readable. I think it's obvious that

      l = new List();
      l.add(foo);
      Foo foo = l.get(0);

      is much safer and easier to read than

      v = new Vector();
      v.add(foo);
      Foo foo = (Foo) v.get(0);

      especially when you consider that the obvious mistake

      v = new Vector();
      v.add(bar);
      Foo foo = (Foo) v.get(0);

      throws a cast exception at runtime.

      I've read a lot of complaints that type erasure (the means by which Java generics are implemented) doesn't solve the whole problem. But there was a certain class of program that generics solved, and it has made development in Java much more productive and safe.
      • by Cyberax (705495)
        Yes, I absolutely hate to maintain old pre-1.5 code because generics make it so much easier to use.

        But the problem is that generics could be implemented in a much better way, C# proves that.
        • by thammoud (193905)
          The .NET library contain two collection classes. One generic and the other non-generic.

          System.Collections.Generic.List l = new System.Collections.Generic.List();
          System.Collections.ArrayList l = new System.Collections.ArrayList();

          Doesn't sound very elegant. At least in Java you have only one set.

    • by twbecker (315312)
      Sure, you can put Strings in an Integer collection, but you'll get a warning at compile time about using a raw type. The alternative, is to create a new type, lose all your backwards compatibility, and force folks to upgrade their entire codebase when moving to Java 5. Personally, I think what was done was a reasonable compromise.
    • by roscivs (923777) on Monday April 16, 2007 @03:00PM (#18754005) Homepage

      Java generics don't provide real type safety, for example, you can easily put Strings in List (that's why Collections.checkedCollection kludge was added).

      I've never understood this objection. This will always generate a compiler warning, and depending on your compiler settings may not even compile successfully. The only time you might turn those warnings off is when you're having to deal with non-genericized legacy code.
    • by 0xABADC0DA (867955) on Monday April 16, 2007 @04:07PM (#18754907)
      What you are missing is that it's a *good* thing that Java generics are not "real" generics.

      With "real" generics the system has two choices: either generate lots of bloated specific instances of the code, or add type-checking at runtime. CLR designers thought they were going to do the former and it was going to be 'uber leet' and fast, but found out it's not practical (most of the optimizations that C++ uses to limit bloat do not apply well in a dynamic language) so they got stuck with the latter, for objects.

      In Java, the code goes to add something to a generic list for example and it does one cast to the generic parameter type. Many times it can completely remove this check since it already knows from flow that the type is compatible. CLR can do this too, but only if it *also* knows the specific instance of the list (what the generic parameter types are), so it can remove fewer checks. This makes optimization harder as well since each use of a generic parameter can potentially block inlining and/or hoisting.

      On top of that, the tests CLR has to do are *much* slower since they have to check many parallel type hierarchies (one per generic type references). For example, when passing a LinkedList of Integers to a parameter of type List of Numbers CLR has to in effect check both List assignable from LinkedList and Number assignable from Integer.

      So in the vast majority of code not only do you end up with more checks but slower ones, and CLR has to maintain a complicated hierarchy of instantiated types to optimize this. All so primitives can be used faster in some cases, which is pretty ironic since in my experience these cases are usually easy to optimize by hand to use an array or patch out to inline C++ or JNI'd code.

      In other words they messed up their runtime for bullet points without considering the implications. Not even to mention that in Java if you don't like generics, you just don't use them.
      • Re: (Score:3, Interesting)

        by Taagehornet (984739)

        What you are missing is that it's a *good* thing that Java generics are not "real" generics.

        It appears that you're confusing CLI generics and C++ templates. I must admit that I have little knowledge of C++ templates, but a comparison of Java's Generics by Type Erasure and C#/CLI's true generics definitely favours the latter.

        The following set of slides by Peter Sestoft sums up the differences pretty well: http://www.itu.dk/courses/PFOO/F2006/diku-javacsha rpgenerics.pdf [www.itu.dk]

        Slide no. 23 sums up the majo

  • by Anonymous Coward
    Amongst those changes (enumerations, auto-boxing, foreach, varargs) generics was the most far-reaching, introducing generic programming in a simpler, safer way than C++ templates and, unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code.

    Yeah, and by maintaining that backwards compatibility, they became totally worthless.

    The only thing it offers is some compile-time sanity checking, but even that can be disabled through use of a new compiler pragma directive to su
    • by LarsWestergren (9033) on Monday April 16, 2007 @03:27PM (#18754409) Homepage Journal
      The only thing it offers is some compile-time sanity checking, but even that can be disabled through use of a new compiler pragma directive to suppress warnings.

      Many operations are ERRORS, not warnings. This is caught by IDEs, and by the compiler.

      In order to make it possible to interact with legacy code, you can pass a generified collection to a method that expects a "raw" collection. This gives you a very clear warning. So for 95% of all use cases, generics give you a lot of assistance. You manage to come up with a remaining 5% example, where a programmer casts, suppresses compiler warnings, and then passes in a object of the wrong type, and this makes generics worthless?

      Wadler was involved with the design of Haskell, and he and people like Gilad Bracha designed Java generics. I trust their skills more than a Slashdot Anonymous Coward.
    • Re: (Score:3, Insightful)

      by DavidYaw (447706)

      Ever wondered why the collection classes require you to pass in an array to the toArray(T[]) method? Because Java generics throw away the class information after compile time (although there's no reason they need to do this, they could have kept it and maintained backwards compatibility), so you have to pass in an array to give the type information Java removed.

      A) Before generics were added, the toArray(T[]) function already existed as toArray(Object[]). Since this function pre-dates generics, the fact that

    • Well, we could be stuck with how it is with .NET... needing a separate runtime for each and every major version.

      I personally would hate to have 7 different JREs, trying to figure out which one I need for which programs.
    • by natet (158905)

      Ever wondered why the collection classes require you to pass in an array to the toArray(T[]) method? Because Java generics throw away the class information after compile time (although there's no reason they need to do this, they could have kept it and maintained backwards compatibility), so you have to pass in an array to give the type information Java removed.

      I think you may be getting your facts wrong on this one. The toArray() methods precede Java Generics by at least a version. Those methods exist

  • I don't use any of the generic syntax at all in my code as I feel it makes it virtually unreadable to other developers. The syntax is just absolutely horrible, plus as most adept Java programmers know (been coding in Java myself since 1.0), the way generics is implemented in Java is broken (depending on your point of view on this matter).

    Then there is the Collections API itself which upon first glance seems like it was written by amateurs who have never had to write any performance critical code in their li
    • by Cyberax (705495) on Monday April 16, 2007 @02:46PM (#18753787)
      Bullshit.

      Generics syntax is quite readable and easy-to-use, especially with good IDE support. And generics certainly make the code more readable because the add type information.

      Foreach loops, varargs and autoboxing is just a minor syntax sugar, nothing really big.

      I've used a lot of collection frameworks in a lot of languages (and even wrote my very own vector and string for C++), Java Collections Framework is quite OK. It's not hard and reasonably fast.
      • by Procyon101 (61366)
        // Java's Readable syntax, using a fold function as an example

        public interface Functor2 {
        R apply(T1 value1, T2 value2);
        }

        public static R fold(Collection coll, R init, Functor2 func) {
        R result = init;
        for (T value : coll) {
        result = func.apply(result, value);
        }
        return result;
        } // Since the compiler already knows the types from context, // this is how it might be written with absolutely no loss of
    • Re: (Score:3, Informative)

      by LarsWestergren (9033)
      Do the guys at SUN have such feature envy of C# (the bastard child of Java), that they can't just say enough is enough?

      Sun does not control the development of Java, the Java Community Process does. And it is not C# that is seen as a threat I believe, but Ruby and functional languages. There is a VERY heated debate in the Java community over the new language features that are proposed for the Java platform, and both sides put up some very convincing arguments (simplicity is good vs a language needs to evolve
    • Re: (Score:3, Interesting)

      by bckrispi (725257)

      Then there is the Collections API itself which upon first glance seems like it was written by amateurs who have never had to write any performance critical code in their lives. For this reason as well, I generally try and avoid using anything in java.util as well.

      And you can justify to your boss spending weeks implementing your own collections framework to save a whopping 50 ms of processing per day? To say nothing of the ramp-up time required of the poor schmuck who has to maintain code that uses your w

  • Generics, jeez (Score:2, Interesting)

    by kahei (466208)
    The original post is being just a little specious on generics -- the reason Java generics are backwards compatible is that they aren't generics, they're just automatic type conversions when accessing collections. Whee. C# generics may not be up to the level of true generic programming (e.g. C++) but they are at least 'templates' in the sense that ArrayList is a different type from ArrayList.

    Java has come a long way but there's still a reason Java programmers cost about 60% of the cost of actual C++ progra
  • by BitwizeGHC (145393) on Monday April 16, 2007 @02:56PM (#18753947) Homepage
    Java generics are kept back-compatible with the old VM spec by way of type erasure: parametric information is "erased" from the type when it is compiled. So List and List and List all compile down to the same type: List.

    Among other hiccups this makes it impossible to overload methods whose argument types differ only in the parametric information included with them.

    By contrast, C++ templates and C# generics create a type disjoint from all other types in the same type class for each set of parameters in the type declaration.

    Yet another sterling example of Java lossage.
    • by BitwizeGHC (145393) on Monday April 16, 2007 @02:58PM (#18753977) Homepage
      Sentence in the above post should have read as follows:

      So List<String> and List<java.math.BigInteger> and List<javax.swing.JComponent> all compile down to the same type: List.
    • by MCTFB (863774)
      Hey if you like 23234290234^345 sized megabyte applications where most of the program memory is used up by a bunch of redundant templates, then more power to yah (-:
      • C++ has that problem, but Microsoft was a bit more efficient with that in .Net. It tries to share code wherever possible.

        For structs and values, code is generated per-type. Thus, there are separate code blocks for List<int> and List<DateTime>, but multiple List<int> instances will share code.

        For classes, all instances share one single code block. Thus, List<LeftHandedScrewdriver> and List<SelfSealingStemBolt> share code.

      • by cnettel (836611)
        That's true for C++ (in most implementations and unless you are conscious about it, like STL, which casts to void* internally in several places), but for C#, a conversion is made back for all "reference types". That is, all non-value types basically share one set of IL and JITed code in the workset. The binary representation in the file will always be a single IL copy for List<int> and List<MyFancyNewObject>.

        I don't see any reason to consider the Java approach superior. The backwards compatibili

      • by jgrahn (181062)

        Hey if you like 23234290234^345 sized megabyte applications where most of the program memory is used up by a bunch of redundant templates, then more power to yah (-:
        Absurd. Let's assume I use 5 kb of std::list<T> (and that's probably generous). To use up a megabyte on that, my program would have to use lists of 200 different non-pointer types. You should probably worry more about massive, recursive inlining.
  • by mr_mischief (456295) on Monday April 16, 2007 @02:56PM (#18753951) Journal
    Wouldn't someone have to be used to _only_ Java to not be familiar with at least some of these concepts?

    Enumerations are available in Pascal and pretty much all of its descendants IIRC. It's also a type of field in an SQL database for much the same purpose as enumerations in programming languages.

    The foreach loop has been in Perl since 2.0 in 1988. C# got foreach in 2000. It's in PHP. It comes from earlier FOR..IN loops from shells.

    I'm sure there are examples of the other features which are similar to the Java version of them. The syntax may be different, and the exact details of darker semantic corners may be different. The concepts, however, are pretty easy to have run across unless someone has only used the one language.

    The review seems to imply that bringing in what has been proven to work well in other languages is too confusing and should be done at a slower pace. The truth is, people program in a subset of any general-purpose language at first, and that subset grows over time. If someone works with code from other programmers, one picks up the parts of the language to which they are exposed as they are exposed to them. No one needs to cram all night to be up on all the new features of a language the day after the manual gets updated.
  • introducing generic programming in a simpler, safer way than C++ templates and, unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code."

    *prepares to be modded troll*

    People need to stop comparing Java/C# generics to C++ templates - they take similar syntax, but they aren't the same thing. I'm not sure how one can even be safer than the other.

    And C# 2.0 maintained compatibility with existing C# 1.0 code (you still have access to the old containers) while actua

    • by jinxidoru (743428)
      This is so true. Although generics give Java/C# a similar tool, they are very different. C++ templates actually create entirely different chunks of assembly code. C++ templates provide compile-time type-checking but they also provide run-time binaries. This makes C++ templates very fast and able to create extremely optimized code for each type used. This may surprise you, because you've heard from people with no C++ knowledge that templates are slow. People who say that are not familiar with templates
  • Java One session (Score:5, Informative)

    by LarsWestergren (9033) on Monday April 16, 2007 @03:03PM (#18754057) Homepage Journal
    Naftalin and Wadler are also holding a Java One session this year, it is on Wednesday, session id is TS-2890. If you have a Sun Developer Connection account (free) you can watch it online after the conference is over.

    I agree with reviewer, the book is very good. It is true that Java generics is a compile time check, and that the generics information is removed (erasure). Nevertheless, that was a deliberate tradeoff for backwards compatibility, and it still makes coding complex Java a lot safer and easier. Look for instance at the 1.5 and 1.6 improvements to the concurrency libraries [sun.com] with Future, Callable and Executors.
  • The most far reaching changes to Java in Java 5 are the changes to improve support for concurrency. Generics are just syntactic sugar that improve compile time type checking. The concurrency support features offer fundamental improvements in the way you can structure your applications to take advantage of increasingly parallel hardware architectures.

  • I'm less than two weeks away from taking the Java 5 certification exam, and Generics are definitely the most difficult new concept for me to get my head wrapped around. Granted I haven't studied it nearly enough yet and haven't done any large scale projects in 1.5 (we use 1.4.2 at work), so hopefully I'll be well prepared by the time next Friday rolls around. I use the Sierra, Bates SCJP book to study and it supposedly has everything I need to know about Generics for the exam, but is it everything I need

Two is not equal to three, even for large values of two.

Working...