Don't violate COM

I remember back in the good ol' days when I was an application developer and I was learning to write in VB. Since most of my time was spent in RPG and COBOL, I didn't do all that much object oriented (OO) programming, but one day my co-worker, Margo, admonished me "Don't violate COM!" Since I did not know what COM was, I was fairly certain that I had not violated it.

Later I learned that COM had something to do with an Object, and to violate it meant to change how it was interacted with, like adding or removing public methods. Since I was still on my first OO project, and had never released the object before I remained certain that I had not violated it.

So now that I am responsible for every thing that happens to WebLogic Workshop (WLW) after it goes to GA, I REALLY get what "Don't violate COM" means. You see, WLW uses a couple (or so) open source products. The two I hear about the most are log4j and XmlBeans.

I hear about our use of log4j with great regularity. And the reason it that log4j violates COM. Here's what happens. Lets say that we ship log4j version A, but our customer wants to deploy a packaged J2EE application that uses log4j version B. If all of version B's interfaces worked like version A's interfaces (plus what ever improvements), life would be good. But since it does not, replacing version A with B results in failures a plenty in the server. Attempting to use version A with the packaged product causes failures in the application.

bummer.

So what is an open source consumer to do?

David Bau spent a bunch of time writing about this in his "Theory of Compatibility" series, parts one, two, and three. Now I'm a big fan of David's, but I think this representation-vs-interface debate won't fix a lot of things. It won't fix C++, or Java. Both of these are interface level compatibility issues. And it does not fix all the software out there. The best fix really is to "Don't violate COM." Yet we all know it is harder to get the cat back in the bag than it is to let it out. In log4j's case, the cat is already out.

Best Practices

If you are writing and contributing to an open source project, DON'T VIOLATE COM! Add a test to your test suite that is a static .jar, and from it run tests against the .jar you just created. If the tests fail, try again. You are probably about to make your consumers have a very bad day.

If you are a consumer, consider repackaging. Here's what we do with XmlBeans (not sure why we did not do this with log4j). We take the XmlBeans source, and scan all of the "org.apache.blah" and replace it with something like "com.bea.blah. This allows a customer to use what ever version of XmlBeans with out interfering with the one we use.