I recently came across this documentation page from the .Net API.
I was investigating the possibility of creating a Map that would allow String keys to be case insensitive in Java. Neither the language nor the standard libraries allow you to do this easily at this moment, because 1) hashCode and equals are methods that are defined on Object and 2) all the collection classes use these methods directly. Therefore, I was wondering how hard it would be to extract these two methods in an external class (you could use a Trait in Scala) and delegate these calls there instead of on the objects themselves.
This idea is not exactly new and it would be pretty easy to implement, and as you can see from this page, it is already supported in .Net.
But that’s not what caught my eye.
Do you notice anything special on this page? Look again.
The key here is to realize that this is not a “C# page” or a “Visual Basic page”. It’s “.Net documentation page”. And for this reason, it describes the functionality in general terms and then it gives specific examples in not one but five languages.
Maybe I’m easily impressed, but I find this amazing.
Here is the deal: I have always been a fan of COM. Since day one. Well, not exactly day one since the early days of COM in C and C++ were extremely painful, but I certainly saluted the ambition behind the idea: trying to make all Windows applications 1) accessible from the outside and 2) from any language. Until Microsoft created COM, this goal had never really been achieved by any technology.
Fast forward thirteen years: COM has morphed into .Net, the complex COM binary interface is now hidden behind a neat virtual machine with a powerful bytecode set, and the dream of writing applications independently of languages is a reality on the Windows platform. Hats off to Microsoft.
Now, where does that leave us, Java developers?
Well, we have achieved an independence of sorts, although it happened much more by accident.
Microsoft built its framework with a clear vision that was spelled out around 1995 and that took many years to carry out. Java, on the other hand, started with a clear focus on the language, with the JVM and the bytecode as a simple foundation to make it easier to run Java programs on several platforms (actually, event the intent for the JVM has changed over the years: it was first designed to run on embedded devices, then in web browsers as applets, and it finally found its true vocation on the server, something that Sun never saw coming).
What’s interesting in this story is that not only did Java emerge as a superstar of languages, but it slowly and surely dragged the JVM and its bytecode into the spotlight as well. The versatility of the original design should certainly be saluted, but it’s eventually the formidable Java ecosystem and its users that took the JVM to heights never envisioned.
It started innocently with a few experiments that generated bytecodes to alter existing classes or to create new ones on the fly, and it’s now culminating with not only some of the most innovative frameworks I’ve seen in years, but the JVM has also the foundation for a multitude of new languages that not only run JVM bytecodes but that also interoperate seamlessly with the Java platform.
In a way, Java has enabled language independence as well. It’s not as extensive as .Net, but it certainly runs on many more platforms.