When it stormed on the scene, Java had several powerful market motivators going for it. One, it promised to do what C++ had failed to do: deliver a well-crafted object oriented language that had C-familiar characteristics. Two, the Internet/Web had well and truly arrived, thanks mostly to the success of Netscape and its browser. Put these two enabling technologies together and, Lo! Here was a way users could finally get a distributed, machine neutral desktop GUI driven by machine independent application code which could travel over the Net at will.

Talk about a one-two punch to Microsoft's financial solar plexus! For the first time in what has seemed forever, Microsoft's desktop hegemony appeared in peril. If its proprietary Windows API hammerlock on the PC client could be broken, then the "open market" floodgates would assuredly burst. Gates and his Redmond minions would be drowned in this technology torrent's thundering path. Is it any wonder this potential Java deluge gave VP Ben Slivka such a strong urge to wet his MS stock option pants?

Thus began Microsoft's now infamous two-front war. One was fought against Netscape. The other was waged against Sun Micro and Java. Both battles ultimately produced the same result: Microsoft ended up in court. The various combatants claimed that the Redmond company had broken the Geneva conventions of fair business practices. In November 1998, Federal Judge Ronald Whyte sided with Sun Micro in its civil suit against Microsoft over breach of contract. In essence, the court said that Microsoft would probably lose the case and the Redmond Renegades had infringed Sun's copyrights by altering Java in a way not allowed under its license. Microsoft had therefore broken its Java contract with Sun. The Judge issued a preliminary injunction and gave Microsoft 90 days to clean up its Java act.

Significantly, the judge didn't require Microsoft to issue a recall on its systems that contained this Sun-offending code. All those millions of Windows 9.x and NT operating systems and Internet Explorers out there with Microsoft-munged Java could stay in customers' hands. If Whyte had ordered such a massive software recall, it could have been economically devastating for Microsoft. So, the Sun victory, while significant, can also be counted at least as a partial win for Microsoft.

At the core of this Java dispute was Sun Micro's allegation that Microsoft had committed two cardinal contract sins. One, Gates and Co. had failed to support the Java Native Interface (JNI). According to Sun documentation, JNI is a standard programming interface for writing Java native methods and embedding the Java virtual machine into native applications. The primary goal is binary compatibility of native method libraries across all Java virtual machine implementations on a given platform. It allows Java code that runs inside a Java Virtual Machine (VM) to interoperate with applications and libraries written in other programming languages, such as C, C++, and assembly. Programmers can write one version of a native application or library and expect it to work with all Java VMs supporting the JNI. Note: The key words here are "all Java VMs."

Microsoft did two things that bent Sun out of JNI shape. First, the Redmond Renegades used its Raw Native Interface (RNI). RNI exposed the layout of internal Java objects to Windows and Internet Explorer native code, a big no-no as far as Sun was concerned. RNI also made implementations of advance garbage collection algorithms more difficult as effective "write barriers" were almost impossible to incorporate. The second big sin was Microsoft's use of COM (Microsoft's Component Object Model) instead of JNI. Says Sun about using COM, "We believe that it is not appropriate to treat all Java classes or low-level native methods as software components." And further, "The immediate adoption of COM is hampered by the lack of its support on UNIX platforms." Sun closes out its remarks with this perfunctory statement, "As soon as cross-platform support for COM is available, the JNI can become a COM interface to the Java VM". Apparently, once Microsoft gets COM running on Solaris, its software component methodology is no longer inappropriate!

Via RNI and COM (and likely other clever coding tricks), Microsoft assiduously and systematically did everything it could to make Java as Windows API specific as possible. In March 1998, Microsoft's announcement of its new Visual J++ tool at last ensured that Java code was going to be captive to Windows, if Redmond got its way. Included with this new iteration of J++ was a slew of new Windows-specific Java class libraries. In addition, there was Microsoft's J-Direct which allowed developers to make direct calls to native Windows functions. This Microsoft Sun-will-be-stopped-at-any-cost Java onslaught was initially dubbed VJ98, but eventually was just called Visual J++ 6.0. Any Java code developed with these new VJ tools virtually guaranteed that it would not run without the presence of proprietary Windows APIs. So much for Sun's vaunted "write once, run everywhere" Java premise.

