subbu.org

Sun's Mustang Regression Challenge is laudable. I say this because designing software for compatibility is not trivial. Some members at TSS made fun of Sun’s challenge, but how many products are so carefully designed for compatibility that they can throw out a challenge to show regressions? Whether this is a marketing stunt is completely besides the point.

Contrast this to software products that often force users to "upgrade" or "rewrite" their applications so that those applications can run on a new version of the same software, perhaps just to get some bug fixes? Any kind of upgrade is usually disruptive, painful and costly.

When the software is designed with compatibility in mind right from day one, upgrades should not be required. One of the reasons software products come up with an upgrade step/tool with a new version of a product is when the product broke backwards compatibility in one area or another. Such compatibility outages usually occur due to incompatible changes made to file/data formats or APIs, which in turn are a result of design choices made without regards to backwards compatibility. There are also cases when the development team wants to get rid of large pieces of existing code, and start from scratch. This reminds of of the change from JAX-RPC to JAX-WS.

Last year the expert group responsible for JAX-RPC 2.0 decided to start from scratch, and call the new API JAX-WS. This is a classic example of dumping an API just because it has too much legacy in it, and so is painful to maintain it. By changing the name, the JAX-WS expert group broke compatibility with existing JAX-RPC applications. To migrate from JAX-RPC based applications to JAX-WS means the following:

• Code compiled to JAX-RPC does not work with JAX-WS.
• Source written JAX-RPC does not compile against JAX-WS.

This is because, the APIs are different (with new package names). In addition, the Java-XML binding has also changed to use JAXB rules. There may be other finer details that might have changed as well (I suspect there are more issues because once you break backwards compatibility the first time, it will be easier to break again and again). The net result is that migrating from JAX-RPC to JAX-WS will be expensive.

By changing the name of the API the expert group merely pushed backwards compatibility questions from the specification to implementations. Implementations will still have support and fix bugs in their JAX-RPC implementations to let existing applications continue to work.

Coming back to the Mustang challenge, here is my suggestion to the TSS critics of this challenge. Take a 10-year break, design and ship multiple versions of some useful software without ever breaking compatibility. I’m not saying this is impossible. That’s when we can take these critics more seriously.

Update: Note that I’m not defending Sun that it has never broken backwards compatibility. As Dalibor points out below, Sun did so on several occasions. Given the large amount of installed software running Java, it makes a lot of sense for Sun to keep up with this challenge for all future releases. Compatibility is a matter of survival for any software.