Echoing the Java Compatibility Call to Arms
Sun itself is asking developers to test their apps with third-part JREs to ensure the Java platform remain compatible. But missing from his claim was the need to test them also with the many cleam room, open source software JREs out there, and the need to throw out references to non-standard, vendor-provided JRE classes from application code.
Sun David Dagastine in his blog
http://blogs.sun.com/roller/page/dagastine?entry=java_compatibility_call... 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
I could add more names to the list, but these already gives an idea of the possibilities. They are more or less ready to use, unlike Apache Harmony which is still in its infancy.
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.