The evolution of Java technology for Internet appliances and embedded devices

The Java programming language inherits much of its syntactical rules, and therefore familiarity, from C/C++. In order to make Java technology more robust, however, some fundamental changes were made to the language definition. For example, the Java language does not permit direct access to memory nor is pointer arithmetic part of the language. To directly access memory, for example, developers may write a "native method" in C and call it from the Java application via the Java Native Interface (JNI).

The Java language supports a true implementation of an array object. Unlike C/C++, the Java runtime performs array bounds to insure the application does not attempt to access any element beyond the end of the defined array. The Java language also prevents implicit typecasting to objects of dissimilar types, especially when precision might be lost (e.g., float typecast to an int). Although these features may be viewed by some as restrictions in the Java language, there is emerging proof from actual development projects that Java technology can reduce overall development time and improve the reliability of the application - a key concern for Internet appliance and embedded device developers.

Viewed at a higher level, Java technology is a pure object-oriented language. For example, the "Hello World" program can only be implemented as a class object. Projects implemented with Java technology should realize the benefits of code reuse and a higher degree of maintainability over time.

The key element of the Java language that is highly relevant to networks is its size as an executable. Since Java applications are intended to be distributed easily across networks, it is important to maintain a compact representation of the code. Java source files entered by the developer are compiled into the efficient and portable bytecode instruction set, which is the representation executed by the Java virtual machine. Rather than requiring an independent set of run-time libraries, like C/C++, multi-threading is inherent to the Java language.

The Java API can be described at either the individual detailed level or as a higher-level collection of functionality. The hierarchy of definitions works something like this: at the highest level, everything can be referred to simply as "Java technology." Below that, Sun has defined some natural sub-setting of Java technology, for example, described previously as specifications for Enterprise Java, PersonalJava, and EmbeddedJava application environments. These specifications are intended to define the various functional elements and class libraries that are most likely to address the requirements of certain categories of applications.

The objective is to help ensure that a Java application written for one category of computing device (e.g., smartphone) will be able to run on another computing device in the same category. Each specification for a Java application environment generally requires a functionally equivalent implementation of the Java virtual machine along with a suitable subset of the Java class libraries. There are 12 primary class "packages" defined, which collect and organize similar and related class libraries. Each package contains multiple interfaces and class libraries, each of which in turn contains multiple fields and class methods.

The Enterprise Java application environment is specified to contain all of the defined Java class libraries. The PersonalJava application environment is smaller, but still requires the complete implementation of its fixed set of class libraries to be fully compliant. The EmbeddedJava application environment, on the other hand, allows developers to include or exclude class libraries according to the requirements of a specific Internet appliance or embedded device application. The upshot is that the EmbeddedJava specification can be implemented differently from one Internet appliance or embedded device to the next, so a full implementation of the platform is not expected.

Vendors of Java technology have taken two different approaches in providing Java class libraries. Some vendors supply only a subset of the Java class libraries, which causes these implementations to be incompatible with the standard Java specifications. Other vendors supply all of the class libraries and allow the developer to select which optional libraries are required for their applications. When it comes to comparing the memory footprint of the various Java and Java-like platform implementations, you'll need to consider which class libraries are supplied to make a true apples-to-apples comparison.