David Herron's Blog

Java is doomed to failure

In the wake of The Rise of JAVA - The Retirement of SUNW I thought something I discovered on osnews.com was more than interesting. (for the record, I hate this change, but after sleeping on it overnight I realized it's just a ticker symbol and has little real effect ... unless marketing decides to return to naming misappropriation such as Java Desktop System)

Today is the 10th anniversary of OSNEWS, one of the news sites I click on every day. For their anniversary they've dug up some of their original pages and at the top of the news for 30 October 1997 they have this gem: C/net is exposing the future Betamaxes and 8 track tapes of the technology world in a column entitled "10 Technologies that Don't Stand a Chance." Judge for yourself. BTW, one of those doomed technologies is Java.

Looking at that 10 years later I can only think the rumors of Java's death are greatly exaggerated.

The snippet contains dead links but thanks to the wayback machine we can read the original articles.

Why, 10 years ago, did C|NET think Java was dead? ... To quote them we have this familiar promise (write once run anywhere) as C|NET described it back then: Imagine a world without computer incompatibilities. You can write a program on one platform, then run it on a Sun workstation, a Mac, and a PC with any version of Windows. The cost of developing software plummets, software becomes cheaper to buy, and a new age of computing dawns. The lion lies down with the lamb. The land flows with milk and honey. Sounds like a great story, eh?

They then went on to describe how, if Java doesn't run on Windows, then we might as well kiss that dream goodbye because Java is doomed to failure. Or, rather, as they say, Microsoft must also use Java and unfortunately we lived through that history which, at the time, was still very fresh, and having gone through those times we have reached a time when Microsoft is not using Java (or, did they fork Java to create C#/.NET?) and Java is still here and taking a significant role in the world of computing. And the real spectre of that time, which is still affecting our thinking today, is compatibility: Everyone will claim to be supporting it under the banner of "open systems," while adding their own proprietary technologies that completely undermine the goal of universal compatibility. Unix has now splintered into the famous 31 flavors: Solaris, Irix, AIX, DG-UX, HP-UX, Ultrix, Linux, and more. That's why Unix is not proving much of a rival for Windows NT. The same thing will happen with Java, only the Java flavors will undoubtedly have cuter names. This splintering is precisely what Sun is suing to stop. But it's hard to successfully sue someone for not agreeing with your philosophical ideals.

You may recall that Microsoft provided an incompatible Java seemingly in an effort to splinter the Java market and turn it into an equivalent of the splintered Unix market. And the suit was about an inability to comply with a contract Microsoft signed, not philosophical ideals.

I think the general consensus is that proprietary extensions to Unix, which led to the splintered market, greatly damaged Unix (especially in the mid 90's) because the divided house of Unix could not compete against the unified house of Windows NT. It's worth pondering the effect of incompatibilities and splintered platforms, because the issue of Java compatibility is still with us today.

Clearly the splintered Unix market has some problems, and most of those flavors of Unix have indeed died or are barely alive. Some have flourished, as has Windows NT (even as it's not called that any longer). But what of Linux? Linux distributions have a lot of incompatibilities between them, but Linux overall is a big deal in the computer industry. I think the splintered Linux market is itself a hindrance and a blessing. That Linux implementations aren't in lock step total compatibility with each other has allowed a lot of innovation and experimentation. But it's at the same time frustrating e.g. if you're browsing HOWTO or tutorials that describe how to do something, but the article is written for a different Linux flavor than the one you're using all the details will be wrong even down to the names of kernel modules to modprobe. Or if you want to download and run some code the incompatibilities mean a huge ./configure script, which might or might not work, installation of a compiler, and enough technical expertise to know how to deal with compilation and installation. Oh, okay, maybe your linux distribution maker has already done the dirty work for you, but the amount of effort going into the distro's build systems etc is yet another symptom of the incompatibility disease.

That you can relatively successfully download a .jar file and it just runs, that's a great and wonderful thing. Someone can click on a JNLP link or enter a page with an APPLET and have a very high chance it will just work. This is the result of the efforts to maintain compatibility, even when challenged by the 800 pound gorilla of the computer industry to create incompatibilities and a splintered market.

Don't get me wrong about Linux. I've been using Linux since 1993 and am rather happy with it overall. But at the moment I'm thinking of how I see tutorial articles like Setting default editor in ubuntu .. or CPU Frequency Scaling In Ubuntu .. or Hyperic HQ On Ubuntu 7.04 .. and while it's cool there's a lot of tutorials on doing X or Y or Z with ubuntu (my preferred distro) why is the tutorial specifically for Ubuntu? Why isn't the tutorial for Linux? Why are tutorials for Ubuntu incompatible with Redhat or Suse or the other distros?

It's unlikely the incompatibilities between Linux flavors are going to kill Linux.. just as the splintered Unix market did not in the end kill Unix. Hey, even Apple is part of the Unix camp (who, at the time of the C|NET article) was getting ready to release Rhapsody... shudder. But I think incompatibilities do hinder adoption of a software platform.

Comments

• Hmm, even XP/Vista is part of the *nix camp to some degree. That splintered *nix world has shards in most mainstream OS pies of any size right now, IMHO.

  Posted by: damonhd on August 27, 2007 at 01:04 PM

• Huh? Apple's OS X recently was certified as Unix (presumably by some POSIX testing or whatnot) but how could you make the same claim for XP/Vista? I'm pretty sure the POSIX container that came with the original NT has been ditched and that was Microsoft's only prayer of XP/Vista being certifiable as Unix.

  Posted by: robogeek on August 27, 2007 at 01:38 PM

• Microsoft eventually bought Interix, and started bundling it with Windows as its POSIX environment. It's not very attractive to port things to, as it only exists for the enterprisey Windows XP/Vista/Server variants, and is stuck on a gcc 3.x development toolchain from around 2002. You can see posts from Microsoft developers every now and then on the mailing lists of the bundled projects, so they seem to be doing some maintenance work, but overall it seems to be in a much worse shape than Cygwin or Mingw32.

  Posted by: robilad on August 27, 2007 at 02:09 PM

• The list technologies that don't stand a chance is interesting... Among them, you can find web push feeds (akin to RSS), PDAs, VoIP, Spam filters and TV (I can't tell if that one is a joke or not). It seems to me this guy has a lack of vision..

  Posted by: npiguet on August 27, 2007 at 11:57 PM

• You may recall that Microsoft provided an incompatible Java...
  Well, could someone points me what was incomplete in MS J++? It fully supported "standard" Java and have several syntax extensions. Frankly, I don't remember whether or not it produced incompatible bytecode...
  Anyway, if Sun preferred something better then law suit against MS that time, then we might get Annotations Facility in 1998-1999 rather then five years later. When I'm looking now at my code that uses NLink library/annotations I see no real difference with MS "annotations" proposed in J++
  VS

  Posted by: vsilaev on August 28, 2007 at 06:36 AM

• [i]Well, could someone points me what was incomplete in MS J++?[/i]

  Two aspects of the incompatibility were:
  1) They didn't include the code for rmi
  2) they polluted the java.* namespace

  They also indicated that they would not support several aspects of the ongoing Java development (notably Java2D).

  Posted by: mthornton on August 28, 2007 at 07:16 AM

