 Jive'n With Java
In
the bad old days, the mainframe was king, disco was cool, and a portable
computer was a suitcase with a 5 inch monitor.
Ah, retro. The sociological malady that hangs about a culture convinced that
things USED to be better. You've seen it: Polyester has made a comeback
and butterfly collars are again "groovy." (If I had come to high school
in that combo, some football player would have hung me by my underwear
from the flagpole, and I would have deserved it, too.) Computer technology is also going through its own "retro" phase. After a twenty
year distraction called the Personal Computer, the idea of keeping all
of the data in ONE place is starting to appeal to the burned out network
administrator. But the paradigm has shifted: All of the number crunching
used to be done on the mainframe, the same place that the data was stored.
You only got to the data by means of a "dumb terminal," which was an appropriately
named keyboard and monitor combination with no silicon gray matter. You
could tell the mainframe what to do with the data, but your terminal didn't
actually do the work, it just acted as a portal. When the PC came along, all of the processing was moved to a small and slow
processor and the data was stored there, too. Then the glory of Windows
(or more precisely, Macintosh) came along to further drag performance down
by making the interface graphical instead of text based, thus changing
the way everyone worked. But the data was YOURS, and couldn't be harmed
by a central repository going down. If the mainframe went down, you could
keep working. The poor nebbish with the dumb terminal was sidelined until
the mainframe administrator pried the rock out of Goliath's skull and set
it upright again. What does all of this have to do with Java, and more to the point, what does
it have to do with AutoCAD? Java is based on the desire to let everyone
get to their work from whatever type of computer or operating system they
are on. AutoDesk recently opted to drop DOS, Unix, Windows 3.1x and support
for Alpha CPUs in Release 14. They are writing their code for specific
hardware platforms (Intel again) because they are the most popular and
it takes a lot of work to custom rewrite your program for every platform.
IF (that is a big IF here, folks) AutoDesk were to write the next version
of AutoCAD in Java, it wouldn't likely matter what hardware or Operating
System the user was running. Know any Unix or DEC Alpha users who would
like to hear that? For the average joe who hasn't read the trade papers lately, Java is a programming
language from Sun Microsystems similar to C++ (which Microsoft uses almost
exclusively to write their programs in.) It is object oriented and uses
"classes" or pre-compiled tools to do certain functions, that way a programmer
doesn't have to write new classes for all of their program, they can just
tell a preexisting one what they want done with the input data. While you
can write your own classes, many common functions are more easily done
by using the prebuilt models. In C++, when you write a program, you must compile the code. This compiling process
makes it run very fast, but because different computers (PC, Mac, Sun,
Silicon Graphics, etc.) and Operating Systems manage their processes in
a unique way, the C++ code must be compiled differently for each platform.
Thus, the programmer must go back and make changes to the code to get it
to run on each platform. This process is called "porting" and it is the
bane of a programmer's existence. Enter Java. Instead of compiling the
Java code to specific platform specs, Java code is compiled to an intermediate
stage called bytecodes that is just shy of being platform specific. The
code is not functional in this form. It requires a final component: the
runtime compiler. This component sits on the machine where the Java program
is to be run and when the Java bytecodes are loaded, this runtime compiler
completes the compiling process, thus making the code platform unique and
hands the now completed program off to be run in the Virtual Machine (VM)
or "Sandbox". (More on the Sandbox in a minute.) The beauty of this design
is the "write once, run anywhere" attribute. If a large corporate program
needs to run on all of the platforms listed above, the programmer only
has to write it once. The runtime compiler on each machine (the part that
is unique to the platform) handles the job of making the Java program unique
to the platform upon which it is run. When the program is closed and reopened,
it must be recompiled. Because Java is small and portable (i.e., not platform specific) its range of uses
is almost unlimited. Smart Cards, Cars, Telco, & Consumer Electronics
are all potential usages. I think the possibilities are obvious: We retain the ability to manipulate data
at the local computer (which was the point of PC revolution) but we make
it possible to run the program on ANY computer without rewriting it and
without relying on the mainframe's capacity to share its number crunching
capacity with 30,000 other people in the organization. It keeps the data,
but our Java program does the bean counting with the brains of the local
processor not caring WHAT processor it is being run on. The first, most obvious use of Java's "write once, run anywhere" attribute
is the World Wide Web. Large companies (such as the behemoth I work for,
Boeing) use multiple platforms for different types of work. Java is how
you write a program that will run on them all. (This differs from Common
Gateway Interface programs because the server is the one that does the
actual work and only reports the findings back to the client machine. But
with 30,000 people at the main plant alone, CGI would drive the server
to its knees if complex processes were run on it.) The main limitation
of Java is its secure nature. While the "sandbox" that Java runs in prevents
it from reading or writing to the local machine, it also means that Java
can be beastly slow to do things that happen quickly with other programs.
At present, Java has no ability to affect your local machine because it
can't write to the drive or make system level calls. Considering that the
Internet is the source for most of the Java in use today, the security
is necessary because the fear of your system being destroyed by a rogue
program is very real. I recently sat in on the keynote address at the JavaOne Developer's Conference in
San Francisco, and got very excited about the potential for this technology.
The main subject covered at the JavaOne conference was a performance improvement
that extends Java's capacity to compete with C++ while retaining the security. As stated above, Java bytecodes are loaded by a runtime compiler and then compiled
to make a program that must run within the VM. With the advent of the new
Java Developer's Kit, programs will have the option to invoke disk and
memory I/O. The way Sun Microsystems keeps the safety while extending these
capacities to the Java program is by having the VM do the file and memory
I/O. The process works like this: The advantage of being able to make requests through the VM is that the capacities and
speed of Java can be extended, without compromising safety. If a Java program
can retrieve its cached components from a local disk, there is no additional
delay as the class files are downloaded and recompiled. If the Java program
needs a file from a central server, it can make the request through the
VM which can open a network port and retrieve the file. The point is that
the VM does all of the work, thus retaining the right to reject a program's
illegal request. While you can't always control what secret horrors get
downloaded from the Web, you can be sure that they won't get at your machine
by using the secure VM to handle the I/O. Presently C++ is the reigning champion of programming languages, and has been so
for the past decade. In only two years, Java has bypassed all other competition
to become the number two standard and continues to gain rapidly on C++.
Classes in Java are offered at 162 Universities worldwide, and more than
Four Hundred Thousand programmers are seriously pursuing the construction
of programs and applications in Java. AutoDesk has done a wonderful job with Release 14 partly because they were able
to focus their energy on one processor design (Intel) and one OS architecture
(Microsoft.) But there are many users of very fast computers that are being
cut off. Java is the opportunity for companies like AutoDesk to open up
their products instead of closing them off. Next month, I'll talk about the comparison between Java and Microsoft's ActiveX.
Be warned: You'll need to wear an arch welder's mask to view this column
next month. Peace, Webwalker |
| (R. Marshall Webber is a Web Developer for the largest building in the world, The Boeing Company's Everett, Washington Commercial Airplane Group. He and his wife, Sarah, make their home near Seattle.) |