The second major contract sin was Microsoft's abject lack of support for the Java RMI as set forth by Sun. RMI (Remote Method Invocation) allows an object executing on a Java VM on one system to invoke methods on an object running in another Java VM on another machine. Unlike an RPC (remote procedure call) or message passing scheme, the distributed RMI methodology allows the passing of machine independent Java code as well as data. Thus, one can move around class or subclass behaviors from one Java VM to another if the required code is not resident on the remotely invoked machine. Ordinarily, because of differences in machine architectures, such ad hoc moving about of executables is out of the question.

In the real RMI world, this means that a Sun UNIX workstation could join with a WinTel PC and do cooperative distributed processing at the object class level. Is it any wonder that Microsoft balked at implementing a valid RMI?

Microsoft had several choices about how to respond to Judge Whyte's ruling. Of course, Microsoft could have immediately appealed the ruling and awaited the outcome. But that would leave Microsoft's Java developers in a likely several year lurch, not a very smart marketing posture. Or Microsoft could drop PC desktop and server support for Java altogether -- unlikely, given the ever increasing presence of Java on the Net and in the Enterprise. However, there are two other possibilities that could get J++ back on the A Train quick and in a hurry.

The judge's ruling gave Microsoft an escape hatch the size of the hole in the Titanic, and likewise, may be destined to sink Sun's plans. To be in court compliance, Microsoft only has to make its J++ tools and its Java VM a secondary set of user options. The Sun-specified Java system must be the primary default setup. Carried to its take no prisoners' Microsoft marketing conclusion, we might witness the spectacle of two wildly diverged Java systems on Windows and IE. One would be the bare minimum Sun-spec'd Java as the court ordered system default; the other an incredibly Windows optimized J++ and MS VM as the "preferred option".

In fact, this is exactly what happened. In January 1999, Microsoft brought its Java VM into court ordered compliance with the release of a service pack for Visual Studio 6.0. However, the Service Pack 2 fix allows users to easily switch from the cross platform Sun Jav"default" setting back to Windows-specific VM code. So even though such court disputed items like the Java Native Interface are now officially supported by Microsoft, Windows developers can easily circumvent having to work with this new Sun-sanctioned code. (Not so coincidentally, almost immediately after issuing this new service pack, Microsoft filed an appeal against Judge Whyte's ruling.)

What's worse (from Sun's perspective) is that when Sun released its new Java 2 SDK at the end of 1998 (nee, Java Development Kit 1.2), Microsoft said it would only be bringing its systems into Java SDK 1.1 compliance to satisfy Judge Whyte. Microsoft asserted that support of the new Java 2 system seemed unlikely. And besides, Microsoft said it still had to study the new Java 2 release. In truth, most all of Java 2 had already been released during that year in piecemeal form. Microsoft already had been given plenty of time to do its Java 2 homework.

Moreover, when Java 2 was announced, Microsoft maintained it had a better software plan for dealing with the problems Java 2 supposedly solved. This is a curious statement from Redmond, as Java 2 offers a host of features that are quite Java specific. These include finer granularity, or control, over the levels of Java run time security. In addition, this new iteration contains such things as enhanced API support for Java 2D; better drag and drop; foreign character support; a Java Plug-in; a JavaIDL for non-Java application support; JDBC 2.0 for improved database access; and a framework for managing collections of objects across unrelated APIs. These are all considered by Sun to be "core" components of the Java 2 SDK. So what, in fact, is Microsoft saying when it has a better solution than Java 2?

Maybe this is where the "clean room" Java option comes in; a Judge Whyte-avoidance path that has been made much easier for Microsoft, thanks to Hewlett Packard.

At just about the same time in March 1998 that Microsoft launched its J++ nukes at Sun Micro, Hewlett Packard also dropped a bombshell on McNealy's well-laid Java plans (was this timing pure coincidence, Muldar?). Apparently fed up with Sun's vise-like grip over the Java standard's process ("This was not an open process" -- Joe Beyers, General Manager, Hewlett Packard's Internet Software Unit), Hewlett Packard announced it was busily creating its own clean room implementation of Java for embedded systems.

