Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Java schism? Embedded leads the way

Embedded systems companies want their Java -- with or without Sun

By Rick Cook, JavaWorld.com, 06/01/99

  • Print
  • Feedback
Java for embedded systems is becoming more open, whether Sun likes it or not. Whether is this a good thing depends on who you talk to -- and what you see happening in the future.

For the people who develop embedded systems, the new developments could be anything from a very good thing indeed to the death of embedded Java. More choices could mean Java and Java tools that do a better job of meeting their special needs. The potentially bad part is that if the process isn't handled carefully, it could lead to a hopelessly fragmented Java that sacrifices many of Java's advantages on the altar of choice.

For Sun it's not a good thing at all. Keeping control of Java these days is like playing the smack-the-gopher game. Every time Sun knocks down a challenge to its hold on Java, another one -- and sometimes two -- pop up. It's much too early to say the gophers are winning, but in spite of Sun's major concessions on licensing Java, there are more of them all the time.

In the last 18 months, Sun beat back Microsoft with a lawsuit over its nonstandard (and incompatible) implementation of Java, and it stalled the consortium of realtime and embedded systems companies who tried to wrest away control of Java in those areas. Now Sun faces a wave of clean room implementations of Java, complete with an independent test suite that can be used to validate the API libraries, and perhaps other critical parts of the system.

The problem is hardly confined to embedded systems. In May, Sun announced that it would seek an alternate route to formal standardization via the ISO. In commenting on the situation, Alan Baratz, president of the Java Software Division at Sun, blamed it on changes in the ISO rules. Others pointed to criticism within ISO of Sun's method of handling the proposed standard.

Sun's Java problems are worst, and the breakaway efforts have gone furthest, in embedded systems because of the special needs of embedded systems developers -- and the feeling that Sun hasn't met those needs. Already a handful of organizations, from HP to open source groups, offer or are working on versions of Java that contain no Sun-licensed code. More such independent versions of Java are in the wings and the effort is spreading.

Technically of course, none of these things are Java. They have names like Chai (HP) and Kaffe (Transvirtual), or they are referred to as "a compiler for the Java platform" rather than "a Java compiler" at the insistence of Sun's lawyers. None of them are entitled to use Java's steaming cup of coffee trademark. And none of the companies seem to care very much.

The fact is, what these companies are after is Java without Sun and Sun's licensing terms. The result could be a major win for Java -- and a huge loss for Sun.

The embedded battle

So far most of the skirmishing has been going on in the embedded systems arena. HP's Chai, for example, is intended for embedded systems use, as is Transvirtual's Kaffe in both its open source and licensed versions.

There are some excellent reasons why these fissures are showing up first in the embedded systems market. Embedded systems companies see enormous advantages to Java, but the market has some special demands that Java doesn't meet very well. What's worse, Sun is widely perceived by embedded systems companies as not understanding the market's special needs and as slow to respond to those needs.

  • Print
  • 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