Java and the new Internet programming paradigm

An excerpt from Rise & Resurrection of the American Programmer

One of the most significant technological developments since the publication of Decline and Fall of the American Programmer has been the introduction of a new breed of languages and development tools for creating applications on the Internet and the World Wide Web. The "information superhighway" is the hottest thing in the computing industry today, but when the Internet and the Web first burst on the scene a couple years ago, they seemed completely divorced from the traditional application development community in IT organizations. Many of the frantic discussions of security and firewalls that take place even today make it evident that many IT managers would like to keep it this way.

[Image - cover of book]

In the spring of 1994, with Sun Microsystems' formal announcement of the Java programming language, it became apparent that this comfortable view of the Internet/Web as a phenomenon distinct from traditional application development was about to change dramatically. Internet aficionados were and still are excited by Java's ability to bring live content to the user's workstation. But for traditional programmers, there are far more profound consequences: Just when programmers were getting used to client-server technology and languages like PowerBuilder, Visual Basic, and Delphi, the Java phenomenon promised to change the nature of application development completely. While technical concepts like object-orientation will continue to play an important role in tomorrow's Web-based applications, just about everything else is going to change in this new world. For example, programmers are likely to spend their time building tiny applets rather than large, monolithic applications -- and the marketplace could end up paying for these applets on a "per usage" basis, rather than on the licensing basis so prevalent today. If you're going to ride this new technology wave, you're going to need to change a lot of your assumptions and plans about the tools you'll be using, the development processes you'll be following, and the professional skills of the people in your organization.

I believe that Java represents an enormous opportunity for the North American software industry. As with all of the other technologies discussed in my book, there are no guarantees and no monopolies -- that is particularly true of technology associated with the Internet. Java-related development is going on all around the world, but the concentration of activity is much higher in the U.S. than elsewhere. We may only have a head start of two to three years, but that should be enough to capture a great deal of the market share before the software industries of Western Europe, Asia, and the developing nations begin making serious efforts to catch up.

What is Java all about?