Embedded systems have very special operational requirements than either your home or office PC. Typically, embedded systems run real time tasks, which live by a whole different set of high performance rules than their conventional computer counterparts. In addition, unlike regular computer systems, memory size constraints are also a big limitation in designing embedded systems. The Java system on your PC or UNIX workstation needs about 500 KB of memory to become a meaningful system with some essential class libraries loaded, with at least 2 MB or more usually needed at the end of the day. In the PC and workstation world, this may not seem like much memory. But in embedded systems where build costs are counted in pennies, every extra KB of RAM is a bean counter's nightmare.

Although Sun had its own EmbeddedJava technology, it was still too laggard (if not allegedly arrogant) as far as HP was concerned in making the required changes for this real time breed of Java. Hewlett Packard derives big revenues from its embedded systems products. They encompass computer peripherals, consumer electronics, laboratory instruments, and medical devices. Business-wise, Hewlett Packard simply could not afford to sit on its hands and wait for Sun Micro to figure out how this parallel computing universe worked. So Hewlett Packard bolted and did a clean room (reverse engineered) version of Java that required no Sun license.

The Hewlett Packard Java VM, called ChaiVM, only needs about 175 KB of RAM to work well, a significant memory savings over regular Java. ("Chai"is Hindi for "te" -- maybe a word meaning "Decaf" would have been better). HP's Chai implementation runs on MIPS, Motorola, Intel X86, and StrongARM processors. Chai includes a full bytecode interpreter; the Java Native Interface (JNI); multithreading capability; concurrent garbage collection; exception handling; and the JDK 2 (Java 1.2) Security Manager.

Significantly, Hewlett Packard also announced that it had picked Wind River Systems' VxWorks as the real time operating system to run its new ChaiVM. This HP decision was a blow to Microsoft as it had hoped that its Windows CE real time operating system would be used instead.

Although Hewlett Packard chose not to use Windows CE, it considerably eased Gates' pain by cross-licensing its new Java development to Microsoft. The folks up in Redmond promptly said it would use this non-Sun product in MS CE. The ChaiVM thus became Microsoft's ace in the hole in its Java poker game with Sun Micro. This HP approach will save Redmond a huge amount of time in getting a non-Sun Java system to market.

In any event, HP opened the Sun Java escape hatch and Microsoft took advantage of it to make a quick -- and confusingly hasty -- exit.

Knowing Microsoft, this ChaiVM windfall probably still left Gates feeling grumpy about Hewlett Packard's choice of VxWorks over CE. But in fact, Sun Micro has much more to feel miserable about with respect to some other HP Chai decisions. For in addition to Microsoft, Hewlett Packard immediately began licensing its new Java to other real time operating systems vendors, like Integrated Systems, Lynx Real-Time Systems, Microware Systems, and Qnx Software Systems Ltd., the majority of whom had also signed on the Sun EmbeddedJava line. Moreover, even mighty Intel threw its support behind HP's new clean room Java. Sun now faced serious Java competition. A palace revolt was underway.

What drove HP in its native compiler approach is increased execution speed of its Chai VM. The overhead associated with Java applications, most especially in client-side apps, has been just too much for many developers and users to swallow. A client side Java application runs terribly slow if it has to transmit a large amount of data or perform a large number of calculations. With regards the latter criticism, engineers have long been complaining that when it comes handling floating point, arrays, and complex numbers, Java just plain sucks. And if the client Java application is doing complex transactions against a database, performance is equally bad. In real time embedded systems, all these negative Java issues are exacerbated.

In addition to HP'e efforts, a number of other approaches to "going native" are being made to improve Java's laggard performance on both embedded and regular computer operating systems. JIT (Just in Time) compilers are appearing which increase Java performance considerably. A well-designed JIT should allow most any Java VM, provided it has the appropriate run time support libraries, to still work as originally envisioned by Sun. However, the JIT approach is inherently limited by the requirement that it perform its optimizations in real time as the user executes the program. Sun's own "HotSpot" JIT is due in 1999.

In marked contrast, native systems like HP's compile the entire Java application before it is executed. This is radically unlike the JIT approach as it forgoes the ability to load new Java classes during execution. Thus, you must specify in advance all of the classes an application will need prior to its compilation.

