Jon Dreyer
March 24, 1998
Java is a combination of language, class libraries and virtual machine that together offer at least the potential of "write once, run anywhere." Microsoft looks at it a little differently. By adding WFC and J/Direct class libraries, which happen to depend on having something very much like Windows underneath the virtual machine, they reduce the promise to "write once, run on any Windows platform."
Most personal computers depend on "Wintel": Microsoft Windows software combined with Intel hardware. Because of Wintel's dominance in the marketplace, most software and hardware developers develop for the Wintel platform, and of course the availability of more hardware and software designed for that platform only enhances Wintel dominance. (This is an example of "increasing returns".) I guess you could call the two of them a "biopoly" or perhaps a "monopolie à deux." Needless to say, this has benefited both companies immensely, to the point where the quality of their products has become almost irrelevant to most buying decisions (except when comparing with other Wintel products).
But the two rulers have a shaky relationship. Each is uncomfortable depending on the other. Intel, for its part, encourages non-Windows software developers to develop for Intel hardware. For example it has courted Unix vendors like Sun and may have invested in Be Inc. Microsoft in turn has ported NT to a few other hardware platforms and has promoted Windows CE, which runs (as far as I know) only on non-Intel hardware, and Windows 95/98, the only Windows architecture that depends on Intel, will probably be pushed aside by Microsoft as soon as the combination of NT and CE has enough of what they need. Both companies seem to wish to retain their monopolies without dependence on the other.
Neither company's efforts to go beyond Wintel have proven very successful. The problem Microsoft has had in promoting non-Intel platforms is the flip side of their own enviable position: Intel's monopoly makes it usually not cost-effective for developers to develop software for non-Intel platforms, just like Microsoft's monopoly makes it usually not cost-effective to develop software for non-Microsoft platforms.
Enter Java. Microsoft originally viewed Java as a threat. With Java, in theory anyway, applications were no longer tied to any particular hardware or software platform. As long as a Java Virtual Machine was available on a given platform, it could support Java applications. The more successful Java became, the less relevant Windows became: Imagine if software vendors started shipping mostly Java apps rather than Windows apps. Suddenly people could start buying Macintoshes, Unix boxes, or any other hardware/software combination that supported Java, without concern for whether applications would be available for their platform. They could choose an OS based on quality, performance and price rather than simply buy Windows because it runs Windows apps. Microsoft knew that if this were the case, there would be much less demand, to put it mildly, for the Windows platform or for Windows apps.
But somewhere within the depths of their fears about Java, Microsoft saw an opportunity. What if they could somehow keep the hardware independence of Java while maintaining software dependence on Windows? The answer was simple: develop Java class libraries that depend on Windows. That is why they developed JFC and J/Direct, which are Java class libraries that export the Windows API. JFC and J/Direct can only be reasonably implemented on Windows or by those with access to Windows source code. So if you want to run applications that depend on those class libraries, which I'll call Decaf applications because they don't run on standard Java Virtual Machines, you are stuck with a Windows platform, but you are not stuck with Intel hardware. Ka-ching!
If Microsoft were to implement these class libraries perfectly, a single Decaf application could run on Windows 95/98 any NT platform, any Windows CE variant, and even the Macintosh, thanks to the Macwintoshes deal I wrote about previously. Of course they won't implement it perfectly; there will be incompatibilities, subsets, FUD timelines, and the rest, but surely this is where Microsoft is attempting to go with Java. If Microsoft is successful, by which I mean that they implement Decaf well on a number of Windows platforms and convince a critical mass of developers to sacrifice the software independence of Java to gain access to Windows APIs (after all you only lose about 10-20% of the market that way), they may succeed at pushing Intel off the hilltop that they have shared until now, without falling off themselves. This is as close as you can come to a Holy Grail for Microsoft.
One of the things that are appealing about Java is that, by being platform-neutral, it gives vendors a chance to innovate and gives users choices. The existence of Java has breathed new life into all sorts of non-Windows platforms like Unix, Epoch32, OS/9, OS/2, and the Mac, to name a few. Until now, the market share of these platforms has been such that there hasn't been much incentive to develop for them, but by writing "pure" Java you write for all of them, which opens up platform choices wider than they've been since the advent of the IBM PC. Given Java's current compatibility and performance problems, it is tempting to go for the Decaf quick fix. As developers and as customers, we need to decide whether to make this Faustian bargain, remembering that freedom, like your soul, is easy to give up but hard to earn back.
Copyright (c) Jon Dreyer, 1998