In Support of Oracle and Java

There's been a lot of Java hate recently, particularly from the open source world, and I have always struggled to see why. Perhaps its opponents lack the pragmatism to see value in diversification. Yes, Java is not a 100% free-as-in-speech platform. But there is immense value in an open source-friendly yet commercially backed platform upon which to build our projects.

Anybody functioning within the four walls of a company knows that, when it comes to big decisions, the executives tend to want to invest in a platform that isn't going anywhere -- and that means, backed by a big bad company. A company with real, long-term economic interest in the success of the technology. And so the adage goes, nobody ever got fired for buying IBM.

But today on Reddit, one of the few places I frequent where I notice this brand of Java hate, I remarked that Mr. Mueller of FOSS Patents blog had an interesting post about the Google-Oracle dispute, available here:

http://fosspatents.blogspot.com/2010/08/oracle-vs-google-licensing-issues.html

Since my current project is written in Java, you can likely imagine I have particularly strong feelings regarding the future direction of the Java platform following Oracle's acquisition. In fact, I thought long and hard about the environment upon which to build my newest creation -- a platform for financial analytics geared towards the quantitative trader/risk manager type -- before writing a single line of code.

Certainly, Mr. Mueller, whose techno-political inclinations can swiftly be ascertained from the name of his blog, has an aptitude with the minutiae of licensing agreements and a legal expertise that I clearly lack. However, I believe that in his dedication to his principles, it's possible that he overlooks what's best for the advancement of technology as a whole. He argues that a flawed, almost duplicitous community process for the Java platform brought about a pseudo-free environment that Google misperceived as genuinely so, ultimately landing them in hot water when they tried to build a mobile Java platform that deviated from the core specification. However, it is specifically this community process that makes Java a commercially viable platform. Java's unique hybrid quality, whereby it has an obvious affinity with the open source world (think Apache projects) while still being backed commercially by a company people trust, makes it an extraordinarily valuable platform not just for open source, nor for commercial software, but for the industry in its entirety.

Droid Does
Every wonder why "Droid Does"? Because Android code is written in Java, the most popular and most commonly taught programming language in the world. That means every coder and his grandmother can write code for an Android phone, since they already know the language, and they can likely write the majority of their app without even getting the Android developer tools (everything except the graphical components).

In order to use Java code on the phones, Google (with its infinite resource) actually re-implemented the Java technologies for mobile devices, basing it on the official Java specification. However, Oracle claims that Google made changes, additions or omissions that compromised the integrity of their implementation. This is actually a violation of the license agreements for the spec itself. One thing is for certain -- Google's "Dalvik" produces .dex files, which aren't compatible with the .class files typically used by the Java platform.

It might seem curious to the non-technical why this is so vitally important to technology companies -- what does Oracle care if Google adds a new feature to their implementation of Java? The reason is compatibility. The entire cohesiveness of the community and the reliability of the platform is compromised when competing dialects get introduced into the wild. When a user downloads Java code, he no longer knows whether Oracle's JVM can run it. Perhaps it's Dalvik code, using special Dalvik-only features.

"Why do we use FinCad?"
I think the value of Java is best illustrated by an example of what I will term "Layman's Paranoia."

The Layman's Paranoia is a simple concept, and since my readers may be technically oriented, I will switch to an example about cars, about which I know absolutely nothing. When something happens to my computer, I slowly work to diagnose the problem, search for the appropriate keywords on Google, and ultimately locate a forum post or HOWTO giving me a solution. Since I am well-acquainted with the diction of the IT world, it is easy for me to handle a computer issue in a calm, collected manner.

But when my car breaks down on the side of the road, I absolutely panic. I certainly don't know how to fix a car. I don't even know enough to diagnose how big my problem is, nor what kind of specialist I may need to call, nor how long the fix will take. This uncertainty is, quite simply, an operational risk sustained by anyone as ignorant as me driving an automobile. And that's precisely the situation you're in as a manager of a technology company with little-to-no genuine technology background (save Excel macros).

Because I'm ignorant about cars, I'm flighty, scared, and prone to pay exorbitant amounts of money to AAA or some kind of insurance club in order to have a tow truck to call when my car breaks down in rural Vermont. That way, when the going gets tough, the risk (whose magnitude I cannot assess a priori) will be handled.

This creates a triangular information asymmetry between customer, mechanic and club. And these asymmetries drive the business. The situation is precisely the same as when, while working as a consultant for a large hedge fund to build a risk management solution, I suggested using a FOSS financial math library.

We were paying unheard of amounts of money to use FinCad, a commercial financial software package, and at the risk of disparaging their good work, it didn't seem to be the ideal tool for our particular application. Meanwhile, the open source option was fairly incredible, allowing us scores of different algorithms for calculating the fair value of an option, or the OAS on a mortgage.

And he said: "But who do we call when it breaks?" He was unwilling to have a non-commercial application underlie the fund's risk management operations. Because if everything goes to hell and the risk system goes down -- well, everyone's going to be looking at him.

Now, I'm not talking about support contracts. Clearly, third-party vendors can offer support for whatever FLOSS packages they please. But, the survival of a genuine platform -- in the way that Java is a platform and .NET is a platform -- requires long-term interest from a corporation with vested financial interest in the success and longevity of the technology.

The Middle Road

The strong-fisted approach to community development portrayed by Mr. Mueller is certainly no exaggeration. But how else can Oracle (previously, Sun) make good on that implicit claim to the aforementioned executives that with Java comes reliability? Java supports a thriving open source ecosystem, including a multitude of scripting and dynamic languages, none of which would ever have been possible if Java had never gained the widespread adoption that it has. 

There are some issues with the lawsuit. In basing its Android platform on Java, Google actually did a solid for Oracle and the Java community by publicizing their endorsement of the platform and precipitating yet another swathe of legacy Java code to be maintained for decades to come. Thanks to the network effect, this adds nothing but value to the Java community.

Nonetheless, I applaud Oracle for taking on Goliath in defense of the promise made to their users and shareholders. Java is something worth protecting, and something of great value to developers. Not only does it allow us to write once and run anywhere, but it actually bridges the two worlds of commercial viability and open source idealism in an elegant, if neither popular nor legally clearcut, way. It is important to keep the economic realities of intellectual property in mind, because often the survival of a technology depends on the kind of corporate stewardship Java enjoys. As a community, open source advocates need to stop pushing their ideas on people to the exclusion of all else, and instead recognize the symbiosis that can develop between the free and the proprietary.