A debate has started up over in Jakarta-Commons as to whether a new version of commons-collections should be created that supports JDK1.5 generics.
Unfortunately, I happen to think that generics (as implemented) have serious flaws. There are just too many weird behaviours and odd corner cases. Just look how big the FAQ is - a sure sign of serious problems. And they also look darn ugly too!
A forked version has been created on sourceforge with generics, but that is far from ideal, as Apache can't link to it (official policy) nor can it easily be kept in sync. However, it does show that the task is possible. Could the fork be brought back to Apache? Well possibly, but that gets bogged down in bureaucracy when the forkers don't have Apache commit priviledges. Even more so when the relevant Apache committer (me) isn't particularly motivated by the issue (generics).
Anyway, I'd like to ask anyone reading this a question or two - do you want a generics JDK1.5 version of commons-collections? Would you mind if parts of the API were changed to fix API design flaws (this would be a major release after all...)? Please comment here, or at Commons JIRA. You can also just vote for the change at JIRA.
Hi Stephen,
ReplyDeleteI'm a fan of Ruby and the "closure" style of programming it encourages.
I had a spell where I was using a lot of the CollectionUtils methods with inline anonymous classes to try to program that way in Java. In the end I quit that and returned to using the Java 5 enhanced for loop instead, because of all the extra casting required with CollectionUtils.
I've started playing around with the collections15 fork and it seems like CollectionUtils is a lot nicer to use in it. I'm not sure yet whether I will use this a lot, but it is a step closer to "Java, the way I want it".
John Hurst
A huge YES for having the collections updated to make use of generics. I've been using one of the forks for about a year or so, and I can't live without it. Code is vastly more readable as a result of using generics. Yes, there are some complexities. Yes erasure is unfortunate. But let's not throw the baby out with the bathwater.
ReplyDeleteI would not use the official Apache version anymore if it weren't for all the projects I do use which have it as a dependency. I've had no issues with http://larvalabs.com/collections/, and from my perspective, it is a huge improvement on the official version.
I am in favour of generics.
ReplyDeleteUsing libraries based on generics is easy, writing generics library is another pair of stuff of course.
And for what concerns the 433 pages of the generics FAQ, I think for an average developer the shorter SUN "Generics Tutorial" (there's a PDF on the net) is quite enough to start.
Definitely FOR an implementation of commons-collection with generics support.
ReplyDeleteOf course, such an implementation already exists, but having it under the Apache Commons hat would allow to insure consistency between Java 1.x and Java 5+ implementations at a minimal cost, no ?
P.S.: John, did you have a look at Groovy ? It offers Ruby-like features (closures are so powerful) along with full Java support. Quite interesting indeed.
i think all the commons projects should switch to Java 5 and leave the current versions as managable branches. Not only generics but all Java 5 stuff should be used. Especially concurrent classes makes many commons objects obsolete..
ReplyDeleteYes, please move to generics. Just make sure it is handled such that we can have both versions in the classpath at the same time easily. :)
ReplyDeleteSince there are so many pro-generics posters hovering about, how about somebody link to an article/blog entry that describes what they are and how they are useful. I read the Java5 release notes about them, but did not find that explanation very helpful. I'm still using Java 1.4.x on a project, and am very happy with it. Somebody help me understand what I'm missing, if you happen to be familiar with a good resource. Thanks.
ReplyDeletePre-Generics:
ReplyDeleteList stringList = new ArrayList();
stringList.add("hello");
stringList.add(new Integer(5));
Iterator iter = stringList.iterator();
while (iter.hasNext()) {
String str = (String)iter.next();
}
Compiles Ok! Runtime error though... oops.
Post Generics:
List stringList = new ArrayList();
stringList.add("hello");
stringList.add(new Integer(5));
Iterator iter = stringList.iterator();
while (iter.hasNext()) {
String str = iter.next();
}
Compile error!
So the benefit is typesafety at compile time instead of runtime.
Of course, the Java implementation is so backwards that typesafety isn't particularly guaranteed. Oh well.
I think the last example sums up the lack of benefit. Instead of typing String once, you now have to type it three times. And those angle brackets just give you headaches.
ReplyDeleteSure you when you get something wrong you'll get a compile error, but big deal. The whole point is that generics tries to solve something that wasn't a problem in the first place (CCEs are actually very rare).
Yeah, well, I did say that Java's implementation was backwards. :) I still think they're slightly better than not having them at all, though.
ReplyDeleteA combination of this and C# 3.0-style type-inference could really be nice, actually.
I never liked the idea of Generics right from the get-go. Looking at them and reading about them, there was just something that rubbed me up the wrong way. That was until I started to actually use them. Now, I'm totally in love (mostly). Looking at it in the context of one example like that given above is just useless. The compile time error stuff is nice and all, but there is just so much more. It's difficult to explain, but they change the way you code in a lot of circumstances. Combined with the other additions in 1.5 (like the enhanced for-loop etc...) it just comes together in a way that you can never really appreciate until you've spent some time working seriously with them.
ReplyDeleteGive it a go.
+10000 for generics!
ReplyDeleteWe now have almost all our code based on generics and we would be pleased to see them in commons-collections as well.
What's the point of non-generic code in this day and age?
ReplyDeleteI guess it's probably worth cleaning up the API at the same time. It is absolutely huge. And, obviously, keep it in line with changes to java.util.
> What's the point of non-generic code in this day and age?
ReplyDeleteWell, a lot of large enterpises are still running JDK1.3 (or even earlier) and perfectly happy. If you work in a small agile environent you can get a completely different view of the Java world from the enterprise view.