Monday, October 10, 2005

Where's My Backwards Compatibility?

I've been around enough to know that the minute you question the open-source gods, you're likely to be cast into the burning fires of hell for an eternity of pain, suffering, and anguish. Nevertheless, they need to be raked over the coals for one very important thing...BACKWARDS COMPATIBILITY.

Let me tell you my current situation. I'm in the process of developing a small database system for a student organization where I'm using several new open-source technologies. Those include:

  • SwiXAT: An XML authoring toolkit for Swing.

  • Spring Framework: Best described as the swiss army knife of toolkits...a little something for every occasion.

  • Hibernate: A popular Object Relational Mapping tool.

As grateful as I am for the availility of these tools, they've given me no end of headaches with version dependencies and backwards compatibility. SwiXAT actually uses Spring and is based on version 1.1.5. Spring, in turn, has database libraries that use Hibernate. In version 1.1.5 of Spring, you use Hibernate 2.x. In version 1.2, you can use the newer versions of Hibernate numbered 3.x.

So, here's the fun. Hibernate 3.x includes the database dialect for Apache Derby (formerly IBM's Cloudscape), but previous versions of Hibernate do not directly support it. While I could dig up the code and package it myself, life would be simpler if I could just use Hibernate 3.x with all of its new whiz-bang features and bug fixes, right? are the two gotchas...

First and most importantly, Hibernate completely reworked its package naming from net.sf.hibernate to org.hibernate as part of its conversion to a JBoss project. I'm not aware of a way to overcome that change without rewriting the code, and I might as well just upgrade as rewrite it myself.

So if I want Hibernate 3.x with org.hibernate namespaces, Apache Derby dialect support, and who knows what else, I need to upgrade to Spring 1.2. Great...the only problem is that SwiXAT uses methods from Spring that no longer exist.

So, because of everyone's lack of interest in backwards compatibility, I now need to rewrite SwiXAT to comply with Spring 1.2 and possibly have to manage my own codebase until the SwiXAT authors are able/willing to upgrade.

If open source projects wish to thrive in commercial space, they must pay attention to issues like these. Nobody likes forced upgrades. Spring could have easily included a deprecated wrapper for the missing functions required by SwiXAT as they appear to be nothing more than OOP self gratification on the part of the developers. Hibernate should have continued with releases under both package namespaces to give developers time to make the change themselves.

Now, can I solve all of these problems? Yes. However, the goal of these projects is to save developers like me time. At this point, have they saved me time? Hard to know until I finish the project.

Ready to be burned at the your worst.



At 8:10 AM, Anonymous Paolo Marrone said...

I'm the author of SwiXAT, and maybe you'll be happy to know that the next version (0.5.0) will be compliant with Spring 1.2.x.
If you cannot wait, get the last development code from CVS.

Paolo Marrone


Post a Comment

<< Home