Java HomeNewsJava-Based AppsDeveloper ToolsDeveloper AssistanceEducationCommunityEventsFeedback
Java Commentary
On the Agenda: So Microsoft Hates Java; What's Changed?
Still trying to interpret Microsoft's shifting position on Java? Simon Phipps of IBM's Centre for Java Technology Development says it isn't that hard to figure out.

So the truth is out at last. Microsoft has declared war on Java. Or, rather, the war is now out in the open.

Fear and Loathing
When Java was first announced in May 1995, Microsoft ignored it. When it grew in popularity during 1995, Microsoft hated it. After missing the Internet wave, Microsoft went through very hard work and internal strife to reach a point where once again it stood a chance of dominating the personal computer world through proprietary technology and "taxing" each future installation. When faced with a simple and effective technology that made it possible to publish software on the Internet without the need to pay the Danegeld, a technology that it did not own (in fact, it was owned by one of their bitterest rivals and deepest critics), Microsoft's hatred grew. But Java's Duke was surfing the crest of the Internet wave that still threatened to engulf it, so finally, in October, 1995, it was forced to license Java for use in its own Web browser. This was packaged for the media as a change of heart. Under the surface, though, nothing changed. Microsoft may have licensed Java, but it still feared and hated it.

"Embrace, extend, ... assimilate"
Accompanying this public position of "embracing" Java was an attempt to reduce its rapidly increasing value. This was done by emphasizing Java's value as a programming language (to write add-ons for Internet Explorer) rather than as a platform-independent software system whose core principle was that the bytecode-binary executables it made would run without change on any platform. Playing down the portable program aspect of Java was key to the strategy of "embrace, extend, and assimilate."

To gain the channel to influence people's thinking, Microsoft needed mindshare. It hacked its Visual C++ developer tool and quickly produced a respectable programming product, Visual J++. The combination of a reasonable product, an already huge captive market to which to address it, and pricing so predatory as to seem free of charge (my copy actually was free) enabled it to rapidly distribute huge volumes and claim market leadership. But Microsoft still feared and hated Java.

Foundation and Empire?
It didn't work, though. Once again, Microsoft's strategy failed. Java spent 1996 going from strength to strength. Its main failing was that, despite maturing ten times as fast as any technology before it, the marketplace still wanted maturity faster. The biggest design flaw in Java 1.0.2 was the windowing layer (the Advanced Windowing Toolkit or "AWT"). In the early days of Windows 3, facing the prospect of portable programming toolkits, Microsoft had very successfully monopolized the developer space for Windows by producing a subroutine library to mask the (hellishly complex) Windows API. Called the Microsoft Foundation Classes, or MFC, the competition was quickly neutralized and Microsoft was able to call the shots. Perhaps the same strategy would work again? Both Microsoft and Netscape tried it-they developed a set of class libraries to feed on the weakness of the Java 1.0.2 AWT and tried to take control of the marketplace by owning the toolkit standard. Unfortunately for Microsoft, the task was a substantial one, requiring evolution rather than invention, and by the time its Application Foundation Classes (AFC) were started, Java had already evolved, and Java 1.1 had fixed the weaknesses AFC hoped to feed on. This didn't stop it from using the name for marketing, but the focus quickly shifted.

Direct to the Metal
As Paul Maritz makes clear, the strategy has now moved on. Stealth tactics have not enabled Microsoft to monopolize Java, so open aggression is the order of the day. Microsoft had always feared the freedom Java gives its customers to deploy their software on any platform: the heart of that ability is standards. So Microsoft's future doesn't include them. It won't be supporting future stages of the evolution of Java; instead, Microsoft has decided to branch off alone and add new capabilities to Java using a set of proprietary APIs. What's worse, the proprietary APIs force the programmer to write Windows code inside the Java program, so that programs using the APIs will not even be usable as part of a wider project. In light of this history, it's hardly surprising that Microsoft should openly declare opposition to openness. But it's still shameful, and their customers will be the ones who suffer.

The Proprietary APIs
When writing software, most of the skill is not in the language work itself; it's in the manipulation of the interfaces to the underlying platform, called Application Programming Interfaces or APIs. The secret of the success of Java is twofold; it produces machine code (bytecodes) that can be run on any platform, and it has a set of APIs (class libraries) that generalize all platforms and allow programmers to master one set of interfaces, but reach all platforms. There are four key APIs that Microsoft doesn't want to support; they are:

  • Remote Method Invocation (RMI), which is used to allow Java programs on different computers to communicate with each other directly.
  • IIOP, a mechanism that allows Java programs to use industry-standard CORBA objects on a remote computer.
  • the Java Native Interface (JNI), which defines the interfaces to platform-specific programs -- the "trapdoor" API that allows programmers to safely call code native to a particular platform. JNI is used to interface to peripherals such as the cash-drawer on a cash register or sensors in a medical instrument. Using JNI, a developer can create a small stub program that connects to the peripheral and then simply recompile it on each platform to produce a native interface to the peripheral.
  • the Java Foundation Classes (JFC), a set of libraries that make use of standard features such as progress bars easy and uniform across all platforms.

Microsoft's replacement for each of these is non-standard and Windows-specific. In place of RMI and IIOP, Microsoft wants programmers to call DCOM, their little-used, Windows-only remote object mechanism. In place of JNI, Microsoft has created the Raw Native Interface (RNI), which again is Windows-specific and offers none of the security sophistication of JNI. In place of JFC, Microsoft is hurriedly inventing J/Direct. J/Direct is just a hole drilled in the bottom of Java through which the programmer can effectively call routines in the raw Windows API. Any program using J/Direct will be a nightmare to port to any other platform, just as programs written to MFC were.

Software Deployment
In the final analysis, does it really matter whether software will work on any platform? After all, 80% of computer users use Windows, don't they? Well, actually, yes, it matters.

Internet
To start with, there's the Internet. There are plenty of people who aren't using Windows and plenty more who aren't using a browser that will ever support Microsoft's proprietary extensions to Java. So content creators on the Internet, who have no idea what platform their target reader will be using but still don't want to use the lowest common denominator (HTML), have a choice of using either a proprietary power that a tiny percentage of readers will see, or of using the highest common denominator (standard Java), which is just as capable but works everywhere. Tough choice.

Intranet
But it's not the Internet where Java will bring huge benefits in 1997/8 -- the bandwidth available to the normal user is still too narrow. The big winners from Java in the coming year will be intranet users, companies with their own internal networks. These networks encounter the same problem as the Internet: accessibility. In a company, people might have varying window versions and software. The only certainty is that they will be running a modern Web browser. The problem of providing company-wide access to a stock inventory, staff shop, or an expense claim system is easily solved by creating an intranet Web site with a Java solution. Everyone can then use it tomorrow morning. As long as the solution doesn't use J/Direct..

 -- Simon Phipps



JavaTM is a trademark of Sun Microsystems, Inc.

Other companies, products, and service names may be trademarks or service marks of others.

Copyright    Trademark

IBM HomeOrderEmployment