If the shoe fits . . .

The vast array of disparate hardware and software architectures present throughout the embedded market begs for a common language and platform with which to develop applications. It was to address this issue that Sun initially developed the Java technology platform. Java, according to Sun's vision, would provide a unifying platform for embedded devices through a Virtual Machine (VM) which would execute Java byte codes portably and transparently. The goal was: “Write once, run anywhere” (WORA).

Unfortunately, problems with Java's speed and predictability in the early days prevented it from delivering on this vision. Today, however, vast increases in microprocessor speed and execution efficiency, combined with improvements in Java technology itself, have greatly mitigated the performance issues.

Additionally, in today's increasingly networked world it has become highly desirable to freely move applications from one system to another, in some cases running web-based applications on “thin” clients of varying architectures. Obviously, the ability to run a single software implementation written in Java byte codes on multiple machines, rather requiring than numerous machine specific binaries, presents a tremendous value proposition.

In short: Java is ready for prime time in the world of embedded systems and smart, interconnected devices. Blame it on the web!

First Iteration of Java in the embedded space

Sun's first iteration of virtual machines for the embedded space included the Personal Java Virtual Machine and the Embedded Java Virtual Machine . . .

• Personal Java Virtual Machine — the Personal Java Virtual Machine (pJava) is a modified version of the standard Java Virtual Machine (Java 1.1). The pJava VM developers took the full Java Virtual machine and optimized it for footprint. The personal Java virtual machine has a full Abstract Windowing Toolkit (AWT) implementation, but does not support Java Swing out of the box.

• Embedded Java Virtual Machine — the Embedded Java Virtual Machine is the Personal Java VM with the option to remove class libraries to meet very small footprint requirements for embedded applications. The Embedded Java Virtual Machine includes a utility called the Java Filter that takes an applications dependencies on class libraries and filters the class libraries to only include the class libraries needed for that particular application. Part of Sun's licensing terms for the Embedded Java Virtual Machine is that the API's for the class libraries cannot be exposed to the community so that Java compatibility is not jeopardized.

The memory footprint for the Embedded Java and Personal Java virtual machines are a recommended minimum of 8MB RAM.

What about “very small” devices?

The emergence of “very small” devices such as pagers and cell phones, with extremely limited system resources, caused a project within Sun Labs to become a Sun product team.

The KVM or Kauai virtual machine (named after a tiny island in Hawaii) is a very small virtual machine that requires only 128KB of RAM. The KVM is a “clean room” implementation, which means it is not a subset/modification of another virtual machine. The KVM lacks many of the features and API's of the standard Java virtual machine, including support for AWT, the common Java API for graphics

Sun also produces another very small Java implementation called the Java Card. The Java Card Virtual Machine is capable of running on “Smart Cards”. The code created for the Java Card VM is compiled and linked before being downloaded to the card in the Java card file format. The Java Card now represents a large percentage of the Smart Card marketplace.

Emergence of the J2ME architecture

The Java 2 Micro Edition (J2ME) architecture is Sun's attempt at creating a set of configurations and profiles to fit many different vertical markets which share certain common characteristics including constrained resources. The J2ME set of configurations is part of Sun's Java 2 array of products that include (biggest to smallest): the Java 2 enterprise edition (J2EE); Java 2 standard edition (J2SE); Java 2 Micro Edition (J2ME); and Java Card.

To further complicate matters, the Java 2 Micro Edition currently contains two basic configurations: the Connected Device Configuration (CDC); and the Connected Limited Device Configuration (CLDC). The CDC is the replacement for Personal Java, and the CLDC is built on the KVM. On top of each configuration, there are several profiles that contain class libraries optimized for certain vertical market segments. These profiles are being defined as part of the Java Community Process (JCP). The JCP allows companies from throughout the industry participate in defining the API specification for their particular vertical market.

Further information about J2ME is available here.

• CDC — the reference virtual machine for the CDC is a new virtual machine called the C virtual machine (CVM), which is a clean room virtual machine built to the blue book specification (Java 1.2). The first profile available for the CDC, called the foundation profile, contains some basic class libraries. Another profile, being created using the JCP, is the Personal Profile; it allows the CDC to replace personal Java. Other profiles are actively being defined using the JCP. Further information on CDC is available here.

• CLDC — the reference virtual machine for the CLDC is the Kauai virtual machine (KVM). An active profile on top of the CLDC is the mobile information device profile (MIDP) that meets the requirements of wireless application developers. The CLDC and MIDP is targets the small battery operated devices that often have a wireless, intermittent connection such as cell phones. Further information on CLLC is available here.

Real-time considerations

A large number of embedded devices have real-time requirements. To meet those requirements, a Java specification request (JSR) was submitted as part of the Java community process (JCP). The first JSR (JSR-000001) is the real-time specification for Java (RTSJ). The real-time specification for Java enables processes to interrupt the garbage collector to ensure predictable response amongst many other improvements.

TimeSys Corporation is developing the reference implementation for the real-time Java specification.

Compilation Technologies

To meet the performance requirements of many embedded devices, compilation technology is required. There are several different compilation methods depending on your requirements . . .

• Ahead-of-Time (AoT) — an ahead-of-time compiler is very similar to a standard C compiler in functionality. It takes Java code and converts it to machine code. The compiler may compile everything, including class libraries. Some ahead-of-time compilers allow you to perform dependency analysis on your code to determine which classes/methods to compile. The resulting executable is referenced during runtime using the Java class path. The problem with compiling everything ahead-of-time for embedded systems is that the size of the executable can be very large. Another issue is that if you want to deploy code on several different hardware/operating system architectures you need to compile the code for each. Also, if you want to change the classes loaded you need to recompile.

• Just-in-Time (JIT) — a just-in-time compiler will take byte codes that are being loaded into the system and compile them. There is a start-up cost associated with this methodology as well as a footprint requirement. The advantage of this solution over the AoT compilers is that it utilizes machine independent Java byte codes.

• Dynamic Compilation — this method looks at the running system and determines what pieces of code are most frequently executing. The dynamic compiler then compiles the “hot” areas of code in order to speed up system performance. The advantage of dynamic compilation is that the amount of memory consumed is configurable – and the ability to dynamically change classes is maintained. An issue with Dynamic Compilation is that it is an unbounded process and therefore can't be used when meeting timing constraints is critical.

Conclusions

The growing use of Linux on embedded devices is part of a general trend of equipment manufacturers adopting open standards and community-developed software. The benefits of this trend are numerous, including: decreased cost per unit, a large and enthusiastic developer community, and a common platform for which to distribute value-added software applications.

Linux is quickly becoming the community-accepted standard for an operating system, while Java is gaining ground as the application environment and programming language of choice. The combination of these two technologies offers a compelling software platform for embedded devices — a much needed solution for the vast array of disparate hardware and software architectures present in the embedded market.

---

Author's bio: David Tannenbaum graduated with a Computer Science Engineering degree from the University Of Pennsylvania. He subsequently worked for Sun MicroSystems technology licensing division, before joining TimeSys Corporation where he currently serves in the role of Director of Marketing.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.