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.