If standardization was good for C and for C++, then it should be good for Java too. Shouldn't it?
It is no secret that I am a strong believer in software standards in general and in programming-language standards in particular. I spent several years on the committee that eventually led to the first of the Posix standards. I worked quite hard for thirteen years on the C standards committees (US and international), through the development of the C Standard and its first revisions. I'm coming up on eight years of steady work on the C++ standards committees, through the development of the C++ Standard and on. I've written or co-authored several books that describe Standard C and C++ in some detail. And I have written 136 installments of this column to date, not counting this one, all on much the same topic.
Mostly I believe that standards are a Good Thing. They provide the proverbial level playing field between companies small and large. On an international scale, they reduce barriers to trade between nations. Most important of all, they encourage a larger and more uniform market for compilers, libraries, and other development tools. Competition on the basis of technical merit almost always benefits the programmers in the trenches.
My early devotion to standards was hardly academic. I began my first company, Whitesmiths, Ltd., over 20 years ago, by reimplementing the Unix operating system and various C compilers. In those days, AT&T Bell Labs owned and operated all that technology. And rightly so, for it was Bell Labs personnel who invented and developed Unix and C. I was careful to make a completely new expression of these products, all the more careful since I had seen the original source while at Bell Labs. I was also careful not to make any unauthorized use of proprietary information or patented technology. And I remained on cordial terms with the folks at Bell Labs who continued to evolve Unix and C.
But still I had a problem. Bell Labs could change the definitions of Unix and C whenever they chose. And, of course, they did. Like any successful software, Unix and C evolved in response to user demands, not to mention input from a host of enthusiastic adoptees. Bell Labs was answerable to nobody, except possibly past customers, when deciding where to take both products. As a tiny player in that game, all Whitesmiths could do was try to respond rapidly enough every time the rules of the game changed.
The Posix and C standardization efforts thus promised us a safe haven. If the programming community learned to value these standards, then Bell Labs was no longer fully in charge. Sure, they could continue to innovate — and they did for some time. But it became less important to match them feature for feature (and bug for bug). A quality implementation that conformed to the relevant standards could sell on its own merits, at least in some circles.
And that indeed proved to be the case. By the time the Posix and C standards became technically stable (which was years before official approval, for both standards), new markets began to form. C compilers were quicker to escape domination by AT&T, and not so coincidentally they became a more important product for Whitesmiths than our answer to Unix. But both Posix and C are working examples of successful standards in action. And they have been so since the mid 1980s.
Standardizing C++
The programming language C++ followed a similar path to standardization, but with rather different dynamics. The effort began in 1989 (yes, that far back), about the time the C Standard was getting its official imprimateurs in place with ANSI in the USA and with ISO on the international front. The fundamental difference between this and the earlier efforts I described above was maturity. Unix and C had each been reasonably stable for several years when their respective standardization efforts began. Both were still being enhanced, to be sure, but the changes were relatively small. Not so C++. It was very much an experiment in progress in 1989 and for several years thereafter.
A host of nontrivial additions to C++ were proposed at the organizational meeting in mid 1989. I don't think any of us at that meeting believed that adding all those features to C++, in the guise of standardizing the language, would occupy the committee for the next eight plus years. Quite the contrary: there were more than a few snide remarks, in the early working meetings, about the length of the C standardization effort. (The C Standard took nearly six years from beginning to official approval, even though it was largely hammered out in the first two years.) But indeed the C++ Standard didn't freeze technically until late 1997. And it did not become official until nine years after the development process began.
And that's partly why I said earlier that standards are mostly a Good Thing. Standards work best when they "codify existing practice," to use the term beloved of standards organizations. If existing practice is still being actively worked out, then standardization can be a distraction. At best, the standards committee becomes the clearing house for innovation. (And I have ample reason to believe that was the hope and expectation of many of the players in the C++ effort.) At worst, the standard freezes before the best answers are determined from experience in the field. (And that happened in many places in the C++ effort, particularly where practically no field experience was available in time.) Somewhere in the middle, the standardization effort simply distorts the usual evolution by competition that often leads to the best answers. (And that invariably happened too, even though the C++ standards committee attracted most of the active players in the game.)
My personal stake in C++ evolved quite differently than for Posix and C. I sold Whitesmiths, Ltd. in 1988, and by 1989 I was on my own as a writer. I spent the next couple of years writing a successful book on the Standard C library and teaching in Australia. By early 1992, I was back home in Concord, Massachusetts and reconsidering my game plan. Writing in general was not as lucrative as I had hoped, but writing books that included software was even more fun and rewarding than I had ever imagined. Code that I had written merely to illustrate a textbook was beginning to earn nontrivial licensing fees in its own right. Since C++ was still rapidly growing in popularity, the natural next step was to write a book on the Standard C++ library. Whatever that was.
So I rejoined the C++ standardization effort, which I had dropped right after the organizational meeting for want of time. You can imagine my evolving surprise as the Standard C++ library grew from a mere seed to a very large organism indeed over the next six years. I got my book out, rather prematurely I confess. But that soon became less important than the software itself. This is not the place to describe all the Sturm und Drang I've weathered in the process. I simply report that the decision to write the Standard C++ library has led to Dinkumware, Ltd., now four years old and well established in the business of supplying standard library software for C, C++, and (oh yes) Java.
I recite this personal history to show how a standard can benefit even when no single large player dominates a marketplace. AT&T's influence over the C++ language diminished almost to nothing during the standardization effort. And since much of the very large Standard C++ library was not part of existing practice, circa 1989, nobody had a dominant position in that arena. So those of us who wished to compete in supplying the Standard C++ library have scrabbled on an equal basis to track the same evolving (and rapidly growing) specification. As compilers come into full compliance with the C++ Standard, that scrabble continues.
Standardizing Java?
So now let's talk about standardizing Java. It's been about five years since Java first burst on the scene. To say that it is a "strongly hyped" language (to use Andy Koenig's bon mot) is an understatement. It has been flogged like crazy by Sun Microsystems, who developed the language and tightly controls its evolution. Some of the earliest pronouncements positioned Java as a "Windows killer." While even Microsoft took those early threats seriously, the death of Windows seems still to be a ways off. Now Java is promoted most strongly as the ultimate in portable languages. In a world of networked computers and rapid software development, it's just the thing for lowering development costs and speeding time to market. Or so says Sun, at least.
The Java language itself is an interesting mix of C — more the dialect described by Kernighan & Ritchie than Standard C — and Smalltalk. It nestles snugly between C and C++ in terms of complexity and power. It comes with a library that is biased strongly in the direction of network and GUI support. Just the thing for writing web applets. But for all of that, Java is a general-purpose, procedural language much like C and C++.
A peculiar feature of Sun's initial implementation is the Java Virtual Machine, or JVM. This is a fictitious computer architecture that can be simulated on a wide variety of real computers. The simulator is written largely in C, of course, for maximum portability and efficiency. But unlike C, the JVM architecture spells out the sizes and representations of all the primitive data types in exquisite detail. A Java program compiles down to "byte codes" — the machine language of the JVM. The idea is that you can compile a Java program and test it on any machine, then download it to another implementation of the JVM and expect exactly the same behavior. More or less.
In point of fact, the JVM does not specify everything exactly enough to ensure absolute repeatability. True, it avoids the problems that a C program faces when the size of int varies from machine to machine. But the JVM introduces a host of new uncertainties with its support for multithreading. As a result, it is very hard to write a multithreaded Java program that behaves well on an arbitrary implementation of the JVM. There are also variations in the screen displayed by GUI calls, almost inevitable given the complexity of the process and the huge variation in display technology. And on top of all that are the uncertainties due to fuzzy specifications and version changes.
To put the worst face on it, Java does not fulfill its promise of letting you "write once, run anywhere." Instead, you have to "write once, test everywhere" to ensure that a Java program is truly portable. To put the best face on it, Java is no worse than any other language for writing portable programs. It gives you a fighting chance, but no ironclad guarantees. In fact, Java is rather better than many other languages — possibly even C — in the support it provides for writing portable code. It is just nowhere near as good as the early hype led us all to believe.
So why would anyone want to standardize Java? Well, if your name isn't Sun Microsystems, and you're not a Sun licensee, the answer appears obvious. Sun's stated policy is to tolerate, even encourage, alternate implementations of Java and the JVM. You can't use the Java name — it is a trademark. But you can certainly make a Java compiler, Java libraries, and a JVM that behave according to the specifications promulgated by Sun. Given the overnight popularity of Java, it is no surprise that any number of enterprises have done just that. But given the overnight popularity of Java, is also no surprise that it continues to evolve under Sun's auspices and direction.
That evolution has been quite rapid. I first saw the Java 1.0 beta specification in 1995. It benefited from a few cleanups, and a much more precise description, on its way to publication in the seminal book by Gosling, Joy, and Steele (The Java Programming Language, Addison-Wesley, 1996). That book established a new standard of excellence. Those of us who love to write compilers and libraries found few blemishes or uncertainties when using it as an implementation guide. In fact, I have done some of both over the past few years. More recently, Dinkumware has developed the libraries that work with the Java front-end translator developed by Edison Design Group (of C++ front-end fame.)
But GJS was hardly out before Sun was promoting Java 1.1. It added a few language features, the most notable being nested classes. Even more notably, the spec for these features was never stated as clearly as the 1.0 spec in GJS. And as a library writer, I was dismayed to see the "standard" Java library treble in size. Java 1.1 went through about five sub-releases. Each one asserted that it merely cleaned up the existing 1.1 spec, but somehow new code kept popping up along the way.
Then, just as things seemed to be settling down, out came Java 1.2. The language didn't change much this time, but the library once again trebled in size. Yes, that's an order of magnitude growth from the original 1.0 spec, in just a few short years. More recently, Sun announced that Java 1.2 was a "code name" for Java 2. (Reminds me of the state legislatures that redefine pi as 22/7, or even 3.0, to simplify teaching math to public-school students.) Maybe it will hold still for a spell now. Or maybe not. Only Sun knows for sure.
So we third-party developers of Java products have strong motivation for developing a Java standard. We are in much the same position as some of us were back in the late 1970s and early 1980s, trying to compete with AT&T in the world of C and Unix. But no analogy is perfect. We are also in much the same position as some of us were back in the late 1980s and early 1990s, trying to track a rapidly changing draft standard in the world of C++. Maybe we'd like a Java standard, but maybe it's too early to freeze the language and libraries.
That's why some people focus purely on the JVM. They argue that the real contribution of Sun's Java is this vehicle for supporting truly machine-independent code. You can compile other languages than Java to byte codes, they assert. Well, sort of. It turns out that the JVM is pretty highly tuned for Java. A few small changes would really improve the performance of C and C++ programs running on a JVM. So the community who would standardize just the JVM are split into two camps. Some favor a quick standard for the JVM as we know it and mostly love it. Others favor a longer development process leading to a real lingua franca for compiling modern procedural languages. Neither express much concern about the Java language and library proper.
Sun Dance
But all of those considerations are academic. What really matters is what Sun decides to do. If Sun chooses not to cooperate with a standards organization, then that organization faces a real uphill battle in producing an acceptable document. An organization can study the matter, discuss goals, and talk endlessley, but it can't do much without Sun. It is worth noting that AT&T supplied the base documents for the Posix, C, and C++ standards — not to mention the valuable time of any number of committee participants — without which none of these standards would likely have come to pass. Indeed, ISO committee SC22 has maintained a Java Study Group for several years now that has lacked the power to do much more than study and discuss.
Then a surprise move came from Sun. Several years ago, as the clamor first began for Java standards, Sun put forth a novel proposal. They submitted a request to ISO committee JTC1, the parent of SC22, to develop and submit a Java language standard themselves. They cited an established "PAS process" (I forget what the letters stand for) that had been developed to speed the adoption of standards already developed by other standards-making bodies, such as IEEE (mostly in the USA) and ECMA (mostly in Europe). Sun hastened to observe that nothing in this process explicitly prohibits a for-profit company from being a PAS submitter.
Sun argued that they could develop a Java standard in "internet time." They could post drafts at their web site, accept commentary, and turn around revisions much faster than a stodgy committee meeting face to face three times per year in various venues, and doing everything by majority vote in the bargain. The world could no longer wait the six to eight years needed to develop standards for C and C++. With Sun in charge and modern technology widely available, it would take no time at all to do the job.
On the other hand, Sun was a bit vague on a couple of important points. They would have to give up control of the Java name, if it was to appear on an ISO standard. And they would eventually have to turn control of ongoing maintenance of the standard to an ISO committee. So murky were Sun's intentions, in fact, that they lost the first ballot within ISO for approval. It took some rather intense lobbying for them to turn things around and finally get ISO approval on the second ballot.
What followed was a remarkable silence. No drafts appeared on the internet. No public dialog, hosted by Sun, ensued. Occasional hints percolated out that licensees of Sun's Java code had some input to the process, but even that was not clear. Sun had two years to develop a draft and submit it to ISO for an up-or-down vote, and it slowly became apparent that they intended to spend that time with little or no public dialog.
Two years came and went. Sun announced they were running a little behind. Meanwhile, those of us who had first hoped for a standard based on Java 1.0 quickly resigned ourselves to some flavor of Java 1.1. Or probably Java 1.2, sorry Java 2.
But then last year came still another surprise. Sun announced that they had decided not to submit a Java standard to ISO after all. They blamed Microsoft (of course) for interfering in some way, and ISO for changing the rules midstream, also in some not clearly specified way. But in any event, after three years of real time (a lifetime or two on the internet), we still had no Java standard. On the heels of this announcement, we all learned that Sun now intended to work through ECMA to develop the long-awaited standard. Last I heard, ECMA committee TC41 has just had its first meeting. How many meetings it will take to hammer out a standard is still not clear. Perhaps another internet lifetime.
If I come across as cynical in this recitation, I suppose I am. I have little problem with Sun not wanting a Java standard quite yet. Much as it would help my own little enterprise, I'm not completely convinced that the world should want a Java standard either. See the description of the C++ effort, above, for some of the reasons why. But I guess I would prefer that we ended up without a Java standard today by a more straightforward process. Even if you don't live on the internet, four years is a long time.
P.J. Plauger is Senior Editor of C/C++ Users Journal and President of Dinkumware, Ltd. He is the author of the Standard C++ Library shipped with Microsoft's Visual C++, v5.0. For eight years, he served as convener of the ISO C standards committee, WG14. He remains active on the C++ committee, J16. His latest books are The Draft Standard C++ Library, Programming on Purpose (three volumes), and Standard C (with Jim Brodie), all published by Prentice-Hall. You can reach him at pjp@plauger.com.