The Java Dream
I was a boy during the dawn of the personal computer age. Like most boys interested in computers at that time, I had to explain a lot of things to adults about Commodore Pets, Apple IIs, Radio Shack TRS-80s, and IBM PCs.
One of the hardest things I found adults to grasp was why a program written for one manufacturer's computer couldn't run on another manufacturer's computer. For example, a word processor written for the IBM PC couldn't run on a Commodore Pet.
Computers already seemed needlessly complicated to adults. With President Reagan making it easier for pretty much anyone to strip mine a national park or perform aircraft maintenance, it seemed almost treasonous that the computer industry was trying to multiply entities needlessly.
Chip manufactures pay some pretty smart engineers loads of money and stock options to figure out increasingly clever ways of moving ones and zeros around. Intel would prefer Motorola doesn't copy all its hard work.
The reason you can't run a program written for the Apple on an IBM PC is, of course, they use different chip architectures. Each computer's chip has a fundamentally different way of moving all the ones and zeros around.
When you write a program in a high-level language like C, you compile it before you can run it. Compiling breaks a command like "x = x +1" down into machine code the chip can execute. If you want your program to run on a different type of computer, you need recompile it for that chip.
The solution to this problem is, obviously, all computers should use the same chip architecture. From the chip manufacturer point of view, that's less than a great idea. Chip manufactures pay some pretty smart engineers loads of money and stock options to figure out increasingly clever ways of moving these ones and zeros around. Intel would prefer Motorola doesn't copy all its hard work.
When hardware manufactures all go off in different directions (consensus building in the computer world is frequently compared to herding cats), eyes turn towards the software side to provide a solution.
Emulators are a traditional solution. An emulator basically simulates a chip in memory. Software is used to move all the ones and zeros around instead of the circuitry etched on the chip. Unfortunately, emulators are slow and require vast amounts of memory. They've never been a good general solution.
The other solution is to give everyone the source code and let them compile it on their system at run time. Like emulators, this is another imperfect solution. Compiling a program takes a long time. No one wants to wait half an hour to run a word processor. Programmers don't want to give away source code either. Finally C and C++, the high-level language most programs are written in, doesn't transfer ("port") easily between systems. C code on Mac, IBM, and Unix gets wildly different for the tricky stuff.
It was these last two problems that engineers at Sun Microsystems tackled. The end result was Java. Please stay with me. Java began life as a language called Oak. Oak was intended for appliances. It had to be small, portable, and bullet proof against stupid programming. As a computer maven, you're usually willing to rise above a Windows GPF and carry on with the proper pioneering spirit. Right? The average consumer, however, doesn't want to have to reboot a microwave.
Java removes the need to distribute source code by letting the programmer compile it into an intermediate stage called "byte code." The tricky, machine-specific stuff is handled by a Java interpreter. As long as you have a Java interpreter (modern browsers come with Java interpreters), you can run Java byte code.
The Java interpreter and byte code are ultimately a compromise. Byte code needs to go through the Java interpreter before the ones and zeros get moved around on the chip. Having a machine specific Java interpreter ultimately allows Java to be universal. Please stay with me. While it's quicker than compiling source code, it's still not as quick as running native code. Would you trade your Pentium II for a 486 so your brother can run the same programs on his Mac?
Some are betting the dream of a universal language is strong enough that developers and investors will stay with Java long enough for it to mature.
* * *
Copyright 2002 Karl Mamer
Free for online distribution as long as
"Copyright 2002 Karl Mamer (firstname.lastname@example.org)"
appears on the article.
Direct comments and questions to mailto:email@example.com