Programming Windows: Microsoft and Java (Premium)

Fearing that Microsoft would try to undermine Java by creating incompatible versions that only ran on Windows, Sun Microsystems insisted that the software giant agree to create the “reference implementations” of the technology for Windows 95 and NT.

Sun was right to be worried: As internal documentation later made public at Microsoft’s antitrust trial revealed, the firm intended all along to usurp Java with Windows-only features that would bifurcate the market and make moot the technology’s cross-platform advantages. Doing so would have the added benefit of harming Netscape because that company’s web browser, called Navigator, relied on Java as well. Only Microsoft’s web browser, Internet Explorer, would be able to run applets created with Microsoft’s specially tailored version of Java.

Microsoft would develop and release a family of Java products and services, codenamed Jakarta, by the end of 1996. These included its Java virtual machine (JVM) for Internet Explorer 3.0 (across Windows 3.1, 95, and NT, and Mac) with its just-in-time (JIT) compiler, Visual J++, its Java developer environment, and the ability for developers to integrate Java with COM objects through Microsoft’s Internet-based ActiveX technologies.

(Fun aside: The name Visual J++ was a play on the name of Microsoft’s C++ developer environment, Visual C++.)

That latter capability was the source of Sun’s fears and the manner by which Microsoft would usurp Java under the guise of extending the technology to work better with Windows.

“Integrating the Java language with COM is something our customers and partners think is extremely important,” Microsoft senior vice president Brad Silverberg was credited with saying in a March 1996 press release. “It brings a whole new dimension to Java: A clear path for integration with existing applications, systems, and technologies. It means that you don’t have to start over to take advantage of Java.”

In case it’s not obvious, the “you” in that last sentence was Microsoft’s customer base, everyone from the developers that targeted its platforms to the corporations and end-users that relied on the resulting software. So, yes, Microsoft’s embrace of Java was self-serving, and an attempt to blunt a major competitor. But the software giant also allowed advanced Java well past the functionality provided by its creators and truly integrated it, and quickly, into the Microsoft software stack.

Indeed, the level of support Microsoft provided for Sun’s language was quite impressive. The first version of Visual J++ was made available to developers in beta form that summer, and it shipped in release form in October. It also entered a market that was crowded with Java developer tools, from Sun’s Java Workshop to third party options like Borland Latte, Symantec Café, and others, but quickly emerged as a front-runner.

Several things set Visual J++ apart from the competition. For one, it was built on Microsoft’s impressive and professional Developer Studio environment, the predecessor to Visual Studio, which Microsoft developers still use today, and the same environment it used for Visual C++. As Microsoft noted at the time, Visual J++ provided “built-in support for managing teams of developers … integrated project management, high-speed compilation, editing, browsing, wizards and browsers, and … Microsoft’s graphical debugger.”

But it is the Windows-only technologies that really stood out. Yes, Visual J++ could be used to create cross-platform Java applets that would run in any web browser on any OS. But it was specially designed to enable developers to link Java applet code with COM components via ActiveX. And that code would only work with Internet Explorer.

An internal memo explained that Microsoft’s “strategic objective” was to “kill cross-platform Java by growing the polluted Java market.” Microsoft, of course, was the polluter.

Even sneakier, Visual J++ automatically generated Java source code that used keywords and compiler directives that only worked with Microsoft’s JVM. So even those developers who intended to use Visual J++ to create cross-platform code were often unwittingly writing applets that would not execute properly in other JVMs.

“[W]e should just quietly grow J++ share and assume that people will take more advantage of our classes without ever realizing they are building Win32-only Java apps,” Microsoft’s Thomas Reardon told colleagues in an internal memo.

The strategy worked. As you might imagine, Microsoft closely monitored the success of its efforts to undermine Java, and it was pleased to discover that over 90 percent of all Java development was happening on Windows within a year, and that over half of all Java developers were using Microsoft’s proprietary extension to Java to access natively Windows functionality.

