Backwards Compatibility Is For Suckers

Ok, so Dr. Lunch is officially a going concern again, having just undergone its first upgrade in (figuratively) forever. Thanks to Drake we're hooked into google analytics, so we have cool interactive graphs to tell us that for some strange reason all our hits are being routed through Guam. Thanks to James, we're one step closer to buzzword compliance -- "hibernate," folks, only 2 years behind the curve. And just for good measure, I fixed the CSS bug that made Dr. Lunch so remarkably unattractive when viewed via Firefox. For those of you keeping score out there, <!-- doesn't start a CSS comment, no matter what MS encouraged me to believe back in its days of browser dominance.

We also took the opportunity to upgrade to Java 5 and Tomcat 5.5, which leads me to my rant for the day. Here's the HOW TO page on JNDI datasources for Tomcat 5.5. Let's look a little closer, shall we?

Please note that JNDI resource configuration has changed somewhat between Tomcat 5.0.x and Tomcat 5.5.x. You will most likely need to modify your JNDI resource configurations to match the syntax in the example below in order to make them work in Tomcat 5.5.x.

Now, I'm used to clean and smooth migrations between different versions of Tomcat, so I didn't bother to read the HOW TO. Why would I? I didn't need to know HOW TO. Our JNDI resource configuration was already TO'd. It had been TO'd for years. So, needless to say, the first time we dropped our little Dr. Lunch WAR into Tomcat 5.5, it crapped out. The cute little WAR that had served us in good times and bad, through Tomcat 2, 3, 4 and 5(.0). And now, all the sudden, it doesn't work. And is there a helpful error message, like, "hey, we decided we liked attributes more than elements, so your context.xml file doesn't work anymore"? No, my friends, there was not. And, as far as I can tell, that's what it came down to. Attributes over Elements.

   <name>
     password
   </name>
   <value>
     foo
   </value>

gets replaced by

   password='foo'

Cleaner? Yes. Simpler? Yes. Way easier to parse? Boy, howdy. Worth breaking backwards compatibility over? Not even if you'd been subjected to a weekend of waterboarding. I mean, given the choice between attributes and nested elements in XML, I choose attributes every time (and, just for the record, I was doing it before it was cool, when I had to argue it out with everyone). But deciding 7 or 9 years into a product's lifecycle that you're going to change how your product gets configured because you like the way one style looks better than the other? Or because you want to cut out some lines of code you wrote years ago? That's boarderline deviant. Fear that this sort of change is going to sneak by is the reason I'm never allowed to upgrade anything at any organization with a bottom without 16 months of nagging.

Now I know the developers of Tomcat are smart fellows (and fellettes). And I'm sure they had some remarkably good reason to break backwards compatibility. Maybe I could even find out what it was if I looked. Maybe I even will, now that I'm done expressing my ill-informed rage. But, really, I better read about a Y2K-sized calamity that was in the offing or else that little vein in my forhead is going to pop out every time I think about this for at least a few months.