Sponsored Links
Java schism? Embedded leads the way
Embedded systems companies want their Java -- with or without Sun
- Feedback
- Discuss
Page 2 of 6
To understand this, it helps to know what the embedded systems world needs and why Java is a combination of ideal and crippled for embedded systems. (For a basic look at what embedded system are, see the sidebar.)
Portability issues
Take, for example, the idea of portability embodied in the slogan "write once, run anywhere." Portability is important in embedded systems, but in that market portability has a somewhat different meaning than in other parts of the enterprise.
That's because in embedded systems there are perhaps a dozen major families of processors that could support Java and most of them exist in several different, and slightly incompatible, versions. Where an enterprise is likely to be built entirely on Intel and perhaps a RISC processor like the PowerPC or Alpha, the embedded systems business uses those chips as well as processors from MIPS, ARM, 68000, several Digital Signal Processor (DSP) architectures, and others. What's worse, a lot of those processors aren't used to develop the software that runs on them. Development work is done mostly on workstations or PCs and the resulting programs are cross-compiled onto the target processor.
A virtual machine does away with cross-compilation, but it leaves the developers stuck needing a JVM for every processor they want to support. And not just a generic JVM, either. If performance is important (and it always is), the JVM must be carefully tuned for each architecture. Supplying all the necessary JVMs to the embedded market is a major effort.
Compiled vs. interpreted Java
However, if a compiler is written in the right way, it's a lot easier to port a compiler than it is to port a JVM. The right way in this context means splitting the compiler into a language-specific front end and a hardware-specific back end. The performance-critical optimizations for the hardware are in the back end, which can support many different languages by changing the front end.
This is exactly what a lot of modern compilers do, including the GNU compiler best known in its C/C++ version. There is now a Java front end for the GNU compiler, and like the rest of the GNU software it is open source. "We offer GNU on about 125 host-target systems," says Kevin Phillips, Java-Linux product manager for native products at Cygnus Solutions, a Sunnyvale, CA vendor specializing in embedded systems products.
"The GNU compiler is designed to be easily retargetable, but also to host different languages," says Cygnus Java Group Engineering Manager Anthony Green. "The Java front end is new, but it's not like something bolted onto the side because the GNU compiler is designed for this kind of architecture."
The GNU compiler is the best known and the most popular example of this strategy, but it is not the only one. HP's TurboChai compiler uses the same strategy in what is, if anything, a more flexible manner. The output of TurboChai is C code, which the developer can run through his or her favorite C compiler and use all the available C tools to develop, optimize and debug. This is less convenient than an all-in-one compiler, but it gives developers access to a lot of tools.
- Feedback
Resources
- A comparison of the NCITS and Sun's Community Source License processes (from the Real Time Java Working Group's point of view)
can be found at
http://www.newmonics.com/webroot/rtjwg/newcomparison.html - Sun's announcement of its plans for Java realtime extensions is at
http://java.sun.com/pr/1998/11/pr981103-02.html - Sun's Community Source License initiative represents Sun's attempt to open up the development process for Java and several
other Sun products. A FAQ on Sun's community source licensing is at
http://www.sun.com/software/ - The Real-Time Java Working Group has some specific criticisms of Sun's process for developing a realtime version of Java.
A question and answer paper on the Real-Time Java Working Group is at
http://www.newmonics.com/webroot/rtjwg/qa.html - Memory management, and especially garbage collection, is a particular problem for Java in realtime and embedded systems. There
are several different ways of doing it. The method Sun used in Java is particularly lame from an embedded systems point of
view, although it has significant advantages in other areas. A discussion of Java's garbage collection mechanism from an embedded
systems viewpoint is at
http://sourceware.cygnus.com/java/papers/nosb.html - HP's Chai can't legally be called a clone of Java without violating Sun's trademark. Whatever you call it, Chai is one of
the first, and most developed, Java alternatives. Information on HP's Chai is available at
http://www.hpconnect.com/embeddedvm - Kaffe is another alternative to Java. The basic version is open source and freely downloadable from the Transvirtual Web site.
(There is also a Comerica version of Kaffe with more tools and such which is not open source.) Information on the Kaffe virtual
machine is at
http://www.transvirtual.com - Jini has important potential applications in networked embedded systems. An explanation of Jini in networking technologies
is on the Sun site at
http://www.sun.com/jini/whitepapers - For more information on Jini, check out Jiniology, the new JavaWorld column debuting this month at
http://www.javaworld.com/javaworld/jw-06-1999/jw-06-jiniology.html - FAQs on Jini are at
http://www.sun.com/jini/faqs/index.html - SIDEBAR
- SIDEBAR_HEADEmbedded, realtime, and near-realtime
- An embedded system is a computer that resides inside another product. It can be
- as complex as a flight control system for an airliner or as simple-minded
- as a microwave oven, but almost all embedded systems share certain
- characteristics.
- Most embedded systems are extremely cost-constrained. Going to a bigger ROM
- because of code growth may only add a dollar or so to each item, but when
- your volume is in the hundreds of thousands or millions a year, the costs
- become enormous.
- Because of the cost constraints, a lot of embedded systems will never use
- Java. There is still a significant market for 4-bit controllers, and only in
- the last few years have 8-bit and 16-bit controllers come to predominate.
- However, as products become more complex and embedded systems become more
- sophisticated (and the need to cut software development times increases),
- the market for 32-bit, 64-bit, and larger controllers will grow.
- Realtime systems are an especially demanding component of the embedded
- systems market. In a realtime system, you have to be able to perform an
- operation within a given time window. The window can range from
- milliseconds to minutes, but the system must complete the
- task within that time. Otherwise, the result can be anything from burned
- toast to a national disaster.
- True realtime systems are expensive because of the need to guarantee
- determinacy. But not all realtime applications have to be timed down to
- the millisecond. Many of them have windows of seconds or minutes, so a
- lot of realtime jobs can be done by ordinary embedded systems software.
- These are so-called soft realtime or near-realtime applications.
- Technically, the software doesn't meet the realtime requirement of absolute
- determinacy, but the time constraints are so loose it doesn't matter.
- :END_SIDEBAR
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2008 Network World, Inc. All rights reserved.