| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 | ||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
 TEST CENTER Making Java work on embedded systems By Bruce Abbott, For InfoWorld Test Center November 17, 2000 See correction below
WHO SAYS YOU can't go home again? The Java programming language, originally designed for set-top appliances, left home to achieve fame and fortune on the World Wide Web. Now the prodigal son wants to return to its old stomping grounds as a programming language for embedded systems. Developing for embedded systems brings a whole new set of complexities with it (see "Embedded intelligence"). You are dealing with new devices, skill sets, and constraints such as speed, memory, size, and time determinism that you didn't have before. Java can help with its object design, inherent Internet integration, and base of knowledgeable developers. In particular, Java 2 Micro Edition (J2ME), a subset of the Java API, is designed to meet the stringent memory requirements of embedded devices. Only the critical features of Java are included in the client. J2ME uses "profiles" to target various devices in two broad categories: those with 128KB to 512KB of memory and those with 512KB-plus. Different user interfaces and other packages may be available based on the device profile. Ironically, some of the features that have made Java an excellent choice for Internet and desktop programming cause problems on an embedded system. The security of running in the Java virtual machine (JVM) sandbox and the lack of pointers make it difficult for Java to control hardware. Automated garbage collection makes programming easier but makes real-time determinism impossible. Further, Java walks slowly and carries a big footprint. The good news is that most of these problems are surmountable and viable solutions are available. So when we ask the question, "Is Java a good choice for programming embedded devices?" the answer is an unequivocal "sometimes." When is Java the right choice? For the microprocessor that handles interrupts to guide the Mars Lander, Java may not be the best choice. If your requirements are to design a lightweight, efficient, mission-critical, time-deterministic application to fire retro-rockets, communicate with sensors, and report orientation of the spacecraft, stick with C or Assembler. For other applications such as tracking package shipments on a handheld device, Java is an excellent option. Devices that need to talk to one another or to the Internet can leverage the inherent features of the language. Applications that work with a server-side software already written in Java can leverage the design and code base in the existing domain. No time like the present One of the reasons for Java's popularity is that it is WORA (write once run anywhere). The same Java code can run on a Mac, a PC, Solaris, or even a mainframe because it is an interpreted language. A platform-specific JVM interprets the bytecodes to run on each OS platform. This takes time, although not as much time as it used to, thanks to just-in-time compilers. But who wants to wait eight seconds to make a phone call while Java allocates memory and loads the necessary classes? AOT (ahead-of-time) compilers interpret Java code in advance, transforming it to optimized, platform-specific binary code. Cygnus Solutions boasts an AOT compiler that speeds code execution by a factor of as many as eight times. NewMonics has developed QuickPERC Compiler, which the company claims increases an application's speed by as much as 20 times in comparison to the regular interpreted mode. Using an AOT, developers lose the benefit of being able to manage and maintain one version of compiled code in one central server location. But this is not a big loss in an environment that traditionally uses a more static codebase, such as an embedded system. Size does matter Although it is not uncommon for the average server to have several gigabytes of memory, a Java-enabled appliance may have less than 512KB. So running Java with a core class library of 1MB before you have even written a single line of code doesn't cut it on an embedded system. Stripping out all unused code, methods, and classes with AOT compilers has ameliorated this problem. Many vendors also have written their own platform-specific core Java classes that are smaller and more efficient while still adhering to the published Java API. Generally, object-oriented languages require more memory than languages such as Assembler and C. This has long since ceased to be a factor on the desktop, but it can be a factor in embedded systems. The right IDE It has been said that as much as 80 percent of the bugs in C programs come from problems with pointers, so Java got rid of them. Java's security model precludes the use of pointers to directly address system memory and real hardware. But those pointers come in handy when you want to address memory quickly and directly. So an embedded system written in Java must make use of native interfaces -- calls from Java to C code -- to perform hardware-specific functions. But this means that you are managing multiple types of code in multiple languages, which in turn means developers must have an additional skill set or you need additional developers. And how do you link all of this code into one module and debug it when something goes wrong? A powerful, feature-rich, multi-language IDE (integrated development environment) that supports code intended for multiple platforms is a big step in the right direction. Several are currently available, including Metrowerks CodeWarrior, which enables programmers to code in several languages in the same IDE, and IBM's VisualAge for J2ME. Because the problems these IDEs solve are complex, they too incur a steeper learning curve. Time to take out the trash One of the often stated reasons not to use Java in embedded systems is its inability to guarantee real-time determinism, which is to say the language will not process a particular portion of code in a predictable, repeatable amount of time. Java uses automatic garbage collection to reclaim unused memory, and developers have little or no control over when garbage collection takes place. When it does, it virtually pauses the entire application. To solve this problem, vendors have come up with different methods and algorithms for collecting garbage. Solutions such as NewMonic's Real Time Executive and Windriver's FastJ can ensure that you will get absolute time determinism. Sun has a different approach, but it is also moving toward a guarantee of real time determinism. Various coding techniques such as the reuse of objects can also mitigate the impact of garbage collection. Reuse is still important Although using AOT compilers costs developers the ability to run the same compiled Java code on any platform, portable Java source code is still a big plus. When a vendor manufactures a new version of its hardware, as long as the visible interface remains the same, the code that talks to that interface will not have to change. That is the essence of object oriented design. In fact, most of the higher application logic can still be debugged on the desktop. Dollars and sense Sometimes the decision to use Java comes down to a cost-benefit analysis. We all know memory and processor speed is cheap and getting cheaper. Although it makes sense to spend a few hundred dollars or even a few thousand dollars for memory on a server, the same logic might not hold true on a cell phone. If you can save $1 by using less memory on 20 million phones, you save $20 million. Other times, memory and speed are less of a factor. Pouring Java into your project If you are thinking about using Java on your next embedded-system project, "technology is unimportant compared to organizational cultural factors," say Greg Wickham, author of Embedded Systems' Compiled Java Experiences. "If you have a shop full of Java programmers doing Web design who are used to sacrificing machine resources to their convenience, you can't just turn them into ES programmers. Take an evolutionary approach to using Java: Don't do whole applications in Java right off. Then the Java guys start talking to embedded guys and they each gain expertise in each other's domain." The further you stray from a generic environment running J2ME bytecode on a JVM, the more complex your application becomes to manage. The rule of thumb here is to go with as much of the standard J2ME as much as you can. Incorporate special solutions only if there are special problems. And don't be surprised if some of the solutions for embedded systems such as AOT compilers and semiautomatic garbage collection make their way back to the desktop and server environment, making Java an even more attractive choice when it leaves home yet again.  Return to our Special Report on Embedded Systems In the story above, we incorrectly referred to IBM's multilanguage IDE as VisualAge for J2ME. The product is called VisualAge Micro Edition. Bruce Abbott (heyabbott@mindspring.com) is a self-employed Java developer.
 RELATED SUBJECTS  Software DevelopmentClient HardwareSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
