• Java Performance Community
• Java Performance Tech Topic

Tuesday November 13, 2007

The Java Experience

Today marks l'anniversaire du Java Libre -- it's hard to imagine all that has happened in the past year. Fortunately Rich Sands provides a great chronology of open sourcing Java SE.

Of all the work that has gone into open sourcing Sun's implementation of Java SE one milestone stands out clearly: Sun's choice of GPLv2 and the Classpath Exception for OpenJDK. Despite the overwhelming success of GPL as the top license choice of open source developers one often finds strange interpretations of it from "it discourages commercial development" to "if there is a GPL coffee cup in your office then the desk, the chair and the lamp must divulge their secrets". GPL is even sometimes criticized for not providing the "freedom to commercialize". It would seem that a fairly significant commercial ecosystem has been built on top of GNU/Linux. The use of the Classpath Exception makes explicitly clear that library and application developers deploying on OpenJDK are free to choose whatever license they wish for their work including closed source. Using OpenJDK as a platform gives you complete freedom.

Modifying the platform, itself, however does mean that changes must stay in the open. If one of your core values is ubiquity then you want the broadest possible reach for the platform on as many operating systems and chip architectures as possible. You want the community to share this complex knowledge to reduce duplication of effort and speed porting. If one of your core values is compatibility then you want to insure that the platform has consistent behavior on all platforms. You want to discourage proprietary "secret sauce" that would attempt to advantage one platform at the expense of the promise of "write once, run anywhere" for the entire ecosystem. So when it comes to the platform itself industries that are characterized by the walled garden approach may indeed have to change their business models. I bet that the most interesting devices of the future will be built upon software development kits which value compatibility out of respect for the career investment made by developers. The reason is simple: developers will advantage device platforms that keep the promise.

On this anniversary let me dream a little bit about what the OpenJDK platform could enable... I am talking about The Java Experience. As both a user and a developer I have become quite a fan of the always-up-to-date facility of Debian GNU/Linux. Debian has a very elegant way of managing software such that interdependencies of one package on others is handled automatically and upgrades of package versions is handled gracefully. Bringing this idea to the Java Platform is not new and is captured by the work on the Java Module System. For me the "Java Experience" would be the full realization of this concept where developers could author Java libraries and applications on any platform for deployment everywhere. To make this work our development tools will have to get smart about all the operating system specific facilities for managing software packages. Adapting a Java authoring tool for Debian will be easy. Training Windows to learn about "packages" will be somewhat difficult.

Imagine the power of being able to press the "publish" button which could upload your Java application to an automated packaging repository. This is about taking the Java promise over the finish line to leverage all the work in the core platform ubiquity to complete deployment. The Java Experience for users could be that once connected to the packaging repository all Java applications are available just by browsing or searching for them by name. One click would download the program you want (and all of its dependent libraries). This would mean that the concept of "It Just Works™" would be available everywhere there is a Java Platform. In this way users could be truly liberated to run the software they like on any device. That's the experience which is possible with OpenJDK.