For about three years, Java inventor James Gosling and a host of other programmers have been working to come up with extensions to Java that would enable its use in "real-time" computing devices--those that require an instant response to an action such as a pilot pulling an airplane's control stick or a car engaging on an antilock braking system.
Java has caught on for mainstream use on desktops and servers, but Sun and its real-time Java partners are having to go through some contortions to adapt it to the real-time area. Among the changes Gosling described at the Embedded Systems Conference Wednesday are a loosening of the restriction that kept Java programs from actions that could harm the computer and some adjustments to accommodate the process by which Java tidies up computer memory.
But the adjustments are worth it, according to Gosling and Greg Bollela, leader of the real-time Java effort at Sun. The reason: Programmers who write software for real-time and other "embedded" computing devices are facing the same crises that have afflicted those who program general-purpose computers. Naturally, the two believe Java alleviates the problem.
"We're operating at our limits of our ability to comprehend just what the heck we're doing," Bollela said during the pair's keynote address at the conference.
Embedded computing systems such as cell phones, network routers, elevators and cars are getting more complex and more computerized with each passing year, and connecting these devices to services over the Internet is only compounding the problem. Java makes it easier to program gadgets and connect to widely different programming projects, Gosling argued.
Sun has had mixed results in its years-long push to spread its products to the embedded world. In microprocessors, Sun's chips are popular chiefly in servers, not in embedded devices, where products from Motorola, MIPS, Intel and others prevail. Sun has had more success with its software, though it has taken years.
Gosling was the inventor of Java, a programming language and other software that let Java programs run on any sort of device, regardless of what chip or operating system it uses. While Java is installed on the vast majority of desktop computers and is common in servers, it's only just begun to make inroads into the embedded area.
Hampering embedded Java have been political battles with competitors such as Hewlett-Packard and NewMonics and the difficulty of squeezing Java software into devices that typically don't have a lot of memory or CPU horsepower.
But Sun is making inroads. One real-time Java company, defense contractor Mitre, has used Java to run the real-time systems of the U.S. Air Force's Airborne Warning and Control System (AWACS) radar and control plane, Gosling said. Java required adjustments, though. One of the key features of Java is its "sandbox," a security requirement that restricts Java programs to a protected part of the computer where they can do no harm. The feature was designed to accommodate the Java programs that arrive over network connections and might not be trusted.
But real-time Java has a provision for Java programs that can actually write to the computer's memory, a region that's outside the protective sandbox. Bollela said, however, that only certain basic Java programs are granted this privileged access.
"We allow physical memory access, something that regular Java doesn't," Bollela said. "But it's pretty controlled, so we think it's pretty safe."
Another problem was Java's process of "garbage collection," a periodic sweep that reclaims memory was once used by a computing process but not freed up when the process was finished. Garbage collection, while convenient for programmers, imposes a large burden on the computing system and could invalidate the guarantee that a process can be started in real time.
Garbage collection is the "single gnarliest corner" of the real-time Java specification, Gosling said. Essentially, real-time Java has a provision for some processes that must be able to run even when the garbage collection is taking place.
The result of these changes to Java is a modification to Sun's Java tagline, "write once, run anywhere."
The phrase is "a marketing slogan I don't actually like much," Gosling said. And in the real-time area, he prefers the heavily modified phrase, "write once carefully, run anywhere conditionally."
The 20 companies involved in Sun's real-time Java effort are collaborating to have a reference design ready by the end of the month, said Vicki Shipkowitz, a group manager in Sun's embedded software effort. However, she and others refused to say when they expected a final version of the specification.
Helping the software effort are companies such as aJile and Zucotto Wireless are building chips that process Java instructions, helping to sidestep some of the processing burden imposed by Java. It now appears that the Sun effort and the competing real-time Java effort from a group called the J Consortium are diverging.
Gosling said the Sun effort is focused on devices where only a small part of a computing system--perhaps 5 percent--requires a real-time response. But NewMonics Chief Technology Officer Kevin Nilsen said in an interview Wednesday that the J Consortium's specification is designed for systems where 80 percent of computing operations are in real time.
Though there are technical differences, "We don't see a huge political difference between the two efforts," Nilsen said.
Sun is sticking by its Java Community Process for choosing and defining the standard, though. "It's not a perfect process, but it seems to be working," Shipkowitz said. "They were invited early on and they chose not to be a part of it."