Generics Considered Harmful? Nope.

I just came across this blog entry by Ken Arnold (who's writing a book on the Java language) where the author argues that generics should not have been included in JDK 5.0:

I don't know how to ease into this gently. So I'll just spit it out.

Generics are a mistake.

This is not a problem based on technical disagreements. It's a fundamental language design problem.
and then the concluding remarks:
... it feels like the JSR process ran far ahead, without a step back to ask “Is this feature really necessary”. It seemed to just be understood that it was necessary.

It was understood wrong.

I disagree with Ken. The big point of adding generics is allowing people to use type checked collections and so on. Nearly all Java programmers use the Collections API. Using the genericized collections in JDK 5.0 is not hard - it's really easy, makes the code cleaner, and detects programmer errors. The fact that creating generic collections classes is hard is besides the point - most programmers don't have to. Yes, there's a price for having more flexible libraries: they're harder to write. That is nothing new. Developers can continue to write JDK 1.4-style APIs and libraries if they want to.

Perhaps the comparison is a bit unfair, but take EJBs. Prior to EJB3, developers had to work really hard to write an EJB. With EJB3, all they have to do is add some metadata annotations to their simple Java code, and everything else is handled automatically. Did this make writing an app server harder? You bet. But that's a fair trade-off - there will be a lot more programmers using EJBs than programmers writing app servers. While not a perfect analogy, I think the same principles apply here. For a few library designers, who now want to create generic types (they still have the option of creating old style types), life just got more complicated. However, for all their clients, life got easier. Easier is good.


You might want to look at the Generics FAQ by Angelika Langer:
to see all the little problems that can arise with Java Generics.

Sure, doing a List<Foo> foo; is simple, but as soon as you want to accept a collection object as parameter, you'll have to learn about Wildcards & Co, because, for instance, List<Object> doesn't include List<String> and so on...

Oh, and you'll have to change from Generics user to Generics programmer very fast, for instance if you want to implement Comparable or Future,... or something like that, and I wouldn't say that only hardcore programmers do that.

Having said all that, Generics are mostly useful for readability... especially for Maps where the types of Key and Value are now easily visible (and you don't have to guess them,which often annoys the hell out of me, as many devs don't bother documenting the types...). The language complexity has had a major increase, and we'll see if that was good or not...

Posted by murphee on July 07, 2005 at 11:27 PM PDT #

Maybe Im just a crusty old Java prgorammer but:

(1) I don't find generics at ALL readable, just the opposite. I thin kthey are almost as obfuscating as C genercis, which is oine big reason the original Java designers considered and rejected them.

(2) I find generics totally unecessary ebcause Java run-tike type checks. The first time I try to use an entry in a list as one object when its really another the VM throws me a ncie, easy to read exception that makes the problem clear.

(3)I agree with Ken. Generics are uncesessary, harm readability, and primarily exist to add a comnfort level for ex C++ coders who haven't gotten over their generics fetish yet. (And. to be fair, I AM an ex C+_+ coder though I \*never\* liked generics and avoided them at all costs.)

Posted by Jeff Kesselman on July 08, 2005 at 01:33 PM PDT #

C++ templates are very different from Java generics. They are also more complicated and more difficult to use and debug :)

Posted by Romain Guy on July 11, 2005 at 04:21 AM PDT #

This comment is mostly in response to murphee...

1. While the constructor line for the generics is less readable, the access code is much more readable... For example, if you are using HashMaps right now, look through your code and imagine if all of the typecasts were erased. That's what I managed to do to all of my code -- I never typecast at all anymore. Iterating through all the elements in a hashmap now is about half as much code (enhanced for loop, no typecasting, no need to cache the key each iteration, etc).

2. That is fine if you never distribute your code to anyone -- but as soon as you distribute your code, it makes the difference between whether you or your customer sees the error.

3. I quit using C++ before templates came out (ie: the very day I tried IBM's JDK 1.02 for Win3.11)... At this point, I find generics to make my code MUCH easier, cleaner and more readable...

Posted by Malachi de AElfweald on July 18, 2005 at 08:34 AM PDT #

Sorry, thought the name was above the post, I guess my comments was actually for Jeff Kesselman.

Posted by Malachi de AElfweald on July 18, 2005 at 08:35 AM PDT #

Your mistake is assuming such a sharp distinction between API creators and API users. Unfortunately, I'm afraid the needless complexity of Java generics will make your error a self-fulfilling prophecy. Because the bar has been raised so high on creating a decent API, most programmers will never regard the classes they create in that light, and will see themselves as mere consumers of APIs.

In a better world, programmers would always (or, often) think of how the classes they create are going to be used by others, and design them with that in mind. Sure, not many programmers will need to build collections, but they will often find themselves building collection-like components like registries and caches that are backed by collection classes, and need to have a flexible yet type-safe API for client code.

The painful wildcard syntax of Java generics has ensured that only a few elite developers will be able to get it right, and scads of coders will churn out classes that can't be reused because they only accept a List<Employee> but not a List<Manager> where Manager is a subclass of Employee.

Posted by David Conrad on April 03, 2006 at 02:29 AM PDT #

Post a Comment:
Comments are closed for this entry.

Tor Norbye


« July 2016