Updated Sept 2010
Java is famous for the
write once, run anywhere sales pitch. Apache, Firefox, and OpenOffice are examples of widely used
run anywhere programs but none of them need Java, proving Java is irrelevant to where a program runs. How close is Java to
write once, run anywhere?
Java is was from Sun, Sun is now owned by Oracle, and Oracle are rebranding all of Sun's software as Oracle. Sun is was famous for the Java
write once, run anywhere sales pitch. There is a huge range of software that works everywhere were Java works and works without a line of Java code. For a long time, much of that non Java code worked more reliably than Java in most of the popular operating systems.
Do You really Want to Write Once?
Do you really want to limit your programs to doing things just one way? The Apache Web server runs on every useful operating system plus a few others. Some operating systems have multitasking, some multithreading, and some have both. Apache version 1 was written for a multitasking operating system so could not use multithreading. Apache 2 is built so it can use any combination by rewriting part of Apache for each operating system. The Apache 2 style flexibility is often more important than trying to make everybody do things the one way.
The popularity of Unix was built on the ability to write Unix many times for many uses. You could get the best out of a Unix system by making Unix use the best features of the underlying hardware. Now there are Unix users saying we should adopt the restricted range of Java. Their Java doublespeak clashes directly with the reasons for using Unix.
Jedit is an example of a
write once program and it sucks on a Windows platform because all the menus are wrong, the keyboard shortcuts are different. You cannot jump back and forth between Jedit and other Windows based programs because of the continual annoying differences. If jEdit was rewritten in a normal programming language and used one of the normal non Java user interfaces, jEdit could work the Windows way on Windows, the Linux way on Linux, and have the option to work the other way on each operating system for the benefit of people using two operating systems in parallel.
OpenOffice works on Windows because the authors set out to copy a Windows based application. Most Java based applications have the Jedit
write once problem.
write once and have a program run correctly on any operating system by separating out the user interface into a custom layer that is rewritten for each operating system. Java applications could be vastly improved by adopting the separate layer approach. GIMP did it successfully long before Java. GIMP's user interface is now supplied separately as GTK.
Everyone installs the right version of GTK for their operating system, just as you do with Java. When you install a GTK based application, the application gets the right user interface, something Java still fails to deliver.
The GTK approach gets you closer to the ideal of
write once, run everywhere with the right user interface.
Cygwin gives you Unix under Windows, which is another approach to the write once idea. I used Cygwin on NT. NT was a POSIX compliant operating system with the Windows user interface. If you stepped from Unix to NT, you could choose between easy Windows programs and cryptic Unix command line programs.
Cygwin added more Unix to NT so you could use Unix shell scripts in NT. If you mostly worked on Unix servers and occasionally on NT, you could use your Unix scripts on NT.
Java has a layer that works a bit like Cygwin but instead of adding to the operating system functions, the Java layer restricts you range. You then have to use Cygwin or GTK style tricks to make full use of an operating system. Out of the Java, Cygwin, and GTK approaches, I find GTK produces the best applications.
There are lots of
write several programs. You find they have downloadable versions for Linux and Windows with Solaris the third option then a variety of Unixes popping up after the release of the Solaris version. Now that Apple have dumped their operating system in the bin and switched to Unix, the Apple Unix version usually appears soon after Solaris. Of the hundred applications I use during the average day, half are cross platform products and most of the cross platform applications are
write several, run most places.
write several sounds bad until you realise you change only a tiny fraction of your code when you change operating systems. For many years Java failed the
write once, run anywhere test because you had to rewrite your Java programs to get around all the errors in Java that appeared in each operating system. Recently the Java people finally fixed Java so it could handle fonts on more than one operating system. GTK did that years ago because the GTK approach is more focused.
Part of the move to Java is to satisfy the problem created by Unix having so many different varieties. Unix bigots started selling Java as
write once, run anywhere when Java first ran on more than one variety of Unix. I exchanged words with one of those bigots in a news group.
All I did was try a Java based program on an operating system which was not Unix then post a question about a Java limitation in a newsgroup. Bang, one Unix bigot jumped on my post and blasted me for daring to use the
run anywhere Java on anything other than Unix. The bigot then commanded me to
upgrade Windows to Linux.
I could have pointed out that I was not using Windows or that Linux is not Unix. Instead I looked through the posts in the newsgroup and noted that the Java based application failed to run on several version of Unix because of Java problems. Pow! The Unix/Java bigot just about burst a blood vessel.
You do not make a program
run anywhere by making it half work on most operating systems. Some background service programs can run like that because they use only the Internet and do not have a user interface. That is a popular approach for Unix utilities running under Cygwin on NT. For everything else, you need a program that works like the other programs on the same operating system.
Using the same interface and keystrokes across programs lets people jump from program to program without slowing down. The car industry learnt that years ago. My European car works almost exactly the same as my wife's Japanese car. The only difference is that my Volvo has the indicator switch on the opposite side to my wife's car. That one little difference is painfully obvious when I drive the other car.
You can imagine how painful it is to try to use a Java application that has everything different. Try to think of a car with the brake pedal and accelerator switched around. What would happen to you if you were driving it for the first time and had to slam on the brakes to avoid an accident? How much delay would there be while you try to remember which pedal is the brake?
JRE or SDK
Java is supplied as the 15 MB JRE (Java Runtime Edition) or the 50 MB SDK (Software Development Kit). Most Java applications use only the JRE. Some Java applications give you the choice of downloading the application with or without Java. You save download time by downloading the Java JRE once then downloading the smaller versions of Java applications.
Some applications require the full SDK which goes against one of the main reasons for using Java. Suddenly you have to use a different version of Java. In the end I deleted that badly designed application and went back to using only the JRE. Do not install the SDK unless you definitely need it and complain to software developers who ask you to use the SDK instead of the JRE.
1.3, 1.4.1, 1.4.2, or 5?
Java 1.3 is the last version of Java to have an acceptable licence. 1.4.1 is the first version of Java to work on most platforms. 1.4.2 is the current thoroughly tested version. The latest version of Java, which should be called 1.5, is now labelled version 5. In version 5 the SDK is named the JDK (Java Development Kit). The version 5 JRE looks to be the same as the 1.4.2 JRE.
Lack of testing
I tried to delete Java from one computer, because I was not using Java on that computer, and the Java uninstall process destroyed the computer. To be exact, it corrupted all the active programs, the operating system, and required a serious time consuming recovery effort to make the computer usable again. This was not an old version of Java. It was a version installed only a month or two before I activated the uninstall process. After 15 years of development, Java is still not tested properly, not even to the to sometimes low professional standards of Microsoft. Now I refuse to install Java on any computer I need on a daily basis.
I use a lot of mobile phones (cell phones) and and other handheld devices. Most work reliably all the time. The few that show weird behaviour and truly stupid errors are Java based devices. Java based phones are going through that incredibly long process of trying to make Java work for more than a short time without screwing up. Java on desktop computers required almost 15 years to make it last a whole day without failure. After 15 years, the desktop Java is down to one screw up per week. Mobile phones based on Java screw up several times a day, the way Java did ten years ago and was still doing many years later. Will Java based phones require five years or ten years to become reliable?
The one thing that might save Java on mobile phones is the use of some Java by Google on their Android. Google do not use Java from Oracle for the same reason Microsoft did not use Java from Sun, Google and Oracle are deadly enemies in the war to control your computer and spending. Google use the open source Java work-alike, named Harmony, from the Apache foundation. Naming the Java replacement Harmony is equivalent to naming one of the atomic bombs dropped on Japan
sweetness and light.
Google use a run time environment named Dalvik and Oracle is suing Google over possible patent infringement in Dalvik. Most of the ideas behind run time environments work discussed in the 1980s so how could Oracle have a patent based on software that was not started until 1995?
Java still has a long way to go before it is
write once, useful everywhere. The Apache Foundation and Google might sdolve that problem with Harmony and Dalvik.
GTK version 2 looks like the best generic user interface for Java based applications and more Java developers should switch to GTK. They should then work on replacing the Java code with code based on a real programming language.