Generics, Cheeta and complexity...
On the Eclipse 3.0 JDT mailing list there has been a lot of talk about the new JDK 1.5 features. They are working hard at adding generic support (along with other 1.5 features and things are coming along. But something struck me again today about how much I dislike generic types. It has been a long time since I've done any serious C++ work but without a doubt generics was something that made normal peoples brain hurt. So here we are about to have this lovely feature delivered to us and I find myself not wanting it.
I mean really how much more complex is this bit...
List myList = new ArrayList();
...
Iterator itr = myList.iterator();
while(itr.hasNext()) {
String foo = (String)itr.next();
...
}
than this bit...
List<String> myList = new ArrayList<String>();
...
Iterator<String> itr = myList.iterator();
while(itr.hasNext()) {
String foo = itr.next();
...
}
In reality most developers who don't understand the cast will not understand the 'generic type' stuff either and will just copy and paste the code and modify where necessary. I know we get a bit of additional type 'saftey' from the compiler here but once you get a ClassCastException once and figure out what caused it you tend to not make that mistake again.
My hope is that we will, as an industry & community, develop some 'best practices' that are borrowed from our C++ colleagues. I guess I don't really expect this to happen, I'm just hopeful.
Anyway this is a recent email from the list with an example of what has become possible in Cheeta. BTW: I love the little animated gif! Even if you are not interested in generics you should check out the gif :-).
Basic support for generic methods is now in, with argument type inference.
For instance, in the example below, U is inferred to be of type String for
the invocation of #foo(...) in #main(...) method.
public class X <T> {
public static void main(String[] args) {
new X<String>().foo(args, new X<X<String>>());
}
<U> void foo(U[] us, X<X<U>> xxu) {
System.out.println("SUCCESS");
}
}
We still need to test it a bit before updating the Cheetah with it.
So what I expect will happen is over the next year or two everyone will make all the same mistakes that have been made in the past with generic types in the C++ world. Here is an example of the kind of ugly stuff that we perhaps will be foisting upon ourselves. Not that meta-programming will be possible with Java generics but equally krufty stuff will be possible I'm sure. Just look at the above example. Try to explain that to the average 'business programmer' that the Simplify Java and J2EE crowd is aiming at.
me in a class with 15 'business programmers'
Well you see John the U stands for a generic return type from the method foo that is only specified when the method is invoked. So since the method foo is invoked with a type of X<X<String>> U is naturally a String. Get it?
John looking back with blank stare... Uh yeah sure so if I add two cups of sugar everything will be ok right?
I know I'm sort of too little too late here but my hope is that we as a community will learn from all the bad stuff that has been done in C++ with generics and not repeat the mistakes made there...
[Update:] Thanks to Ben's comment I figured I'd post the JSR homepage and a mail address for feed back. Let the expert group know your opinion.
[Update 2:] If only I'd read for myself and not rely on others comments... As David Flanagan points out in his blog the time for comment is long since passed so don't hassle the expert group :-)

