The "embrace and extend" directive from Redmond has received heaps of criticism -- but a positive spin on the plan is offered here
According to Sun Tzu, the Chinese strategy master and author of The Art of War, “The skillful leader subdues the enemy’s troops without any fighting, he captures their cities without laying siege to them, he overthrows their kingdom without any lengthy operations in the field.” What he calls the “strategy of the sheathed sword,” Microsoft calls “embrace and extend,” a strategy that uses Java to maintain Microsoft’s dominance in the software industry. Despite the uproar over Microsoft’s strategy in the industry, it’s bound to prove appealing to many developers.
Microsoft arrived at this Java-focused point rapidly. After a late start, Microsoft has made the Internet its own and is maneuvering at lightning speed to control this new world as adroitly as it did the old. Microsoft has made the unthinkable commonplace: It has given some products away for free, has licensed others to independent standards organizations, and has adopted standards and technologies developed by others. No objective observer viewing Microsoft’s Internet announcements over the last twelve months can call them anything less than brilliant.
Embrace and extend
The problem with Microsoft’s strategy? It wasn’t established by Mother Theresa, and altruism does not reign in Redmond, WA. Like all companies (including Netscape and JavaSoft), Microsoft is struggling for competitive advantage, and its plans for embracing and extending the technology developed by others must be viewed in this light.
Many reports on Microsoft make its initiatives sound like a euphemism for the medieval torture on the rack — whereby the victim’s hands and feet are securely embraced, the body continuously extended until death or religious conversion ensues. Actually, what Microsoft is doing is not very different from what Netscape is doing. Some view the Java strategies of Microsoft and Netscape as a life and death struggle, but compromise is possible. In fact, it is under way.
Microsoft is extending Java on several fronts, each exhibiting careful thought and posing its own level of threat and opportunity. Perhaps the most important is the adaptation of the Java virtual machine (JVM) into the Microsoft virtual machine (MSVM). The MSVM is an ActiveX/COM interpreter that executes Java code by wrapping it and exposing all interfaces through standard ActiveX APIs. This means (much to the chagrin of Microsoft’s detractors, perhaps) that ActiveX controls and Java applets can share resources and can follow the same rules — such as the standard OLE and COM interfaces. With much of the existing software in the world (particularly within corporations) conforming to the OLE and COM specifications, the scope of Java could be broadened dramatically.
MSVM is positioned as a clean superset of the standard VM; that is, it is extended. Standard Java code will execute in the MSVM, yet when necessary or desirable, developers have access to additional, albeit non-portable, features. (Microsoft has announced a plug-in that lets users access MSVM through Netscape Navigator — proving, among other things, that the company has a sense of humor.) These enhancements are important to many corporations trying to leverage their existing investments in both software and the skills of their development staffs while beginning to move to cross-platform standards.
MSVM boasts many good aspects. For one, it permits code to access local resources, including memory and disk. This approach is legal under the JDK 1.1 specification, so long as it is done by trusted code local to the system or packaged as a cabinet file (.CAB) that has a digital signature.
The Microsoft extensions are platform-anchored — that is, they provide access to proprietary Microsoft features available on the Windows platform. And ActiveX and COM now are under the control of the Open Group and are putatively cross-platform. But what does it mean to implement these technologies on a Macintosh, Sun workstation, or AS/400? What does it mean for software emulation of the underlying execution architecture or through the use of a compatible coprocessor?
The jury is still out on these issues, which angers much of the Java community. Yet the fury is very selective. The difference in how Microsoft supports ActiveX and COM is not too far from Netscape’s use of its Internet Foundation Classes and IIOP: both are extensions, both are proprietary, and both are “standard.”
Microsoft’s implementation of Java and the MSVM includes a tight link to COM, the company’s standard object model. This approach is, and should be, legal because COM is a competing vision for distributed computing — not strictly a language issue. One should be able to write valid Java code to either a COM or IIOP/CORBA interface.
However, supporting COM from within the virtual machine can be a slippery slope because it imposes an additional component object model along with JavaBeans. Microsoft has announced tentative plans to release a JavaBeans interface in mid- to late 1997. JavaSoft has already announced a unidirectional ActiveX bridge that will enable JavaBeans to act like ActiveX controls. A bidirectional bridge is in the works at Microsoft.
Microsoft has been slow to adopt the JDBC database interface standard, and most observers will see this as an opportunity for Microsoft to push its own standard. JDBC is a layered standard, not a language or run-time construct. Oracle is doing the same thing — providing a layered standard — with J/SQL. Database connectivity is an area for innovation because ultimately it is a database issue not a language issue.
“100% Pure Java” considered
JavaSoft introduced its “100% Pure Java” initiative at Internet World in December in an attempt to address these issues and tie a standard set of functionalities to the Java brand name. This initiative is both important and somewhat silly. It is important because it defines a basic core of functionality that must be common in any software that is Java. It is silly because that core is a moving target, and also because many developers will choose to code outside the core for performance or development-time reasons.
The simple reality is that, as always, developers will have to make hard choices about functionality and portability. That choice will always involve tradeoffs. Writing truly portable applications — those that can be written once and executed anywhere — will always involve writing least-common-denominator code. Anyone who has used the Java AWT libraries will understand the implication of that statement. For those who choose portability, the Java core must be well-defined and unfailingly defended. The language, VM, and JavaBeans APIs, among others, must be consistent across platforms in order to ensure portability.
The question is, of course, obvious: What percentage of developers really want to write least-common-denominator code if it is easier to write more fully functional software that performs better on a smaller number of platforms? Again, the jury is still out.
It is important to remember that Java is a programming language. Portability is one of its most important features, but not its only one. Java is a fine language for writing platform-dependent code that is scalable, easy to develop, and inexpensive to maintain. For many developers, particularly those who have standardized on Windows, these features may be all that matter.
Conclusion
The Microsoft approach to Java is many things, but it certainly isn’t off base. One thing’s for sure, it has sparked debate. The Java community is abuzz with questions like: What does it mean to maintain a portable standard and still enable innovation? Whatever else JavaSoft does in light of inevitable innovation, it must defend the core Java language and component object model against those who wish to extend or adapt them. Nearly everything else is fair game. Many areas remain open for innovation, but these features define Java. There can only be one of each.
