In the final months of 1998 it was worth reflecting on the networked application platform and its star player, Java, as we headed into the new year. Many of you have written and put forward your own assessment of the Java movement as it rode into 1999, representing the fourth year of Java as a commercially available development platform.

This is the first installment of our theme "Java - Into Its 4th Year," and we will review the platform independence promise of the Java platform: run anywhere, anytime. It's not an all or nothing proposition.

Never has more hype surrounded a basic notion of platform independence as Java's "run anywhere, anytime" promise. This was particularly acute with Java on the client side (in browsers). Unfortunately, Sun's marketing messages were taken completely out of context and Java developers assumed that any piece of compiled Java code would magically run not only on all virtual machines and platforms, but in all circumstances as well. Why would any experienced developer fall into such a predicament?

The marketing message should probably have been "Java, run anywhere, anytime - with the appropriate amount of effort!" It's certainly possible to create a Java client that runs across the vast majority of possible client configurations. Creating a Java client that runs across all possible client configurations is not significant, that is, it's not necessary to cover all permutations to achieve the desired effect. In other words, if out of 100,000 end users 10 can't access your Java client because they're running OS/2 and the Navigator 2.0 browser, does that constitute a failure in deployment? I should say not.

A well-engineered Java client is extremely successful against a wide cross-section of possible client configurations easily covering 90% of possible end users. Witness the Yahoo! game site and its multiplayer Java games: chess, backgammon and checkers.

The Yahoo! games constituency runs across Macintosh, Windows and Solaris Workstations, and various versions of browsers across each. Witness the PROGRESS Apptivity 3.0 Java client that supports Netscape and the IE 3.x and 4.x browsers across all major OS platforms. "Support" doesn't translate into "works every time without any effort on your part"; it translates into "will be portable with a reasonable amount of effort by the developer and the vendor."

On the server side, Java platform independence has received additional scrutiny. While it's clear that the UI layer presented the toughest platform challenges, the server side is not immune from slight discrepancies in the JVM. The most important thing to remember is that server-side processes, particularly those oriented at high-transaction business functions, are very reliant on the robustness of the JVM implementation. A server process with 1,200 threads and 1,500 object instantiations is no angel; it's significantly dependent on its Java container. Such a beast running on JVM 1.0.2 would most certainly come to a crashing halt, while under JVM 1.2 it would most likely hold its own. It would perform even better if such a complex process was abstracted on top of a competent CORBA infrastructure.

Once again, this shows the importance of layering the Java solution and insulating the developer from the challenges faced in achieving platform independence and performance. On the client side, the developer using a proven, supported Java client architecture will achieve success far and above a counterpart creating the client from scratch. At the very least, the Java client should take advantage of a foundation class such as JFC/Swing, AFC or Netscape's IFC. On the server side, the developer building on top of JDK 1.2, Corba and EJB will get to successful deployment and scalability while the developer building from scratch will most likely never achieve deployment at any reasonable scale!

Java is heading into its fourth full year as a legitimate language and platform, and with it, developers can achieve platform independence with a reasonable effort. How much effort will be required to port an ActiveX control across Unix, Windows and Mac platforms? How much effort will be required to port a significant C or C++ executable across these platforms?

Platform independence is not an all or nothing proposition. It's a question of practicality, and a question of reasonable effort leading to significant value!