Friday March 10, 2006 
Today's Page Hits: 261
Friday March 10, 2006 Capatibility between Java implementations is critical to the success of the platform. Its the responsibility of the JRE vendor to ensure that any Java application will run. Yes, any Java application. After all, compatibility is the a key ingredient to what makes Java. "Write Once Run Anywhere", Right?
Apparently this isn't always the case. Here's an example of a "compatibility issue identified on the Java.net Glassfish Project.":https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=761 There are always bugs in software and some of those bugs can break compatibility. It is of utmost importance that issues such as this are addressed in a timely manner.
This is where you come in. When testing Java software, whether it be new development, a purchase evaluation, or your tried and true back office application, please do the following. Run your application with your JVM of choice, but also test it against other JVMs running on the same platform. That's right, if you're running Sun's JVM, also test BEA JRockit and IBM JDK. Multiple Java implementations are available on Windows, Linux, and now Solaris SPARC. If any of the implementations show incorrect behavior or dare I say don't run at all, I implore you to send a note to the implementation's support channels and if possible file a bug. None of the Java vendors out there can possibly test enough Java applications, and in many ways we're relying on the users to let us know if something's broken.
In the end, any Java application should run on any Java implementation. Hands down. No excuses. If you run into problems, have questions about Java performance, or identify compatibility issues running Sun's JVMs, in particular "Java SE 6 ":https://mustang.dev.java.net, please post a note on the java.net performance forum or feel free to send me a comment here. I would love to hear your compatibility successes, along with the issues seen with our competitors JVMs 
We're very serious about performance, compatibility, and reliability of the Java platform. If a vendor is not doing well in this regard I would like to know about so I can take steps to ensure compatibility guarantees of that implementation.
We're very serious about performance, compatibility, and reliability of the Java platform. If a vendor is not doing well in this regard I would like to know about so I can take steps to ensure compatibility guarantees of that implementation.
Post a Comment:
Comments are closed for this entry.
Yes, I know there is some sort of philosophical hangup between the Sun and Linux folks. I don't care (and I understand the rationale given). Yes, I know it is possible to install Sun's JVM on Linux - but since this isn't the default, this is going to cost some amount of grief (how much I will have to find out).
What I expect as an application developer is for Java to be ubiquitous. It's not, and that is a problem.
As a developer I expect my Java application (a web application in my case) to run on whatever platform I need to use. Performance is important, so running a second-rate JVM is not interesting.
My wish is that Sun adopt a whatever-it-takes approach to getting the JVM into every (major) Linux distribution. That would do a lot for compatibility.
Posted by Preston L. Bannister on March 10, 2006 at 06:50 PM EST #
Sun is a proprietary software vendor. It makes money from selling proprietary software commercial usage and restribution rights, like for example, their JVM implementation.
It is Sun's right to limit the distribution of their proprietary works in whatever way they think makes them the most money in licensing revenue. It is also the right of Linux distributions not to want to ship proprietary software with limited usage and distribution rights.
As for compatibility of free software VMs, that could be easily improved by sharing the TCK, i.e. the compatibility test suite, under a non-discriminatory license with the implementors of free VMs, and allowing Java users to verify if the JVMs they use are indeed as compatible as vendors claim.
Currently Sun only offers access to such test suites under the ridiculous "Read Only" license, which explicitely prohibits doing anything else but reading the tests, only. The other alternative is the TCK scholarship process, which unfortunately is plastered with NDAs, and extremely prohibitive license agreements as one can see on Apache Foundation's TCK page.
As long as it is in Sun's business interest to be a proprietary software vendor, that situation is unlikely to change: Java will be an open standard for suitable definitions of 'open' and 'standard', just like 'write once, run anywhere' will be true for suitable definitions of "run", and "anywhere".
It's a sad state of affairs, and noone except Sun can change it. Unfortunately, they have no business reasons to do so, their fanbase likes the things the way they are.
cheers, dalibor topic
Posted by Dalibor Topic on March 12, 2006 at 02:14 PM EST #
Note that Sun gives away Java for Windows and Linux - no license fees involved here. On Windows Sun has (finally) pretty much worked out the versioning bit. On Linux/Unix(?) - not so much. :)
What I am looking for is the JVM as a standard - a common base on which to run code. Pretty much everyone is looking for a better base than C/C++ for new code. With a bit of effort, that base could be Java and the JVM. Sometimes the space between "always" and "almost-always" makes a huge difference.
You are right in saying the ball is mostly in Sun's court. I suspect at least in part they are still trying to make up their collective corporate mind. :)
(There is more to be said about performance and ubiquity in the contexts of desktop applications and webhosting - but David's focus in this weblog is more on server mega-applications).
Posted by Preston L. Bannister on March 13, 2006 at 05:00 PM EST #
Posted by Fernando Lozano on March 15, 2006 at 12:36 PM EST #
Posted by Fernando Lozano on March 15, 2006 at 12:37 PM EST #