Java schism? Embedded leads the way

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.

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.

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.

Another way around the problem is not to use Java as the realtime operating system (RTOS) at all. This can range from simply grafting a JVM to an existing RTOS, to running Java as a thread within the RTOS. This last method is the approach taken by Negev Software Industries (NSI), which calls it a “Java Software CoProcessor.” In the NSI system, the JVM is a thread within the company’s RTOS, which takes care of the specialized needs of realtime programming. Like any other thread, the JVM is interruptible by higher priority threads, but the JVM provides threading support for the Java software. The threads of Java software are mapped onto the single JVM thread by the NSI system.

The need for speedy change

Then there is the matter of speedy change. How fast will Sun be able to make tools and changes available for the embedded systems community? So far Sun’s record here isn’t outstanding. Sun’s major focus with Java has been on the enterprise rather than the embedded market, and it shows in the release of the various tools. EmbeddedJava, Sun’s version of Java for embedded applications, slipped several times before it was finally released. In fact, HP’s Chai beat EmbeddedJava to market.

Licensing woes

The terms of the Java license were another issue. First, there was the money. Java’s first licensing agreement was based on the way things are done in the enterprise: companies that wanted to use Java in their products had to pay a stiff up-front fee, which might or might not be supplemented by a royalty on each copy shipped.

The amounts involved could be staggering by embedded systems standards. For example, Microsoft paid 8.75 million for its license, according to documents filed in the Sun-Microsoft Java lawsuit. Apple paid million and Netscape paid 50,000. Meanwhile some embedded systems developers said they were offered deals with royalties that could range from to 5 per copy sold.

The big prices may be appropriate for something like a set-top box, but it is highly inappropriate for, say, a piece of medical equipment that may have a production run only in the hundreds. Although microwaves, cell phones, and set-top boxes are definitely part of the embedded systems world, an even larger number of projects involve items that will only be built in the hundreds or thousands. Worse, many embedded systems markets are notoriously price sensitive; royalties of several dollars a copy could eat up a significant chunk of the profits on each sale.

Money, however, wasn’t the only sticking point. Under the terms of the original Java license, improvements on the JVM would have to be offered free to Sun to be passed on to other Java licensees. In an industry as devoted to differentiation by tuning as embedded systems, this was enough to cause a lot of people to balk, especially because of the changes Java needed to suit it to the embedded systems world.

All of this would be of only historical interest except for one thing: During the critical period in 1997 and 1998 when the dark (Sunless) Java movement was gaining its initial momentum, these terms remained in force. Sun didn’t announce its new, more liberal, version of the license agreement until the very end of 1998, by which time HP, NewMonics, and others had either already launched their versions of dark Java or were well on their way. For example, the Real-Time Java Working Group had already set up the R1 committee under the auspices of the National Committee on Information Technology Standards (NCITS) to consider an independent standard for realtime Java. Arguably, Sun could have headed off its problems by loosening the reins earlier, but by the time they did liberalize their licensing, dark Java was off and running.

Sun’s response

Sun isn’t sitting still on any of this. In the last six months the company has launched a whole series of initiatives, products, and legal threats aimed at keeping Java a unified whole and under its control.

Some of these moves have been unqualified successes. For example, Sun won its lawsuit against Microsoft by claiming the Redmond behemoth had made its version of Java not only nonstandard, but incompatible. Some of Sun’s moves have been at least partially successful: Sun has been able to stall the Real-Time Java Working Group with a combination of new licensing terms, a more open standards process, and some expression of intellectual property concerns to NCITS. Currently, the Real-Time Java Working Group is in a holding pattern following a decision by the NCITS not to grant the R1 committee the authority to draft a standard.

With some of the moves it is simply too early to tell. The response that got the most publicity was Sun’s December 1998 announcement of its Community Source Licensing program for Java. Sun has also finally released EmbeddedJava, its version of Java for embedded systems. EmbeddedJava promises smaller, faster Java software for embedded systems.

Meanwhile, Sun’s position is that everything is fine with Java, embedded or not, and the standards effort is moving ahead on all fronts. The company points out that a number of embedded systems companies, such as Wind River Systems, have licensed Java from Sun, and that its own EmbeddedJava and Community Source Licensing agreements address many of the objections raised against Sun’s Java. The real issue, Sun says, is protecting its intellectual property.

“They basically want free access to our trademark,” says Sun Product Line Manager for EmbeddedJava Vicki Shipkowitz. “The steaming cup of coffee stands for security and compatibility. We have to make sure that the end users know that if that see a cup and steam, the platform is compatible.”

Testing, testing. . .

One thing Sun does control, firmly, is the official test suite for Java products. A product can’t be called “Java” unless it has passed the test suite. This has been a major stumbling block for the developers of dark (Sunless) Java because they didn’t have any way of assuring their customers of complete compatibility, not just with Sun’s version of the Java standard, but with other Java-like products.

That changed in May. Cleanroom Java got a major boost when Cygnus announced a suite of test software written to the published Java specifications. Products that pass this suite should work together seamlessly, whether they would pass Sun’s Java test suite or not.

The project, called Mauve, brings together test suites being developed by several different organizations, including Kaffe developers Transvirtual, HP with Chai, and the GNU Classpack project. “We were all working on our own cleanroom implementations of Java,” says Cygnus Java Group Engineering Manager Anthony Green. “We all travel in the same circles and we decided it would be a bright idea to collaborate on the test suite work.”

“Our goal in the Mauve project is to come together and agree on correct behavior,” says Green. In fact, the Mauve test suite can be used to test multiple versions of Java, as defined by Sun. “The approach we’ve taken is to develop a tagging scheme,” says Green. “The individual tests are tagged to different versions of the Java language specification or to different Java Development Kit implementations defined in the Java Class Library from Sun. We’re testing for comparability against what Sun has defined, not defining any new standards.”

This works in part because Sun did a thorough job of documenting Java. “In general, they [Sun] did a pretty good job,” says Cygnus’ Phillips. “There are just a few places where the implementation is undefined.”

Cygnus doesn’t claim that software that passes the test suite will pass the Sun Java comparability tests. In fact, says Green, they don’t know if it will or not since they’ve never examined the Sun comparability suite. “My understanding is that Sun’s comparability kit tests for comparability against Sun’s implementation [of Java],” Green says. “Where that deviates or expands on the written specification, we might miss out. We’re testing against the written standards.”

Is there a future for Java?

As cleanroom implementations to the Java standard proliferate, and as more companies develop embedded tools built around the Java notion, there is an increasing likelihood that, at least in the embedded systems field, Java will slip out of Sun’s control entirely.

Whether Java will shatter like C or Unix is another matter. No one wants to see that happen, but such balkanization becomes a real possibility as dozens of companies develop their own compilers, JVMs, class libraries, and APIs. The proliferation of software built to the Java standard, but without Sun, increases the chances that this will happen.

However, it doesn’t guarantee that it will. Unlike Microsoft, none of these companies have any commercial benefit from incompatible versions of Java — in part because most of the companies in the embedded systems market are fairly small and none dominates the industry the way Microsoft dominates the desktop. For now, the cleanroom implementers are taking precautions, such as the Project Mauve test suite, to see that their products are compatible. We will undoubtedly see a lot of extensions to Java in the embedded market, but they are more likely to take the form of class libraries or tinkering with the JVM.

However this plays out, Java — or things based on Java — is almost certainly going to play a major role in the embedded systems market in the next decade. At this point there is no good alternative that combines Java’s object orientation, strong typing, ease of software development, momentum, and mind share.