Like many of you, I work with operating systems other than Windows NT, including operating systems produced by companies other than Microsoft. Dealing with various operating systems brings some balance to my life. By working outside the NT environment, I get a good view of what's hot in non-Microsoft markets. 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 probably know, the answer is Java. Java has become the new Holy Grail outside the Microsoft universe--Java promises rapid, object-oriented application development that results in platform-independent applications. Java applications can be standalone or client/server applications that ride over TCP/IP, the most popular network protocol on the planet. Today, you can find Java compilers where you least 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 is not the first programming language that has promised to be easy to use, platform independent, network friendly, and so forth. Remember BASIC and ANSI C? These languages promised that you could write an application once and easily port it from one machine to another. Did these languages live up to this promise? In most cases yes, if you followed the ANSI standards, which supported only a subset 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++ that addresses many of the complaints about the complexity of C++. In other words, think of Java as C+++. Java does have one interesting architectural difference from C and C++: Java is not truly a compiled language; it is a tokenized language similar to the original BASIC implementation.

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

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

Suitable for Consumption?
Once you get past a thoughtful and analytical inspection of Java, you can get down to brass tacks: Is anyone going to write Java applications? Will those applications be any good? I'm not talking about silly bouncing-head or tic-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 is struggling to prove itself as a mainstream development language.

Over the past several months, I've looked at four types of Java applications targeted at a mainstream data processing environment. From my perspective, these applications illustrate both the current state of Java development and the potential of Java programs. The applications I examined include:

  • Terminal emulation: Several companies offer Java-based terminal emulation products. These products use a Java applet to deliver terminal access to UNIX and IBM hosts. This Java applet (in most cases) communicates with a back-end server, which in turn communicates with the hosts. The intent of these products is to enable terminal access from any system capable of running a Java-enabled Web browser.
  • Remote application access: Insignia Solutions developed a Java application that lets you access DOS and Windows applications running on a remote NTrigue server. NTrigue is Insignia Solutions' implementation of Citrix WinFrame with added support for X Terminal access. In fact, Insignia's Java applet, Keoke, is an X Windows terminal emulator customized to connect to NTrigue. Keoke lets Sun's line of network computers access DOS and Windows applications (via NTrigue), and can also run from Java-enabled Web browsers.
  • Web browsing: Sun initially developed the HotJava Web browser for its Solaris workstations and its line of network computers (NCs). HotJava is written entirely in Java and runs as a standalone Java program (as opposed to running inside another Web browser). HotJava comes with runtime versions of JVM software. Sun has also developed a commercial version of HotJava and JVM for Windows 95 and NT, as you see in Screen 1. The beta version of HotJava for NT is fun to work with, but not fully functional.
  • Office applications: Corel is leading the drive toward Java by porting its popular Corel Office application suite to Java. The suite includes WordPerfect (word processing), Quattro Pro (spreadsheet), and Presentations (business presentations). The Corel Office suite can run from Java-enabled Web browsers (in theory) or from a standalone JVM environment. Screen 2 shows Corel's WordPerfect running from a Web browser. In my mind, nothing illustrates the power and potential of Java better than Corel Office for Java.

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

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

For example, I was annoyed that most of the terminal emulation applets use an 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) NT 4.0.

The two large-scale applications, HotJava and Corel Office for Java, did not fare as well in the test environment. The HotJava browser failed to handle many different types of Web pages correctly, and Corel Office would run only under Netscape Navigator (an ironic development when you consider that Java is supposed to be platform independent). Yet despite these shortcomings, the raw potential of both HotJava and Corel Office impressed me. These two products might not be ready for production work today, but someday (soon, I hope) they should be real contenders.

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

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