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