Clearly, it needed to do more.

So, in 1998, Microsoft unleashed the second major version of Visual J++, called Visual J++ 6.0 to match up with the then-current version of Microsoft’s developer suite, which had been renamed to Visual Studio. Among its many improvements was the ability to create full-fledged 32-bit Windows applications using the Java programming language and a new framework it called the Windows Foundation Classes (WFC). It also allowed developers to create ActiveX controls that could then be utilized in other languages and environments like Visual Basic. With Visual J++ 6.0, Microsoft’s usurpation of Java was complete.

“This object-oriented framework encapsulates, simplifies and unifies the Win32 API and Dynamic HTML programming models, enabling developers to create high-performance, feature-rich, native Windows-based applications in the Java language using prebuilt sets of classes and components,” Microsoft announced when the technology was finalized in October 1998. “In addition, WFC lets developers build their own components that can easily interoperate with components written in other programming languages.”

If that sounds familiar, you know your history: WFC was the prototype for the work that Microsoft would later do with .NET, albeit unwittingly. At the time, Microsoft wasn’t plotting .NET, it was furthering the COM platform instead. And had things not gone horribly, horribly, wrong, it is quite likely that the next decade of Microsoft software development would have been focused on J++ and WFC instead of C# and .NET.

Naturally, things did go horribly wrong.

As it turns out, Visual J++ was released in the wake of an incredible antitrust suit, which was launched the U.S. Department of Justice (DOJ) and 20 U.S. states against Microsoft. It was also launched in the wake of an October 1997 lawsuit brought against Microsoft by Sun Microsystems, the creator of Java. “Sun is seeking to have Visual J++—which ships with Microsoft’s proprietary extensions to Java—removed from the market,” I wrote at the time.

The Sun suit, of course, would figure prominently in the more sweeping antitrust suit, which we’ll be examining later. But it was launched for all the right reasons: Microsoft was, as Sun charged, trying to destroy Java by destroying its cross-platform capabilities. Sun’s goals were reasonable, too: All it wanted Microsoft to do was live up to the conditions of the licensing agreement it signed. And it had created a Java compatibility test to prove Microsoft’s noncompliance.

Microsoft called the charges “outrageous.” Of course it did.

Over the next few years, Java was shown to be ineffective at creating browser-based web applications, in part because JavaScript was so effective. Netscape eventually dropped Java from its web browser. And Sun, with partners, like IBM, moved Java to the web server, where it continues to enjoy some success. As for its part, Microsoft could see the writing on the wall. And with its Java future being torn away from it, the software giant began pursuing another path. One that would look and feel like Java but would be created internally.

In January 2001, Microsoft finally settled the case with Sun. It agreed to pay Sun $20 million and would stop using “Java compatible” trademarks on its products. For its part, Sun terminated Microsoft’s Java license but allowed Microsoft to continue shipping Visual J++ and to ship its older and now out-of-date Java software to allow a graceful transition for developers.

“It’s pretty simple: This is a victory for our licensees and consumers,” Sun CEO Scott McNealy was credited as saying in a prepared statement. “The community wants one Java technology: one brand, one process, and one great platform. We’ve accomplished that, and this agreement further protects the authenticity and value of Sun’s Java technology.”

“This settlement is great news for the industry and Microsoft, as it means we can focus all our resources to help enable the next generation of software with Web services,” Microsoft vice president Sanjay Parthasarathy said in a similar statement issued from the other side.

He was right about one thing: Microsoft would focus all its resources on a new generation of software and web services. But that new generation of offerings wouldn’t be based on Visual J++, which Microsoft quickly killed, nor would be it technically based on Java at all, though Microsoft did briefly support via something called J# (“Jay sharp”). Instead, it would be based instead on a new Java-like platform called .NET, and on a new Java-like language called C#.

Microsoft was not done embracing and extending Java.