Sponsored Links
Java schism? Embedded leads the way
Embedded systems companies want their Java -- with or without Sun
- Feedback
- Discuss
Page 3 of 6
Another company that uses a Java front end on an existing compiler is Metrowerks, a general software company rather than a specialist in embedded systems. Metrowerks is adding a Java front end to its Codewarrior and is using the same tools as other Metrowerks compilers.
This brings us to the whole issue of compiled versus interpreted Java. Java, of course, was conceived of as an interpreted language and Sun is still oriented toward interpreted or Just-In-Time (JIT) compiled Java, where the code is compiled as it is run. Going to conventionally compiled code -- code compiled when the programmer writes the software -- usually means doing away with the JVM and losing the ability to download new or modified applications as needed. In general, embedded systems companies don't need the advantages a JVM brings nearly as much as they need the speed, compact code, and object orientation of the Java language. Embedded systems code may occasionally be patched or upgraded, but it isn't expected to change very often. Nor do most embedded applications involve downloading new applets or libraries. As a result, many of the embedded systems vendors are offering compilers rather than, or in addition to, JVMs.
Garbage collection: not ready for realtime
Another place where the embedded market and Sun's Java vision part company is the matter of memory management. Sun chose to develop Java with automatic memory management -- garbage collection -- using a conservative algorithm and effectively no alternatives. When the software runs out of heap space, everything stops while the garbage collection routine goes through the heap and discards all objects that are no longer needed. The result is easy, hassle-free memory management.
Unfortunately, it is not time determinant. That is, the programmer has no way of controlling when the garbage collection routine runs or how long it takes. And while garbage collection is going on, everything else comes to a screeching halt. This is completely unacceptable to realtime programmers and it doesn't make other embedded systems programmers happy either.
The clean room companies use several strategies to get around the garbage collection problem. One is simply not to use garbage collection at all. The programmer is responsible for managing the heap and avoiding memory leaks and such. Some companies, such as Diab Data, offer a choice. Programmers using the company's FastJ compiler can use conventional Java garbage collection, or they can turn it off and handle memory management themselves.
Putting responsibility for memory management back onto the programmer isn't an ideal solution, but it isn't as much of a problem in embedded systems as it is in most other kinds of programming. Most of the software that will run on an embedded system is a known quantity when the system is designed, and the code sizes are often fairly small. Under those circumstances, it may not be necessary to ever collect garbage if the heap is big enough.
Another approach is to use a different garbage collection algorithm. Both HP with Chai and NewMonics in its PERC Virtual Machine use this approach. Specifically, they offer incremental garbage collection -- the garbage collection is interruptible by higher priority processes.
- 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.