Sun Java vs. The World As We Know It

Or, Why Microsoft Still Doesn't Want You to Have it Your Way

Francis Vale

Microsoft will be "pissing on" parts of Jav"at every opportunity"
-- Ben Slivka, Microsoft Vice President,
from his e-mail to Bill Gates,
presented as evidence at the DOJ antitrust trial.

Java has had a tempestuous history in its short-lived existence. If any technology can be said to be political, it is this one for creating machine independent code that can float across a network. Originally called 'Oak", Java was envisioned by Sun Micro as a small-scale language for embedded systems. But in just several short years, Java has possibly become the indestructible Ginsu knife via which anti-Microsoft zealots hope to carve up Bill Gates' global software empire. It now seems that Java can slice, dice, chop, and do almost an endless variety of tasks, from operating your ten dollar disposable cell phone to running your multimillion dollar enterprise systems. If this one technology size fits all sounds too good to be true, well, it probably is.

At the core of Java is a relatively straightforward notion: create an elegant object oriented language that produces code which is completely machine neutral. The neutrality is achieved via a byte code interpreter that translates the Java source into a native executable. In computerdom, this notion of using a machine independent byte code interpreter, or virtual machine, is at least 25 years old. (Remember P-code from UCSD?) But as we all know, timing is everything.

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.

Which it will have to quickly do, since in January 1999, Microsoft abruptly and without warning yanked all the Java tool sets from its MS CE web site. Suddenly gone were CE Visual J++ 1.1; J++ SDKs for CE Versions 1.0 and 2.1; and all word of CE J++ Service Pack plans. Instead, said Microsoft, developers could expect to be getting a whole new Java tool suite based on HP's Chai. Also AWOL was any MS news about CE support for Sun's RMI and JNI. Given the most assuredly heterogenous mix of real time operating systems in the market place, such cross Java platform support by Microsoft is almost a business mandate -- unless, of course, you are Microsoft, and you just make up the rules as you go along. Most conspicuously missing along with all these Java tools were any specifics as to when their new Chai CE replacements would be available.

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.

Moreover, Hewlett Packard was hard at work in developing "native compilers" for Chai. HP's approach will result in compiling Java byte code to platform specific executables. Thus, this HP Java code loses its ability to get up and instantly move over to a foreign platform. It becomes just like any other fully compiled language, like C. Instant Java code portability is a major Sun marketing point in its fight against Microsoft. But now, with HP's blessing, it appears that Microsoft was right after all when it said that Jav"was just another programming language."

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.

