Java: Cornerstone of the Global Network Enterprise?

by Bryan Youmans
Virginia Tech
CS 3604
Spring 1997

"[Java is the] Cornerstone of the networked enterprise"

Thus proclaims Sun Microsystem's JavaSoft, the company responsible for the creation, design, and distribution of the Java programming language. With the advent of the World Wide Web and the opening of the Internet to millions of people worldwide, a revolution is taking place which will affect the way the world conducts business, students research, and everyone gathers information. This has been a cumbersome and treacherous, if inevitable, process due to the vast array of different and incompatible hardware platforms and the operating systems which run upon them. Until now: the creation of Java, a programming language which produces platform independent applications and includes many forms of security built in, has and will continue to revolutionize the way information is transferred across the lines of communication which interconnect our world.

A Brief History of the Java Language

The development of the Java language began as a response to a letter written in 1990 to the CEO of Sun Microsystems. Patrick Naughton, a disgruntled Sun software engineer, detailed in his letter the many reasons he was leaving Sun to work for NeXT; chief among these complaints was the confusion and frustration he and his co-workers felt when programming which stemmed from the huge assortment of application programming interfaces (API's) which Sun supported. Shaken by Naughton's keen assessment of the problems their software division faced, Sun's management commissioned Naughton, Bill Joy, James Gosling, and three others to form a research group to create something new and exciting which alleviated this problem.

The team, codenamed Green, set for themselves the goal of creating a single operating environment, both processor and the software to run upon it, which could be used by all consumer electronic devices, from computers and video game machines all the way down to remote controls and VCR's. Their vision was to enable interactivity between all such devices, as well as to speed development and reduce the cost of implementing new features through the use of a single, small core operating environment. After much research and testing, the result was a simple object-oriented programming language named Oak, after the tree which grew out the window of Gosling's office (although other stories abound).

After many months of testing and tweaking Oak, the designers developed a small hand-held device which featured an easy-to-use, graphic-intensive and appealing interface called "*7". The user's guide and helper for this device was an animated figure named Duke, who later became Java's official mascot. At this point, Sun made Green its own company and changed its name to First Person. The company began searching for a market for its unique product; after deals with companies such as 3DO and Time-Warner fell through in the interactive television area, the outlook for the fledgling company seemed bleak.

Then in 1993 the National Center for Supercomputing Applications (NCSA) released Mosaic, an application which allowed users to easily and graphically access portions of the previously arcane, text-based Internet. Within a year, this visually-based, readily accessable network of Internet sites known as the World Wide Web had grown from a mere research project into a revolutionary medium to transmit ideas and data. The number of web-sites, or areas accessable by a web-browser such as Mosaic and its descendants (most notable among these being Netscape), was growing at a phenomenal rate.

In 1994, the First Person team decided to adjust its design and began developing a "language based operating system" to enable online multimedia software. In a most unusual, but increasingly common and Internet-savvy, move the company also decided to give the source form of the Oak language away over the Internet. Renamed Java by Sun, this new language enabled users to produce programs named applets which could be transmitted and run over the Internet, a somewhat different end product from what was originally envisioned back at the beginning of the decade. Although Java can produce stand-alone applications, it is its Internet-spanning ability that has brought it to the forefront of the modern computing stage. The final piece to the puzzle, somehow enabling browsers to execute these new Java applets, was provided in 1995 when Sun produced its HotJava web browser and allowed Netscape to support the Java language as well.

JavaSoft, the current name of the company which oversees the development of the Java language, was founded in January of 1996, and a few months later released the Java Development Kit (JDK) version 1.0. The newest version, version 1.1, is scheduled to be released sometime soon in the first or second quarter of 1997. The result of the entire project is the Java programming language: a small-instruction set, object-oriented, interpreted language. Actually, users can compile Java code directly into stand-alone executable applications, but its real power lies in its ability to produce machine-independent bytecodes, low-level instructions which can be placed on a server and transferred over networks to client machines. Once transferred, these bytecodes are allotted a secure space on the client machine through the web-browser in which to run; the Java Virtual Machine (the browser's Java run-time environment) translates these architecture-neutral bytecodes into machine-specific code, which is then tested and executed. This form of network distributed program is called a Java applet, and this is the weapon with which Sun is hoping to revolutionize the computing and information-processing world.

Language Design Goals - an Overview

Originally, C++ was intended to be used for the Green project, but it soon became apparent that problems existed, initially with the compiler technology, but later whole sets of problems developed which were best avoided by simply designing a new language that was familiar yet simpler than C++. Familiarity to C and C++, which most programmers today are at least somewhat knowledgeable of, was a major design consideration, and makes the language more comprehensible to as large a group of modern programmers as possible. Yet, while retaining the look of C and C++, the development team wanted to make Java more simple to ease the programming burden and reduce need for extensive and esoteric programmer training. Java's designers achieved the desired simplicity by removing many rarely used, confusing, and redundant features of C and C++

Some of the similarities to C++, which help ease the migration to Java and reduce the learning curve, include: keeping the low level syntax nearly the same, and following C/C++ closely in the basic set of primitive data types and arithmetic/relational operators which are supported; it is object-oriented like C++; and it is statically-typed to allow extensive compile-time checking, but goes further by eliminating the loopholes C++ inherited from C. Also, the performance of Java's interpreted bytecodes, once converted to machine-language, was found to be almost indistinguishable from C/C++'s performance (the standard benchmark for fast performance).

However, by simplifying the language model inherited from C++, the designers have eased learning the new language and helped to facilitate quicker programming. Many of the aspects eliminated from C++ and some new features added to Java emphasize early bug detection during development. By removing confusing, unused, and redundant C/C++ mechanisms, developers can more easily read and maintain someone else's code. This is also aided by the fact that no preprocessing is done; all definitions and information for classes and their methods exist in the Java source files. Readability is also increased through the elimination of user-defined operator overloading.

Some object-oriented designers feel that multiple inheritance is unneeded and reduces the readability and comprehension of code; Java eliminates outright multiple inheritance and its problems and replaces its functionality with interfaces (basically a non-instantiateable class). Any type coercion which results in a loss of precision must be accomplished through explicit casts. Also, Java has no pointers, at least none that programmers can manipulate. This has many effects: programmers can't corrupt memory by referencing a pointer out of an array bound (array bounds are checked by the Java run-time system); it increases the reliability of Java programs by eliminating what some estimate to account for 50% of software bugs; there is no memory leakage due to dangling pointers; and complex pointer arithmetic is removed, making programming easier.

Java is also more purely object-oriented than C++. C++ dilutes the purity of the object-oriented paradigm by allowing the mixing of C-style functions with object-oriented classes and methods, but Java does not allow functions, only classes and their methods. This also enforces the stricter encapsulation and information hiding that is the foundation of the object-oriented paradigm. Java also fits distributed client-server applications better by enforcing the encapsulated message-passing paradigm, and produces cleaner and more portable code than C++.

Unlike many other conventional languages, Java supports system managed memory allocation/de-allocation. Java contains an automatic garbage collection which runs as a low-priority background thread, helping increase performance by allowing the interpreter to run at full-speed without needing to continually check the run-time environment. This automatic garbage collection, being an integral part of the design of the Java run-time environment, results in an easier programming task and better performance than when explicit memory management is required. Java's memory management model, with its lack of pointers and pointer-arithmetic, immediately eliminates whole realms of programming errors that plague most C and C++ programs. Java's memory model eliminates the possibility of overwriting memory and corrupting data. Because it uses true-arrays, subscript checking is possible.

Java is also more robust and secure than C++. Java provides both extensive compile-time type checking as well as run-time checking. C++ inherits many loop-holes from C in regards to compile-time checking, mostly in method and procedure declarations. Java does not allow C-style implicit declarations, as C++ does, thus providing more better compile-time checking. Any reduction of errors results in faster product distribution and less maintainance. Java also incorporates many security features, both in the language itself and in the run-time environment, which protects applications written in Java from being harmed by external hostile code, and protects client-systems from being intruded upon by those Java applets they have downloaded and executed. Because the language in its Internet-based form is interpreted, this maximizes its portability and dynamic capabilities by generating architecture neutral bytecodes which will execute on any platform for which a Java-enabled web-browser exists. The interpreted nature of Java results in a faster development cycle because the link-phase is simpler and quicker than in a typical compiled environment.

One difference between Java and C/C++ which does not simplify programming, at least for beginners, is the multi-threaded capabilities and parallel-computing nature of Java. C/C++ programmers may find it more difficult to write in this type of environment than the conventional single-threaded style. However, the integration of these multi-threaded components, such as Mesa-style monitors, into the language itself make them easier to use, more robust, and more responsive in interactive settings on well-equipped platforms.

Overview of Security Components

One problem which has plagued the Internet as a medium for conducting business and accessing the world has been the ease with which hostile users can steal private information or sabotage other's computers and entire networks. Indeed, researcher's at M.I.T. cracked Netscape 2.0's encryption codes within a day; many other horror stories abound which relate the relatively low level of safety and security facing the networked world of today. The designers of Java, eager for their new programming language to become the foundation for networked communication and information retrieval, knew they must incorporate many forms of safety measures into their product if it was to succeed as a serious business tool.

The Java Virtual Machine protects the user from hostile, malicious, and potentially damaging code through the use of a hierarchy of interrelated security mechanisms. Throughout the various stages in the lifetime of a Java application or applet, rigorous checking and precautions are enacted to ensure the security of the local machine in which the Java code will execute. First, the language has many forms of safety measures built in, which the compiler ensures source code does not violate. Second, the class loader checks to make sure that all namespace and access restrictions are followed by the bytecodes extracted from the loaded Java .class files. Third, the run-time environment verifies the authenticity of the bytecodes before they are executed to prevent an altered compiler from producing code which violate Java's built-in rules to guarantee the security of the local host.

The Java compiler rigorously type-checks all source code. It also checks for the legality of all casts, strictly enforces array bounds, and performs the first check to ensure that access modes are adhered to. Because the Java language does not include pointers, access to objects cannot be forged or manipulated from outside. This eliminates runaway pointer errors common to C++ which may allow an object, either intentionally or accidentally, to modify another object's memory.

Once Java classes have successfully compiled and complied with the security checks at that level, they can be sent to other machines as .class files, which contain the platform-neutral bytecodes and more typing information. The class loader ensures that a class from a less-secure realm cannot replace a class from a more secure realm. One implication is that downloaded applets cannot read from or write to the local disk. Each package of applets or classes loaded into the local system is placed in a separate partition or namespace, which the applets or classes are unable to access across unless explicitly given permission to. Finally, the class loader ensures that once code is placed in its partitioned namespace, certain assumptions about the security of the system will always be true. Information can not be stolen and sent back to a remote computer, for example, because applets are also prohibited from making connections across the network. The applet has free reign inside its own namespace, or "sandbox", but it can not under any circumstances read or alter data outside of its sandbox.

Whereas the Class Loader provides high-level security, the class verifier is distinctly lower-level. Once the bytecodes are loaded and extracted from the Java .class files by the class loader, the Java Virtual Machine's run-time verifier subjects the bytecodes to more rigorous testing to ensure they meet security requirements before they can be executed. These tests range from simple format checks all the way up to theorem provers to once again guarantee the bytecodes do not forge object references or violate access restrictions. The bytecodes also carry within them extra type information which allows the run-time verifier to check that objects are not illegally manipulated. Because the interpreter can rest assured that all code is secure and all rules have been followed, it can run faster than it would if run-time checking needed to be done during execution.

Unfortunately, the sandbox model of namespace partition which exists in the current Java Environment does not adequately address other security and privacy issues. Some further security features are currently being added to the next version of the Java Development Kit. Because of the nature of transmission of applets across the Internet, it is still possible for someone to intercept the code and substitute virus-ridden code or faulty and deceptive information in an effort to receive private information from the client. If, however, applets and Java files could have a digital signature embedded within them which would authenticate the code as legitimate and trustworthy, the end-user's Virtual Java Machine would be able to determine if the files had been tampered with or did not originate from the location they claimed to come from and therefore refuse to execute them. One method to implement these digital signatures is through the use of Java Archives, or JAR files, which are simply entire collections of related Java class files bundled together. The digital signature would then be based on the unique contents of the JAR file, and would be tamper and forgery proof. Because of the inherent insecure nature of the transmitting medium for Java applets, the Internet, future Java implementations will incorporate some method of encrypting sensitive data, such as bank account or credit card information.

Implementation Plays an Important Role in Security

Examination of early releases of Sun's own HotJava browser and Netscape's Navigator version 2.0, the first two web browsers to support Java applets, discovered several flaws which compromised their security. Most of these flaws were the result of errors in the implementation of the Java language, while some arose from unintended interactions between browser features.

Both browsers were subject to Denial of Service attacks, which allowed an applet to consume CPU cycles through busy-waiting or complete memory allocation which starved other threads and system resources. HotJava also allowed applets to conduct two-way communication with arbitrary third-parties on the Internet, even though the language design clearly calls for restrictions upon this behavior in applets. Similarly, Netscape did not uniformly enforce Java's policy that an applet can only open a connection back to the server it was loaded from. Some versions of HotJava, notably the Windows95 version, allowed applets to write to the systems main \TEMP directory, leading to abuse through hard-drive corruption and over-writing. Others allowed applets access to user's private information through environment variables. Other flaws were discovered, including execution stack overwriting through buffer overflows and changing proxy variables.

All of these security infringements resulted from failure to properly enforce and implement Java's policies, and these specific flaws have since been patched. However, it is clear that specific implementations of the language must be rigorously tested to ensure they obey Java's security mechanisms.

The execution of remotely loaded code is still relatively new, and more work will be done to further protect today's Internet-based computer society. Sun hopes that Java is leading the way towards making such network-based computing safe. With the Internet revolution only just begun, only time will tell if indeed Java has what it takes to become, as its designers fervently hope, the "Cornerstone of the networked enterprise."

Bibliography

English, Jason. "What is Java?" http://www.javasoft.com/nav/whatis/ , February 14, 1997.

Gosling, James and McGilton, Henry. "The Java Language Environment" http://www.javasoft.com/doc/language_environment/ , February 2, 1997.

"About JavaSoft" http://www.javasoft.com/nav/about/index.html , February 15, 1997.

Fritzinger, J. Steven and Mueller, Marianne. "Java Security". http://www.javasoft.com/security/whitepaper.ps , January 27, 1997.

Dean, Drew; Felten, Edward W.; and Wallach, Dan S. "Java Security: From HotJava to Netscape and Beyond". http://www.cs.princeton.edu/sip/pub/secure96.html , February 2, 1997.

English, Jason. "Java Reaches New Heights" http://www.javasoft.com/features/1996/december/newheights.html , February 14, 1997.

"The Java Language: An Overview". http://www.javasoft.com/doc/Overviews/java/java-overview-1.html , February 3, 1997.

Felton, Edward W.; Balfanz,Dirk; Dean, Drew; and Wallach, Dan S. "Web Spoofing: An Internet Con Game". http://www.cs.princeton.edu/sip/pub/spoofingDocumentWithLongUntypeableName.html , February 3, 1997.