Sun Burns Java Standardization Effort

March 4th, 2000 - Chuck Flink

For me, the most under-reported story of the week was Sun's withdrawal of Java from the ECMA standards body.  The ECMA Secretary General referred to it as "an enormous waste of experts' time and companies' money".  I'd refer to it as another example of Sun acting like a bunch of spoiled children.  You can read the report on ZDNet.  For a change, I recommend reading the Talkback associated with this ZDNet article.  As of this morning (3/4/00), the vast majority of the responses are not the normal mindless bashing, but rather serious concern about another good idea gone bad.  This tells a chilling story.  In my not so humble and reasonably experienced opinion, Sun has really damaged itself with this move. 

The story, briefly, is this:  Two years ago, at the height of Java excitement and in the beginning of the Sun / Microsoft battle over Java, Sun declared it would turn over Java standardization to this European standards group.  This week Sun backed out and claimed they would setup their own Java standardization effort based on working with their Java partners, not an independent entity like ECMA.  If this wasn't so reminiscent of Sun's past addiction to having things there way or no way, the controversy may have died down in spite of the strong words of the Secretary General.

Note:  much of what follows is included in the Talkback referenced above.  If you read my Talkback contributions, you may want to skip to the end where Future Directions for Java are suggested.

In my opinion and the opinion of many others, Sun has had a history of splendid opportunities wasted due to unmatched arrogance.  Here's the history as I remember it over the past 20 years.  See if you want to add or subtract from the list:

1)  My UNIX is better than your UNIX:

Since the birth of Sun as the commercial spin-off of government funded UNIX R&D 25 years ago, Sun has been stiffing every known partner that attempted to enlist Sun's support for a UNIX standard.  They will talk standards, but always come down to claiming their solution is better than anything offered by anyone else:

• X-Windows, when proposed by CMU and DEC was derided as "junk" by Sun spokesmen compared to their array of windowing systems.  I attended an early USENIX conference where Sun sung the praises of their existing Sun Windows and coming NeWS product.  But in spite of all the noise, Sun never could settle upon and release as an open standard any of these "superior" solutions.  (NeWS was the "revolutionary" Network Windowing System of 15 years back that used PDF as the rendering language on window terminals rather than use the X protocol.  Take a look at the X-Windows market today and the rapidly expanding Windows Terminal market.  Where's the impact of NeWS?);

• "Stateless" NFS vs. that "horrible" RFS that AT&T promoted. So much wasted time and energy, and what do we have now?  SAMBA/SMB is used more often than NFS; RFS dead; and to make NFS work efficiently over the Internet, it had to be augmented to include caching and hence is now "state-full", just like RFS!  After all the words wasted condemning AT&T for designing RFS just that way for just that reason, NFS has come full circle, killing partnerships and wasting time, people and money in the process;

• Motif vs. OpenLook “look and feel” battle, again waste while fighting for control more out of ego than technology;

• Sun's RPC vs. the Open Systems Foundation's RPC... Now Sun blames Microsoft for not being compatible with Sun when Microsoft is compatible with the OSF standard Sun refused to join!  Now OSF / X-Open appears to be dead, representing another cross-vendor partnership that could have succeeded with a little help from Sun.

• Now Sun arguing over "community licenses" for Solaris rather than joining in any meaningful merger with the Linux community.  If they were truly interested in open standards, they would work to make Linux truly portable and standard across the market, including porting their own customers to Linux while providing the strong vendor commitment necessary for Linux to ever take the lead.

2) The System V debacle:

AT&T bent over backward  in the deal to "bury the hatchet" with Sun and FINALLY have a common standard UNIX (10 years ago) in the form of System V Release 4, supposedly the merger of System V and Sun's UNIX of the day.  AT&T agreed to disagree by supporting BOTH RFS and NFS, the C library (libc) ala Sun and libc ala the C standards committee, Motif and OpenLook, etc. on down the line.  With the possible exception of memory management, not one feature was properly analyzed and integrated into a standard solution!  Everything was parameterized out the kazoo!  

When the release finally when out, Sun's release of System V ran Sun's features just fine but the AT&T compatible features were very buggy.  Sun then claimed that they were now standard with AT&T, even though the "standard' side didn't work as advertised!  AT&T management had been too trusting to have put the teeth needed in the contract to enforce true standardization.  Sun sold with "Berkeley UNIX options" as default while AT&T sold with System V options as the default.  Since the market was heavily seeded with personnel familiar with Berkeley UNIX from the days when BSD was essentially free to Universities (thanks to government funding), System V as a standard distinct from Berkeley UNIX essentially died off.  Marketing goal satisfied, Sun never again returned to an objective analysis of why Bell Labs and the majority of the UNIX vendors of the era had wanted to see a more reasoned, less ad-hoc standard. 

Not long after that AT&T sold UNIX to Novell and got out of the computer business.  Thanks Sun, for being such a helpful "partner".

3) Windows NT on SPARC:  

