Generics considered keen
Ken Arnold makes a good case for generics being poorly thought out. I take issue, though, with the claim that we should avoid them.
He makes the statement that "But we have a demonstration proof that we can live without it, namely that we have for nearly a decade." This is specious, IMO. Prior to the introduction of Java, we lived without a cross platform language with library support for networking, threading, and GUI classes. In those days, I worked on a Windows app in C++, and moving even a part of it to my Mac was a dreadful pain. While we were living without the tools Java brought, I ended up not being able to bring cool things home from work.
Different programmers apply different weights to various features, and choose environments accordingly.
Most Objective C programmers today claim that garbage collection is not needed. (At least, those that I have talked to.) After all, if you balance your release and retain calls, you get better performance for very little real work. What they miss is the complexity they have absorbed - many new Cocoa developers spend a while playing with this, then go back to Perl, or Ruby, or Java, because in those languages, they do not have to fight the collector. Thus, only those who are either suited to it, or who are practiced stayed.
I do know Cocoa, and I can handle release and retain. I still find it much more convenient to drop objects on the floor, knowing that the GC will get them as time permits. If my program starts chewing through memory, then I run JProfiler and fix the problem, but that happens perhaps once or twice in a project development cycles, and takes just a few hours. Contrast this with the larger number of hours needed during the course of development to get release and retain right, and the right solution is clear.
Thus, even though they are still living without GC, I do not believe that this is a demonstration proof that they _should_ live without GC. I, certainly, would enjoy ObjC a lot more if retain and release were no-ops.
So, back to Java.
The generic syntax gets nasty when you hit the hard parts. Clearly, that _is_ out of whack. No arguments.
What, then, are the benefits of generics that outweigh the costs? Cast elimination for Collection usage, pure and simple. By eliminating casts, I eliminate a chance for a developer to misread the API docs, or otherwise misunderstand my intent. Further, having collections return typed objects encourages people to use real objects in those collections, because they get expressive power.
My current 1.4 code is littered with casts, primarily in the database access toolkit code and its clients. These methods return Collections of Objects, when I know for a fact that they are returning Collections of Thingie instances. Every single cast means that programmer has to go look at the API docs to figure out just what objects are coming back from an insufficiently generic method.
Sure, these casts are probably right in the mainline code, else they would have gotten a class cast exception, but I would far rather catch problems at compile time, by making the strongest statement I can make about a method.
Further, new users of my code, and of other code, are going to see _simpler_ code with generics, because they do not have to do the casts required by 1.4. Since each cast requires a new user to know what they are getting back, rather than having my code tell them, I think that is a win. New developers will likely get things right, because they then get typed collections.
Perhaps more important, those new developers will be encouraged to make stronger statements about their collections. They could return Collections of Objects, or Collections of Maps, but now there is encouragement to return a Collection of Thingies with typed fields.
I do note that fewer arrays appear in code with typed collections. This is empirical, not scientific, but based on what I see, the crufty array syntax may be less of a problem than one at first might think. Essentially, List
From where I sit, the overall idea and _most_ of the implementation of Java 5 generics lead to easier code to comprehend and use. Put another way, while I want to see the problems fixed, they do seem to have some benefits.