Real-time Java Wars Yield Uneasy Truce

Alexander Wolfe

Sometimes the most effective way to wage a war is to declare victory and go home. That's what's seemed to have happened in the battle between Sun Microsystems. and its rivals over a series of real-time extensions to the Java specification.

To understand where real-time Java stands today, this tangled, fractious story is best told backwards. We'll start with the latest developmentsıwhich could result in some useful implementations by year's end. Then we'll work our way back through to the history of the full-blown fights over real-time Java that flared in late 1998.

The initial fracas flared up between Sun and Hewlett-Packard. The sticking point was and continues to be control of the spec. While Sun is willing to accept input from other companiesıindeed, it is developing its spec under the rubric of its "Java Community Process"ıSun nevertheless wants to maintain firm control of the final document. That is, they have decided not to cede the spec over to one of the industry's neutral specification-maintenance organizations.

That position has stuck in the craw of the many other players, both large and small, that have been involved. For one, IBM has been playing a prominent role in attempting to get past the conflict and move real-time Java forward. Indeed, many believe IBM may yet emerge as the preeminent purveyor of Java in the embedded and real-time arenas.

"I call IBM the stealth company," said Jerry Krasner, director and research editor of Electronics Market Forecasters. "They have been superb at pushing forward the standard and at launching tools for deeply embedded development." More good news is that this year's JavaOne conference, to be held in June in San Francisco, should yield some hard information of interest to developers. Further informationıperhaps the announcement of some of the first real-time Java implementationsıcould be on tap this fall at the Embedded Systems Conference.

Lay of the land
A little background is required to understand the lay of the real-time Java land. It's confusing, hard to navigate, and involves a cast of players which are often hedging their bets by sitting on both sides of the real-time Java fence. Even those involved in the work find the shifting sands of alliances and development efforts confusing. Indeed, it is the objective of this article to recount as clearly as possible what has happened and where things are going, even though no single engineer in the industry is privy to every facet of the multi-sided Java jewel.

To recap, the conflict over a real-time Java specification began simmering at ESC in November 1998 between Sun and Hewlett-Packard. That's about the time Sun corralled a group of its Java licensees and began to develop a spec of real-time extensions. The Sun-led group was called the "Java Experts Group."

Unhappy with what they felt was a heavy hand by Sun in its control of that spec effort, a competing collection of Java vendors led by Hewlett-Packard and NewMonics Inc., formed its own group, known as the "J Consortium." Both parties wanted to control extensions that have to be added to the Java Virtual Machine to enable it to support real-time operation. The extensions help ensure that a given Java implementation can deliver guaranteed responses to interruptsıa tenet of real-time operation.

Interestingly, both groups worked to create their real-time spec using the same baseline document: "Requirements for Real-time Extensions for the Java platform," published by the Information Technology Laboratory of the National Institute of Standards and Technology (NIST).

Adding to the inbred aspect of the two opposing efforts is the fact that representatives from both the Experts Group and the J Consortium had a hand in creating the NIST requirements document.

Winning the war?
Today, according to most knowledgeable observers, Sun and the Experts Group have won the spec battle.

Currently, version 0.9.2 of the Experts Group's spec is available on Sun's Web site (see Resources). It's expected that version 1.0 will be published on or around June 1 by Addison-Wesley as part of its well-known series of Java books. The 1.0 spec itself is currently set to be formally unveiled at the Embedded Systems Conference this fall.

"This specification, which is close to beta release, will benefit companies who are anticipating an industry standard application programming interface (API) that extends the Java platform with hard real-time capabilities," said Vicki Shipkowitz, an embedded product manager at Sun.

More important, several companies are believed to be hard at work on reference implementations of real-time Java. These include QNX, Agile, and another company I'm not allowed to mention, having been sworn to secrecy. The only hint I can drop is that it is definitely not a couple of engineers working in a Silicon Valley garage. (Quite the contrary, in fact.) Also expected to field a real-time Java is a company called TimeSys.

For its part, IBM is thought to be writing the conformance test suite through which future, third party, real-time Java implementations can be validated.