With the second major release of Windows NT (3.5), Microsoft made a concerted push to be independent of the Intel platform by porting NT to every popular 32-bit microprocessor.  Eventually, every single computer manufacture accepted the offer from Microsoft and the potential that there could be a market for NT on their systems, except Sun.  (And don't tell me it was because of byte order.  That problem was solved in the Mips/SGI platforms and the same solution could have worked on a variant of the SPARC chip.)

In retrospect, Sun's resistance may have been a good short-term move for Sun's shareholders, but apparently not their customers.  I say this because virtually every vendor that was able to do true side-by-side comparisons of NT on Intel vs. NT on their platform eventually concluded that it was cheaper and more profitable to sell an Intel based box (or clone) than to continue to support cross-platform NT compatibility.  All have how switched to selling Intel compatible architectures, at least as an option to the segment of the market interested in Windows compatibility.

This, personally, was a severe blow to me.  I had been a strong advocate for UNIX as a hardware independent platform, and felt the lost promise of UNIX was due to the failure of hardware vendors (prime example, Sun) to properly support a truly compatible version of UNIX.  OS difference was no longer the issue in the NT on RISC shoot-out.  It certainly appears that, without incompatibility locking in the customer, all these other architectures proved to be too expensive to sustain. 

This history has profound implications concerning Java and the Virtual Machine approach to "true" compatibility.  I have not sorted it all out yet, but it suggests again that Sun is not interested in exploring the technology options fairly, but in controlling the options presented to their customers.

4) "RISC will always be better than CISC." 

Yea.  Check the benchmarks now folks.  Again, I could write a book on all the ramifications of RISC vs. CISC (Reduced Instruction Set Computer verses the Complex Instruction Set Computer) .  Sun made the superiority of RISC chips the centerpiece of the SPARC sales pitch.  So did Mips and other RISC chip vendors.  And for a while, I was strongly on-board the RISC bandwagon.  There is a lot to be analyzed as we review the technology for reasons why the "revolution" never lived up to its promise, but consider this:  

If the RISC vendors had partnered, taking the best of each design and production process, I believe we'd be in a far more competitive and advanced market than we are today.  As a leader in the RISC movement, from the very beginning, I believe Sun is guilty of letting a great opportunity slip through their fingers out of fear of losing control.  They wanted control, rather than the best technology for the customer.

 5) "We'll have SPARC clone vendors....

 ....just like Intel and you'll be able to have competitive buys of Solaris boxes just like in the Intel and Mips world."  Where are all those SPARC clones and box partners today?  I'm afraid they are as popular as the Apple clone manufacturers we were also promised.   

Solaris on the Intel platform is a step, but why not simply recognize that UNIX is now "generic" technology.  The profitability left in Solaris exists only because of the incompatibilities that lock users into Solaris relative to Linux.  Merge the Solaris technology with the Linux community.  Make it open source and encourage the integration of the various UNIX factions around a single open source based on the best objective technical compromise between the factions rather than on maintaining control.

6) Sun and Netscape's deal to take over the web server world....  

(This predated the AOL purchase of Netscape, but supposedly is still in play.)   Where are the many systems integration partners that were going to be making big money on this deal?

7) Oracle and Sun's deal to build a new generation of cheap "Internet Terminals" and destroy Microsoft's desktop dominance.... 

Take a look at the Compaq iPAC for $499 and cheaper, more capable PCs coming rapidly down the pike.  Or consider the various "Windows Terminals" coming out to support Windows 2000 Terminal Server features.

If Sun and Oracle really hate Microsoft, quit giving Bill Gates ideas!  Every time these companies try to out flank him, he pivots and executes their "plan" better than they do!  He's trying to do the same thing in the embedded and Internet appliance markets.  And that reminds me:  Java was born in Sun's effort to be at the center of that market!

8) And now the Java standards debacle.....

The history of Sun's many failed attempts (above) is full of great opportunities identified, but squandered through a failure to sustain a long-term partner relationships clearly focused on providing the best technology for the customer.

What a waste by a bunch of spoiled children who never learned the #1 kindergarten lesson: share your toys and clean up you own messes!  Sun folk:  if you want to avoid getting the reputation you claim Microsoft has, grow up and learn how to be a friend your partners can trust!

Future Directions for Java:

Where do we go from here?  The next step for the Java community is to come to grips with reality:

• Java is primarily an evolution of the C programming language
• the Java VM is an obsolete idea that has been tried dozens of times in the past
• strong partnerships are the key to success (i.e. give up on Sun unless it sees the light)

One of the milestones in the evolution of programming was the development of C and the UNIX OS.  At it's time it represented a splendid example of what I refer to as mental impedance matching.  This occurs when a technology optimally matches mental capacity of entrepreneur and the problem of the day.  For example, C was just "high level" enough to garner the majority of the benefits of a compiled language, but just "low level" enough to be efficient and easily used by the programmers who grew up with assembly language.  UNIX as a standard OS for the minicomputer revolution provided precisely the right problem.  The Open System revolution added the emotional drive and gave a sense of adventure to the whole cause.  AT&T's government regulated, non-computer-industry centric position discouraged it from exercising any stifling control.  And hence we have tremendous progress in a few short years from an army of independent entrepreneurs, students and academics. 

