Fernando Lozano's Blog: March 2006 Archive

Posted by flozano on March 20, 2006 at 06:50 AM | Permalink | Comments (5)

Remember last year's JavaOne NetBeans Day? It was more about JavaStudio than Creator. I hope this year we have an event centered on NetBeans itself and less on the closed forks maintained by Sun.

NetBeans has a very active community and interest in it is growing because of the unique features of the open source software base, but Sun people always look more interested on marketing the closed derivatives than the open source project itself. I was disappointed every time I read a blog or saw a presentation about NetBeans that spent more time on Java Studio Creator and Enterprise than on what I could do with Netbeans itself.

I don't want to see previews of the next JavaStudio releases. I want to see previews of what NetBeans developers are doing as open source software I can get from CVS and try right now (and maybe contribute to). I don't want to learn about all the nice features JavaStudio offers me -- for this I can ask for a Sun representative to visit me, or I can go to the JavaStudio web site, or I can also join SDN and have the CD mailed to me.

It has not been very honest from Sun to use the NetBeans brand as a disguise to market JavaStudio. If you want, host a JavaStudio day also, But please, don't mislead me again to see a NetBeans presentation or article when what I'll really get is a JavaStudio advertisement!

Echoing the Java Compatibility Call to Arms

Posted by flozano on March 15, 2006 at 10:07 AM | Permalink | Comments (2)

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_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

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.

Powered by
Movable Type 3.01D

java.net RSS Feeds