Portable application software can allow users of non-Windows and non-Macintosh machines access to a lot of software otherwise unavailable. OS/2, an operating system that is generally considered quite good technically, suffers horribly from a lack of application software. OS/2 users would benefit tremendously from good Java applications.
Portable application software puts pressure on the OS vendors to provide better products and respond to customer feedback. Currently, once you choose an operating system, you're stuck -- switching would involve too much repurchasing of software (and the vendor knows this). Java applications make switching operating systems easier, forcing OS vendors to be more responsive to their customers because of the threat of defection.
Portable application software can give users more choices because software vendors who might have elected to support only one or a few operating systems now can support all operating systems with a Java implementation.
- Portable application software can make life easier for users who must use several different types of machines. They will have the chance to use the same software on the various machines.
MIS departments: Software maintenance gets simpler
MIS departments see one very big benefit to Java portability: the reduction of the number of different pieces of software they must maintain. Consider a company with Windows machines, Macintoshes, and Unix machines -- not all that unusual these days. Such a company often needs a variety of software packages that perform the same task. To meet word processing needs, it might use both Microsoft Word for the Macintosh and Word for Windows (quite possibly different -- and incompatible -- versions). In fact, chances are, the company will have several versions of Word for Windows (to accommodate Windows 3.x and Windows 95/NT machines). Finally, except via a Windows or MacOS emulator, Word won't run in any flavor on a Unix machine, which makes it likely those users will have to use a different word processor. Passing files between these various systems can be difficult at best.
A single word processor running on all these machines would make life much simpler for the MIS department.
What portability really means to Microsoft
Java is an example of something Alvin Toffler calls a "product system." Just like highways and cars, and unlike umbrellas, product systems derive their benefits from the interaction of many things rather than the individual things themselves. He writes:
Umbrellas and automobiles are different... . A person can use an umbrella without buying another product. An automobile, by contrast, is useless without fuel, oil, repair services, spare parts, not to mention streets and roads.
The mighty auto ... is a team player completely dependent on other products. So is a razor blade, a tape recorder, a refrigerator, and thousands of other products that work only when combined with others...
Each of these is part of a product system. It is precisely their systemic nature that is their main source of economic value. And just as "team players" must play by certain agreed-on rules, systemic products need standards to work. A three-pronged electrical plug doesn't help much if all the wall sockets have only two slots.
The distinction between stand-alone and systemic products throws revealing light on an issue that is widening today's information wars all around the world. The French call it la guerre des normes -- "the war over standards." Battles over standards are raging in industries as diverse as medical technology, industrial pressure vessels, and cameras.
Some of the most explosive -- and public -- disputes are directly related to the ways in which data, information, knowledge, images, and entertainment are created and distributed.
-- from PowerShift, Chapter 12: "The Widening War," by Alvin Toffler
A J-code program is useless without a JVM to run it. Additionally, a JVM is useless without a J-code program to run. Even a single JVM and a single J-code program are fairly useless in isolation. The combination of many J-code programs and JVMs is what creates value.
There already is a war in progress over the direction Java is to take. Three major companies, Sun, Netscape, and Microsoft have differing views about the future of Java. Sun and Netscape see Java as a tool for creating applications and applets that run everywhere. Microsoft sees Java as a tool for creating applications that run on Windows.
Java as a language does not threaten Microsoft. As long as the Java language works with and on Microsoft operating systems, it is no more threat to Microsoft than other programming languages.
Java as a virtual machine is not much of a threat. Windows NT has implementations for Intel x86 machines, DEC Alpha machines, MIPS, and PowerPC machines. (However, support for MIPS and PowerPC ends with Windows NT 4.0.) Microsoft need not care about the difference between Windows programs that run on Intel machines and Windows programs that run on non-Intel machines.
The Java OS/GUI libraries do threaten Microsoft. The ability to easily switch operating systems is a threat to a company with 80 to 90 percent of the desktop operating system market. Even more dangerous to Microsoft is the possibility that if enough portable Java applications are written, need for Windows evaporates. The much simpler JavaOS will run all the Java applications without a Microsoft operating system. Thus, Java directly threatens Microsoft's operating systems business.
Microsoft can employ two tactics. The first is to implement standard Java libraries poorly or not at all, and then provide a Windows-only alternate library that runs well on Windows operating systems and not at all on non-Microsoft operating systems. The second tactic is to add functionality to the standard Java libraries by providing libraries to fill voids. For example, the Java Abstract Windowing Toolkit (AWT) does not provide access to all the Windows GUI functionality. Microsoft can extend the AWT to provide access to these functions. A side effect is that Java programs using these library extensions won't be portable to non-Windows machines.
We already see indications of Microsoft's intention to pursue both approaches. According to PCWeek, Microsoft "will not support all the core JDK 1.1 APIs in Internet Explorer or Windows." In addition, the magazine noted Microsoft "plans to create Java libraries dependent on Win32 APIs."
For some applications, this extra non-portable functionality will be useful enough to give up the portability to non-Microsoft operating systems. But for many other applications, using these extensions will add only cosmetic appeal with little functional benefit while locking the application and its users into the Microsoft universe.
Java provides three different types of portability, and the way the three interact is what makes Java special. Without CPU and OS/GUI portability, Java is just another good programming language. The Java language and the Java virtual machine without OS/GUI portability creates programs that port between, for example, different CPUs running Windows NT but not between machines running Windows and machines running MacOS. We don't need Java for this; we can do it today with a recompile. To achieve Sun's goal of "Write once, run anywhere," programs cannot sacrifice any of the three forms of portability provided by Java. It will be both easy and alluring, in the near future, to write "portable" Java programs that in reality port only between machines running Windows, and Microsoft can be expected to encourage this. Whether programmers and the companies they work for resist this while still writing programs that meet their users' needs remains to be seen.
Learn more about this topic
- Harbison and Steele, 1991, CA Reference Manual. Englewood Cliffs, NJ:Prentice Hall.
This book provides many good examples of differing behavior by different implementations of the C programming language.
- Alvin Toffler, 1990, PowerShift. New York:Bantam Books.
PowerShift provides a good discussion of how power, wealth, and knowledge interact. Toffler doesn't provide a lot of predictions in this book, but mostly focuses on trends already underway.
- Some programming language implementations that either support the JVM or run under it:
This is a page of links to Ada implementations that emit J-code, a comparison of the Java language with the Ada95 language and other Ada links.
From the author:
This is a simple BASIC interpreter I wrote in Java. When you load this page a new window will pop up with the interpreter running in it (well loading first). It's a primitive BASIC, uses line numbers, implements most of BASIC-80.
This is the home page for a language that builds on Java. The site contains a whitepaper on the language, tutorial, programmer's manual and other neat things.
This site contains Misty Beach Forth. Misty Beach Forth is an implementation of the Forth language that runs in a Java environment. It does not (yet) produce independent class files.
This is the JavaSoft home page.
This is the home page for W-Prolog, an implementation of Prolog written in Java.
This is the home page for NetRexx, a dialect of the Rexx language.
This is the home page for Kawa Scheme. Quoting from the home page:
Kawa is an implementation of the Scheme programming language. It is implemented in Java, and compiles Scheme into Java byte-codes.
- In addition to this list, the folks at SIG are working on a version of Eiffel that supports the JVM:
- Lucent Technologies' Limbo is another programming language that produces object code for an imaginary CPU:
- JavaOS provides a simple way to run Java applications:
- For another approach to distributing CPU independent programs, see
- "Microsoft splitting Java", by Michael Moeller, Talila Baron, and Norvin Leach, PCWeek, November 25, 1996.
This article discusses Microsoft's plan to release a Java language compiler that emits native Windows applications instead of J-code.
- "DEVELOPER DILEMMAWhich is the real OS? -- Java on Road to Fragmentation", by Deborah Gage, Computer Reseller News, November 11, 1996.
This article discusses the battle between Microsoft and Netscape to extend the Java APIs to areas that Sun had, at the time of the article, ignored.
- "Microsoft's Strategy on JavaEmbrace, Extend, Disparage", by Jeremy Carl, WebWeek, December 2, 1996.
This article discusses many things in a short amount of time. Among those things is Microsoft's belief that Java's cross-platform capability is of limited value.
- "The Backstage Battle over Java", by Nate Zelnick and Jeremy Carl, WebWeek, December 16, 1996. This article discusses Java and COM.