• I yahoogle'd "Microsoft Java Incompatibility" and found some articles and a whole walk through history. The following two seem most relevant.

  
  Microsoft sheds its Java skin -- again (1998) discusses changes by Microsoft in their Java SDK and J++ to improve compatibility and discusses the still-missing features
  How to avoid potential pitfalls of Microsoft's non-standard SDK for Java Shows explicitly the differences, so that you can avoid using or depending on those differences

  Posted by: robogeek on August 28, 2007 at 12:14 PM

• BTW, the rules for Java compatibility says that the parts which are specified by the platform spec, those must be compatible, with nothing added nor removed. But it is perfectly okay to add other stuff, such as what Apple does by adding OS X specific features in packages that are outside the ones in the platform spec. Microsoft could have followed the same strategy but instead they insisted on mucking with the defined packages and other defined interfaces.

  Posted by: robogeek on August 28, 2007 at 12:20 PM

• As a heavy Java user/programmer I agree w/all you say except for the part where you say that when I look at an APPLET there is a very high chance that it will work.

  In my experience APPLETs rarely work. On ANY computer (not just mine). APPLETs are a terrible failure.. one that has marred Java's name for years.

  Today Flash just works.. applets are still feel like Russian Roulet!

  Posted by: dog on August 28, 2007 at 09:33 PM

• Besides leaving out RMI, MS also left out JNI.

  They also added two of their own keywords, multicast and delegate, which did produce incompatible bytecode. See this article

  I found it interesting that whether adding keywords was allowed or not came down to the wording of "keywords, one of..." (see above link, 2nd to last paragraph), which is the exact same wording as the C standard has (C99 section 6.4.1). The only difference is that the C standard also says, in a footnote: "An implementation may define new keywords..."

  I really think the JLS should have been (and still should be) tightened up to say things like "...and nothing else is a keyword".

  BTW, congrats on getting an Ubuntu release named after you, Dave:

  Posted by: atripp on August 29, 2007 at 01:02 PM

• Well, there's Herron and then there's Heron. Not the same.

  Posted by: robogeek on August 29, 2007 at 01:56 PM

• J++ was developed and distributed under a license from Sun, intended to make Java applications more native on Windows (sounds like what Apple's doing to me...). Microsoft had permission from Sun (as was common at the time) to create their own libraries and ship those (wait, isn't that what most of us are doing? SWT anyone?). Sun didn't like Microsoft's VM becoming more popular than theirs on Windows, withdrew the license, and accused Microsoft of trying to destroy Java. The rest is history (and often distorted to make Microsoft look like the bad guys when they were doing nothing that wasn't allowed under the license they had).
  J++ was not much good compared to later Sun releases, but certainly had potential. Had Sun not unilaterally cancelled the license and sued Microsoft afterwards MS most likely would have adapted J++ to stay in line with Sun releases of the language.

  Posted by: jwenting on November 08, 2007 at 10:55 PM

• @jwenting, please read How to avoid potential pitfalls of Microsoft's non-standard SDK for Java ... that was published November 1, 1997 and it is far enough into the past that it is not part of any spincycle you're suggesting happened. That article goes over the differences Microsoft introduced, every one of which is incompatibilities they introduced. It wasn't that they added additional stuff, but that they changed the stuff which was there, and they removed other stuff. That led to an incompatible thing which they tried to foist as Java.

  Posted by: robogeek on November 09, 2007 at 06:49 AM

This work is licensed under a Creative Commons License.