Dr. Dobb's Sourcebook January/February 1997
My September/October 1996 column contrasted Java with Microsoft's COM model, at least in respect to compound documents, and it engendered a flurry of e-mail messages with two recurrent themes: using an ActiveX control (compared to a Java applet) as a way of inserting components into web pages, and the suitability of Java as a general-purpose programming language in light of perceived performance problems.
Just to get my prejudices out of the way up front, I think that ActiveX on the Internet (or an intranet) not only perpetuates, but makes worse, the very problems that Java solves quite nicely. Moreover, Microsoft's Internet Explorer with ActiveX enabled is essentially a virus-downloading engine, the use of which should be banned outright at any company with an internal network hooked up to the Internet.
I look at Java as a language for the business world, where robustness and maintenance are paramount. Given the current state of the technology, there are better tools than Java to write games with, but so what? Consumer-market programs and their problems are not really relevant here. The code that makes a program truly robust (like bomb-proof memory management) slows down any program. The issue is not that Java is inherently slow -- it isn't. The features of the language that make it slow (such as garbage collection) also make it robust. These same features will have to be present in a C or C++ program if you intend it to be equally robust, but you will have to implement these features by hand. A robust C or C++ program will run at the same speed as a Java program, but will be twice the size at the source-code level. A flaky C or C++ program will be faster, of course. It's okay for a game to crash your computer -- you just hit the reset switch. It's not okay for a database server to crash a banking network, for a flaky program to bring down the entire telephone system or a fly-by-wire airplane like a Boeing 777, or for the Space Shuttle to crash on takeoff. (Not that any of this code was written in Java, but I think that it could well have been, had the language been sufficiently mature.)
The real problem is that network maintenance is incredibly expensive. Research firms such as The Gartner Group (http://www.gartner.com/) and Forrester Research (http://www.forrester.com/) have determined that maintaining a single PC on a large corporate network costs between $13,000 and $15,000 a year. (That's per machine.) In a large corporation, which could have 10,000 computers on its network, this comes to about $150 million a year -- far from pocket change.
There are three main culprits that foster the problem of network maintenance.
The Cowboys. The first culprit is the "cowboy" who installs (onto his or her "personal" machine) some freeware garbage that either brings down the network or infects it with a virus. An ActiveX control is nothing but a standard Windows DLL that is executed by the browser as a side effect of the download. In other words, an ActiveX control is a virus -- a benevolent one we hope, but a virus nonetheless. If you'd like to see an ActiveX application such as this in action, check out Fred McLain's "Exploder" control (http://www.halcyon.com/mclain/ActiveX/). Clicking on the "Boom" link reboots your computer (after giving you ten seconds grace to push an abort button). Writing an ActiveX control that reformats a hard disk would only require a couple of hours of work. It's only a matter of time before somebody does it. Be careful.
Microsoft has published a lengthy response to the Exploder control (http://www.microsoft.com/intdev/security/seccon.htm/). Microsoft's argument boils down to the notion of "signing" the control -- attaching an encrypted data block that identifies the author and source of the control. In theory, if you know who caused the problem, you know who to sue to get damages. Signatures just don't solve the problem, though. First, it's too easy to sign a control that seems to be safe, but isn't. (One that injects into the system a virus that's activated several months after the control is downloaded, for example.) By the time you detect the damage, the signature is long gone. A disgruntled employee of a large software company (even Microsoft) could inject malevolent code into an otherwise legitimate, signed control. Of course, a really malevolent control -- one that reformats your hard disk, for example -- can do a lot of damage before you can stop it, and just knowing where the control came from won't be much consolation. In any event, the control could, in theory, destroy the signature before the damage became visible. This is particularly the case with Windows 95, which doesn't have a secure file system.
Finally, signatures can be forged (it's difficult, but not impossible -- an FBI cross check isn't run on everyone who applies for a signature), and the entire system depends on you having the resources to take the culprit to court and prove to a jury that the person you're suing actually wrote the control. Juries, remember, are often unconvinced that a DNA "fingerprint" is reliable. The fact is that downloading an unknown program and executing it is inherently unsafe.
Since Java applets execute under either a real interpreter or interpretive environment, the virtual machine can prevent the running applet from damaging the host system. A Java applet running under Netscape's Navigator, for example, cannot do disk I/O -- it simply can't escape from Navigator to do real damage.
The Demons of Complexity. The second issue is complexity. Writing even a simple ActiveX control is a complex endeavor because the underlying technology (OLE) is poorly designed and needlessly complicated. MFC helps, but programs written in C++ are also inherently complex and very hard to maintain, even when the program is well designed. It's almost impossible to hire competent C++ programmers who understand the importance of good design -- who actually design their programs before coding. In any event, MFC is a mess from a design point of view, and it's almost impossible to do anything but a quick hack with it. Visual Basic has all the same problems in spades. In an environment where software quality and maintenance are important, any technology as needlessly complex, and with as steep a learning curve as OLE is undesirable.
I remember a Microsoft Developer's Conference not that long ago where Rich Rashid gave a keynote address on the theme of complexity, which he rightly identified as the biggest problem in the software world, both at the UI and programming level. This talk came on the heels of two days of seminars on OLE programming that left the participants more confused than when they had started. We clearly have a left-hand-not-talking-to-the-right-hand problem here. I'm convinced that one of the reasons that the Macintosh never got more than about 20 percent market share was that the machine was too hard to program compared to competing operating systems. A platform cannot succeed without software, and the only software that you could get for the Mac was software that required the unique capabilities of the machine -- like typesetting and graphics packages.
Most business applications involve simple data-entry screens and reports. These can be implemented quite easily in a mix of HTML and Java.
The Tower of Babel. The third problem with ActiveX is the most important one from a corporate information systems point of view. Every time a new version of a commonly used program (Microsoft Office, for example) comes out, someone has to go around and install it on every machine on the Internet. Remote installations are theoretically possible, but hardly ever work reliably. The situation is made much worse when the Internet is heterogeneous -- with a mix of PCs, Macs, UNIX boxes, and so on, all running different versions of the same program that have to talk to each other. Things get really untenable when you need to run potentially incompatible programs (word processors or graphics programs, for example) on different platforms, but still need to share data between users across platforms.
ActiveX objects are compiled so that any given control runs on only one hardware platform. Moreover, ActiveX controls run only on Microsoft operating systems (or operating systems that incorporate Microsoft technology). A compiled, OS-dependent technology just doesn't solve the problems previously discussed.
In the Java model, everybody (on any hardware platform running any operating system where a Java Virtual Machine exists -- and that's just about everybody) is running literally the same code. The Java bytecode is downloaded from a central server to the client platform when the program is used the first time -- just like loading a web page. The code is then compiled locally, by a Just-In-Time compiler, or interpreted by a virtual machine on the client platform. You get a download-time hit the first time you run the program, but thereafter you're running the cached code, which is updated automatically by the browser if the version on the server changes. Moreover, if the program is structured correctly, you can download only those parts of the program that you'll actually use. On a high-speed intranet, you don't even need a disk on the client machine, since the download time is reasonable and all files are stored on the server, not the client.
Network maintenance for 10,000 machines becomes a simple matter of walking over to the server and plugging in a new disk. The clients are updated automatically the next time they run the program. Everybody's running the same code, regardless of the platform, so everything's compatible -- even disk files. Backups of the whole network are accomplished by backing up the server -- you don't need to worry about important data being lost because you forgot to back up your own machine or because the machine was turned off when the network-level backup occurred.
More importantly (and the reason Microsoft is running scared at this point), the client machine can be a lean-and-mean network computer running any operating system that can host a Java Virtual Machine. Sun is pushing Java OS, a very small OS easily loaded into ROM. Microsoft is pushing an even more bloated version of Windows NT that requires a pretty significant hardware investment just to load. On the server side, NT does okay on a small network, but is slow on large networks. (See, for example, PC Magazine's September 10, 1996, issue on web sites, in which NT-based and UNIX-based web servers are compared.) Sun (and IBM-mainframe) servers are faster than NT, and more reliable. NT 4.0 crashes almost daily on my machine, usually with an OLE-related problem -- and remember, ActiveX is OLE.
The best example, right now, of doing things right with Java is Corel's Office Suite for Java (which includes WordPerfect, Quattro Pro, and Chart, all rewritten in Java). The architecture is essentially the one I described earlier -- the program is designed to be resident on a server and downloaded to the clients when needed, with all files stored directly on the server, not on client machines. As of this writing, the program is still in progress, but a prerelease version can be downloaded from Corel's Web site (http://www.corel.com/). I should warn you that the program is intended for an intranet environment where high-speed downloads are the norm -- it takes a while to get the thing loaded over a 28.8 modem; ISDN is best. Check it out.
DDJ