With the Java 2 Micro Edition (J2ME), Sun Microsystems delivers a partitioning scheme that embedded Java developers need. Whereas the Java 1-based PersonalJava specification was monolithic, the J2ME provides a superset environment that comprises the latest Java 2 support. J2ME's modular approach puts it ahead of the competition by allowing incremental improvements through the addition of new specifications.
J2ME is a subset of the J2SE (Java 2 Standard Edition) and J2EE (Java 2 Enterprise Edition). It splits things up by virtual-machine, configurations, and profiles. Yet it doesn't eliminate support defined under Java 1. Selecting the appropriate configuration and profile combination allows an application to be built on standard speficications. This makes it easier to incorporate third-party support and supplies a well-defined platform for downloaded applets.
Embedded developers rarely start from scratch these days. Instead, they relay on platform-based development, which affords a quicker and more reliable way to complete an embedded application.
J2ME stresses this approach. In addition, its partitioning allows for multiple and hierarchical specifications. Developers can then choose the appropriate combination on which to build, thereby minimizing the amount of custom code used while at the same time retaining a standards approach to application development.
Incremental performance improvements and related memory requirements are furnished by the virtual machines (VMs) used with the various Java 2 specifications. The K virtual machine (KVM) sacrifices speed for compactness.
Although the standard Java virtual machine (JVM) has a larger footprint, it attains better execution speed due to improved compilation. Containing the largest compiler improvements, Java Hot Spot technology is applied where memory usage isn't a major issue.
The VM specifications are only guidelines. Third-party VM implementations vary from hardware implementations to NewMonic's PERC and HP's Chai. Chai relies on ahead-of-time (AOT) compilation combined with pruning of unneeded classes to accomplish fast execution speeds while keeping code size low. Others, such as Insignia's Jeode, incorporate features not set in the specification (i.e., scheduled, non-blocking garbage collection).
Most VM implementations hide their product-specific features from applications, thereby preserving compatibility among platforms. The customization of these kinds of features is often done through deployment tools that are product specific but transparent to applications.
Configurations provide a basic set of classes, including math and Java language support. The primary purpose is to provide a level of communication that is appropriate for a device's environment. The primary differences are in throughput and connection availability.
The connected limited device configuration (CLDC) is targeted at mobile and battery-operated devices like cell phones, where a network connection may be slow or intermittent. A superset of this is the connected device configuration (CDC). It's designed for devices like Internet appliances that have a reliable network connection available. Power and memory availability is typically better with a CDC than with a CLDC device.
CDC devices generally implement support applications like the Java embedded server (JES). JES has its own partitioned architecture for bundled and custom services. But it is independent of the J2ME partitioning presented here.
Profiles Profiles are built on top of configurations. The naming convention is actually arbitrary since profiles also can be modeled after other profiles.A highly preferred profile is the Mobile Information Device Profile (MIDP) for wireless devices. MIDP runs on the CLDC configuration. The MIDP doesn't use the abstract windows toolkit (AWT). Instead, it defines its own user-interface classes that take into account the hardware limitations (like the lack of a mouse) of platforms that benefit from MIDP. Also, MIDP doesn't include floating-point support that's often lacking in low-power, portable devices. This combination is used on a number of commercially available cell phones.
The Foundation Profile is an offshoot of the CDC configuration (see "A Solid Foundation," opposite). It adds security classes that provide a higher level of security than the CDC alone. While applications can be built using this profile alone, they're more likely merely to be based on it.
For example, the Personal Profile is based on the foundation profile, but it adds the AWT user-interface classes. As with other class definitions involved in the profile specifications, the exact implementation and scope of classes used are not limited to the profile's requirements. There are actually two common AWT implementations that are available.
Some class definitions are not included in either configuration or profile definitions. For example, the remote debugger support is optional, allowing it to be removed when a product is deployed. VMs often incorporate debugging as an optional feature.
The Foundation, Mobile Information Device, and Personal Profiles are not the only profiles that will be available. They are only the ones that have been finalized. Another profile being developed is the Handheld Profile. Although the initial proposal is based on the CLDC, that may change as many PDA vendors prefer the more robust CDC foundation. This type of discussion is one reason why the current J2ME profile and configuration architecture took awhile to develop, but the result is a more robust platform that is usable in a larger number of embedded projects.
Profile and configuration specifications come out of the Java community process (JCP). Current and pending JSRs can be found on www.java.sun.com. JSRs offer target platforms, memory requirements, base software support, and classes included within the specification.
Current J2ME specifications and development are concentrated on the MIDP and the Personal Profile. This follows existing Java 1 embedded development. Two specifications dominated embedded Java development prior to J2ME—PersonalJava and EmbeddedJava.
Replacing The Old PersonalJava is a specification that originated from Java 1. It has been very popular for embedded-Java development and enjoys extensive third-party support. This platform was designed for systems with at least 1MB of memory and a user interface.PersonalJava has been a widely used platform. Therefore, it's not surprising that it is compatible with the Personal Profile that runs on the CDC configuration. The Personal Profile/CDC combination is actually a superset of PersonalJava, but the memory footprint is comparable. In addition to being built using the latest Java classes, the J2ME ap-proach has the benefit of new and improved I/O support.
In reality, J2ME and the Personal Profile do not re-place PersonalJava. Rather, J2ME and its accompanying specifications redefine how classes are partitioned.
There is no difference from a program's point of view, since ther linking is transparent to configuration and profile boundaries. The main difference that's be-tween the old and the new is that the newer J2ME is based on the latest Java releases.
EmbeddedJava is de-signed for very compact systems. Its footprint starts at 128 kB to 512 kB depending on the classes that come with the application. EmbeddedJava is a subset of PersonalJava. As a result, applications de-veloped for EmbeddedJava can be easily moved to a PersonalJava platform or a J2ME CDC with a Personal Profile platform.
Because of the licensing terms from Sun Microsystems and the fact that it usually lacks a user interface, EmbeddedJava remains relatively hidden from view. Unlike other Java platforms, EmbeddedJava implementations may not expose their API. This was designed to prevent fragmented applet designs.
EmbeddedJava doesn't have a counterpart under J2ME like PersonalJava. Much of the interest for compact designs has been superceded by the J2ME CLDC configuration with the wireless profile. Most J2ME development tools can build directly on top of a configuration.Thus, it's still possible to achieve a very compact design using the new specifications.
Other limited Java configurations, such as the JavaCard specification, are not addressed by J2ME. JavaCard is a very specialized environment that does not need the flexibility or connectivity support that J2ME provides.
The current J2ME specification does not include any real-time support. There is a real-time Java specification that has been finalized. Development of a validation suite will complete the process. The real-time support can be use in conjunction with J2ME, which can run on top of an RTOS as well. Typically, the RTOS support will be exposed through the Java real-time support.
J2ME will dominate embedded Java development in the future as Java 1 developers begin to employ the latest tools. This is likely to occur quickly since J2ME is basically a new way of looking at the latest Java tools and classes.
See associated figures 1 and 2
| A SOLID FOUNDATION |
|
CDC Configuration and Foundation Profile |
| J2ME profiles are built on existing configurations. For example, the Foundation profile is based on the CDC configuration. Only a couple classes are added as the Foundation profile is designed to be the base for additional profiles. Profiles can also be based on other profiles. For example, the Personal profile is based on the Foundation profile shown above. |