A good example of the gone-native approach is found in Tower Technologies "TowerJ", which runs under LINUX. Like Hewlett Packard, Tower Technologies developed TowerJ without a Java license from Sun. TowerJ has paid off in huge Java performance dividends. Volano LLC released benchmark results (the "VolanoMark") in November 1998 that put TowerJ first on the server-side Java performance list. TowerJ beat out even Microsoft's much touted Java SDK NT speed demon. In contrast, Sun Solaris and its "traditional" Java system came in a distant third, turning in a VolanoMark nearly half as slow as TowerJ. Clearly, this let's-do-it-all-at-once Java compilation approach pays huge performance dividends, on servers, clients, and most especially on embedded real time systems.

In December 1998, Hewlett Packard threw down the Java gauntlet for real. It lined up twenty-five supporters for its clean room Java VM and launched (you guessed it) a new Java industry consortium. This one is called the "Real-Time Java Working Group." Significantly, this new industry group enlisted the support of the National Committee for Information Technology Standardization (NCITS), formerly known as X3, which also oversaw the specs for C, C++, and FORTRAN. These NCITS guys are industry heavyweights.

Ostensibly, this Java palace coup is taking place just in the real-time embedded world. But with NCITS involved in overseeing real-time extensions to Java, the dynamics could abruptly change to also include Java in normal computing environments.

In the face of all these developments, Sun obviously had to do something to stop the Java barbarians at the contract licensing gates; otherwise, its Internet-inflated stock price citadel would be forever lost. And therein lies the business rub: If McNealy lets go of Java completely and it becomes just another ANSI-spec'd language, the market perception of Sun and its Java crown jewels goes right out the door along with it. In this era of tulip-mania inflated Internet stock prices, perception counts for far more than profitability. Sun is therefore in the unenviable position of being wantonly manipulated thanks to its own Java marketing success. Worse, Sun does not possess the Microsoft-like prowess to overcome its maddening market situation. The consequence of all this has been a confusing Sun series of Java licensing fits and false starts.

To counteract its contract critics, in December 1998 and in conjunction with its release of the Java 2 SDK, Sun revamped its Java licensing policies. Prior to this contract revision, Sun demanded up front one time Java licensing fees that ranged from five to seven figures, depending on the licensee's annual revenues. This kept all but the most flush players out of the Java game. But now, these onerous fees for Java source code access are forever eliminated. However, the new Sun licensing policy still keeps per unit royalties payments intact if a company plans to ship commercial products that use the Sun Java SDK. There is still no free Java lunch.

Java variants like PersonalJava and Embedded Java also come under this new contract/licensing policy, as does JavaJini. CardJava, however, stays with the old licensing program, but who knows how long even that will last.

But maybe most galling to Java licensees was the contract stipulation that any extensions or revisions they made to the Java code became the intellectual property of Sun, and that all such modifications were to be shared among all Java licensees. Ostensibly, this was to make sure that Java technology did not fragment like UNIX did. Only a united Java front, Sun proclaimed, could withstand a highly focused and ferocious market onslaught from Microsoft.

This all had the ring of truth, to be sure. But what company wants to spend thousands of man-hours developing an edge over its competitors, only to have to give it all away? Therefore, in conjunction with the dropping of its up front source code fees, Sun also announced its new "open Java licensing" policy that same December. Unfortunately, this new Sun stance on open source has more holes in it than Swiss cheese, and contains not more than a little Orwellian doublespeak.

First, the holes: To counter its critics, like Hewlett Packard, and most especially to blunt the NCITS from publicly sanctioning new Java extensions, Sun now says that all such extensions are the intellectual property of the developer, and do not have to be shared with other Java licensees.

In the new Java Jini (more about which technology later on) Technology Core Platform License, Version 1.0 DC, it states that if you license this code from Sun, you must also: "grant to each Licensee a license to Your Error Corrections and Shared Modifications, of the same scope and extent as Developer's license to You for (Sun) Original Code, Upgraded Code and Reformatted Specifications..."

Simply translated, if you fix any bugs or modify the Java source code as delivered to you by Sun, you still have to share them with everyone else. According to Sun documentation, its JavaJini license will be the model for all other Java systems, as well. In the case of Jini, the Sun "Original Code" encompasses the following:

1.Jini Technology Core Platform Source

net.jini and all sub-packages distributed with release 1.0 DC including:

2.Specifications (description of specifications and other documents):

Jini Technology Core Platform Specifications