Tags: Java
There was a little throwaway idea in my previous posting, Java is doomed to failure, which is growing on me. While writing I had this thought about the Unix wars.. and really that period, the fallout from which is still with us, is a great analogy of what could happen with Java if the various implementations were allowed to differ greatly.
Compatibility matters. That's more than just a slogan on a T-Shirt, it's something we put a lot of effort into. We have lots of engineers working on compatibility tests as a specific focus, performing compatibility tests, and we contractually require the Java licensees to perform compatibility testing.
The Unix wars were a failure of compatibility. For those young enough to have not lived through the Unix wars... Unix is this software platform developed by AT&T Bell Labs engineers which has had a long and circuitous history of arcane proportions. Originally Unix was this cool little thing, when I first encountered it (V7 on a PDP11) Unix was this fun thing, and a huge breath of fresh air from the DECSYSTEM-10 (TOPS-10) on which I'd cut my teeth. Comparing the two was night and day, and I was hooked. I even have a xerox copy of the Lyons book, an annotated copy of the V6 source.
V7 came before the commercialization that led to a couple dozen companies selling hardware running a variant of Unix. As Unix spread to various implementations incompatibilities grew. The incompatibilities made it hard to port software, and fortunately C/C++ has a preprocessor and the #ifdef constructs sort of saved the day by filling our code with arcane tests and twisting threads of duplicated code that implements the same things in different ways.
4.2BSD was 'better', wasn't it? It sure seemed better but, heck, it was incompatible.
Linux came along offering a clean room implementation of Unix, and it too was incompatible, and later on the dizzying varieties of Linux distributions all grew serious incompatibilities with each other. And the Mach/NeXT/MacOS thread of Unix implementations offered their own incompatibilities.
One problem which arose is in the early-to-mid 90's it appeared Unix was gonna die. The incompatibilities made it tough for the Unix market to be taken seriously, and Microsoft made inroads because like 'em or hate 'em, one thing they do is compatibility (of a sort). In a former job I had access to Windows source code and was astonished one day reading Windows NT source to find a comment saying something like "this is a bug, but if we fix it then application XYZZY from WHOZIT, Inc. will break". Indeed many of the Unix's of that time did die.
Another effect of the incompatibilities was the ./configure script. It's now ubiquitous, but I'm reasonably sure the first one was in the Perl distribution. If you're Unix-experienced you know the drill, ./configure, make, make install. The ./configure scripts are enormous shell scripts which check all sorts of system characteristics, often by writing and compiling small C programs to check various things. The most amusing of checks I saw in ./configure scripts was that Perl's checked to see if you're running Eunice, and printed "Congratulations, you aren't running Eunice" .. that is, unless you were running Eunice, and I used to work for the company who developed Eunice.
Anyway I'm sure many people see the ./configure script as a savior ... and for the longest time that's how I saw that script. The ./configure was certainly easier than the alternative of figuring out on your own the settings for conditional compilation choices. But if you stop and think about it, as I've done recently, I see the ./configure script as a symptom of a deeper problem.
The ./configure script points to the compatibility problems which have been endemic in the Unix/Linux camp for over 20 years. Wasn't POSIX supposed to save us from compatibility problems? Bzzzzt, nice try.
There it is.. compatibility.
I think one higher purpose for software is for it to run on whatever hardware you have available. Isn't it frustrating to have a Mac and e.g. want to run Quicken and find that Quicken for the Mac is so bad compared to Quicken for Windows? (BTW, I heard on the Javaposse podcast this week that
Intuit will launch soon a cross-platform cross-browser version of Quicken built using Java Server Faces)
In other words I think there is a universal desire for software portability, which in turn requires very strong software compatibility.
But how is this going to be implemented? Do we allow Microsoft to take over the computer industry and make us all use Windows? Or, what?
Source:
weblogs.java.net