Diverging approaches
In terms of technology, the two real-time Java specs provide a fascinating view into the different ways engineers believe that they can take advantage of Java's higher level of abstractionıdespite its trade-off of poorer runtime efficiency.

Sun's (that is, the Experts Group's) spec is somewhat looser, in that it gives developers more freedom as to how they can implement its required features. In contrast, the J Consortium document, which is also available on-line (see Resources), is much more specific as to mandated practices, including class structures and the handling of different types of events.

"The garbage-collection behavior is very much unspecified by Sun," said a Java-savvy engineer. This could lead to charges that the Sun spec does not strictly mandate determinism; that is, all implementations hewing to the document would be embedded, but some would be more "real-time" than others. (Sun says it has laid down firm provisions for hard real-time performance.)

Sun's initial rationale for its real-time spec was laid out in a document which read, in part: "This extension is necessary because the guarantees and APIs provided by the standard Java platform do not meet the needs of real-time systems. We propose to develop a real-time Java standard extension specification and reference implementation. The underlying technology needed to implement this spec is essentially a Java virtual machine (VM) that is built to honor deterministic guarantees of its run-time behavior. A central component of this VM is a real-time garbage collector. This VM would only be implementable atop suitable target platforms, such as a real-time operating system." The spec was to have profiles aimed at both "hard" and "soft" real-time systems.

As for the real-time operating system (RTOS) community, most RTOS vendors have steered toward Sun's side of the fence. That's because the competing J Consortium run-time doesn't necessarily even need an RTOS. It can run on the bare metal. That's not true of Sun's approach, which requires that the real-time APIs be interfaced through an RTOS.

Game's not over
Meanwhile, the J Consortium made a decision to focus on a smaller group of real-time requirements than were laid out in the broad-based "Requirements for Real-time Extensions for the Java platform" document published by NIST. "We decided to pare back the ambitious list in the NIST requirements document and focus on core extensions, which address the traditional embedded developer who's used to C or assembly language," said Kelvin Nilsen, chief technology officer at NewMonics.

"It's unclear which group Sun is trying to address," Nilsen charged. "They're not addressing issues of memory footprint and aren't fully addressing the issues of performance and latency."

Regardless, it's not currently clear how many J Consortium-based implementations will make their way to market. "The J Consortium is continuing to make tweaks to their spec, but there's no plan that I'm aware of for anyone to implement it," one industry pundit claimed.

Not so, according to NewMonics's Nilsen. "NewMonics and some other companies like Aonix are looking at ways to bring the J Consortium spec to market, but no companies other than Omron have announced anything officially," he said.

Indeed, the game may be far from over. One fascinating rub is that nearly every Japanese Java vendor is supporting the work of both groups. In the United States, companies have been more apt to take sides. While Sun constitutes the backbone of the Experts Group, the J Consortium is populated by Hewlett-Packard, Microsoft, NewMonics, Siemens, Omron, and Aonix (the latter three are members of both groups.)

For example, the APIs specified by the J Consortium have been added to Japanese vendor Omron's proprietary implementation of real-time Java. For that reason, the Omron code effectively constitutes a superset of the J Consortium spec.