Another example of a Java native compiler is "JOVE." According to Instantiations, Inc, its developers, JOVE is a true optimizing "whole program" native Java compiler which translates Java class files directly into optimized native machine code. Some competitive compilers (like TowerJ), asserts Instantiations, simply translate Java byte codes into C code and rely on C compilers (which have no knowledge of Java's object-oriented constructs) for native code generation. These compilers have no direct control over the machine code that is ultimately generated. Jove is an "ahead of time compiler", and does its optimizations during the deployment phase of a project when developers are preparing the application to be distributed to users. A JOVE graphic shows a complete Java app being turned into a 100% native .exe file for a Windows9X/NT PC.

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

- Jini Architecture Specification v. 1.0 DC

- Jini Lookup Service Specification v. 1.0 DC

- Jini Lookup Attribute Schema Specification v. 1.0 DC

- Jini Discovery and Join Specification v. 1.0 DC

- Jini Distributed Event Specification v. 1.0 DC

- Jini Distributed Leasing Specification v. 1.0 DC

- Jini Transaction Specification v. 1.0 DC"

-- Copyright 1999, Sun Microsystems

If you modify or fix anything of the above, Sun owns it, and you must share it. Moreover, the "Original Code" includes pretty much the whole Java Jini enchilada. The same all encompassing "Original Code" ownership principles will most certainly apply to other Sun Java systems, as well. So it seems you still get to work for Sun and other Java licensees for nothing.

Moreover, Sun gets to decide as it goes along what constitutes "Original Code." (See the "Upgraded Code and Reformatted Specifications" contract lingo mentioned above). If a company develops a proprietary extension to Java Jini that Sun later on decides ought to be part of the Original Code, all Sun has to do is roll out its own version of this new functionality. McNealy then blesses its own version as being "Upgraded Original Code" and this licensee's proprietary extension now becomes a contract outlaw. No doubt, contesting such licensing issues will make many lawyers rich for some time to come.

Is this a new Sun game anybody really wants to play? Apparently some do, because in response to these latest Sun maneuvers, at least three embedded systems vendors -- Connectix, Insignia Solutions, and the Tao Group-- dropped their plans for also making Java clones. But from a business plan standpoint, their no-go decision makes perfect sense. With the prospect of garnering huge up front fees gone, and all that remained was waiting several years to collect nickel and dime royalties, their collective business plans quickly went to hell in a hand basket.

Significantly, Hewlett Packard said that Sun's new contract and modified open source moves were "a step in the right direction" but declined to drop its own Chai plans, or to stop continuing to work with the NCITS. Hewlett Packard would stay its Java clone course. This can only spell more bad news for Sun.

Now for the Sun doublespeak: In Sun's public pronouncement about its new Open Source licensing policy, dubbed "The Sun Community Source License (SCSL), the company publicly stated what was good and what was bad about Open Source licensing (currently made famous by LINUX). Under the section "Open Source Disadvantages", Sun listed the following objection to this now tried and true methodology:

"There may be no responsible organization. Bugs introduced by another organization may be too difficult for a using organization to fix and of too low priority for the author to fix in a timely manner."

What Sun is arguing for, of course, is that it, and not some unruly mob on the Net, should be policing the Java code. But later on as Sun expounds in this same public document on why Java SCSL is good for you and Open Source is bad, Sun states, under the heading, "Increased Quality", the following:

"Simply stated, with more eyes looking at the code, there is more chance that errors will be caught and repaired, particularly when that code is used in situations and contexts not anticipated by the original developers and researchers. It might be thought that with an Open-source type of model there would be increased likelihood of errors in code, but the Open Source experience is largely the opposite - that because the source is published, developers are generally very careful while developing code in order to avoid public embarrassment."

So, under Open Source Disadvantages this type of Java bug fixing is bad, and under SCSL it is good! It's hard to say which is more ludicrous or outlandish, the new Sun Java contract or this Sun marketing doublespeak. Either way, it's clear that Sun is frantically scrambling to hold on to Java, and that letting go will be neither easy nor painless.

The only real business alternative for Sun with Java is to develop innovative systems that people will willingly pay money for, whether they be an OEM, ISV, or end user. This is so patently obvious as to be almost absurd. But this simple truth seems to have eluded this Silicon Valley company more often than not in its ongoing marketing miasma machine. Java Jini is one good case in point of what Sun can create as a viable business product.

Jini is a small system (its core functionality is just 48 KB) that extends the Java RMI technology. As noted, RMI allows an executable Java class or subclass to be moved across a network as needed and invoked on a remote system to access a service of some type. Jini solves the problem of what that service is, where it's located, and how to handle security.

In Jini-speak, a service could include printers, displays, or disks, software applications and utilities, databases and files, or even users of the system. When a Jini-enabled service is plugged into a network, it multicasts a special 512 byte packet on a well-known port that announces its presence. Based on prespecified conventions published by Sun, this item tells the world, in this case a special Jini lookup service, what it is and what it can offer.

The distributed lookup service acts as an available service registry, a small database, really, which can also be nested in a hierarchy. The extended RMI is then used to shuttle executable Java code objects that contain the interface, along with any other descriptive attributes, between the requesting client and the available service. For example, they could consist of an object class of printer descriptions, with subclasses of special printer capabilities. By moving this Java interface code (called "proxy" in Jini) back and forth directly over the network between distributed Java VMs, you are removing distributed device drivers out of the operating system loop.

A two-phase commit protocol is also implemented which coordinates state changes between distributed Java objects. In addition, a time-based "leasing" service extends the Java programming model. Leasing seeks to mitigate the adverse effects of a network connection failure between a service and its requesting client. The Jini lease binds the two parties together and the prior service state can be safely reclaimed at network reconnect. (If you look at the "Jini Technology Core Platform Source" reference above, most all of this can be easily gleaned.)

What may not be apparent is that Jini can support any programming language, so long as it has a compiler that produces compliant bytecodes for the Java language. And even more significantly, an object in the lookup service can also be a complete user interface (which will be identified by the Java programming type "applet"). This latter capability means that both services and their user interfaces can be easily combined and distributed. So, use your browser to log onto Jini, then have it step out of the way, as Sun says, "to let the human user interact directly with a service." This has some amazing implications, if you think about it.

As interesting, it is not even necessary for Java or Jini to be on a device for it to communicate with a Java proxy server. A developer can create a private protocol of his own design that will enable a non-Jini device to communicate with a Java VM or Jini proxy sever on another system.

Of course, Jini does have its downside. Due to the often-large size of a roaming Java executable, this system obviously needs lots of bandwidth, as well as a skilled network administrator to setup the IP address tables. As important, the organization has to set policy about appropriate authorization privileges. For example, access to certain classes of Jini-enabled services might be either allowed or denied, depending on the circumstances and who the user is.

Despite these obvious issues, Sun first pitched Jini at embedded systems for consumers, like for smart stereo systems, DTV set top boxes, intelligent cell phones, and the like. But unless Sun figures out a way to overcome the need for a sophisticated network administrator, not too mention scarce consumer bandwidth, this use of Jini is a non-starter from the get-go. For example, how do competing DTV broadcasters get their IP address assignment act together when you switch TV channels? And how (and by whom) is it decided which Jini services from competing providers are made available to the consumer?

However, Jini in the enterprise makes a great deal of sense. The skilled staff is already on hand, and the enterprise needs that Jini fulfills are much greater than those of a consumer flipping through a Jini-enabled DTV broadcast of Gilligan's Island. The lightweight two phase commit protocol and the network fail safe aspects of Jini are especially appealing when designing distributed systems. Already, both Federal Express and Computer Associates International have reportedly said to be rolling out Jini-enabled systems come the end of 1999.

Given the incredibly broad definition of what constitutes a service under Jini, the potential of this architecture within the enterprise is huge. But so are the political ramifications. Jini really does drive a stake through the heart of a proprietary operating system, like Windows. Clearly, Microsoft now has a big new concern for aggressive targeting. But will Microsoft be hampered in its counterattack thanks to the Sun Java court precedent and the overhanging cloud of the DOJ case?

Apparently not. Microsoft has already indicated that at the Los Angeles WinHec conference in April 1999, it will be announcing its Jini counterattack. Microsoft believes that the ability for distributed systems and services to automatically identify themselves to networked clients is important for future development, but that the overhead associated with the Jini approach is too onerous. So look for a Microsoft solution that leverages its Windows and IE APIs, and dismisses the RMI notion of moving proxy executables about as so much overhead nonsense.

You can also expect Hewlett Packard to enter the anti-Jini fray. The company already possesses a mature technology for enabling communications between heterogeneous, distributed devices, called JetSend. This communications technology already works with a number of real time operating systems. So it's reasonable to expect a sharp Jini riposte from HP along the lines of JetSend in the not too distant future.

Still, it may be Java Jini that finally wins Sun its elusive victory over Microsoft, but perhaps not in the way Scott McNealy expected. Device driver support has long been at the crux of any operating system's acceptance. Via Jini, Open Source LINUX users get simple and quick access to a large class library of machine independent device drivers. Plus, LINUX users gain instant admission to distributed services across the enterprise. As a consequence, this no cost, Open Source operating system's surging popularity would increase all the more. Indeed, in 1998, LINUX was the only operating system to gain market share against Windows. Support for Jini will only add to the non-stop LINUX momentum.

This in turn brings us right back to turning Java into Open Source, a move that Sun has been kicking and screaming against despite its SCSL lip service.

Java has become much bigger than Sun. Java is now so many different things, to so many different people, with so many different and diverging interests, that it's become next to impossible for just one company to manage it all. Worse, it is becoming increasingly clear that Sun, even with its SCSL approach, won't be able to keep up with what's required. For example, none of the performance problems seem to have been resolved with the release of Java 2. Many developers are sticking with the Java 1.1 SDK, as it's leaner, faster, and better implemented. In fact, IBM says it will only ship Java 2 if its customers request it, and/or when Big Blue finally thinks it's ready for prime time.

In retrospect, it appears the Open Source Java die was cast almost from the very day it was announced. The Open Source movement marks the single technology event that can actually topple Microsoft. Java, in all its manifestations, fits perfectly in this new techno-politico flow. Like LINUX, and despite all of Sun's machinations, Java fundamentally takes the philosophical stance that no one company should have proprietary control over computing's future -- whatever that future may ultimately turn out to be.

With both Open Source Java and LINUX, the dividing line between what goes into the operating system and what doesn't ceases to be an artificially created marketing battle line. The demarcation line becomes, instead, a technical issue of what works best for the user.

Yes, we will watch the company's stock price take a huge tumble the day Sun Micro finally turns over all of Java to the Open Source world. And yes, when the Sun stock drubbing dust finally settles, McNealy may have to find a new line of work. But as loser's compensation, he might at least take comfort in the fact that the dynamic duo known as Open Source Java and LINUX may have finally toppled Microsoft.

Copyright 1999, Francis Vale, All Rights Reserved

21st, The VXM Network,