Columns

Write once and run ...Sun mantra is questioned

• By Peter Fischer
• July 16, 2001

Almost everyone has been exposed in one way or another to the on-going war between Sun and Microsoft over Java. Sun's attempts to leverage Java "write-once, run-anywhere" capabilities of the language are being buffeted by Microsoft's strong foothold in the desktop operating system market and efforts to drive Java as just another programming language for delivering Windows applications. Microsoft's attack on Sun comes from two directions -- cross-platform woes and performance problems.

The latest installment occurred a few months ago when Microsoft escalated its war with Sun over Java. At the heart of this battle is Microsoft's refusal to distribute Sun's Java Foundation Classes (JFCs) in its release of the Java virtual machine. The JFCs are replacing the problematic user interface portion of the Abstract Windowing Toolkit (AWT), which allows complete customization of the user interface in a platform independent manner. Sun insists that the Java Foundation Classes are an integral part of Java and need to be present in any Java implementation. Microsoft's stance is that the JFCs present an operating-system-like functionality and that layering the JFCs on top of Windows is pointless because developers can access Windows directly through Java.

At the heart of Microsoft's two-pronged attack is the issue of the cross-platform capabilities of Java and reinforcing the fact that Java is a long way from delivering on its promise of "write-once, run-anywhere." Indeed, many seem to have been swept up in the hype of true cross-platform capability and true portability. Surely, the current failure of the 100% Pure Java Initiative has not helped Sun's cause in trying to win developers over to their portability initiative with Java.

The write-once, run-anywhere mantra has been diluted by the effect that different Java runtimes and virtual machines have on user interfaces. An application that looks great on Windows, for example, may look horrible on Solaris. Sun has indeed recognized this portability hole and is planning to address it in the next release of the JDK. Version 1.2, due out by year's end, will deliver to platform ISVs almost 80% of the Java runtime as a cross-platform implementation. The remaining 20%, which includes tuning the environment for specific hardware, will be done by the licensee. This 20%, however, still leaves the door open for portability issues.

Sun has promised true portability too early and fanned the marketing flames thereby raising expectation of the capabilities of Java. By now I/S professionals realize that Java is not as rich as it will have to be in order to deliver on all its promises. Even tool vendors are feeling this too as their environments are focused on providing access to the Java languages and its functionality in developing applications while achieving 100% Pure Java is a minor issue.

In addition, Microsoft has been touting their Virtual Machine (VM) as the fastest in the industry. Microsoft's performance advantages will continue to dominate the market until JavaSoft delivers on its promise of increased performance. The recent release of the Java Performance Runtime for Windows, which has an improvedJava virtual machine and Symantec's (Cupertino, Calif.) just-in-time (JIT) compiler, serve to narrow the gap in the short term. In addition, JavaSoft hopes to flatten the remaining performance issues by using its HotSpot Java Virtual machine technologies that it acquired earlier this year, which promise to rival the native platform performance of C++ code.

In spite of this, Microsoft is still blasting Sun and JavaSoft over the inefficiency of their cross-platform concept. Microsoft's position is that if an operating system that holds a large market adds a new feature, then advantage should be taken of it and not suffer the compromises of platform independence.

Microsoft tools for Java

What impact does that have on the software development industry in general? Some shops are looking to Microsoft for a total Java solution -- tools, performance and JDK 1.1 support. Some shops are finding it increasingly difficult to avoid Microsoft solutions. Their experience with delivering a developer-friendly environment using wizard technology makes their product suite very enticing. Their end-to-end solutions for Java provide the seeds for a cost-effective decision from both a staffing and purchasing view. However, their reluctance to fully embrace Java end-to-end tempers the fervor.

Microsoft's AFCs, which are written entirely in Java and therefore cross-platform, offer a rich set of functionality for building Java applets and applications and are positioned to make the JFCs irrelevant. By using the AFCs, developers can create robust cross-platform applications with modern user interfaces that are customizable, offering an alternative to the JFCs.

Microsoft does not have to embrace JavaBeans -- it just needs to provide access to and from Beans from its tools and ActiveX/COM. Whereas the JavaBeans/Active Bridge offered by JavaSoft does provide access to JavaBeans from ActiveX containers such as Word and Visual Basic, Microsoft's VM offers true bi-directional support between ActiveX and JavaBeans. For example, the Java VM in conjunction with the SDK for Java allows the use of JavaBeans inside ActiveX containers such as Word and Visual Basic. In addition to this high-level access to ActiveX functionality, the VM offers low-level integration at the COM interface level, providing JavaBean access from COM object clients.

At the bottom of the integration stack is the Raw Native Interface. This is for developers who need "pedal-to-the-metal" performance and is not for the faint of heart. It provides an efficient way to manipulate objects written in native code such as C and C++.

Where are we headed? So what is up Microsoft's sleeve? Is it trying to kill Java? All indications are that it is fully embracing Java as a great development language -- for Windows. Microsoft is after all, in the operating system business so it should come as no surprise that they would indeed reject any perceivable threat to their domination of the desktop OS market.

Microsoft among other vendors has taken advantage of the portability holes in the Java SDK to date to enhance its Java VM with value-add features that reflect the capabilities of the underlying operating system. Indeed, if 100% Pure Java is attainable, why should vendors be prohibited from adding extra features? After all this is an industry where vendors attempt to gain market share through product differentiation. Should Java be any different?

For certain sectors of the development community portability is a moot issue. Indeed, on the server side where true performance is a major concern, the decision is driven by the hardware and operating system. True Windows NT shops are less concerned about cross-platform and find the value-added features more attractive for their Java solutions.

A peripheral incident in the industry that may sway the tide of this war is the recent agreement between Microsoft and Apple on Java. One implication of this new "partnership" is the ability for ISVs to develop on Windows but deploy on Windows and MacOS. This "write-once, run-several places" capability could have a potential huge effect on ISVs such as Adobe and Autodesk, who may not have to port to Java in order to have their applications running on both Windows and Macintosh machines. If users do insist on Java, Microsoft will be in a much stronger position to promote its version over the 100% Pure Java brand.

Microsoft has always shown that they are responsive to the needs of the development community so ultimately the decision may come down to what developers and users want. If developers demand the JFCs, the outcome of this battle may be interesting to say the least. On the other hand, Microsoft does have a solid strategy and product set to support Java for both Windows and Internet/Intranet solutions with their Active Platform.