In a nutshell, Java is an object-oriented programming language based on C++ that allows small programs -- or "applets" -- to be embedded within an HTML document. When the user clicks on the appropriate part of the HTML page to retrieve it from a Web server, the applet is downloaded into the client workstation environment, where it begins executing. [Editor's note: Since this text was written, the definition of Java has expanded beyond Web-based applets; Sun expects the language to be used for all sorts of applications, and promises a Java operating system, Java microprocessors, and more -- and now refers to Java as a platform.]

Java's origins go back to 1991, when Sun Microsystems began looking for ways to create platform-independent code to support consumer electronic products. After some initial efforts with C++, the Sun project team abandoned it and created its own language initially called Oak, later renamed Java. Oak first was used to create software for a personal, hand-held remote control device, but when the project team lost a bid to develop a television set-top box for Time-Warner, attention switched to the Web. The Sun project team then built a Web browser, originally called WebRunner and then renamed HotJava, in the Java programming language. The rest, as they say, is history: Sun formally announced Java and HotJava at the SunWorld '95 conference in San Francisco on May 23, 1995.

The relationship among Java programs (or "applets"), the Java-enabled browser, and the Web is illustrated in Figure 1. Users access a Web page and pull it down to their client. In this case, though, the Web page contains an additional HTML tag called "APP," which refers to a Java applet, and that applet can be located anywhere on the Web. If the user's Web browser is Java-enabled (for example, Sun's HotJava browser or Netscape's Navigator 2.0), then the applet is pulled down into the user's client computer and executed within the browser environment.

Figure 1. Relationship between Java applets, Java-enabled browser, the user, and the Web

Java is often described as a "cross-platform" programming language; it's also common to refer to Java programs as "architecture-neutral bytecodes." It has to be this way, of course, because the Web server that delivers the Java applet to the Web client doesn't know what kind of hardware/software environment it's running on. And the developer who creates the Java applet doesn't want to worry about whether it will work correctly on OS/2, Windows, Unix, and MacOS.

The key to Java, as used on the Web, is the notion of executable content, rather than static content. What capability does this provide us? Thus far, most of the demonstrations and examples have involved fairly simple graphics -- a bouncing ball on a Web page, for example. But there are some other examples you can look at, if you have a Java-enabled browser, of course:

  • The Rolling Stones' Web site ( contains animated flags and a puzzle that allows the user to slide squares around to form the "tongue" logo.

  • The NandO Times Web-based news service ( displays a ticker tape of headlines about sports, politics, national news, and world news that scrolls continuously across its primary page. Each of the four categories of news stories is illustrated with a picture; the pictures change in synchronization with the news stories in the ticker tape, thus providing an interesting amalgamation of the best of TV and newspapers.

  • ESPNET SportsZone ( an up-to-date scoreboard of football, baseball, and basketball scores.

  • HotWired ( uses Java to animate its Web pages for the digital version of Wired magazine.

  • Dimension X ( has been working on Iced Java, a 3-D rendering engine.

  • VPRO (http://www.vpro.n1), a public broadcasting organization from Hilvershum, Holland, uses Java to provide an automated, hands-off tour of its Web site.

  • Sun Microsystems ( has a number of Java examples and demos as well. This Web page links to several other important resources about Java; see the references below for details.

The Java environment

The full Java Development Kit contains the following components:

  • The Java compiler, javac, which translates human-readable Java source code to architecture-neutral bytecodes.

  • The Java interpreter, which executes Java programs on the user's PC or workstation.

  • The C header and source file generator, javah and java_g. These are used to generate header files for C, as well as source files for making "methods" (roughly equivalent to procedures or subroutines in other languages) within Java.

  • The Java disassembler, javap, which prints out information about a class file (a file containing a Java applet).

  • The document generator, javadoc, which is capable of generating an HTML file from a Java source-code file.

  • The profiling tool, javaprof, which formats the performance data created if the programmer uses the -prof option in the Java interpreter to obtain statistics on run time and performance.

Simplicity and familiarity

By basing the language on C++, Sun obviously hoped to take advantage of a large installed base of experienced C++ programmers; in so doing, they were able to make use of important features of object orientation, which Microsoft will find far more difficult to do if it continues using Visual Basic as the foundation of its Internet programming technology. (Visual Basic supports the concept of encapsulation, for example, but does not support inheritance or polymorphism.)

Further, as we'll see in the more detailed discussion of the Java language below, Sun has removed several of the more esoteric and troublesome features of C++, such as multiple inheritance and pointer arithmetic. The primary reason for doing this was to ensure robust behavior, but it has also resulted in the creation of a language that's easier to learn and understand. And in the tradition of C++ and other object-oriented languages, Java gives access to existing libraries of tested objects that provide functionality ranging from basic data types to network interfaces and GUI toolkits.

Though experienced programmers may find Java easy to learn, neophytes and users probably won't have the same experience. As Andrew Leonard points out in a recent issue of Web Review:

A more critical question is what effect Java-esque technologies are having on the average individual's ability to use the Net/Web creatively. The online universe is becoming more complex. Is it leaving us behind? Forget about The Future of the Net. Time to switch memes. What about The End of the Net as We Know It? Once upon a time, the World Wide Web was a truly democratic medium. Learning enough HTML to put up a Web page took an afternoon. Anybody could become publisher of their own Webzine. As a petri dish for Do-It-Yourself cultures, the Web offered astonishing potential. That was then. Try learning to write a Java applet in an afternoon. Unless you're already an accomplished programmer, the kind of person who spits out Perl scripts like sunflower seed shells or reads C++ manuals as if they were comic books, you might find yourself moving a bit slowly. And it's not just Java. Creating a 3-D VRML world isn't trivial either. Just mastering all the possibilities of a new version of Netscape before the next upgrade rolls along is an exhausting challenge. And so on. The Web is stratifying. A priesthood of technonerds -- a Webmaster aristocracy pulling down high salaries and wielding great power -- is emerging.

The solution, I believe, will eventually involve two "levels" of Java language: the professional level and a "light" level for users who need to create simple, one-line applets to control the behavior of their HTML pages. Netscape has already taken the initiative, with the scripting language built into Navigator 2.0. And in December 1995, Netscape and Sun announced a joint effort to continue this work in the form of a scripting language called JavaScript.

Security and robust behavior

Security and robustness are obviously important in the distributed environment represented by the Internet; if you download a Java applet from a Web server, for example, you really don't want it to run amok on your computer and delete all the files on your hard disk. This is not as far-fetched as it might sound, because the incorporation of Java applets into Web pages means that you may be invoking computer programs written by people anywhere in the world, located anywhere on the Web. Indeed, once you begin using a Java-enabled browser, you're automatically at risk since you don't know at the moment you decide to retrieve a Web page (say, by clicking on a hyperlink within an existing page being displayed on your computer) whether it will contain embedded Java applets.

Sun has addressed this concern by imposing severe constraints on the Java programming language, as well as extensive run-time checking in the interpreter located inside the Java-enabled browser. The Java language, for example, forbids the use of address pointers and pointer arithmetic found in C and C++; this eliminates a large class of innocent errors that might otherwise plague the user of Java applets. In addition, the following steps have been taken to increase the level of security and robust behavior:

  • 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++:

  • Primitive data types: Java supports numeric data types (8-bit byte, 16-bit short, 32-bit int, and 64-bit long); there is no unsigned specifier for integer data types. The 8-bit byte data type replaces the old C/C++ char data type. Real numeric types are 32-bit float and 64-bit double; these types, and their arithmetic operations, are as defined by the IEEE 754 specification.

  • Character data types: Java's char data type is different from traditional C; it defines a 16-bit Unicode character, which defines character codes in the range of 0 to 65,535. The Unicode character set facilitates internationalization and localization of character codes, in keeping with the worldwide nature of the Internet.

  • Boolean data types: Java adds a Boolean data type, which assumes the value true or false. Unlike common programming practice in C, a Java Boolean type cannot be converted to any numeric type.

  • Arithmetic and relational operators: All of the familiar C and C++ arithmetic operations are available. In addition, Java adds the ">>>" operator to indicate an unsigned (logical) right shift; it uses the "+" operator for string concatenation.

  • Arrays: Java allows the declaration and allocation of arrays of any type, and the programmer can allocate arrays of arrays to achieve multidimensional arrays. To get the length of an array, Java provides a length() "accessor method." Access to elements of an array can be accomplished with normal C-style indexing, but the Java run-time interpreter checks all array accesses to ensure that their indices are within the range of the array. Note that the familiar C concept of a pointer to an array of memory elements does not exist in C; arbitrary pointer arithmetic has also disappeared, which means that programmers won't be writing code that marches right past the end of an array, trashing the contents of innocent areas of memory and causing program failures in various unpredictable ways.

  • Strings: The string class is for read-only objects, and the StringClass class provides for string objects that the programmer wishes to modify. Note that strings are Java language objects, not pseudoarrays of characters as they are in C; however, the Java compiler understands that a string of characters enclosed within double quotes is to be instantiated as a String object. As noted earlier, the "+" supports concatenation of strings; the length() accessor method can be used to obtain the number of characters in the string.

  • Multilevel breaks: Java has no goto statement, but it does contain a break and continue statement, combined with the notion of labeled blocks of code, to provide the programmer with a mechanism to exit from multiple levels of nested loops. This is in contrast to C, where the continue statement only allows the program to escape to the immediately enclosing block of code. Java's break label and continue label statements are equivalent to the next label and last label statements in the Perl programming language used by many Internet application developers.

  • Memory management and garbage collection: Java does not support the malloc and free commands, with which C and C++ programmers have traditionally managed the allocation of memory within the programs. Java has a new operator that allocates memory for objects; the run-time system then keeps track of the object's status and automatically reclaims memory when objects are no longer in use. Because Java does not support or allow memory pointers, all references within a program to allocated storage (for example, to objects that have been created within the program) are made through symbolic references or "handles." The Java memory manager keeps track of references to existing objects, and when an object has no more references to it, then it becomes a candidate for automatic garbage collection. The Java run-time system performs background garbage collection during idle periods on the user's workstation.

  • Integrated thread synchronization: Java provides multithreading support at the syntactic (language) level and also via support from the run-time system and thread objects.

Features removed from C++

The discussion above has already illustrated some of the features that Sun removed from C and C++ when it created Java. Here's a more complete list:

  • Typedefs, defines, and preprocessors have been eliminated: There is no typedef, no #define statement, and no preprocessor. As a result, there is no need for the header files one typically sees in C and C++. Instead, the definition of other classes and their methods are included within the Java language source files. This is more than a cosmetic trick: In order to understand the typical C/C++ program, you must first read all of the related header files, #defines, and typedefs to understand the overall context of the program.

  • Structures and unions have been eliminated: Java achieves the same effect by allowing the programmer to declare a class with appropriate instance variables. C++ might have followed the same approach, but for obvious reasons, chose to maintain compatibility with C; the Java designers deliberately avoided committing themselves to C/C++ compatibility when they felt it was inappropriate to do so.

  • Functions have been eliminated: Anything the programmer can do with a function can be accomplished by defining a class and creating methods for the class. Thus, the Java designers have tried to eliminate the practice of creating "hybrid" mixtures of OO and procedural programming style.

  • Multiple inheritance is not supported: Only single inheritance is allowed. The desirable features of multiple inheritance are provided with interfaces in Java, which are conceptually similar to what's found in Objective C. An interface is a definition of a set of methods that one or more objects will implement; they contain only the declaration of methods and constants.

  • Goto statements have been eliminated because the most legitimate uses of the goto have typically been to exit from the innermost part of a loop, and that facility has been provided with the break and continue statements.

  • Operator overloading has been eliminated, which means that there are no mechanisms for programmers to overload the standard arithmetic operators. Where this kind of familiar C/C++ activity needs to be carried out, it can be accomplished in a more straightforward way by declaring a class, appropriate instance variables, and appropriate methods to manipulate those variables.

  • Automatic coercions of data types have been eliminated on the premise that if the programmer wants to "coerce" a data element of one type into a different data type, it should be done explicitly with a "cast" operation. Thus, the fragment of code shown below:

    int sampleInt;
        double sampleFloat = 3.1415926535;
        sampleInt = sampleFloat;

    would result in a compiler error because of the possible loss of precision. To accomplish this properly would require the programmer to write the code in the following fashion:

    int sampleInt;
        double sampleFloat = 3.1415926535;
        sampleInt = (int)sampleFloat;
  • Pointers and pointer arithmetic have been eliminated since they are one of the primary causes of bugs in programs. (Pointers in a data structure are roughly equivalent to goto statements in a control structure.) Because structures are gone, and arrays and strings are represented as objects, the need for pointers has largely disappeared.

Object-oriented features

With the exception of primitive data types, everything in Java is an object -- and even the primitive types can be encapsulated within objects if necessary. Java supports four fundamental aspects of object-oriented technology:

  • Encapsulation: Instance variables and methods for a class are packaged together, thus providing modularity and information hiding.

  • Inheritance: New classes and behavior can be defined in terms of existing classes.

  • Polymorphism: The same message sent to different objects results in behavior that is dependent on the nature of the object receiving the message. If you send a "move" message to an "animal" object, you don't want to be concerned with the nature of the animal you're talking to; if it's a bird, it should be smart enough to carry out the "move" by flying, whereas a snake would respond to the same message by wriggling, a rabbit would hop, and so on.

  • Dynamic binding: As implied above, a programmer doesn't want to be required to specify, at coding time, the specific type of object to which a message is sent; the type resolution needs to be done at run time. This is especially important for Java, because objects (Java applets) can come from anywhere on the network and may have been developed by anyone.

Java follows the C++ tradition of supporting "public," "private," and "protected" variables; the default (if the programmer doesn't specify one of these three) is "friendly," and indicates that the instance variables are accessible to all objects within the same package but inaccessible to objects outside the package. Like C++, the programmer can declare constructor methods that perform initialization when an object is instantiated from a class. But rather than the destructor method that one finds in C++, Java has a finalizer method; this does not require (and does not allow) the programmer to explicitly free the memory associated with the object when it's no longer used.

Like many object-oriented languages, Java supports class methods and class variables -- that is, methods and variables associated with the class as a whole, rather than instances within the class. Class methods can't access instance variables, nor can they invoke instance methods. By definition, a class variable is local to the class itself, and there is only a single copy of the variable, which is shared by every object that the programmer instantiates from the class.

Also, Java supports the concept of abstract classes and abstract methods. This allows the programmer to create a "generic" class, defined in the form of a template. By definition, the programmer cannot instantiate objects from the abstract class; objects can only be instantiated from a subclass of the abstract class, and it's only within those (concrete) subclasses that the defined methods can actually be used.

Java comes with several libraries of utility classes and methods; these include:

  • java.lang: a collection of language types that are always important to a compilation unit. This library contains the definition of object (the root of the entire class hierarchy in Java) and Class, plus threads, exceptions, and wrappers for primitive data types, and various other fundamental classes.

  • roughly equivalent to the Standard I/O library in most Unix systems; it contains classes to access streams of data and random-access files. An associated library,, provides supports for sockets, Telnet interfaces, and URLs.

  • java.util: contains utility classes such as Dictionary, HashTable, and Stack, as well as Date and Time classes.

  • java.awt: an abstract windowing toolkit (AWT) provides an abstract layer enabling the programmer to port Java applications from one windowing system to another. The library contains classes for basic interface components such as events, fonts, colors, buttons, and scrollbars.

Java multithreading

The Java language and run-time environment support the concept of multithreading, so that Java applets can operate concurrently to play music, run animations, download a text file from a server, and allow the user to scroll down a page. Multithreading is a practical way of obtaining fast, straightforward concurrency within a single process space (that is, taking into account that there may be programs other than Java and the Java-enabled Web browser running on the user's platform, and the user's operating system may also be attempting to coordinate background printing, spreadsheet recalculations, and various other processes).

The Java library provides a class that supports a collection of methods to start a thread, run a thread, stop a thread, and check on a thread's status. Java's approach is sometimes called "lightweight processes" or "execution contexts"; it's modeled after the Cedar/Mesa systems implemented by Xerox PARC, which in turn are based on a formal set of synchronization primitives developed by Professor C.A.R. Hoare in the mid-1970s.

Java's threads are preemptive in nature, and the threads can also be time sliced if the Java interpreter runs on a hardware/software platform that supports time slicing. For environments that don't support time slicing -- such as the Macintosh System 7.5 operating on the computer I used to write this book -- a thread retains control of the processor once it has begun unless a higher-priority thread interrupts. This means that for compute-bound threads, it behooves the programmer to use the yield() method at appropriate times and places in order to give other threads a chance to operate.

At the language level, methods within a class that are declared synchronized are not allowed to run concurrently; such methods run under the control of monitors to ensure that their instance variables remain in a consistent state. Every class and instantiated object has its own monitor that comes into play if necessary. When a synchronized method within a class is entered, it acquires a monitor on the current object; when the synchronized method returns (exits) by any means, its associated monitor is released and other synchronized methods within that object are then allowed to begin executing. Thus, if programmers want to ensure that the classes and methods within their Java programs are "thread safe," then any methods that have the ability to change the values of instance variables should be declared synchronized; this will ensure that only one method can change the state of an object at any time.

Security mechanisms in Java

Security is one of the big concerns on the Internet these days, and the designers of Java have taken it into account in their definition of the programming language, in the compiler, and in the run-time system. As we've already seen, the Java language has eliminated memory pointers -- which means that programmers can't forge pointers into memory, one of the typical sources of security breaches. In addition, the run-time binding of object structures to physical memory addresses means that a programmer can't infer the physical memory layout of a class simply by looking at its definition.

However, it's not enough to make a more restrictive language definition and enforce it with a compiler. The problem is that a Java-enabled Web browser is importing applets from anywhere on the network, including, potentially, applets that "look" like Java but might have been created by a bogus compiler or even hand-coded by a hacker. Thus, to ensure security, the Java run-time interpreter cannot trust the incoming code and must subject it to a verification process to ensure that:

  • The incoming code doesn't forge memory pointers.

  • The incoming code doesn't violate access restrictions.

  • The incoming code accesses objects in the manner that they have been declared (for example, OutputStream objects are always used as OutputStreams and never as anything else).

The complete process in the creation, compiling, loading, verification, and execution of a Java program is shown in Figure 2. The key point here is that the Java bytecode loader and bytecode verifier make no assumption about the primary source of the bytecode stream that the user wishes to execute; it may have come from the user's local file system (that is, on the user's own workstation), or it may have come from anywhere on the Internet.

Figure 2. Implementing security in Java

When the bytecode verifier is finished with its examination, the run-time interpreter can be sure that there will be no operand stack overflows or underflows, that all object field accesses will be legal (that is, appropriate usage of private, public, and protected methods and instance variables), and that the parameter-types of all bytecode instructions are correct. As a result, the interpreter does not have to check for stack overflows or for correct operand types while the Java applet is executing -- and it can therefore run at full speed without compromising reliability.

While a Java applet is running, it may request that a class, or set of classes, be loaded into the user's computer -- and, of course, these new classes could also come from anywhere on the Internet. The new incoming code also has to be checked by the bytecode verifier, but there's one more level of protection that needs to be explained, involving "name spaces."

Most programmers understand this concept from their previous work, but for the nonprogrammers reading this, a brief analogy will help explain the concept. Suppose that you have a brother named Fred and that your spouse also has a brother named Fred. At the dinner table, your spouse casually says, "Oh, by the way, Fred called today to say hello." The question is: Which Fred? It depends on whether you're talking about the "name space" of your own family or that of your spouse. In the case of Java, when we refer to a class name, we need to know which name space it's associated with.

The environment seen by a thread of execution running Java bytecodes -- for example, a typical Java applet -- can be visualized as a set of classes that are partitioned into separate name spaces. There is one name space for classes that come from the user's local file system, and a separate name space for each network source of Java bytecodes. When a class is imported from across the network, it is placed in the private name space associated with its origin. Whenever a Java class refers to another class, the Java run-time interpreter first looks for the class within the name space of the local system (where the built-in classes referred to above reside), and then in the name space of the referencing class. As a result, it's impossible for an imported class to act as an "imposter" of a built-in class. And the built-in classes can never accidentally reference classes within imported name spaces -- the Java interpreter requires them to reference such classes explicitly. Similarly, classes imported from different origins (for example, attached to different Web pages) are kept separate from each other.

Final comments on the Java language

One reason for giving you all of this detail about the Java language is to impress upon you that it's obviously a serious, heavy-weight programming language. This is not something as simple as the HTML formatting syntax that someone can pick up in an hour or two; it's not intended for casual amateurs.

But by the same token, the serious programmer doesn't want a casual programming language for building industrial-strength Internet applications; to implement secure, robust, multithreaded, object-oriented, distributed applications requires something more sophisticated than the current forms of such popular languages as Visual Basic, PowerBuilder, and Delphi. And it's interesting to see that in many ways, it doesn't require more than C++, but rather, less than C++.

Note that Java can be used to write an entire application, not just tiny applets embedded within HTML. The most obvious example is HotJava: it's written in Java. I expect that many of the tool vendors will begin using Java for their own browsers and development tools -- and it's conceivable that some of the "conventional" applications could migrate to Java. I can easily imagine a scenario in which my word processor and spreadsheet become Java-enabled applications. [Editor's note: Indeed, Corel already has shown demos of a java version of WordPerfect.]

Alternatives and competitors

If you aren't prepared to learn Java yourself or to convert all of your existing Internet applications to Java, what are your alternatives? At the moment, there seem to be three or four, including products from Microsoft, Borland, Texas Instruments, and ParcPlace.

Of these, Microsoft is clearly the most significant. Whatever Microsoft does on the Internet will have an impact on the rest of the vendors. Hence, it's significant that Bill Gates announced in December 1995, as part of a massive Internet publicity blitz, that Microsoft had signed a letter of intent with Sun Microsystems to license Java. The company also announced it was introducing a new language called Visual Basic Script, which is upwardly compatible with Visual Basic 4.0 and which will take advantage of Microsoft's OLE as a technology for distributing objects (in a fashion similar to applets) across the Internet.

The announcement came just as this book was being finalized, and as such, it's far too early for me to assess the full significance of Microsoft's Internet strategy. But the key points to keep in mind at this early stage [Editor's note: as of late 1995] are these:

  • Java has all the attention and the support of the media, as well as the momentum of some 30 companies that have licensed the technology, but there is little or no installed Java technology aside from the 50 to 100 sample applets that one can download from Sun's Web page. This is likely to change rapidly in 1996, and it will be interesting to see how much momentum the language is able to create in the marketplace.

  • Meanwhile, Microsoft has an enormous Visual Basic installed base, especially in the business community; estimates have been as high as three million copies of Visual Basic in mid-1995. The business application development community has never been fond of C++ and might be more inclined to leverage its investment in Visual Basic applications than to invest in additional training and development to adopt the Java technology.

  • While OLE is obviously a full-fledged technology and while Visual Basic 4.0 is now a fairly robust language, neither of these two cornerstones of Microsoft's Internet technology were actually designed and developed with the Web in mind. What's impressive about Java, as I've pointed out here, is the level of effort Sun has gone to, to make it an effective tool for robust, secure applications on the Web. Visual Basic Script might compete effectively with JavaScript, and the marketplace for these lightweight scripting languages might turn out to be much larger than the marketplace for professional Java applications. But if you do want to build professional, industrial-strength applications to run on the Internet, you'd better look closely at the details of Microsoft's approach to see how it will handle security, fail-safe operations, and so on.

  • While Microsoft has licensed the Java technology, it's not yet clear how much support it'll actually provide. The announcement indicates that Microsoft will be adding enhancements to Java to make it more efficient for the Windows 95 environment, but that the changes will be given back to Sun, which continues to own the technology. My guess is that Microsoft has to pay lip service to Java in order to avoid being characterized as an "outsider" and also to cover its bases if Java does end up dominating the marketplace. But I suspect that the company's primary interest will be to ensure that Java applets can somehow work compatibly with Visual Basic, and that Visual Basic is where Microsoft will continue investing its efforts.

Meanwhile, Borland will build a high-performance, visual rapid application development environment for creating Java applications. The product, code-named Latte, will be developed in Java and is intended to radically increase the speed of developing Java applications. Borland plans to begin rolling out stages of Latte in 1996; see the Resources section for the Borland Java Web site, which includes a variety of Java-related information.

Also, Texas Instruments has announced a new version of its Composer development environment, which will allow Web browsers to interact with Composer-built server components, using the TI Arranger technology as the Web gateway. This doesn't change the overall paradigm of Internet applications in the fashion that Java does, because the "intelligence" of the application will still be located on the server, but it does bring higher-level analysis and design tools into the picture. See the Resources section for TI's WWW address for more information.

Another example comes from ParcPlace-Digitalk, the vendor best known for its various Smalltalk products and tools. At the Internet Expo conference in November 1995, ParcPlace announced a new product called VisualWave for "live" Web applications. It consists of an application development environment, based on Smalltalk, that will automatically generate the HTML and CGI interface logic necessary to run a Web application. Again, this is more like the traditional form of Web application development than the Java approach, but it does have the advantage of providing a single, integrated graphical environment with which developers can create an application to deploy on the Web. And because VisualWave generates the Web interface automatically, it's possible to develop applications that can run both as a client and as application servers for use by Web browsers. This allows the developer to choose the appropriate deployment platform of an application without changing source code -- but note that the components of the application don't move dynamically from the server to the browser during run-time execution, as would be the case with Java. For more information, see the Resources section for ParcPlace's Web URL.

A final note on alternatives: As the manuscript for this book was being finalized, I received an e-mail message from software engineering consultant Bob Munck, who points out that Intermetrics has targeted their AdaMagic compiler to generate Java bytecodes (which is also a good illustration of the need for the SIGAda Working Group to encourage the use of Ada for Web applets and applications). The compiler is running and is very close to being validated.

Munck argues that Ada95 has several advantages over Java, including being an ISO standard with a large number of existing compilers and development systems, as well as having a great deal of legacy code in Ada83. I'm not convinced that anyone outside the U.S. defense establishment cares very much about Ada, but it is interesting to consider that an entirely different source language -- and one that has been just as carefully designed to handle secure, robust, concurrent execution of processes -- might be the starting point for Internet applications. For more details, contact Munck at

Strategic implications

Many articles in the trade press during the summer and fall of 1995 proclaimed that Java is the beginning of a "revolution" in software. Having watched "silver-bullet" revolutions like case technology and pen-based computing come and go during the past decade, I'm always a little wary of such euphoria. Nevertheless, it's hard not to get excited by all this -- and there certainly are some strategic implications that you should be thinking about:

  • Java-enabled Web pages are more interesting than those created without Java, so if your company is planning to use the Web to attract potential customers to your products and services, you need to be aware that your competitors will probably be using Java to create a more tempting and interesting environment in which to participate. Judge for yourself: Take a look at some of the Java demos listed above to see what kind of competitive difference they're likely to make in your world.

  • Java may replace Perl and CGI interfaces, so if you're just now beginning to explore the idea of Web pages connected to application functionality, you should seriously consider jumping right over the current generation of tools like Perl. This will be more of a problem for the organizations that have already invested a lot of time and effort in Perl scripts. But remember, it could be worse: It's not as bad as all those tens of millions of lines of COBOL legacy code that we're trying to maintain.

  • Java facilitates a new form of client-server applications; this may turn out to have the largest impact on many of today's conventional IT organizations. Rather than building your next application with conventional client-server tools and programming languages like Visual Basic or PowerBuilder, why not use a Java-enabled Web browser for the client, and an internal Web server as the application server, with connections to the data server on your enterprise mainframe?

  • Java could seriously decrease the interest in languages like Visual Basic and PowerBuilder, to the extent that those languages are being used for conventional client-server development projects today. Of course, Microsoft is working to make Visual Basic a Web-oriented language, and Powersoft will presumably do the same. But by the time they do so, it may be too late: Java may have captured the "mind share" of the leading edge of Web-oriented application developers.

  • Java may renew the interest in C++; I'm one of the people in the computer field who has described C++ as "the assembly language of the 90s," largely because of the problems associated with language features that Java has eliminated. Maybe Java will come to be the equivalent of "safe sex" for the C++ programmers of the world.

  • Java, together with the Web, may begin to minimize the importance of specific hardware/software environments. This is the result of the architecture-neutral approach taken by Java, together with a similar philosophy from Netscape, which owned most of the Web browser marketplace as this book was being written. Given the inertia that exists in the marketplace, I certainly don't think this will result in Intel and Microsoft going bankrupt tomorrow morning, but it could well take a lot of pressure off the beleaguered Macintosh owners around the world, and it could also fuel a renaissance in Unix and Unix-oriented hardware platforms. And even if Microsoft and Intel don't collapse entirely, the notion that those two companies might no longer "own" the desktop marketplace could be a staggering change in today's industry.

  • Applets could lead to the end of "fatware" and could change the distribution mechanism for software products, which could also trigger some enormous changes in the economics of the software industry. Imagine, for example, what the world would be like if your word processor and spreadsheet program were written in Java; for starters, you wouldn't have to buy it in a shrink-wrapped box, because you could download it from the Internet, with assurances that you always had the latest version. And there would be a much greater chance that you could customize the features and components of the word processor in ways that you can't easily do today. If you don't like the spellchecker on your Brand-X word processor, for example, why not treat it as an applet and replace it with a different spellchecker applet available from a third-party source? Companies like Microsoft, Novell, and Lotus who currently make a lot of money selling us "office suites" with 80-plus megabytes of software (much of which we don't need or want but are forced to buy anyway) would find it a radically different world.

  • Java could change the economics of paying for software; the software industry today is based on the concept of entire applications delivered to the marketplace in shrink-wrapped boxes for a fixed one-time cost, for which customers are given a license that allows them to use the software forever on a single platform. As we've already seen, Java makes it possible to market smaller, bite-sized pieces of functionality -- but more importantly, Java makes it possible to sell one-time usage of a piece of software. This one-time usage could be defined for a single transaction, or for a single session during which the user is connected to a Web server. Software guru Brad Cox argues that such a model will be the catalyst that spawns a thriving industry of software component-builders. (See References.) It's far too early to tell whether this will actually happen, though it's fairly clear that it requires a completely different business model than the one currently used by software product vendors. The companies most threatened will be the ones that sell relatively small products -- software utilities and games, for example -- though those companies may be nimble enough to change their way of doing business. It will be much more difficult for the larger, more established software vendors to respond to this new approach.

Summary and conclusions

While Java is exciting, it's important to remember that it's also very new. However, the potential for Java is so enormous -- in terms of its impact on the overall computing paradigm -- that an organization would have to be suicidal to ignore it. Of course, your organization may not see it that way, especially if it has a great deal of its culture invested in current client-server technologies or in ancient technologies like mainframes and COBOL. Over the next five years, I expect to see most conventional IT organizations slowly moving into the world of Web-based application development, but they'll probably do it through extensions of existing technology (for example, with products like TI's new version of Composer or ParcPlace's VisualWave). But as you make your plans for this new world, remember to make the distinction between the "Java paradigm" -- where live-content applets are dynamically sucked down into the user's workstation for execution -- and the old-fashioned paradigm of building static applications for a client-server architecture that happens to use a Web browser for a client and a Web server as a gateway into the traditional storehouse of enterprise applications and databases.

Whatever the organization decides to do about the Java paradigm, my advice to you -- as a professional programmer, software engineer, or application developer -- is to invest the time and effort to learn this technology. The elimination of the "social contract" between employer and employee means that it may be necessary for you to invest your own time and money to become competent in Java. If you decide not to, you might be able to continue earning a living writing PowerBuilder programs; but you also run the risk that your organization will surprise you one day by telling you that your job has been outsourced to someplace in Guatemala or Greece, where equally competent PowerBuilder programmers work for a fraction of your salary.

There's another aspect of the Java paradigm that you need to think about. As I suggested above, it may be the catalyst that generates a booming cottage industry of applet builders. As a result, you may find that it's possible to create your own "cottage business," rather than working in a large organization with hundreds of other developers. Indeed, it's possible that you may find it necessary to do so in order to maintain your current income. We can already see a small form of this with Visual Basic, which supports an industry of nearly a thousand tiny, cottage-industry companies building VBX components. In the past, one of the big obstacles to this kind of business was the cost and difficulty of marketing one's products. But the Internet, as we all know, is not only an environment for software development, it is also a wonderful mechanism for marketing one's wares via the Web.

The idea of a nation of programmers working from their individual cottages is perhaps a bit extreme; obviously, there will still be room for corporate IT development, as well as conventional software-product builders. But the scenario I've described here does suggest that the conventional IT organizations and Silicon-Valley shrink-wrap software-product companies might not continue to be a growth industry over the next five to 10 years. By analogy, mainframes haven't disappeared, but most of us don't consider it a growth industry. Similarly, COBOL hasn't disappeared, and it still forms the basis of employment for some two million programmers in the U.S.; but even with the recent arrival of object-oriented COBOL, it's hard to imagine it as a growth industry. What I'm suggesting here is that client-server technology and all of the currently popular tools and languages for traditional client-server development may also cease to be a growth industry within the next couple of years. The Java paradigm may well replace them.

In the extreme case, this paradigm shift could put all of the big software companies out of business. As I said earlier, I seriously doubt that Microsoft and Oracle and Computer Associates and the other big software companies will go out of business, but for some of them, the paradigm shift may turn out to be nearly impossible for their existing culture to support, just as IBM found it difficult to switch from a mainframe culture to a PC culture. But if it's hard for the American big-company culture to change, it's also hard for the big-company culture in Europe, Asia, Africa, and South America. It's easier for the culture of a small company to change, and it's even easier for a completely new culture to emerge in a start-up company. There will be many such start-up companies created by the Java paradigm, and several of them will be in places outside the U.S. To participate in this paradigm shift requires a combination of infrastructure (for example, easily available 28.8-kilobyte access to the Internet), technology (a Pentium-based machine in one's own cottage), and an entrepreneurial spirit. And while the U.S. doesn't have a monopoly on these items, it does have a head start. I see it as one of the best things that has happened to the software industry since the introduction of the PC and MS-DOS in the early 1980s.

Ed Yourdon is a consultant with more than 30 years of experience, as well as the developer of structured-analysis and object-oriented software engineering methodologies used by computer professionals around the world. He is the editor of three industry journals and newsletters, has written 21 books, and is a keynote speaker at many major computer conferences. His work takes him to over a dozen countries each year, which provides the global perspective in Rise and Resurrection of the American Programmer.

Learn more about this topic

  • Web sites
  • Books
  • December, John. Presenting JavaAn Introduction to Java and HotJava. (Indianapolis, INSams.Net Publishing, 1995).
  • Tittel, Ed, and Mark Gaither. 60 Minute Guide to Java. (Foster City, CAIDG Books Worldwide, Inc., 1995).
  • Articles

Join the discussion
Be the first to comment on this article. Our Commenting Policies