Binary Backward Compatibility

I saw this interesting article about a weakness in the Scala language. The weakness applies not just to Scala, but to pretty much any language: the community using the language cannot grow past a certain point until it somehow solves the problem of libraries depending on other libraries in a large (deep) tree. Why is this a problem? Because when the language moves forward (to the next version) a deep dependency tree means you can't move forward until every library in the tree is moved to the new version, and making every library in the community do that simultaneously is extremely difficult. You can see the problem right now in the Python community: Python 3 was realeased THREE YEARS ago, but today many major libraries still don't support it.

What I found most interesting was something that David Pollak (the post's author) alluded to but did not emphasize: an example of a language that has solved this problem. Surprisingly, it is the much-maligned Java. (And perhaps this feature is one of the reasons for Java's success in "the enterprise", where backward compatibility to old or unmaintained libraries is often a very big deal.) The Java solution is to provide an incredibly strong amount of backward compatibility at the binary level (not just the source). As far as I know, essentially all code written under Java 1.0 (16 years ago) will still compile under the most recent Java release, and code compiled by that Java 1.0 compiler will still run under the most recent JVM. The price paid is some real ugliness in the name of backward compatibility like old APIs that still return Hashtable or ArrayList instead of Map or List, and type erasure that makes typed collection less powerful than they could be). But however much you may scoff at Java for poor language design, this feat of backward compatibility is something quite impressive.

Posted Wed 07 December 2011 by mcherm in Programming