Then came the Object Oriented Programming revolution and C++ was born.  C++ retrained a generation of programmers, moving them from viewing the machine through a veneer of High Level Language to viewing abstract objects through a language they were already largely at home using.  Java is the natural next step in the evolution of C.  It drops many of the obsolete constructs and migrates the programmer more fully into the OOP model of programming.  This is a valuable and worthy step that does NOT need to be aborted out of an absurd adherence to the Java VM model!

Let Java comfortably evolve into a compiled language as the new generation of C it really is.  But don't keep pretending it is some type of glorious new answer to the needs of the entire world.  I look forward to the rewrite of Linux in compiled Java and the continued growth of this branch of the family tree.  There are already Java compilers and Java VM byte-code translators that produce the type of performance oriented code that CAN put Java into the mainstream of programming, the very area dominated by C++ today.  Sun, let it happen!

Now let me give you examples of previous "invention" of the Java Virtual Machine some seem to think is so new and creative.  I just pulled off my shelf the book:  Computer System Organization, by Elliott I. Organick.  It is one of the seminal books in the history of computer architecture.  It describes the Burroughs B5700/B6700 series of language-oriented computers, all designed around an architecture inspired by the Algol programming language.  The intent was to be an optimal blending of hardware architecture and compiler technology.  In the few years after this book, the B1700 was developed as the lowest cost member of the B*700 family.  While the high-end machines were based on an optimum match of the hardware to the target language, as proposed by Sun for the future "Java Chip", the B1700 was micro-programmed to emulate any of a family of language oriented virtual machines (VMs):  one designed for Algol, one designed for Cobol, another designed for Fortran, etc.  A micro-programmed OS time-shared the hardware between these multiple language oriented VMs, allowing the B1700 to simultaneously run programs written in each of these languages.

In 1976, I tried to buy a B1700 to develop an emulator of the Trident Missile fire-control computer under development at my Navy Lab.  Burroughs refused to allow us to micro-program a B1700 on the grounds that the technology was an important company secret.  We ended up with a Nanodata QM-1, emulated the as-yet-to-be-built Trident computer, allowing the compiler and OS developers to begin modular testing on schedule, even though development of the real hardware had slipped nearly a year.  Shortly after testing began, the OS developers discovered confusion between themselves and the hardware engineers that would have cost months and millions if not discovered so early.  The VM we built paid off well for the Navy.  Our success spawned research funding that allowed a couple of us to implement the Emulation Aid SYstem (EASY) and the Simpl-Q VM that shaped the next 5 years of our research.  EASY was an operating system written in Simpl-Q that functionally was the parallel to the B1700 micro-coded operating system.  It managed the sharing of the QM-1 hardware between multiple emulators, and itself was written in Simpl-Q and ran on an emulation of a VM designed to optimally support the Simpl-Q language in the context of our needs.

I describe this history not to make myself sound great.  This work turned out to only count as Masters Degree projects for me and John Perry.  (John built a code generator for the Simpl-Q compiler, generating the Easy-Q code-bytes that I interpreted in the VM.  I designed and built the OS and micro-coded VM, we jointly designed the byte-code architecture to make each of our jobs easier.  John got his MS from University of Maryland, I got mine from VPI&SU.)  How is it that less than a generation later, the Java VM is suppose to be such a revolutionary concept?

The fact is, besides the Java VM, Microsoft ships the Visual Basic interpreter and the Scripting Engine, all three essentially language oriented VMs, but none are a displacement for compiled C used in the bulk of the software.  

The disturbing fact that the Java industry needs to face is that the vaunted portability common to VM-based architectures just does not carry the day compared to the efficiency of compiled code and the relative insignificance of architectural differences (e.g. RISC vrs CISC as an extreme case). It is more productive for AMD to win market share by cloning the Intel instruction set than by designing a Java chip.  If it wasn't, we'd be awash in Java chips by now.  If language oriented design (which I defended with my heart and soul in the 1970's) was a key concept, we'd all be running on Burroughs platforms rather than Intel chips.  Learn the history, observe the interplay of technologies, and make your own conclusion.

Finally, I return to the issue of trustworthy partners.  These are the ones that win by delivering technology to customers, not by taking their peers to court.  The long-term successful company is the one that defends it's turf by providing the best technology to the entrepreneur and ultimately to the end user.  Arguments about "control" lead ultimately to the loss of anything worth controlling. 

Disclaimer:  These are my opinions and experiences.  I don't claim to be more than I am:  a retired, middle-level technologist who loved my adventures with supercomputers, micro-coded language-oriented architectures, and most of all, UNIX.  Your memories of the history that got us here, and your projections of where the technology will take us, are always welcome in my inbox.  Email feedback below and I'll provide an addendum to this article correcting any oversights of misimpressions I may have given.  Thank you in advance!

Return To The Flink Ink Section