Siemens, which is one of the fence sitters, prepared an interesting technical presentation to the J Consortium (it's not known if the documents were shown to the Experts Group, too). The slides add some quantitative meat to a proposed series of real-time profiles, which would address a range of real-time requirements from soft to hard. Specifically, the Siemens engineers proposed an initial profile which requires "the fewest extensions and which reflects existing real-time practice."

This profile is based on the use of call-back routines with separate execution contexts (that is, events are processed distinctly). "Such a profile can provide for extremely short worst-case response" in the tens of microseconds, the Siemens engineers noted in their slides.

They also suggested limiting priority levels to no more than ten. Finally, garbage collection should fit within the regular thread-priority scheme and should be pre-emptable only by threads that don't themselves require memory clean-up.

Where's Waldo?
Despite such assiduous specmanship by both committees, a strange fate seems to have befallen real-time Java. While the technology was clearly the star of the fall 1998 Embedded Systems Conference, lately, an eerie silence has settled upon the community.

Indeed, earlier this year, perhaps the biggest shock at the Spring 2000 edition of the Embedded Systems Conference in Chicago was the relative quiet surrounding real-time Java. In contrast, last year the conference was abuzz with advance word on great things to come.

One reason for this year's relative silence may be a split in viewpoints among embedded developers. That is, developers anxious to find an alternative to Microsoft's Windows CE (a real-time version of which has not yet been completed) are hoping to get their hands on some meaty real-time Java implementations. (Still to weigh in is the wild card of embedded Linux; it's currently an open question as to whether that OS is ready for prime time in real-time applications. More about embedded Linux next month.)

Still, Java developers appear to be plugging away quietly, especially in the Internet appliance realm. The trend has already started, as a host of embedded systems developers rush to ready an emerging generation of Web browsers, pagers, smart phones, and a bunch of other small-form-factor productsıthe latest in downsized, low-power, consumer-oriented gadgets.

Even at this date, however, no one is positive quite how Java will fit into this brave new embedded world. Indeed, contrarian experts are not yet willing to commit to the extra memory footprint and software libraries Java tends to require.

That's why the potential entrance of an embedded or real-time Linux opens up a whole new can of worms. The full-blown implementation of Linux is available essentially for free (that is, it's open source); however, that version is more appropriate for desktop and enterprise markets. The dynamics of Linux in embedded apps are not yet clear, although product announcements are imminent. Should that come to pass, it could force Sun and its allies to place real-time Java, too, into the open source realm, if only to maintain the OS's position as a potent competitor. Indeed, reports to that effect have been circulating for months, though no officials will provide definitive comments.

Stop-gap measures
For the time being, Sun appears to have an interim strategy up its sleeve. The company is poised to launch something called the "Java Community Process 2.0 (JCP 2.0)." That will supersede the current JCP under which the Experts Group's spec is being developed.

However, Sun won't yet say exactly what JCP 2.0 is or how it's different from today's JCP. A company spokesperson did provide a nebulous explanation to the effect that "there is a great dialogue going on between all the members of the Java community. They are exchanging ideas very proactively. I think you can expect something in the near future, but it's not imminent."

What exactly that means, no one in the Java community is quite sure. Pundits believe JCP 2.0 will be more open than the current processıthough how much more open is anyone's guessıbut that Sun will still have the final say when it comes to the Java spec.

Vigorous adolescence
Moving forward, most Java supporters believe the language is entering an adolescence from which it will emerge with renewed vigor.

"The embedded stuff is clearly a longer haul than the Enterprise was," James Gosling, one of the original developers of Java at Sun, said. While things are now looking much brighter, that still seems to be the case.

In addition, everyone agrees that a rapprochement is in order if Java isn't to suffer the same fate that fragmented Unix into dozens of flavors. "For a real-time Java spec to be effective, it's going to have to include the major players coming together in a totally open standard," said Krasner of EMF. HP, Sun, and IBM all say they want to agree on a single spec for real-time Java.

That's why the engineer with his or her real-time design on the chopping block might be wise to consider that it may well be the marketplaceırather than a that will have the final say.

Alexander Wolfe is managing editor for microprocessors and embedded at Electronic Engineering Times . He holds a B.E. in electrical engineering from Cooper Union. He wrote assembly language code for embedded systems in the early '80s. He later co-authored From Chips to Systems: An Introduction to Microcomputersı2nd Edition (Sybex, 1987). He can be reached at awolfe@cmp.com

Resources
Many of the Java specs and related documents are available on the Web:

www.rtj.org (Java Experts Group)

www.j-consortium.org (J Consortium)

www.nist.gov/itl/div897/ctg/real-time/ (NIST requirements document)

java.sun.com/products/ (Every API document ever released by Sun)

java.sun.com/javaone (The annual Java-fest, slated for June 6-9 )

www.newmonics.com (A different approach)