Tuesday, August 10

If it ain't broke, don't fix it

Last week I had a little debate with my right hand man. We finally took the plunge and switched from Microsoft J++ to Eclipse as our primary IDE. This move required a massive change to the source tree due to a bug in Eclipse where it refuses to compile if you have a subdirectory with the same name as a class; but I digress. This isn't another blog rant about what's good and bad about Eclipse. We both put all our other work aside and spent the entire day performing a massive reorganization of the code tree... and this was a major pain in the ass thanks to Microsoft Visual Source Safe; but again I am straying from the main topic. We made Eclipse happy, and it returned the favor.

So back to the debate. J++, being the dinosaur that it is, compiles and conforms to the 1.1 version of the JDK. Eclipse, on the other hand, supports the 1.4 version of the JDK. So my right hand man sends me an instant message telling me that he's going to start using the newer 1.4 version of the collections API. That set off the klaxons in my head.

What's the harm in using the newer collections API? Well, before I answer that question, let me first ask what's wrong with the older versions?
  1. Are the older collections broken? Nope.
  2. Do the newer virtual machines support the older collections? Of course.
  3. I am aware that the newer collections offer [theoretical] performance gains by sacrificing thread safety, but our system has no performance problems, so I'll refer you to the quote by Joseph Newcomer in my prior blog post.
So there's certainly no need to switch to the new API, but why wouldn't we? Well, here are my reasons:
  1. Inconsistency within our code base. We have over 115,000 lines of Java code in our product. It's over four years old. If we start using the newer collection API now, there's inevitably going to be a situation where we are returned an old collection from and older object and have to convert it into a newer collection in order to pass it into a newer object. That means we'll need to build, or find and possibly license, a set of utility classes for converting from one collection type to another. This is discussed in an old article from Sun entitled Converting Between Old and New Collections. This headache can be avoided by continuing to use the older collections.
    Side note: I have another mantra about not passing generic collections in and out of functions, but that's a future rant.
  2. Portability. Yeah, the major platforms have ports of the latest JDK versions, but there's always the possibility that we'll have to port to a platform that's a little behind the curve. If that scenario ever surfaces, we'll have to re-code all the classes that take advantage of the shiny new toys in the later versions off the JDKs.
So I had to exercise my seniority and put the kibosh on the new collections.


Anonymous said...

Thread safty is under-rated (IMO). Race conditions are (IME) one of the hardest things to debug on the planet so having some backup protection for a theoritical performance hit isn't such a big deal.

-Marco (still usin' the Hashtable like the dinosaur that he is)

Jed Wesley-Smith said...

ha ha, that's the funniest post I've read in ages. Collections have been there since 1.2 - like five years ago...

Sachin said...

I can totally understand your thoughts on why you didn't want the newer Collections. I have a few points to the contrary, though :-)

In my experience, there are a few reasons where the earlier you move to the newer JDK the better it is.

a) Some functionality which you would like in your application is available in a newer JDK. If you aren't going to compile with that JDK, then someone is going to copy the code from there into your source base and that's going to be a maintenance nightmare.
b) Java has been consistently delivering better performing libraries version after version. You did say performance is not a problem. Therefore this point is not applicable. Perhaps you run with the newer JDKs/JREs?
c) JDK 1.1 is really really old. Your programmers will probably be quite a bit more productive with the newer APIs and frameworks?

Besides, refactoring your code to comply to the newer Collections across the board should be a reasonably easy task with the newer IDEs (Eclipse?) ?