Fernando Lozano's Blog

Echoing the Java Compatibility Call to Arms

Sun David Dagastine in his blog http://blogs.sun.com/roller/page/dagastine?entry=java_compatibility_call_to_arms asks developers to test their applications on all available JREs, citing Sun, IBM and BEA.

I agree with them that no matter how big are vendors and JCP efforts to promote compatibility and interoperability, the ability to run apps is the real measure of compatibility, and you will only get that if most developers test their code with as many JREs as they can, and report back any unexpected behavior.

But I have to add that it's not enough to test the biggest proprietary JREs, which are all of them Sun licensees. Java compatibility will only be real when there's also an independent JRE implementation that is able to run most if not any Java app and you are free to port this JRE to the platform of your choice. That's the true meaning of IT standards: not having to rely on a single vendor to run your apps. David's request is about relying on just Sun as the direct or indirect supplier of JREs.

Even if you argue that free software / open source software JRE implementations are not yet certified and may lack important parts of the JavaSE APIs, there's a good chance they already have enough to run your app, and the problems you may find when they don't run your app are actually your fault, not JRE flaws, as in the case of OpenOffice.org (see http://people.redhat.com/green/linuxworldfreej.pdf).

Hey, they already run Eclipse and Tomcat! Red Hat guys are even running JonAS under GCJ! Why then wouldn't your app run under a free software / open source JRE?

Here's a few good candidates you can try. Please add at least one of them to your standard testing practices:

• Kaffe - http://www.kaffe.org
• GCJ - http://gcc.gnu.org/gcj (this already comes bundled with most Linux distros
• JamVM - http://jamvm.sf.net (good for embebed devices, small RAM footprint)
• SableVM - http://www.sablevm.org

The developers of these free software / open source software JREs found that the single bigger headache, which prevents them from running even some open source Java applications, is the use of vendor-specific, non-standard classes by the applications. Most of the time they are com.sun.* classes bundled with Sun JRE.

So I add to David's request: please treat any use of non-standard JRE classes as a programming error. This will help a lot achieving true standard, compatible and ubiquitous Java.

Comments

• all this discussion could be solved by just one simple act from SUN:
  convert the JVM to an Open Source SUN JVM I still waiting a reason to keep the JVM license proprietary..

  Posted by: felipegaucho on March 16, 2006 at 09:09 AM

• Hi Felipe, although I'd prefer Sun to open source its JVM, there's benefit from third-party implementations, specially ports o new processors, and even if there's only one open source implementation everyone else uses, it's still important to have formal standards, besides a testing and certification process for use by the ports. This would give great confidence for anyone replacing the inner workings of the JVM to use new ideas and alghoritms.

  Sund would help A LOT with those third party effors if the TCK at least were released under a non-restrictive license. The way it is today, third party projects can't use it to verify compatibility during initial stages of thei projects (and maybe even during later stages).

  Posted by: flozano on March 16, 2006 at 11:35 AM

This work is licensed under a Creative Commons License.