This paper defines the JavaTM Platform and provides descriptions of each of its parts. It is written for developers and others interested in understanding the wide range of environments where Java-powered applets and applications can run.
For more up-to-date and detailed information about the features and architecture of the Java Platform and development environment, refer to the Developer's Corner at the JavaSoft web site http://java.sun.com
. In particular, see The Java Language Environment: A White Paper.
The Java Platform is developed by JavaSoft, an operating company of Sun Microsystems, Inc.
Please send any comments or corrections to doug.kramer@sun.com
Copyright © 1996 Sun Microsystems, Inc. All rights reserved.
The Java Platform is a new software platform for delivering and running highly interactive, dynamic, and secure applets and applications on networked computer systems. But what sets the Java Platform apart is that it sits on top of these other platforms, and compiles to bytecodes, which are not specific to any physical machine, but are machine instructions for a virtual machine. A program written in the Java Language compiles to a bytecode file that can run wherever the Java Platform is present, on any underlying operating system. In other words, the same exact file can run on any operating system that is running the Java Platform. This portability is possible because at the core of the Java Platform is the Java Virtual Machine.
While each underlying platform has its own implementation of the Java Virtual Machine, there is only one virtual machine specification. Because of this, the Java Platform can provide a standard, uniform programming interface to applets and applications on any hardware. The Java Platform is therefore ideal for the Internet, where one program should be capable of running on any computer in the world. The Java Platform is designed to provide this "Write Once, Run Anywhere"SM capability.
Developers use the Java Language to write source code for Java-powered applications. They compile once to the Java Platform, rather than to the underlying system. Java Language source code compiles to an intermediate, portable form of bytecodes that will run anywhere the Java Platform is present.
Developers can write object-oriented, multithreaded, dynamically linked applications using the Java Language. The platform has built-in security, exception handling, and automatic garbage collection. Just-in-time compilers are available to speed up execution by converting Java bytecodes into machine language. From within the Java Language, developers can also write and call native methods-methods in C, C++ or another language, compiled to a specific underlying operating system-for speed or special functionality.
The Java Language is the the entry ramp to the Java Platform. Programs written in the Java Language and then compiled will run on the Java Plaform. The Java Platform has two basic parts:
These are described in detail later in this paper. Combined, these parts provide an end-user runtime environment for deploying Internet and intranet applications.
Certain Java Platform licensees (listed in "Where Will the Java Platform Be Deployed?" on page 10") have contracted to include the Java Base API in their particular implementation of the Java Platform. As more class libraries are developed, the Java Base Platform will grow, and these additions will migrate in a timely fashion into the Java Base Platform present on each licensee's operating system.
Another set of APIs, called the Standard Extension API, is being defined by JavaSoft, in partnership with leading industry companies, to extend the base functionality. Over time, some subset of the Standard Extension API will migrate into the Java Base Platform.
The API targeted for this platform is called the Java Embedded API. The Java Embedded API is the smallest API a low-function embedded device can have and still run. Because this platform is still under development, this API has not yet achieved the level of a standard. Consequently this API is not yet well-defined, but it will probably consist of the packages java.lang
and java.util
. A Java-powered application written for one particular device could operate on a wide range of similar, dedicated devices.
In addition, building applications from shared, reusable objects can further reduce cost by allowing developers to concentrate on creating only what is novel. Developers can distribute by network rather than compete for shelf-space in software stores.
Companies with large intranets, that may not find it worthwhile to upgrade to the latest memory-consuming operating system, can run Java-powered applications on all their existing machines. By providing corporate data in a format readable by Java-powered applications, corporations give users the platform-neutral access to the data they need.
When customers are running on the Java Platform, companies can take advantage of the interactivity of the Internet by moving employee tasks out to customers. Companies can reduce time spent on order-entry by having customers fill in order-entry forms themselves on Web pages. This is more practical than previously possible, because the customer can now be on any operating system.
<applet>
tag is embedded in a Web page and names the program to be run. When that page is accessed by a user, either over the Internet or corporate intranet, the applet automatically downloads from the server and runs on the client machine. Because applets are downloaded, they tend to be designed small or modular, to avoid large download times.
However, an applet requires a network to run, while an application does not. Applications have greater freedom in that they have full access to system services. For example an application, unlike an applet, can have normal read and write access to files on any disk. Since an applet can potentially be downloaded from an untrusted Web page, it is restricted from having read or write access to any file system except the server from which it came. This constraint will be relaxed when applets can be marked with digital signatures, allowing the end-user to be assured that it has been downloaded unaltered from a trusted source. Where local file storage is required, currently an application is required.
First, the Java Base Platform is currently embedded in the most widely used Internet browser, Netscape NavigatorTM, and will soon be in Microsoft Internet Explorer. It is, or will become, available in other browsers, such as HotJavaTM.
Second, the Java Base Platform will soon be embedded in all leading desktop, workstation, and network operating systems-see Figure 1. Being available on the combination of Microsoft Windows, Macintosh, OS/2, and UNIX computers, the Java Base Platform will have an installed base as large as these platforms combined. By targeting this platform, developers will tap into the new, exploding market for Web and intranet applications without being tied to any particular hardware or operating system environment. The Java Platform will become the platform for all network- and Web-based computing.
Third, with the JavaChipTM family of integrated circuits, the platform will be available in a wide range of consumer and industrial embedded devices such as dedicated Network Computers, set-top boxes, printers, copiers and cellular phones.
Figure 1. Companies licensing the Java Base Platform to embed in operating systems.
The microJava and UltraJava are actual chips being developed by Sun Microelectronics based on the picoJava design. These chips have the Java Virtual Machine and Java Embedded API implemented in silicon, and vary in their application-specific I/O, memory, communications and control functions. The JavaOS can run in RAM on JavaChip. The JavaChip family enables the Java Virtual Machine to run in the most efficient, cost-effective manner, bringing high performance to dedicated Java-powered devices, such as Network Computers.
JavaOS is designed for Network Computers, consumer devices, and network devices for embedded applications, such as printers, copiers and industrial controllers. These devices will have instant turn-on, no installation setup, no system administration, and, when on a network, can be automatically upgraded.
JavaOS will be widely ported to a range of microprocessors, including the JavaChip family. When JavaOS runs on a JavaChip, the microprocessor's silicon Java Virtual Machine is used.
When developers write source code in the Java Language, this code can call APIs defined in the Java Base API, Java Standard Extensions API, or a new API defined in the source code itself. At runtime, all three kinds of APIs have equal standing, and are not distinguished on the basis of their source. Compiling the source with the Java Compiler generates bytecodes that are executed on the Java Platform.
As professional programming languages go, the Java Language is simple, yet flexible and powerful. It is object-oriented (with single inheritance), statically typed, multithreaded, dynamically linked, and has automatic garbage collection.
Its syntax is based on C and C++, so those programmers can pick it up quite easily. There's less redundancy which means developers should be able to more easily read someone else's code. For example, the Java Language has no user-defined operator overloading, as is found in C++.
The Java Language gives developers the ability to do three different kinds of programming in one language. Like the symbolic programming language Smalltalk, the Java Language is object-oriented, has dynamic linking, and has a class hierarchy with single inheritance. For numeric programming, the Java Language has platform-independent data types, array bounds-checking, and well-defined IEEE arithmetic. These capabilities provide good grounding for writing stable numerical algorithms that give repeatable results. For systems programming, expressions, statements, and operators in the Java Language are in most cases the same as in the C language.
The Java Language encourages catching bugs early, during development, before the software is released. It does this by strong data typing, automatic garbage collection, array bounds checking, lack of automatic type coercion, and the lack of the pointer data type. These safeguards help in the age of the Internet, where developers are deploying software very rapidly.
The Java Language has multithreading built in, with a strong model of how thread-critical code can be synchronized to avoid race or timing problems. With the growth of multiprocessing and a decrease in processor costs, the Java Language is poised to enable a new generation of concurrent applications and services.
Exception and thread mechanisms are integrated with the language and its type system. In addition, the language includes dynamic linking of subclasses with methods that override or add functionality at runtime. In other environments, these features have typically been arcane and complicated system services. There is a great simplicity and advantage to having these facilities in the language and therefore portable between platforms. The language also defines what binary compatibility is, by defining a class (.class
) file format, which includes the instructions for the Java Virtual Machine in the form of bytecodes.
1 This section and the Virtual Machine section are borrowed heavily from the keynote address given by Bill Joy, Founder and Vice President of Research at Sun Microsystems, to Internet World on April 30, 1996.
Figure 2. The Java Base Platform is uniform across all operating systems.
In this figure, the Java Base Platform is the part shown in black, including the blocks labeled Adapter. The Java API includes both the Java Base API and Java Standard Extension API. The classes are the implementation of that API. The Java Virtual Machine is at the core of the platform. The Porting Interface lies between the Java Virtual Machine and the operating system (OS) or browser. This Porting Interface has a platform independent part (shown in black) and a platform-dependent part, shown as Adapters. The OS and JavaOS provide the window, filing and network functionality. Different machines can be connected by a network, as shown.
The Java API framework is open and extensible. Specifications for each interface are being developed by industry-wide specialists in each area. Forthcoming specifications will be published and open to industry review. Implementations of the API specifications will be available from JavaSoft and others throughout the industry. In today's environment of rapid innovation, the Java API framework allows that innovation to easily exist as extensions to the Java Platform.
The API is organized by groups, or sets. Each of the API sets can be implemented as one or more packages (namespaces). Each package groups together a set of classes and interfaces that define a set of related fields, constructors, and methods.
In addition, the Virtual Machine defines a machine-independent format for binary files called the class (.class
) file format. This format includes instructions for a virtual computer in the form of bytecodes. The bytecode representation of any Java Language program is symbolic in the sense that offsets and indexes into methods are not constants, but are, instead, given symbolically as string names. The first time a method is called, it is searched by name in the class file format, and its offset numeric value is determined at that time for quicker access at subsequent lookups. Therefore, any new or overriding method can be introduced late at runtime anywhere in the class structure, and it will be referred to symbolically, and properly accessed without breaking the code.
The bytecodes are a high-level representation of the program so that optimization and machine code generation (via a just-in-time compiler) can be performed at that level. In addition, garbage collection can occur inside the Virtual Machine, since it holds variables in stacks in the Java Platform address space.
Currently, the Java Base API is defined to be the Java Applet API, described in the next section. Over time, as the platform develops, this base will grow, as some of the Standard Extension API migrate into the Java Base API. The Java Base API is also known as the Java Core API.
java
package: java.lang
, java.util
, java.io
, java.net
, java.awt
, and java.applet
. (Notice that the Java Applet API is the full set of APIs available in version 1.0.2 of the Java Development Kit from JavaSoft.) The current plan for this migration is shown in the following table:
Migrate to
|
Remain as
|
---|---|
Java 2D | Java 3D |
Audio | Video, MIDI |
Java Media Framework | Java Share |
Java Animation | Java Telephony |
Java Enterprise | Java Server |
Java Commerce | Java Management |
Java Security |
An implementation should do whatever is appropriate for the platform it runs on, within its hardware constraints. For example, desktop operating systems that have access to a speaker will produce audio; however, a mainframe or network operating system that has no speaker is permitted to do the equivalent of a no-op or some other well-defined behavior, such as throw an exception.
Java Security includes an abstract layer that applications can call. That layer, in turn, makes calls to Java Security packages that implement the actual cryptography. This allows third-party developers specializing in providing cryptographic functionality to write packages for Java Security. Java Security also includes system support for key management, including a secure database, certificate facilities, and so on.
This architecture provides for replaceable, upgradable security. Whenever a stronger algorithm or a faster implementation becomes available, modules can be replaced in the platform, in a manner completely transparent to applications.
The Java Media API is composed of several distinct components, each associated with either a specific type of media (audio, video, 2D, 3D), or a media-related activity (animation, collaboration, telephony). Collectively, these interfaces provide Java Language programmers with the ability to handle a wide variety of different media types within their applications and applets.
The Java Media API is highly extensible. The API accommodates today's large and ever-changing suite of media transports, containers, and encoding formats, and allows the addition of new media-related functionality as they become available.
JavaSoft has been working with a group of industry-leading companies to establish the standards for Java Media: Adobe®, Apple, Intel, Macromedia, Netscape, SGI, and Sun Microsystems.
The components of the Java Media APIs are as follows.
World wide purchases of retail and wholesale goods and services during 1994 totaled 4.6 trillion dollars, 13% of which was spent remotely via catalogs, television, and various public and private communications networks. As this remote commerce migrates to the Internet, a standard framework within which to conduct these transactions becomes increasingly important. This is especially true as a rapidly increasing number of players vie for position to provide such facilities as electronic currency, online shopping malls, digital signature verification, and financial analysis.
The initial component of the Java Commerce API is the Java Wallet, which defines and implements a client-side framework for conducting network-based commerce. Think of Java Wallet as an empty wallet ready to hold credit cards and cash, and a blank ID card ready to be filled in with personal information.
Servlets are platform-independent Java-powered objects, the server side counterpart of applets. Servlets can reside locally on the server, or be downloaded to the server from the net under security restrictions. Servlet examples range from simple HTTP servlets (efficient replacements of cgi-scripts) to more complex servlets using JDBC/ODBC that offer database connectivity.
The Java Management API is composed of several distinct components, each associated with an aspect of the total management space. Taken together the objects defined using the Java Management API will encapsulate distributed network, system, and service management components.
The components of the Java Management APIs are as follows:
<applet code=
filename>
tag to a Web page, which names the entry-point bytecode file.
When an end user visits that page, the <applet>
tag causes the bytecode files to be transported over the network from the server to the end user's browser in the Java Platform. At this end, the bytecodes are loaded into memory and then verified for security before they enter the Virtual Machine.
Once in the Virtual Machine, the bytecodes are interpreted by the Intepreter, or optionally turned into machine code by the just-in-time (JIT) code generator, known more commonly as the JIT Compiler. The Interpreter and JIT Compiler operate in the context of the runtime system (threads, memory, other system resources). Any classes from the Java Class Libraries (API) are dynamically loaded as needed by the applet.
Figure 3. Source code is compiled to bytecodes, which are executed at runtime.