Dr. Dobb's Journal September 1997
Michael is DDJ's editor-at-large. He can be contacted at mswaine@cruzio.com.At its World Wide Developer's Conference, Apple did three things that it more or less had to do: It cleared up some confusion about its operating-system strategy and what the opportunities are for third-party developers; it demonstrated a tightness of focus unlike anything seen from the company in years; and it made a mighty effort to hitch its wagon to Java's rising star.
Apple needed to build a bridge to the future. It needed a modern operating system -- one with full memory protection, preemptive multitasking, multithreading, and symmetric multiprocessor support. The leaky, barnacle-encrusted antique raft called the MacOS was fine for liberating slaves and dodging the tight collars of civilization, but it wasn't going to get Apple over the choppy waters ahead. The company had several bridgework options. It could:
For a while they strongly considered adopting Jean-Louis Gassée's Be operating system. But whatever the merits of BeOS, using it ultimately meant substituting someone else's unfinished OS for Apple's own unfinished OS. Possibly a smart move given the state of that internal unfinished OS, but crow meat is notoriously hard to swallow. So they passed on that bridge deal.
Leading us to the chosen option:
Keeping the MacOS alive is a key feature of this strategy, and Apple is serious about it. Copland was intended as a replacement for the MacOS, and support within Apple for MacOS development had dwindled to a handful of engineers. Now the MacOS division is staffed up, and significant upgrades are planned for years to come. And since the Blue Box is an integral part of Rhapsody, whether customers have the MacOS or Rhapsody, they will be able to run MacOS software. Apple figures it is protecting or increasing the customer base for MacOS software, because anyone choosing Rhapsody will still be able to run MacOS software (and will need to, until a base of Rhapsody apps get built up). And if Rhapsody brings new sheep to the fold, it will actually increase the Mac software customer base. So goes the thinking.
But it's not that simple, because the changes that Apple is undergoing are more complicated than this. At the same time that it is adopting this dual-OS strategy, it is also adopting a multiplatform strategy, and it's not at all clear -- at least not to me -- how these changes play together. It's a real cross-platform platform. Developers will be able to do development once -- for Rhapsody's Yellow Box environment -- and deploy the software everywhere -- on Rhapsody-equipped machines, MacOS-based machines, and Wintel boxes. Just as you can create fat binaries that run on 68K Macs and PowerPC Macs, you will be able to create obese binaries that will run on Mac and Windows.
The NeXT crew brings some crucial Windows experience and technology to Apple. They'll bring over a lot of datatypes from Windows, and they'll employ their experience in writing device drivers.
Demos at WWDC suggest that a lot of the cross-platform work has been done. Apps were shown that had been developed on one platform and that ran on the other. One question relates to the quality of the cross-platform apps. NeXT's customers have mostly been pretty knowledgeable, not the typical shrinkwrap software buyers. One product demonstrated at WWDC, Create from Stone Design (http://www.stone.com/), seemed to measure up to commercial software standards, and reportedly was developed in a remarkably short time. (It's really an OpenStep application and has been around since 1990.)
This dual-OS, cross-platform strategy will be realized in a number of products and development platforms, including MacOS, Rhapsody, Rhapsody for Intel, Yellow Box for Mac, and Yellow Box for Windows. It's all very complicated, but it's encouraging that Apple is actually doing it and not just talking about it.
What's the upside? If Apple delivers Rhapsody on time with all its promised functionality, and if it can deliver an acceptable user experience (a moving target, as Rhapsody's target audience grows from the initial small crowd to a much broader audience), and if third-party developers quickly pile on with quality applications, Apple really could have a demonstrably better platform for users and developers than anything its competition can deliver, grow its marketshare, and regain the image of a technology leader. To do that, all it has to do is deliver on the following promises: nearly 100 percent compatibility for old Mac programs, the best Java development and delivery platform on the planet, a true object-oriented development environment that lets you produce quality, shrinkwrap software several times faster than you can now, hot technology for developing and deploying web sites, and a cross-platform strategy that increases third-party developers' potential market without undermining Apple's own hardware business.
I said something about Apple clearing up confusion about its operating-system strategy and what the opportunities are for third-party developers, and Apple certainly did that at WWDC. It also created some new confusion with the complexities of platform options, but at least it gave developers a lot to think about.
I also said something about Apple demonstrating a tightness of focus unlike anything seen from the company in years, and you may object that a dual-OS, multiplatform strategy is not what you call focus, but I stand by that claim.
As Steve Jobs said in his "fireside chat" on the last day of the conference, focus is all about saying no. And Apple has been saying no a lot more lately.
In the past six months, Apple has spun off its Newton division, shut down several projects not central to the core business, and tightened the focus to a few lines of hardware, key OS technologies like QuickTime, and these two operating systems. One of the casualties of the naysaying was the document-centric computing initiative embodied in OpenDoc. The official Apple position is that OpenDoc is on maintenance, and indeed it is still around, even being folded into the OS 8 release this month. Apple makes a good case that OpenDoc is not dead, but it's worth remembering that Apple's Senior VP of Software Engineering spoke at WWDC of having "put a bullet in the head" of OpenDoc. His words. Well, his and Steve Jobs'; during WWDC, each of them took credit for killing off OpenDoc, using identical language.
This was one of the least popular of the recent acts of naysaying. Jobs and others from the NeXT gene pool spoke carelessly at WWDC of Java having most of the benefits that OpenDoc offered, anyway, and Gil Amelio repeated this nonsense. But while the word Java does seem to have the semantic plasticity of the word smurf, nothing in the technology currently encompassed by the J word offers the exact capabilities that OpenDoc offered. Okay, offers. OpenDoc was/is a useroriented component software model, and that's something different from all the other component software models out there, Java-centric or otherwise.
Jobs took some heat for his comments from people who had invested time in OpenDoc, and who believed that the technology was a good thing. One developer at the fireside chat nailed him thus: "It's sad and clear that, on several counts you've discussed, you don't know what you're talking about. I would like, for example, for you to express in clear terms how Java in any of its incarnations addresses the ideas embodied in OpenDoc." Jobs, to his credit, acknowledged that there are many occasions when he doesn't have the faintest idea what he's talking about. But he defended the decision in terms of focus.
Interesting alternative views began to appear in developer discussion lists after the conference.
Like: Maybe we don't need Apple to keep OpenDoc moving. Can't we do it ourselves? Most of the standards it was built around are still widely accepted. Like: Maybe it's okay that it's dead. So far as the underlying technology goes, it was an attempt to paste true object-based computing and late linking onto the MacOS, which looks less necessary with Rhapsody on the scene. And as to the real difference between OpenDoc and other component software models, its orientation toward letting the end user do the wiring of components, how good was it? There were a lot of issues that hadn't been addressed yet. Why not scrap it and start over in an environment (Rhapsody) that doesn't just talk the object-oriented talk?
Others think that the OpenDoc decision is a great loss to computer users.
I think they're right. OpenDoc was a genuinely new approach to software development and distribution, and to the relationship between customer and vendor. It was radical, and required the cooperation of people who are currently heavily invested in the current model. I wanted to see it succeed, and hope that its vision can someday, somehow, be resurrected.
But I also think that Jobs was right in advising Apple to drop it. That particular revolution isn't Apple's job. It's about focus.
I also said that at WWDC Apple was making a mighty effort to hitch its wagon to Java's rising star. I don't know how to make that sentence play nicely with my bridge metaphor, but it's true.
Scott Forestall, manager of the Java applications technology group at Apple, told developers "We are fully embracing Java. So anything [Java based is] going to run on the Apple platform." And they want to provide a really optimized virtual machine. "We're working really hard on that. We have a lot of resources dedicated to it. And we want your Java to run as fast as possible on our platform. We believe we are going to provide the best possible platform for both developing and deploying Java applications." On top of that, Apple is going to open up its entire Yellow Box platform to Java, so you'll be able to program completely in Java using Apple's entire platform.
Apple will support Java's AWT in Rhapsody via a peer model: If there's a window in AWT, then there will be an associated window peer in the Yellow frameworks that make up the Yellow Box. "If there's a button here, there's a button there. So we're going to provide the complete AWT implementation. And, in fact, the complete JDK implementation on our platform. One hundred-percent Java compliant. Anything you write to Java works. What does it give us? It gives us all the other frameworks. It gives us Netscape's IFC. It gets us Microsoft's AFC. It gets us Lighthouse's JFC. It gets us the Colonel's (kernel's) KFC."
Forestall also wanted everyone to understand that any JavaBean written by anyone, anywhere, would run on Rhapsody. Clearly, Apple is making the big promises, and clearly, too, a big effort.
Speaking of beans, I heard from a lot of kindred spirits (or fellow grumblers) when I complained recently about the sorry state of editing of some of the new Java books. I guess a lot of people have been burned by bad editing. And while you may be able to sue someone if you're burned by too-hot Java (that's not exactly a professional legal opinion; it's actually a subplot on an old Seinfeld episode), books are pretty much sold as is.
One reader agreed about the poor editing of Java books generally, and then pointed out some editing errors in this inestimable publication. I immediately jumped up from my desk, shouting, à la Hamilton Burger from the old Perry Mason series, "Objection! Irrelevant, immaterial, and incontinent!" but then I relented and posted his full flame to my Hall of Flame site (http://gate.cruzio.com/~mswaine/HallOfFlame/hallofflame.html).
Later, subdued and chagrined, I wrote down the following positive report about some Java books, or more specifically, JavaBeans books. I recently looked at three such books: JavaBeans Developer's Reference, by Dan Brookshier (New Riders Publishing, 1997); Web Developer's Guide to JavaBeans, by Jalal Feghhi (Coriolis Group Books, 1997); Presenting JavaBeans, by Michael Morrison (Sams Net, 1997).
First, points for chutzpah: Author Feghhi was so confident of the merits of his book that he responded to my complaint about the poor editing of Java books by sending me his book.
Feghhi is right; his is a good book, but that's not to say that the editing is perfect. It took me a few seconds to figure out what the arrow labeled "HOP" in the diagram on page 69 referred to. Context relieved my confusion: It was supposed to be IIOP, the Internet Inter-ORB Protocol. Oh, well. All three books present some sort of overview of software component architectures. Feghhi starts right off with this, spending several chapters giving a clear explanation of components, frameworks, and the object bus, then contrasting fairly the OpenDoc/CORBA, ActiveX/DCOM, and JavaBeans approaches. There's also a nice explanation of how different a bean looks to its implementer, to an application developer, and to an end user. Morrison's book, mentioned here last month, gives you only enough background in software component architectures to set up his discussion of JavaBeans. Ditto for Brookshier, who is also fairly dismissive of the ActiveX/DCOM approach because of security problems.
All three books walk you through the relevant APIs, but Brookshier's book, being a Developer's Reference, spends about 300 of its 700 pages documenting the Core JavaBeans API, the AWT API, the New Event Model API, the Serialization API, the Java Core Reflection API, and the Internationalization API. Morrison covers the JavaBeans API only, and that primarily in the context of explaining how to develop Beans. Feghhi takes a similar tutorial approach, although he gets fairly explicit about the Core Reflection API.
All three books present both detailed explanations of the concepts in JavaBeans and explicit tutorials on how to build and package Beans. Brookshier, whose book, including the API documentation, is about twice as thick as the others, is also the most conceptual of the three in his approach; Morrison is the most hands-on.
All three books come with CDs. Morrison's has Sun's JDK for Windows 95/NT, Macintosh, and Solaris; BDK for Windows 95/NT and Solaris; demos and shareware; plus sample code for four Beans. Feghhi's has sample code, useful Beans, and a Visual Basic application built with Bean technology. Brookshier's has Sun's JDK, BDK, and source code from the book.
Morrison and Feghhi have both written readable books that should get you up to speed quickly on the technology. Brookshier is a bit drier, but, with all the reference material in the back of the book, there's more chance you'll keep this on the shelf after you've read it.
At least until the next version of JavaBeans comes out.
DDJ