Java used to be the prime choice for creating applications that can run in any platform. But if you want to take advantage of the latest additions in the Java 6.0 release of the platform, you will probably face a big disappointment at distribution time. The main problem is that most users don't have the correct version of Java in their system. In a word, it is a big pain for most users to update the Java Runtime Environment. In the case of Windows, whenever you update Java, it will add a new version to the machine, so after a while, a user will find 4 or 5 different versions of the JRE in their systems. Each download is big and slow. I am not familiar with the case of linux, but for the distributions I have tried, Java 5 is installed by default. Finally, just this week Apple announced the availability of Java 6.0 for MacOS X Leopard with support for just 64 bit Intel processors.
Are we stuck with Java 5.0 to be sure we can deliver an application that any user can use? I would love to hear your opinion.
6 comments:
You raise a very good point. Would you be interested in cross posting this to JavaLobby?
If so send me a mail and we can organise it.
James
If you are developing for the desktop use Java 6 u10. The install experience has been streamlined and incremental patch-in-place updates are planed for future releases.
(I really don't want to pray the rest of the feature list here ;-))
If you are developing applets this should be really a no brainer. Alone the "out of process" feature of modern browsers+java should simplify your decision.
Thinking about it, it has never been different. If you use new features not available in prior Java RE releases you are not compatible with older Java. This will never change.
The only compatibility which is java typical is bytecode backwards compatibility. Feature backwards compatibility is not possible without a time machine or silent/painless runtime updates (like in java 6u10).
Hasn't it always been the case that it's more a marketing slogan than anything else? In this day and age, it's important to not only run, but to fit in and deliver functionality according to the platform you're on. Java is remarkably bad in this aspect, since it's designed with the lowest-common-denominator in mind. Apple for instance is not interested in this aspect - everything they do is to break out of the box.
Also, ask yourself the question why there are so few successful Swing desktop applications (no Eclipse and NetBeans don't count) and why Picasa, Google Earth and Firefox took a different approach.
Hi James. I am interested im posting this blog entry in Javalobby. Please let me know what I should do.
Thanks.
WORA (Write Once Run Anywhere) is not about version to version compatibility, but rather about platform to platform homogeneity for the developer/user. What you're talking about was something that was never promised by the WORA slogan. Also, concerning Apple - if they were not so insistent about developing their JVM/JDK in-house the wait would not be so long. I fell for Java developers using Macs (who have not discovered Open JDK). I'm not attacking your article, but I think the argument is facile and did not really merit propagation to JavaLobby. Just my 2 cents.
There are two parts of the WORA problem: being sure you've got a VM on the client's system, and being sure you've got a suitable system library on the client's system. Java 5 is backward compatible with a huge range of Java VMs, while Java 6 isn't -- but if you run a Java 5 app on a Java 4 system, you're likely (almost certain) to hit a library incompatibility.
The solution isn't to give up, of course; the solution is to make sure that the Java environment is VERY easy to update. This is what "Java 6 update n" is about; Sun is at long last trying to make Java very easy to distribute, install, and update, and to make missing libraries easy to locate.
Post a Comment