Dr. Dobb's Journal July 1997
Michael, DDJ's editor-at-large, can be contacted at mswaine@cruzio.com.It is an unquestioned article of computer faith that James Gosling originally named the Java language "Oak" in honor of a tree outside his office window. According to this official Sun story, the name Java only emerged after a long trademark search.
I wonder.
I mean, think about it: We're talking about James Gosling, one of the most caffeinated programmers on the planet. Let me quote from the definition of "tense" in The Hacker's Dictionary (Guy L. Steele et al., Harper & Row, 1983):
This routine is so tense it will bring tears to your eyes. Much thanks to Craig Everhart and James Gosling for inspiring this hack attack.
And from the definition of "hack attack," so there can be no doubt about the state of wiredness being induced here:
I've been up for thirty hours; I had a hack attack and finished off that new feature I thought would take two weeks to program.
You get the picture, right? Since his MIT days, Gosling has been staying up late, staring bleary-eyed at a computer monitor, writing tense code that inspires hack attacks. And we all know what that means. Coffee. Possibly cappuccino.
Second point: Consider the picture we now have of Gosling, the bleary-eyed, caffeine-wired hacker, cranking out code so tense it brings tears to your eyes. I ask you, is this a person who stares out his office window? Is this a person who knows that he has an office window? Or is this a guy who invents a language and names it after his favorite drug? I think all this Oak business is just an urban legend.
My recent rehashing of Ward Mullins' ten criticisms of Java inspired some reader mail.
Bill Marsh thinks that only numbers one through four of Mullins' list of criticisms are valid complaints about the language, the other six being complaints about the atmosphere surrounding it. "I was surprised," Bill says, "that there was no mention of the ease of network programming with Java. This makes the language worthwhile by itself."
Indeed. Java benefits from having come into existence after the importance of being totally wired (Netsavvy, that is) had been made manifest. It was defined from the start (or from 1.0 anyway) to provide a lot of Net capabilities, with classes for creating and manipulating data packets, sockets, and URLs. Although Sun's claims about Java being easy to program in are exaggerated, it really is surprisingly easy to put together Internet applications and applets with Java. Right on, Bill.
Edward Diener thinks that all this fussing over Java's faults and virtues sounds a lot like certain articles that used to run in Computer Language magazine. Ed was apparently not a fan of CL. "Each issue seemed to feature some ludicrous debate about the best computer language in which to write a program. After a few issues of this, I ended my subscription. I have also done my best to avoid all debates about which language is better than which language. After all, could you imagine arguing with an Italian that Russian is better than his language? Or vice versa? Absurd!"
Actually, I can easily imagine an Italian and a Russian arguing over the relative virtues of their languages, although not as easily as I can imagine a Frenchman and a German doing so. Linguistic ethnocentrism is, if anything, more virulent for natural than for artificial languages. There's an interesting online publication out of Munich (http://www.heise.de/tp/tpfhome.htm) where you can read an article about how English is doomed to extinction because of the Web. The article, I need hardly mention, is written in English. But I digress.
Say on, Ed Diener, say on.
"My biggest gripe regarding Java," Ed continues, "is that every mention of it comes with a corresponding putdown of C++. Why? Unless I am missing something deep, Java is about 85% C++ give or take 10%. If you like Java, enjoy yourself. I like C++. Maybe I'll learn Italian some day. Maybe you'll learn Russian. Who knows?"
Good call, that, about everybody gratuitously bashing C++ as they rush to deify Java. I may not be the best person to respond, since I never became a C++ fan, no doubt because I never got very good at programming in it. And Java is certainly highly similar to C++ in syntax, making my enthusiastic embracing of Java look a little silly. But I think the point Ed is missing is that the Java hoopla is not about Java the language, but about Java the phenomenon.
Java the phenomenon encompasses JavaOS the operating system, JavaBeans the software component architecture, Java microprocessors, and a plethora of APIs, as well as Java the language. Java the phenomenon is spreading like mold on the surface of a misplaced cup of coffee. Books on Java are popping up as fast as web books last year or Internet books the year before. Companies doing embedded applications, smartcards, and thin clients are committing their fortunes to Java-based technologies that are today more promise than delivery. Apple has latched onto Java as though it will be the salvation of the company. It's hard to understand why, because there's not much here that we haven't seen before. "Write once, run everywhere" sounds great, but it rests on an object model derived from C++ and a bytecode approach last seen in the UCSD p-system back in the '80s.
Sun is pushing Java as the answer to security on the Net, and there are several security measures built into Java and the applet model, but nothing that couldn't be implemented without Java.
JavaBeans provides an interesting model for creating component software, an exciting possibility, but so, in different ways, do ActiveX and OpenDoc.
The explanation for Java the phenomenon seems to have something to do with the right pieces being put together in the right way at the right time and promoted in the right way. "Write once, run anywhere" not only sounds good, it sounds like an answer to the Wintel monopoly. And Sun is brilliantly managing to associate the words "Java" and "security" in the minds of people who don't know what Java is or what the real Internet-security issues are.
Those people matter, the people who know frighteningly little about computers but control departmental budgets. They tend to latch onto a magic phrase that they think will keep them out of trouble. In the 1980s, they asked "Is it IBM compatible?" In the 1990s, they asked, "Does it run Windows?" And I can almost hear them starting to ask, without having a clue what it means, "Was it written in Java?"
I suspect that Ed will learn Java, but who knows? I know this: There is zero probability that I'm going to learn Russian.
William Beebe connects my Java jabs with the musical parodies I quoted from Don Slepian and comes up with a little ditty of his own:
When my project's hit a brick wall
K&R, they come to me
Speaking words of wisdom
Code in C
Code in C, Code in C
Code in C, yeah, Code in C
Java's not the answer
Code in C
"Since programming and music are supposedly intertwined within the psyche of the programmer," William says, attempting to palm off one of the ripest chestnuts of computer lore, "maybe you should have a musical language parody contest."
Not a bad idea, William. See the last page of this issue.
In trying to stay on top of the Java phenomenon, I read mailing lists, online pubs, magazines, and books, as well as my e-mail. The books almost invariably disappoint. The current crop, in fact every wave of them so far, seem more than usually rushed. Some semirandom examples:
Laura Lemay has become a technical-book publishing empire unto herself. Her name may not be as big a draw as the ubiquitous Dummy, but it's creeping up there. One such entry is Lemay's Teach Yourself Java for Macintosh in 21 Days (Laura Lemay and Charles L. Perkins, with Timothy Webster, Hayden Books, 1996). Like all her books, it is thoughtfully organized and well written (although, in this case, not written entirely or even mainly by Lemay), but it is poorly edited.
There are syntactic errors in the code, errors in tables, and errors in the text, including mistakes that seriously affect the usefulness of the book. And there's no excuse for publishing code with syntactic errors. Zero syntax errors is easily achievable, so anything less is unacceptable.
The Lemay book is not alone. In fact, despite its errors, I think it's one of the best Java books out there.
Freddy Hill writes, "An acquaintance of mine, Lewis, had purchased Norton's book on Java, and the book was filled with typographical errors in the code. Since Lewis was a novice, he could not find the errors; thus, he halted his attempts to learn Java."
I haven't read the Norton book, but Freddy's tale of woe doesn't surprise me. Core Java, Second Edition, by Gary Cornell and Cay S. Horstmann, SunSoft Press/Prentice Hall, 1997) is another highly regarded Java book, and deservedly so. The authors know their stuff and share a lot of practical advice that could only come from being down in the trenches. They also speak honestly and thoughtfully about what they like and don't like about Java.
But the book is, again, not well edited. A good editor could have helped these guys with the organization of their material, and alerted them when they were repeating themselves unnecessarily.
A minor gripe: Core Java should really be called Core Java for Windows 95 Programmers. The examples, tips, and insights are nearly all Win95 specific. There are some allusions to Solaris and a fleeting acknowledgment that the authors have heard of something called a Macintosh. But this is really a Win95 book, a limitation nowhere indicated on the cover. There is nothing unusual in this, unfortunately. Computer-book publishers are getting more casual than ever about acknowledging such limitations. But in the platform-transcending atmosphere of the late 1990s, maybe we shouldn't let them get away with it.
Book authors and publishers have an insurmountable problem in a fast-moving area like Java programming. There's really no way they can keep up, and even the standard references go quickly obsolete. Version 1.1 changes so many things that those just getting started with Java now are perhaps lucky that they can just jump in at the 1.1 level. A warning: It's really important to publishers to have the latest version number on the cover, even if the author has only briefly seen a beta. Compare the copyright date with the release date of the new version before you accept the claims on the cover.
One Java book in which I haven't yet found any typos is Michael Morrison's Presenting JavaBeans (sams.net Publishing, 1997). This may just be because I've been reading so many books lately that I'm getting bleary-eyed (but not in the tense Gosling way; this is more of a loose goose blear).
JavaBeans is, of course, Sun's API for developing component software. It includes the needed interfaces and classes for creating beans, as these software components are called. Presenting JavaBeans does a good job of presenting JavaBeans, and includes four sample beans on the accompanying CD-ROM, including beans for an LED display and a simple audio player.
I like Morrison's organization. He starts off with 40 pages of introduction, in which he lays out the basic concepts of component software and the various facilities provided by the JavaBeans API, explaining what they're for and why you might want to use them. Then he jumps right into the API, detailing its features so that you know what you've got to work with, and then, around page 125, he gets to some examples of bean construction.
Mac developers should note that the BDK, or Bean Developer's Kit, is not available for the Mac at the time I am writing. Versions for Windows 95 and NT and Solaris are included on Presenting JavaBeans accompanying CD, but you'll have to download the Mac version when it's available from Sun's site; it's free, though. And sams.net does acknowledge this on the cover of the book.
Seems like everybody is developing beans now, but that's probably an illusion of the SunSoft reality repurposing machine. Still you wonder when a company you thought was dead resurfaces as a bean factory (http://www.taligent.com/).
Morrison calls JavaBeans "possibly the most exciting and promising software component technology available." I had to check the publication date on this book myself; the "available" qualifier sounded just too appropriate. But no, Morrison delivered his manuscript before Apple announced that it was pulling out of OpenDoc development. Just prescient, I guess.
Because a reasonable argument can be given that OpenDoc was a particularly exciting and promising software component technology, albeit a component technology of a different sort.
The OpenDoc idea is, or was, to give components to mere users and let them configure their own integrated software. Sort of like UNIX pipes, only not really. More like audio components. I speak as though that option is now closed, but in fact OpenDoc is not dead. It's just been pulled off life support.
Apple's position, stated at one of this year's cutbacks, is that it's moving its component technology resources from OpenDoc to Java, whatever that means, and that the releases of OpenDoc and CyberDog that ship with Mac OS 8 (formerly known as 7.something) will be the last major update to Mac OpenDoc. There will be no OpenStep API for OpenDoc. CI Labs has been disbanded and its assets returned to its sponsor companies, principally Apple and IBM. IBM may still be planning to support the Windows version of OpenDoc.
One phrase I like to keep in mind when thinking about component software is "how to hook a customer directly to a product." It's not terribly catchy or original or surprising, but it reminds me that there is a constant battle to eliminate the middleman, and that it can always be done.
The phrase is from Roger Black's Web Sites that Work (Roger Black and Sean Elder, Adobe Press, 1997). Black is a famous designer, mostly of magazines. I'd say more, but Black says it far better in the book than I can here. There are those who think that Black is just a bit, shall we say, full of himself. In this book, he gracefully acknowledges his coauthors and removes himself from the book in the introduction by the technique of banning the first person from the book. Or that's the theory, anyway. The third-personing of the author actually has a very different effect. Roger Black is one of the themes of the book. There's a chapter of Black's from-the-hip prognostications about the Web, a chapter of images from his past work, quotes about Black from the editors of Wired, and so on.
Nevertheless, the book is a real boon to anyone trying to make sense of web-page design. It's full of firm dos and don'ts, like "Don't repurpose," "Make everything as big as possible," "Put content on every page," and "The first color is white; the second color is black; the third color is red."
When you're dealing with design issues but aren't a professionally trained designer, what you want most is strong clear assertions that cover all the decisions facing you and eliminate the ambiguities and grey areas. And you don't care whether the assertions are the best possible views on the issues; you just want them to be not wrong.
That's Black.
By the way, regarding that urban legend of Java's naming, I have heard another theory of how the language got its moniker. This one says that Java is an acronym for "Just Another Virtual Architecture." That can't be true, can it?
DDJ