Java Executive Summary (Preliminary)

Rayme Jernigan

Produced for the RTP Java User's Group
Updated: 1/16/96

Overview and Description

The Java programming language is an object-oriented language which has the familiarity of C++, but it's smaller, simpler, more robust, and more secure. The Java programming language was designed with a "clean sheet of paper." Many features of C and C++ have been omitted because they promote programming errors, are security risks, or add unnecessary complexity to the language. Memory management, for example is automatic; a garbage collection algorithm runs as a low-priority thread in the background. (For more on how the Java Language Differs from C and C++, see

Another difference between Java and C/C++ is that once you develop a Java program, it will run unmodified on any platform... MacOS, Win '95/NT, Solaris, whatever; so long as the Java Virtual Machine, also known as "the runtime," has been ported to that platform.

You can think of the Java runtime as kind of a universal software microprocessor that makes arbitrary platforms and operating systems always look the same to Java programs after they have been compiled into object code... even if the underlying platform's architecture and environment are very different.

The compiled Java program is said to contain "bytecodes" since most of the Java virtual machine opcodes are 8-bits in length. These bytecodes are collectively protected by special built-in security features so they may be passed across an unsecured network, have their integrity verified by the bytecode "verifier," and then be loaded and executed by the "runtime" (in a "Java-aware" web browser, for example).

The unique portability and security of Java has led web browser leader "Netscape" to incorporate the Java runtime and verifier into their World Wide Web browsers.

Soon anyone with releases of Netscape 2.0 or later will be able visit a web site which has Java "applets" on board, and run these applets using their browser platform CPU by just clicking on the screen.

For example, suppose you wanted to download a compressed, tar'ed, zipped, postscript document from somewhere on the web. Currently you would need to make sure that you had the correct version of the latest decompression and conversion utilities, and word processor... all carefully integrated into the correct version of your operating system. But if the needed applets were installed on the web site, the user could just click on the web page document link. The right applet could transparently load and display (for example) the requested document on your "Java-aware" browser-correctly and automatically.

The same principle can be extended to more complex Java software packages. Since Java supports dynamic binding, the data of interest can be loaded up front, and then the rest of the computer program can be cobbled together according to the user's choices "on-the-fly," without re-compiling the whole program. There is no "fragile superclass" problem in Java.

A CAD program may first load the CAD data file, for example, and then dynamically load and apply special visual effects such as rendering, lighting, rotation, and so forth as these features are requested by the user. Other examples may include financial analysis and transaction tools, multi-user games and gaming, virtual worlds, audio-visual "chat," telephony, wireless, Internet "shopping" and auctions. In short, since applets require no "advance purchase" applets are uniquely suited for application domains which may be linked to a web site, and visited spontaneously.

Some of the companies who have a monopoly based on their operating systems or microprocessor architecture may be made uncomfortable by this. Not only might users not care so much what their OSes and CPU are... they might be less interested in buying shrink-wrapped software... at least not as it's currently distributed. The desired capability may be simply available on the web, tied to the content or capability the user is interested in. Just point and click. Why buy the whole Swiss army knife when you only need a toothpick? And the toothpick may be free?

From the user's point of view, however, applets must be either verified as being from a safe source, or contained to prevent them from doing harm to the client platform. This safe-source verification is needed in addition to the bytecode verification currently employed by web browsers.

By default, applets are assumed to be hostile. Ways to know exactly where a particular applet comes from (as you do when you buy shrink-wrapped software) are on the way. But currently, "beta" applets that run on browsers are "contained." They may execute in the browser... they may load files from the server they came from, but that's all. They may not perform any other I/O, save that which takes place with the user... the keyboard and mouse, for example.

In addition to the web-traveling "applets," more conventional stand-alone applications may also be developed in Java. The Java language development team thinks Java will eventually replace C++ in this regard; both in the field, and perhaps as an instruction language for object-oriented programming as well.

A Java "application" (as opposed to an applet) is like any other full-blown shrink-wrap-type application you might install in your system. It does not require a browser or bytecode verification, and it may perform file I/O operations and open sockets on the net. You are presumed to know exactly where it came from... just like ordinary shrink-wrapped software.

A Java application also has the interesting property of being portable, without modification, to any platform which hosts the Java runtime. The "look-and-feel" of the application is consistent with other applications from that platform. Compiled C or C++ "native code" may be linked into stand-alone Java applications as well. (But note that these native code extensions will not be portable).

You may hear Java applications and applets referred to as "alpha," "pre-beta," or "beta." These refer to the version of Java runtime on which they were designed to execute. Beta applications and applets will not run on alpha versions of the runtime unless they are modified, and vice versa.

There were two public alpha releases of the Java programming language that I'm aware of: alpha2 and alpha3. These were followed by the pre-beta release, the 1.0 beta, and the current release-2.0 beta.

Sun froze the programming interface, or "API" beginning with the first beta release. Any Java code written to the Beta API will be compatible with future releases of Java, according to Sun. However, future releases may be improved or extend beyond the beta API. Macromedia and SGI are partnering with Sun to define a interactive "multimedia API" for a future release, for example.

Sun has developed and released its own free Java-aware web browser called "HotJava." HotJava was itself written in Java. It was developed for the alpha releases of the Java runtime. It does not currently work with the Beta code. Java-aware Netscape browsers do, however, and Sun plans a beta release of HotJava early in '96. There are still alpha applets on the web, so the current HotJava browser is still useful. And it does permit more flexibility in browser-local and net data access than does Netscape. But the alpha applets are quickly being replaced by beta versions.

Here are a few of the industry partnerships announced in 1995:

In addition to Oracle, several companies have announced, or leaked rumors about $200-$1000 Java-aware Internet terminals, AKA "Interterms" or "Internet PCs." Others include Sun (by Toshiba), IBM, and less known companies such as the WebBook Company, and Viewcall Europe Plc. of London.

As a general rule, these Java terminals will tend to have very thin OSes, and little or no local mass storage. Oracle's Larry Ellison was quoted in the December 4th Business Week as saying that he is going to put his 1Mb Java-based OS into the public domain in the Spring. The Internet terminals should begin to appear this Spring and Summer.


Considerable interest is beginning to develop in increasing the speed of Java. To date, performance (excluding native code) depends mainly on the type of host CPU, and to some extent programming skill.

The first increase on performance may come from Sun itself. Sun has announced that a "Just-In-Time" (JIT) compiler will be available for the runtime early in 1996. The JIT compiler will resolve all symbolic references in the applet just before runtime; currently they are resolved on first use during runtime. This and other optimizations, the Java development team says, will move Java from being about 20-30 times slower than C/C++ native code, to near dead-even. (I should note that in real applications and applets, Java's efficient language design and threading are considered to conceal this difference somewhat.)

There is also a group addressing real-time issues in Java. Many features of Java are designed to be simple and effective for general use, but may not be suitable for the more demanding real-time applications. Sun's "mark and sweep" garbage collection (GC) algorithm is a good example of this.

The Java Virtual Machine specification requires that garbage collection be used for memory management, but does not require that Sun's particular implementation be used. Accordingly, a group has been formed to specify real-time enhancements for GC and also other Java elements, and have released a draft "real-time API." See:

Distributed Processing

Scripting Tools



Developer's Tools



The Web

Triangle Java Sites


Developer's Reference





Java Press Releases and Other Articles

General Java Indices