Java and the new Internet programming paradigm

An excerpt from Rise & Resurrection of the American Programmer

1 2 3 4 5 Page 2
Page 2 of 5
  • The Java run-time interpreter verifies that bytecodes (the compiled architecture-neutral form of Java applet that gets downloaded from the Web server into the user's machine) don't violate any language constructs -- which could happen if an altered Java compiler was used by a hacker. The verification logic checks to make sure that the Java applet doesn't access restricted memory, forge memory pointers, or access objects in a manner inconsistent with its definition. It also ensures that method (subroutine) calls include the correct number of arguments of the right type, and that there are no stack overflows.

  • During loading of the Java applet, the run-time interpreter verifies class names (a "class" is an entire Java applet) and access restrictions.

  • If a Java applet attempts to access a file for which it has no permission, a dialog box will pop up to allow the user to continue or stop the execution of the applet.

  • Future releases of Java are planned to have facilities for using public key encryption to verify the source and origin of the Java source code and its integrity after traveling through the network to reach the user's machine.

  • At run time, information about the origin of the Java applet can be used to decide what the applet is allowed to do. For example, a security mechanism can be used to determine whether the compiled Java bytecodes originated from within an organization's security firewall or not. This makes it possible to set a security policy that restricts the use and execution of Java code that an organization doesn't know or trust.

This last point is crucial, for there are likely to be a number of attempts -- both innocent and malicious -- to circumvent the security mechanisms that Sun has built into the language. In its white paper on the Java language, Sun expresses the following optimistic statement about Java security:

Java is designed to operate in distributed environments, which means that security is of paramount importance. With security features designed into the language and run-time system, Java lets you construct applications that can't be invaded from outside. In the networked environment, applications written in Java are secure from intrusion by unauthorized code attempting to get behind the scenes and create viruses or invade file systems.

For the security-conscious organizations, though, the firewall protection mentioned above will be crucial -- at least in the short term.

Portable, architecture-neutral behavior

A basic objective of the Java environment is to operate within a heterogeneous networked environment; to be of practical use, it must be capable of executing on a variety of hardware platforms, in conjunction with a variety of operating system environments, and with multiple programming language interfaces.

The primary strategy for accomplishing this is the use of a compiler that generates bytecodes from a Java source program. The bytecodes are transferred from the Web server to a Java-enabled Web browser, where they are interpreted at run time by a Java interpreter. Obviously, the Java interpreter software has to be cognizant of the hardware/software environment in which it operates, but the Java applets do not.

To achieve a higher degree of portability, Java imposes a strict definition (based on an IEEE standard) on data types (for integers, floating-point numbers, and so on) and the behavior of its arithmetic operators. This ensures that numbers look the same and behave in the same way regardless of whether the Java applet is running on an Intel platform, a Macintosh/Motorola platform, or any one of the dozens of Unix environments that exist around the world.

The architecture-neutral and portable language environment is collectively referred to as the Java Virtual Machine (JVM). What the marketplace sees is a specific implementation of the JVM for a specific hardware and software environment. The JVM is based primarily on the POSIX interface specification (which is also an open, industry-standard definition) for portable system interfaces.

In this area, Sun starts from an entirely different premise than that of vendors like Microsoft. Though Microsoft is certain to have a viable technology for developing applications on the Web, it's likely to be based on a proprietary language (for example, Visual Basic) on a proprietary operating system (Microsoft Windows) with a proprietary technology for distributing objects (OLE), and all of this was created originally for a single hardware environment -- that is, the Intel platform. From a philosophical perspective, Microsoft seems to have adopted a centralized, top-down approach reminiscent of the old U.S.S.R. government. Sun has adopted something closer to the grass-roots, U.S.-style of operation.

High performance

Java was designed with the realization that performance would be important for some situations, but not all. The typical user running a Java applet on a Pentium processor probably won't know or care if it takes a few milliseconds longer than a hand-coded C++ program would have -- just as the user who uses a Visual Basic or PowerBuilder application typically doesn't worry about performance very much. The important point here, of course, is that the Java applet does run on the user's machine rather than executing on a Web server, where the competition for hardware resources is likely to be much greater.

But efficiency and performance involve more than just CPU cycle; in particular, they involve the issue of "bandwidth." Most Java applets are relatively small (the typical demos involving graphics applets to make a ball bounce around the user's Web page are about five kilobytes) and will only have to be downloaded once. This is in stark contrast to the behavior that the user sees with today's Web applications, where the interaction between the user and the application invariably involves a great deal of traffic between the Web client and the Web server -- since the application logic executes only on the Web server today. The network delays are typically orders of magnitude larger than any performance delay that might be noticed by an applet executing on the user's computer.

However, keep in mind that a Java applet could be written to continuously grab more Web pages and images and stuff; indeed, one or two of the popular Java demos do just that by giving the user an automated "run-through" of a sequence of pages on the server. And even if only one Web page is retrieved, it could still have a large graphic or multimedia component that could swamp the resources of the user's machine and network connection.

But if we return to the issue of Java performance on the client machine, we do have to acknowledge the possibility that a Java applet could swamp the computational resources of the user's computer. Sun has attempted to avoid as many performance problems as possible by adopting a scheme, for example, that allows the interpreter to run at full speed without having to check the run-time environment. The Java run-time environment also contains an automatic "garbage collector," to reclaim objects and storage space no longer needed by the Java applet; by allowing it to run as a low-priority background activity, there is a high probability that memory will be available when the Java applet needs it, which leads to better performance.

To illustrate the basic performance of Java, Sun tested some simple programs on vintage-1995 high-end PCs and workstations, with the following results:

  • Creating a new object takes approximately 8.4 microseconds.

  • Creating a new class with several methods takes approximately 11 microseconds.

  • Invoking a method on an object takes approximately 1.7 microseconds.

  • Invoking a synchronized method on an object takes approximately 16.3 microseconds.

It's reasonable to assume, I think, that the performance issues for typical single-user environments will become less of a problem as the hardware technology continues to advance over the next several years and as users have more and more powerful workstations on their desks.

Sun has also provided a mechanism that allows compute-intensive sections of a Java applet to be translated on the fly (that is, at run time) into native machine code for a specific hardware environment and then interfaced with the rest of the Java environment; this is roughly equivalent to a scheme in which a compiler's final machine code generator has been combined with the dynamic loader. Such an approach might be necessary for certain mathematical, engineering, or scientific applets, but I doubt that we'll see very much of it. The performance of bytecodes converted to machine code in this fashion is roughly the same as with native C or C++.

Multithreaded behavior

It's important to note that the level of interactivity is different with Java, because user input is controlled from the client rather than the server. With current HTML interfaces, there is no response to Web input until the user clicks on an "input" button of some kind. Typically, there's only one thing going on -- and while users are waiting for a response from the network, it appears to them that nothing is going on.

Java is based on the assumption that users really need and want to do several things at the same time. For example, users working with a Java-enabled browser can run several animations concurrently while downloading an image and scrolling the page currently displayed on their computer screens. To achieve this high degree of interactivity for users, it's important to have a multithreading capability.

Java supports multithreading at the language level with the addition of sophisticated synchronization primitives. The Java library provides a Thread class, and the run-time interpreter provides "locking" and "monitoring" operations, as I'll describe in more detail below. At the library level, Java's system libraries have been written to be "thread safe" -- that is, the functionality provided by the libraries is available without conflicting with multiple concurrent threads of execution.

One last point: It's encouraging to note that Java is not a hog. Unlike many of today's bloated software packages, it doesn't fill up your entire computer; the basic Java interpreter requires about 40 kilobytes of memory, plus another 175 kilobytes for the standard class libraries and multithreading support. That will probably grow over time, as the language and environment become more sophisticated, but it's a far cry from the two megabytes of memory that my word processor demands as a minimum.

The Java language

As I've noted already, Java is based on the C++ language and still looks superficially like C++. As a result, programmers who are already familiar with C, C++, Objective C, Eiffel, Ada, and various related languages should find it relatively easy to learn the language. Sun estimates the required time period to be a couple of weeks; as one textbook author put it, "the wonderful thing about Java is that it is not rocket science to use."

On the other hand, it may not be so easy for the community of business-oriented application programmers, meaning those who are currently programming in "old" languages like COBOL or "new" languages like Visual Basic and PowerBuilder. Languages like Smalltalk and Delphi are somewhere in the middle; they have much of the object-oriented flavor of Java, but the syntax is different enough that it will take a while to digest.

And, as noted earlier, there's another community that will find Java quite difficult: end users and "casual programmers" who have learned how to create HTML pages but who have never learned a formal programming language. That's the primary reason for the JavaScript language that Sun and Netscape announced and that Netscape delivers with Navigator 2.0 in early 1996.

Below I'll describe Java's main components, as well as the components of C++ that Sun deliberately removed when creating Java. I'll also discuss the object-oriented features of the language.

The main components of Java

The main features of Java show many similarities to and some differences from C and C++:

1 2 3 4 5 Page 2
Page 2 of 5