• Java Performance Community
• Java Performance Tech Topic

Thursday January 17, 2008

Where is Tom?

Now breaking a long hiatus in blogging is my announcement that I will be leaving Sun. I have a new opportunity which will challenge me to grow in new directions and I intend to seize the chance.

I have really enjoyed working with everyone on our new OpenJDK Community. OpenJDK is a huge project and we've made great progress since announcing the plan to open source Java. Of course there is more to do, but that's completely understandable when one changes the engines on a 6 million line-of-code airplane -- in flight.

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.

Tuesday November 06, 2007

Red Hat and OpenJDK

I'm sure you've seen the news that Red Hat has signed the Sun Contributor Agreement (SCA) and the OpenJDK Community TCK License Agreement (OCTLA). My coworkers webmink, barton808, mr and rsands have already blogged about it!

It's important to realize that IcedTea is intended as a temporary project until the remaining closed bits of OpenJDK have been removed. The best explanation of comes from Andrew Haley (aph) when he introduced IcedTea.

• Being available on all architectures supported by the distribution
• Debugger support so that, for example, it is possible to step from C++ code into Java code and back again.
• Profiler support for mixed source programs... possibly even with kernel profiling (with oprofile)
• Being installable as a valid build dependency for Java library and application developers

• GNU/Linux applications based on Java could have a substantial percentage of code which is architecture independent. This would reduce the number of packages and size of the distributor's archive (because a *.jar file should run anywhere -- you package it one time for all architectures). It would also reduce time to build a new OS release for each architecture.
• OS developers could write administrative utilities (at least partially) in Java instead of C and thus benefit from a rich set of libraries while avoiding the pitfalls of pointer manipulation
• The pluggable look and feel framework of Java could help GNU/Linux get beyond the widget/desktop differences (Gnome, KDE, Xcfe) so that Java applications always look well integrated.
• Developing GUI administration tools for GNU/Linux could improve the "ease of use" barrier for a new class of GNU/Linux users.

• There is now an OpenJDK Porters group proposal to facilitate porting to new architectures (and other operating systems). Many developers have contacted me about porting OpenJDK to new combinations of operating systems + chip architectures.
• Adding debugging and profiling capability to the HotSpot virtual machine is complex precisely because the methods are dynamically compiled, but we can leverage the technology in the NetBeans profiler -- recently available under the GPL.
• As OpenJDK expands our infrastructure it will be easier to collaborate with the community on open source replacements for the remaining encumbrances. Consequently the 100% open source OpenJDK would be a candidate for inclusion in the main repository of Free Software GNU/Linux distributions.

(A big grazie to neugens for enhancing my flickr photo!)