|
|
|
|
Sponsored Link •
|
|
Advertisement
|
Support for platform independence, like support for security and network-mobility, is spread throughout Java's architecture. All the components of the architecture--the language, the class file, the API, and the virtual machine--play a role in enabling platform independence.
Java's architecture supports the platform independence of Java programs in several ways, but primarily through the Java Platform itself. The Java Platform acts as a buffer between a running Java program and the underlying hardware and operating system. Java programs are compiled to run on a Java virtual machine, with the assumption that the class files of the Java API will be available at run-time. The virtual machine runs the program; the API gives the program access the underlying computer's resources. No matter where a Java program goes, it need only interact with the Java Platform. It needn't worry about the underlying hardware and operating system. As a result, it can run on any computer that hosts a Java Platform.
The Java programming language reflects Java's platform independence in one principal way: the ranges
and behavior of its primitive types are defined by the language. In languages such as C or C++, the range of
the primitive type int is determined by its size, and its size is determined by the target
platform. The size of an int in C or C++ is generally chosen by the compiler to match
the word size of the platform for which the program is compiled. This means that a C++ program might have
different behavior when compiled for different platforms merely because the ranges of the primitive types are
not consistent across the platforms. For example, no matter what underlying platform might be hosting the
program, an int in Java behaves as a signed 32-bit two's complement number. A
float adheres to the 32-bit IEEE 754 floating point standard. This consistency is also
reflected in the internals of the Java virtual machine, which has primitive data types that match those of the
language, and in the class file, where the same primitive data types appear. By guaranteeing that primitive
types behave the same on all platforms, the Java language itself promotes the platform independence of Java
programs.
As mentioned in the previous chapter, the class file defines a binary format that is specific to the Java virtual machine. Java class files can be generated on any platform. They can be loaded and run by a Java virtual machine that sits on top of any platform. Their format, including the big-endian order of multi-byte values, is strictly defined and independent of any platform that hosts a Java virtual machine.
One aspect of Java's support for platform independence is its scaleability. The Java Platform can be implemented on a wide range of hosts with varying levels of resources, from embedded devices to mainframe computers.
Even though Java first came to prominence by riding on top of a wave that was crashing through the desktop computer industry, the World Wide Web, Java was initially envisioned as a technology for embedded and consumer devices, not desktop computers. Part of the early reasoning behind Java was that although Microsoft and Intel had a dominant clutch on the desktop market, no such dominance existed in the embedded and consumer systems markets. Microprocessors had been appearing in device after device for years--audio-video equipment, cell phones, printers, fax machines, copiers--and the coming trend was that, increasingly, embedded microprocessors would be connected to networks. An original design goal of Java, therefore, was to provide a way for software to be delivered across networks to any kind of embedded device--independent of its microprocessor and operating system.
To accomplish this goal, the Java runtime system (the Java Platform) had to be compact enough to be implemented in software using the resources available to a typical embedded system. Embedded microprocessors often have special constraints, such as small memory footprint, no hard disk, a non- graphical display, or no display. These constraints mean that embedded and consumer systems usually don't have the need, or the memory, to support the full Java API.
To address the special requirements of embedded and consumer systems, Sun created several incarnations of the Java Platform with smaller API requirements for embedded and consumer systems:
These Java Platforms are composed of a Java virtual machine and a smaller shell of runtime libraries than are available in the standard Java Platform. The difference between the standard and the Personal Platform, therefore, is that the Personal Platform guarantees the availability of fewer Java API runtime libraries. The Embedded Platform guarantees fewer APIs than the Personal Platform, and the Card Platform fewer than the Embedded. Yet although each platform addresses a progressively smaller execution environment, with progressively tighter constraints on resources, the APIs are not necessarily subsets of each other. Each API subset is geared towards a particular target, and therefore include just the APIs that make sense for that target.
In addition to guaranteeing the smallest set of APIs, the Card Platform, which is targeted at SmartCards, uses only a subset of the full Java virtual machine instruction set. Only a subset of the features of the Java language are supported by this smaller instruction set. As a result, only Java programs that restrict themselves to features available on the Card Platform can run on a SmartCard.
Although Sun attempted to address the special API needs of the embedded and consumer markets with these three subsets, the special API needs of these markets turned out to be a bit too heterogeneous for the three API subsets to adequately address. Because of the special constraints of embedded systems, especially the small memory footprint and lack of disk storage, vendors of embedded systems are often under tremendous economic pressure to pick and choose APIs. Because of the low price points for embedded devices, vendors often simply can't afford to include APIs that aren't directly needed by their device. Despite the three subsets defined by Sun, vendors still felt the need to define and support their own API subsets.
Eventually, Sun recognized their three subsets wouldn't suffice, and changed their approach to defining API standards for the embedded and consumer worlds. Instead of trying to define one-API-fits-all subsets, such as Personal and Embedded Java, Sun defined a very minimal API set they called the Java 2 Platform, Micro Edition (J2ME). On top of J2ME, Sun planned to facilitate the definition of API subsets by individual industry segments appropriate for their market niche (such as automobile, TV set-top box, screenphone, wireless pagers and cell-phones, personal digital assistents, etc.). Sun called these API subsets "profiles." The old Personal and Embedded platforms become profiles in the new approach.
Because the Java Platform is compact, it can be implemented on a wide variety of embedded and consumer systems. The potential compactness of the Java Platform, however, does not restrict implementation at the opposite end of the spectrum. The Java Platform also scales up to personal computers, workstations, and mainframes. Although in Java's early years, Java Virtual Machine implementation had scaling difficulties on the server side, virtual machines were tuned for servers and now many implementations yield very good performance on the server side. At this end of the spectrum, Sun has defined an API superset: the Java 2 Enterprise Edition (J2EE). In addition to the standard Java APIs, the J2EE includes other APIs that are useful in enterprise server environments, such as servlets and Enterprise JavaBeans.
In the end, Sun's revised approach to defining APIs yielded three basic API sets, which demonstrate the scaleability of the Java Platform:
|
Sponsored Links
|