Java schism? Embedded leads the way
Embedded systems companies want their Java -- with or without Sun
By Rick Cook, JavaWorld.com, 06/01/99
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone
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.
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone
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