Java: The Buzz from Beyond

Like many of you, I work with operating systems other than Windows NT,including operating systems produced by companies other than Microsoft. Dealingwith various operating systems brings some balance to my life. By workingoutside the NT environment, I get a good view of what's hot in non-Microsoftmarkets. Believe it or not, the whole world isn't revolving around ActiveX.

If ActiveX isn't the rage of the industry, then what is? As you probablyknow, the answer is Java. Java has become the new Holy Grail outside theMicrosoft universe--Java promises rapid, object-oriented application developmentthat results in platform-independent applications. Java applications can bestandalone or client/server applications that ride over TCP/IP, the most popularnetwork protocol on the planet. Today, you can find Java compilers where youleast expect them (e.g., Java is even available for the RPG-entrenched AS/400).

Déjàva Vu
For many of you, this buzz may seem strangely familiar. I assure you Java isnot the first programming language that has promised to be easy to use, platformindependent, network friendly, and so forth. Remember BASIC and ANSI C? Theselanguages promised that you could write an application once and easily port itfrom one machine to another. Did these languages live up to this promise? Inmost cases yes, if you followed the ANSI standards, which supported only asubset of the useful things you really wanted to do in your program.

So what's different about Java? Is Java dramatically better than ANSI C?Most developers will tell you that Java is, at heart, a derivative of C++ thataddresses many of the complaints about the complexity of C++. In other words,think of Java as C+++. Java does have one interesting architectural differencefrom C and C++: Java is not truly a compiled language; it is a tokenizedlanguage similar to the original BASIC implementation.

Because you don't compile Java programs into machine language, Java code isuniversal. You can download and run the same Java program (applet) on a PC, aMac, and a UNIX system. Each system runs the Java program under a JavaVirtual Machine (JVM), a set of software programs that either interpret theJava tokens (bytecodes) or translate the Java code into machine code using ajust-in-time (JIT) compiler. In most cases, the JVM is associated with a Webbrowser; thus, Microsoft Internet Explorer (IE) and Netscape Navigator includeJVM software. You can also get standalone JVM software so that you can run Javaapplets independent of a browser. (By the way, if you want to do file I/O, youneed standalone JVM software--IE's software and Navigator's JVM software don'tsupport file operations for security reasons.)

Although Sun Microsystems designed Java to be platform independent, someJVM implementations support special extensions that are machine specific. Theminute you use any of these extensions in a Java program, you can kiss platformindependence goodbye--it's the same result you get if you deviate from the ANSIstandard when you're writing a C program.

Suitable for Consumption?
Once you get past a thoughtful and analytical inspection of Java, you canget down to brass tacks: Is anyone going to write Java applications? Will thoseapplications be any good? I'm not talking about silly bouncing-head ortic-tac-toe applets; I'm talking about full-weight data processing applications.Clearly, Java has proved itself as a means of enhancing Web pages, but it isstruggling to prove itself as a mainstream development language.

Over the past several months, I've looked at four types of Javaapplications targeted at a mainstream data processing environment. From myperspective, these applications illustrate both the current state of Javadevelopment and the potential of Java programs. The applications I examinedinclude:

As you can see, this mix of client/server, Internet, and traditionalbusiness applications is eclectic (for more information about theseapplications, see the sidebar, "Where to Go"). Of course, theinteresting question is, How did these applications fare in a test environment?

I found the terminal emulation and remote application access programsusable, although I confess I did not exercise every conceivable option. In fact,my complaints about these applications have virtually nothing to do with theJava part of them.

For example, I was annoyed that most of the terminal emulation applets usean interim server system instead of directly connecting to the host systems.Similarly, I was disappointed that NTrigue is based on NT 3.51 and not (yet) NT4.0.

The two large-scale applications, HotJava and Corel Office for Java, didnot fare as well in the test environment. The HotJava browser failed to handlemany different types of Web pages correctly, and Corel Office would run onlyunder Netscape Navigator (an ironic development when you consider that Java issupposed to be platform independent). Yet despite these shortcomings, the rawpotential of both HotJava and Corel Office impressed me. These two productsmight not be ready for production work today, but someday (soon, I hope) theyshould be real contenders.

In fact, most Java applications I looked at were beta versions, which isgood evidence that we are at the leading edge of the Java development cycle. Aswe move forward, the current line of Java products will slowly move from beta tofinal release and many new Java applications will appear on the horizon.

Given this trend, Java should certainly play a major role in thedevelopment of cross-platform applications. For now, we have little choice butto wait for production versions of these applications to arrive. In themeantime, we have plenty of ActiveX controls to keep us busy.