Wednesday, September 28, 2011

What the hell is wrong with collections API in Java?!

Today is the day when steam came out of my ears and I started screaming "WTF?!?!". So what's wrong? Let me explain...

The good part

I came to pure Java from Groovy. I never liked Java as a language in particular (I'd even go as far as "I hated it with a passion") but life is life and I've had to put my hands into the dirty world of legacy Java code once again. Being the Groovy fan for quite some time now tough me that functional programming style is something that makes your life easier and the code itself a lot more readable. That's especially true in regards to collections!

I don't want to bring up obvious examples like sorting a collection using spaceship operator or something along those lines. That's been done to death. Instead I'm going to tell you a story...

The story so far...

Back in the days there have been collections and a handful of utilities to back up the bare collection objects (java.util.Collections). At some point people saw that what the creators of Java the runtime library gave them to play around was not enough so they invented commons-collections. And life was good again because we could do things easily that were cumbersome before. That was in the pre-1.5 days so no generics were involved as you might imagine. That in turn forced the developer to do idiotic type casts from Object to the respective type when implementing for example a Transformer.
After a while Java the language 1.5 came to existence so people sat there and wondered how we can make the best out of it. This is how commons-generic came to be: The same set of utilities but with generic parameters so you can avoid doing silly casts. That must have been a brilliant idea, you might wonder... But as it turns out the compatibility is virtually non-existent so you can stick it up a$$ since everyone else is using the old commons-collection anyways...
If that wouldn't ring any bells yet not so long ago Google came up with yet another professional and good looking collections library, the google-collections project later on included into google-guava. Yet again the same stuff happened: separate predicate definitions, mapping functions - you name it!

Groovy the savier

I know you're going to say that Groovy is a dynamic language and I should back off of Java and not compare apples and oranges together. But then wouldn't it be at least sane to allow some classes/interfaces to be extended in some way? Like they do it in C# or VB using extension methods... Oh and btw. if you're saying that they will be in version 8 I rush to explain that C# had them from 3.0 which is not so far away from Java 1.5 as far as I can remember...
So back to Groovy... If you want to transform some list of objects into another list of objects you have the all mighty collect method that does exactly what you need. If you want to extract just a single property from all instances in collection you just type for example people.firstName and that's it. It's really simple...

But there we are... in Java

If you'd like to make use of your code in all the fancy collection utilities hyper super duper tools you'll have to create your own version of the predicates/mapping functions (to be on the safe side, of course) and then create tons of adapters just to satisfy the compiler and the ever growing egos of collection utilities libraries creators.

Have fun!

No comments: