For When You Can't Have The Real Thing
[ start | index | login ]
start > java


Created by dave. Last edited by dave, 20 years and 359 days ago. Viewed 2,617 times. #1
[edit] [rdf]


I've long felt that Java was a solution in search of a problem, one which would only be saved either by some clever, never-been-seen-before type of application (the killer app phenomenon), or by the simultaneous explosion of obscenely cheap computing cycles and market cosolidation.

I think that the latter has happened.

Remeber when java was introduced? The motto was "write once, run everywhere." Java was going to replace the operating system in your computer, and you would get your apps and store your data from/on the web somewhere. You would be able to get at anything from anywhere at any time. We'd have java in our fridges, alarm clocks, cellphones.

Micrososft would be dead. Long live the network computer.

Well, it hasn't exactly worked out that way, has it.

I remember a few years ago when Sun was pushing the first of it's networking appliances, it was forced to publically admit that it didn't use any of the devices internally. It was embarrassing, as Sun was candidly admitting that this solution that they were pushing on everyone else wasn't good enough for their own purposes.

And why would it be? The Ultra-5/-10 computers that were being released at the time were more powerful than the old SPARCstation-20s of old, at a fraction of the cost. These were real, honest-to-goodness workstations and servers that cost about as much as a top of the line PC workstation. With the introduction of the PC-on-a-PCI card now available, you have the best of both worlds.

Problem: none of this runs Java. It runs Solaris. The PC card runs Windows.

With the introduction of Solaris 2.6, Sun changed the installer from a compiled application to some form of Java application. The install times of Solaris soared when comparing the new 2.6 with the older, non-java 2.5.1.

Faster computers, faster OS, java installer, slower install. You do the math.

Corel, the current darling of the Linux world, went down the java path in a previous attempt to find something 'new and cool' that would propel the company into the stratospheric position its delusional founder thought it deserved. There was, at one point, a mostly-functional version of Word Perfect that was written entirely in Java. It downloaded pieces of itself from the web server as they were required.

Of course, the problem was that it was slow. Capital L slow. Unusably slow. The project has since dissappeared, and Corel is currently two more get-rick-quick schemes past it. Again, you do the math.

The final indignity, if you would, was Microsoft's attempt to hijack the entire proceeding. First by clobbering Netscape, then by trying to extend the java specification by adding windows-only functionality. One might argue that if Microsoft was interested, it must have been 'the next big thing'. One would be ignoring the fact that Microsoft tries to extend anything it can, whether or not it is a viable exercise.

It is only with the recent results of faster-cheaper-better processors currently available that an interpreted language becomes practical for large scale, user-interactive tasks. If a computer can run this code fast enough for the user's needs, it may well be cheaper to develop for this target than to go through the painful task of building a compiled program. Even though the compiled program will always be faster, the project may not warrent the extra time or expense of such development. (This can be illustrated in the phenomina of "Internet Time.")

So with all of the 'solutions' that java was supposed to bring to the table being useless, why does java soldier on? Perhaps because of the Computer Tech's Patented Excuse For Everything:

Because we can.

And there's nothing wrong with that.

no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful: | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt