JavaWrite once, run anywhere?

Write once, run anywhere? content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

One of the main benefits of using Java is that the language is cross-platform, meaning that you can run its bytecode on any machine that has the Java runtime environment, whether it be a browser or interpreter. Sun sums up this philosophy, as “Write once, run anywhere.” Is this true? If not, can Java survive?

The answer to this question cannot be a simple yes or no, unfortunately. Whether Java is fully cross-platform or not depends on your level of Java development. If you’re involved in high-end development, where you’re building on top of libraries, you will probably not notice any cross-platform issues.

It actually is amazing how well some parts of Java are cross-platform. If you develop a high-end complex multi-threaded application, you may not have to make any refinements to run it on other platforms. Can the same be said about any other language?

However, if you’re into low-end development, where you’re making your own libraries and widgets, you will notice differences and inconsistencies between platforms. One such difference is in the use of peers in the AWT controls, such as buttons, comboboxes, listboxes, scrollbars, etc. A peer basically leaves the graphical representation up to the operating system. This means that elements such as buttons look different on each operating system, leaving an inconsistent look and feel for a Java app. (See the graphic below)

A more pressing concern is the expression of click counts in a mouseDown event. On Windows, for a single click, the click count is 1, if you double-click, it’s 2, and if you triple-click, it’s 3. However, on the Macintosh, the click count just increments without resetting. So if a user double-clicks twice on your GUI, the first time it will work on both platforms. The second time on Windows, the click count will be 2, but on the Macintosh, the click count will be 4.

Yet another example is the infamous z-order problem. At Stingray Software, we made a Java ComboBox, but it was quickly found that the drop-down panel we used would cover components in Windows, but hide behind those components in MacOS and UNIX. To deal with the problem, we had to put a branch in our code to have the combobox determine on which OS it was running and then respond appropriately.

A solution to the z-order problem

String osName = System.getProperty(“”);
if (osName.equals(“Windows NT”)||osName.equals(“Windows 95”)
||osName.equalsIgnoreCase(“mac os”)) {
// add components from top to bottom (z-order wise)
} else {
// add components from bottom to top (z-order wise)

The JVM problem

Variations in Java Virtual Machines (JVMs) are an ongoing problem, too. Different vendors make their own JVMs: Microsoft makes three — Windows, MacOS and UNIX; Sun makes two — Windows and UNIX; Netscape makes a lot, including Windows, MacOS and a few flavors of UNIX; Apple makes one — MacOS; Borland makes one — Windows; Symantec makes two — Windows and MacOS; and so on. You can see that with just the Windows OS, there are at least five different JVMs available, each with its own implementation.

As a result, to properly ensure that a Java app works as it should, it must be tested on every different operating system: Mac, Windows, Solaris, HP/UX, etc. Then, for each operating system, it must be tested with every JVM available for that operating system.


Is there hope on the horizon? It looks like Sun’s latest response is its Java Activator, an ActiveX component (for Internet Explorer) or plugin (for Netscape Navigator and Communicator), which replaces the JVM in the browser with the standard Sun JVM. This looks like a step in the right direction, but still isn’t the final answer since Java Activator will cause code to run slower. Also, Java Activator works only on the Win32 platform, so it leaves Mac vs. Windows issues unresolved.

Another solution is to use native compiling, a process that takes your Java code and translates it directly to a native executable. This is the approach taken with Supercede and Symantec’s Visual Café, but only works with Windows. Native compiling won’t produce a cross-platform application, but it will deliver versions of an application that work the same on every Windows box, regardless of the JVM.

The ultimate solution is for Sun to take control of all JVMs in an effort to maintain cross-platform integrity. As long as OS and IDE/Compiler companies are making their own JVMs, each will want its implementation to be the best and fastest. After all, that’s how you sell operating systems and IDEs. With each JVM optimized differently, every implementation of the JVM will have its own personality, confounding the cross-platform issue.


Java remains a great language — it’s powerful, easy and useful. But “write once, run anywhere” is critical to the survival of Java in the world of development. Developers will be willing to deal with the performance hit incurred in using Java if it will work cross-platform, but if there’s no assurance of cross-platform functionality, then there’s no tradeoff for the performance hit. Without cross-platform assurances, instead of using Java, developers will “go native” and worry about porting their creations to other platforms as it becomes important. If “write once, run anywhere” can be assured, Java has a great future.

Jason W. Purdy is the Java Product Manager with Stingray Software, Inc., a leading developer of Java and C++ class libraries. To find out more about Stingray, please visit

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories