Java Industry News
"If It Ain't Broke, Don't Fix It" - JDK 1.4 vs JDK 1.1 Isn't Always a Shoo-In
"What's the harm in using the older collections API?" asks Thomas E. Davis
Aug. 20, 2004 12:00 AM
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?
- Are the older collections broken? Nope.
- Do the newer virtual machines support the older collections? Of course.
- 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 a quote by Joseph Newcomer:
Optimization matters only when it matters. When it matters, it matters a lot, but until you know that it matters, don't waste a lot of time doing it. Even if you know it matters, you need to know where it matters. Without performance data, you won't know what to optimize, and you'll probably optimize the wrong thing. The result will be obscure, hard to write, hard to debug, and hard to maintain code that doesn't solve your problem. Thus it has the dual disadvantage of (a) increasing software development and software maintenance costs, and (b) having no performance effect at all.
-- Joseph Newcomer
So there's certainly no need to switch to the new API, but why wouldn't we? Well, here are my reasons:
- 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.
- 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. However, I did make two exceptions to usage of new JDK features.
- Early this year, during some database profiling, we stumbled across a JDBC driver that blew all the others away, and it required JDK 1.3 or later, so I allowed it.
- HTTPS. Yes, you can get it done with the older JDKs and some third party libraries, but it's painful and it's ugly.