Java Dives Into Real-Time Role

Thanks to tweaks and modifications, Java is finding a home in critical applications ranging from the military to telecommunications.

David Lammers, Contributor

July 28, 2005

7 Min Read

For several years now, real-time versions of Java from smaller companies such as Aonix, Aicas and Apogee Software have jousted for market share. Now, large companies such as Sun Microsystems Inc. and IBM Corp. are starting to field technology aimed at the real-time Java market, often working with large customers in the military-aerospace arena.

To date, real-time Java often has been "soft" real-time. As Anders Flodin, director of strategic alliances at Aneas (Stockholm), said, "Java is not going to be used anytime soon for projects that could crash the space shuttle."

In robots and industrial control, in fiber-optic switches, telematics and set-top boxes, Java is beginning to inch its way into markets that were traditionally dominated by C-based code. "Whether it is real-time or not is open to debate, but Java's percentage in embedded has been increasing slightly year-over-year," aid Steve Balacco, a senior analyst at market research firm Venture Development Corp. (Natick, Mass.). "From my understanding, the folks in the military are among the early adopters of real-time Java."

Earlier this year, Venture Development surveyed about 500 embedded developers, and only 9 percent said that their current project would include a Java Virtual Machine (JVM). Of those that said their project would include Java, slightly less than half (46 percent) said the effort involved real-time aspects.

In military projects now under way, such as the U.S. Navy's DDX battleship or the Pentagon's effort to create a networked battlefield that would connect soldiers and their commanders, Java may play a role in real-time applications. Data must be captured and delivered, and decisions must be communicated rapidly. "The military programs involve 'a system of systems'-some of which are real-time-that are interconnected," Balacco said.

Kelvin Nilsen, chief technology officer at Aonix, said that real-time Java is seeing strong growth overall. "I would say about half of our new business [at Aonix] is in the military sector," he said. "There is a strong upsurge in the military, in unmanned aircraft and other newly deployed systems. There is activity in telematics, both in the commercial and military sectors."

The military's goal, Nilsen said, "is to put a backpack on a soldier and take advantage of the available bandwidth for secure, digital communications, and then make good use of the data. Java provides a quicker way to automate those functions."

"The military contractors have been public about using Java, that they are investigating real-time Java," said Joe Jacobs, vice president of sales and marketing at Objective Interface Systems Inc. (Herndon, Va.). "What is not clear is within the system, where they switch tools to Java. Thus far, Java has been used for enterprise aspects of these systems, not for control of the turbines and not for the avionics."

The recent big splash in the Java market came at Sun's JavaOne conference in late June, when the Santa Clara, Calif., company deployed its Project Mackinac as a commercial product named the Sun Java Real-time System (RTS).

Greg Bollella, a distinguished engineer at Sun who previously worked on real-time Java at IBM, has been heading Sun's real-time Java project. Bollella said Sun's first implementation of Java RTS is based on the Solaris 10 operating system, with latencies in the 10- to 20-microsecond range for dual-processor, Sparc-based workstations. Response times are slower for single-processor systems and depend on the number and type of device drivers, how many PCI slots are filled and other factors, he noted.

Asked which processors Sun management would support next, Bollella said ports to either the X86 or PowerPC platforms are under active consideration.

"Inside Sun, the first question is whether the hot spot JVM is ported to that OS and hardware combination," he said, adding that some 32 combinations have been ported. Sun plans to support a family of development platforms, with various hardware footprints and different "temporability" demands-that is, latency and jitter times.

Pricing from Sun also is being formulated, he said, though many customers with long-range projects will negotiate individual contracts rather than pay strictly on a per-seat basis.

Bollella said Java RTS is an "advanced, unified," real-time application development platform, which "means it has real-time scheduling techniques instead of hit-and-miss. It also means it is using object-oriented methodologies for design instead of procedural coding."

Java RTS supports a mix of nonreal-time and real-time threads, and it will be supported by a modern tool set, using both Netbeans and Eclipse-based development tools, he said. The product includes features that exert control over asynchronous events and support asynchronous transfer of control.

Unified, Bollella said, means engineers could do all of their programming in Java, instead of "splitting up projects among C, C++ and Ada." Programmers could use regular Java for nonreal-time coding, implement real-time threads for the soft real-time portion and then use "no heap" real-time threads that do not resort to garbage collection, thus guaranteeing deterministic behavior.

Garbage collection refers to the process of freeing up dynamically allocated memory that is no longer referenced. Its impact on response times is a central debate among Java experts.

James Hunt, chief executive officer of Aicas (Karlsruhe, Germany), said Sun's Java RTS announcement is "not bad news for us, because it raises the interest in real-time Java. We have many more programs going now than we did last year."

With 18 people on staff, Aicas is involved in the European Union's Hydras project to develop a next-generation military aircraft. Aicas' U.S. affiliate, based in Connecticut, is working with U.S. military contractors on real-time Java projects. Several of these contractors are working on high-performance tasks, where no time delays are permitted for garbage collection and other functions.

IBM, a leader in using Java for enterprise applications, is working closely with Apogee (Campbell, Calif.) to deploy Java in the embedded markets. Steve Gruber, director of embedded-software business development at IBM, said the two companies have been working on custom development projects with "several" customers that require some real-time responsiveness. IBM has real-time Java projects at several locations, with the largest at Hursley, England. Projects range from industrial control to set-top boxes and telecommunications.

Garbage issues
Flodin at Aneas said that Sun, IBM and others are working to improve the performance of Java with some new garbage-collection algorithms.

"I think real-time Java will be used in systems where we can live with failure," Anders said, referring to the softer forms of real-time systems.

But Bollella said Sun's Java RTS product includes major advances in garbage collection-improvements that allow programmers who are adept at real-time programming to tackle hard real-time applications within Java.

"Overall, we think applications developers with domain experience shouldn't have to think about the ugly details below Java RTS," he said.

But he also noted that "real-time programming is hard," demanding "fundamental engineering trade-offs when thinking about real-time garbage collection and predictability of the execution of logic with respect to time."

Because Java RTS mixes real-time and nonreal-time code, developers can use regular Java for maximum-throughput portions and move to "low pause time" with garbage-collection techniques that "break work up into smaller bits" so the garbage collection isn't noticeable, Bollella said.

Also, the real-time garbage collectors within Java RTS have tuning knobs associated with them to direct how much work must be accomplished within particular intervals. When predictability must be maximized, programmers work on a "heterogeneous reference space" with different kinds of memory heaps, including immortal memory and different versions of scoped memory.

"In those cases, the collector and threads might be working on different heaps. Some of those heaps the collector might not touch," said Bollella.

In Java RTS, there comes a point where the garbage collector ceases to operate, reducing overhead due to collection to zero, but requiring more analysis.

"The real-time collectors have tuning knobs to tell collectors when to run, and how much to run. To tune them, the programmer must have values to tune," he said. "To do that, the programmer has to know how an application program is behaving with garbage collection over time."

Real-time programming is challenging because programmers "must do some extra things," Bollella went on. As predictability improves, "what does increase is the complexity of the programming model. You have to do more analysis, some extra things to make the analysis more tractable. When the programmer hops over to the scoped-memory side, you have to think more. It's true: Real-time programming is hard."

    See related chart

Read more about:


About the Author(s)

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights