Analysis of Hewlett-Packard’s JVM: Java grows up

Hewlett-Packard Co.’s release of its own Java virtual machine for embedded systems and Microsoft’s decision to use the HP JVM in its windows CE operating system threw a hand grenade in the henhouse of the JavaOne conference — at least if you go by the press coverage. The HP announcements got more ink than anything that happened all week at JavaOne and set everyone trying to decide What It All Means.

My take is that HP’s move means two things:

1. Java is growing up.
2. What’s good for Java isn’t necessarily what’s best for Sun.

Why HP created its own JVM: 4 reasons

Press coverage in the wake of the HP announcement has tended to focus on the financial reasons for Hewlett-Packard’s move. That is, that HP was trying to save money by avoiding Sun’s license fees. That’s true, but it’s only part of the story. In discussing the move, HP tells a more complex tale.

According to Hewlett-Packard, the decision to develop its own virtual machine “compliant with the Java virtual machine specification” (a circuitous phrase that HP employed instead of the simpler “Java virtual machine” to avoid inappropriate use of Sun’s Java trademark) came as a result of four factors.

One factor is expertise. HP believes it can do a better job of designing a virtual machine to run Java on embedded platforms than Sun — and with good reason. Hewlett-Packard has more experience with everything from palmtops to embedded systems than any other major computer company. HP has succeeded in a palmtop market littered with the bones of major computer company failures. HP also has experience in embedded computing through its extensive printer and test-and-measurement businesses. (It is no accident that one of the common interfaces for calculators and electronic instruments is named after HP). Much more than Sun or Microsoft, HP understands what it takes to make a successful embedded application.

One of the things an embedded system requires, according to William Woo, director of engineering at Hewlett-Packard, is flexibility. “For an embedded system that goes in an instrument, we need to think about what the instrument needs. If you’re going to put the embedded system in a printer, the needs are a little bit different,” Woo says. “In embedded systems you have a lot of constraints. Sun isn’t very flexible. You have to ship what they tell you to ship.”

One of the biggest problems with Java for embedded systems is that Java’s automatic garbage collection makes it extremely difficult to write real-time applications. Garbage collection is the process of reclaiming memory from objects that are no longer needed. It makes life easier on software developers than the alternative, which is to have the programmers handle memory management, but it also occupies the system for unpredictable lengths of time at unpredictable intervals. Hewlett-Packard’s virtual machine uses a variant called incremental garbage collection that reclaims memory as it goes. The result is what Woo calls “soft real time,” which isn’t good enough for everything, but provides a lot more determinacy than Sun’s method. Woo hints that HP intends to go further in later versions, perhaps all the way to a true real-time virtual machine.

Another major constraint is what Woo calls “footprint”– how much memory the embedded system requires. Typically in an embedded system, the physical limits combined with the need to hold costs down requires that the software run in as little memory as possible. An extra meg or so of RAM in each system adds up quickly when you’re talking product volumes in the hundreds of thousands, like inexpensive printers. Getting the smallest footprint means customizing the embedded software for each application.

This is an especially sticky point because it runs contrary to Sun’s Java vision, which calls for a limited number of carefully controlled subsets rather than a modification for every product. In the comments after the HP announcement, both Sun and HP referred to this issue. Sun claimed HP’s approach amounted to introducing a random variation of Java, while HP said that Sun’s position was a “religion” rather than rational.

While Sun’s position makes a lot of sense in computers, networking, and systems-level applications, Hewlett-Packard’s position comes closer to the way things typically are done in the embedded systems world. Write-once-run-anywhere is much less important in an embedded system where functionality is carefully defined in the design, user programmability is strictly limited or non-existent, no one but the manufacturer writes software for the item, and software changes consist of bug fixes and updates rather than new applications.

For most embedded systems designers, the attraction of Java lies in things like its high-level object-oriented nature and the uniform development and target environments on a given project. With the exception of some high-end devices like set-top boxes and distributed control system (DCS) controllers for factory automation, the write-once-run-anywhere concept isn’t that important.

The second major factor: Sun’s licensing agreements for Java. “On the financial side, the model Sun is used to is an enterprise side of the model and it doesn’t translate well to the embedded side of the business,” Woo said. In other words, Sun wanted too much money per copy of the JVM shipped. This can be a major problem in the notoriously price-sensitive world of embedded applications. The volumes associated with an embedded product like a printer can be very high, and margins can be razor-thin by computer or workstation standards.

Also of concern, Woo said, are Sun’s intellectual property demands. “The current license intellectual property agreement essentially requires you to give back to Sun anything you put in the virtual machine,” he says. In embedded systems, where software is often a key differentiator, this isn’t very attractive to an innovative company like HP.

The fourth factor is simply availability. According to Woo, Sun didn’t have an embedded version of the JVM a year or so ago when the HP project began. Moreover, Woo points out, Sun still doesn’t have an embedded JVM. EmbeddedJava is still just a specification rather than a shipping product. This may be a rational schedule from Sun’s standpoint. After all, it has a great deal to do in developing the various versions of Java. But Hewlett-Packard and other companies that want to use embedded Java want it now. HP had the resources to develop its own virtual machine and the need for one, so it went ahead and did so.

In sum, Sun doesn’t think like an embedded systems company. That’s hardly surprising since embedded systems are only a tiny part of Sun’s business and Sun has concentrated on the hardware side of embedded systems. HP has a much more business-critical embedded-systems business and does think like an embedded-systems company.

Sun tends to dismiss this argument by pointing out that a number of embedded equipment makers, such as Motorola and Nokia, have signed on with Sun. This is true, but companies like Motorola and Nokia don’t have the range of embedded products that HP does. They produce high-end products like cell phones rather than HP’s mix of products from inexpensive printers to test and measurement equipment.

Beyond specific objections, Hewlett-Packard’s action highlights several key aspects of Sun’s approach to Java. The first is that Sun simply does not have the resources to meet everyone’s needs. The company’s priority for EmbeddedJava makes sense in terms of Sun’s overall Java strategy, but it doesn’t help the companies that want an embedded version of Java now for their next generation of products.

HP isn’t the only company to complain about Sun’s licensing. “I know of a couple of engineering projects people building with embedded systems [who] tried to look at Java,” says Larry Perlstein, a market research analyst who follows Java and embedded systems for Dataquest.”Both of those projects ended up going with something else because they felt Sun was not focused in the embedded space.” Another company, Rockwell, also built its own JVM for the JEM-1 Java processor because it didn’t like Sun’s terms.

Clean-room JVMs aren’t exactly new, especially in the embedded end of the market. Rockwell developed its own JVM for its JEM-1 Java microprocessor (apparently in part because it didn’t like Sun’s license terms), and NewMonics uses a proprietary Java-based VM with extensions to support its real-time version of Java. However, these companies are not as big as Hewlett-Packard — and they didn’t make licensing deals with Microsoft. (For more details about Java and embedded systems, see the recent JavaWorld cover story, “Java embeds itself in the control market.”

“That was probably the attention getter,” Woo says dryly of the deal with Microsoft.

While the arrangement certainly garnered a lot of attention, not all of the resulting comment has been well-founded. Because of the Java wars and Microsoft’s insistence on developing Java in its own (Wintel-centric) image, there is a tendency to regard any significant Java version that doesn’t come from Sun as an attack on the essence of Java. Phrases like “splitting Java” and “shilling for Microsoft” are being used to describe the agreement and Hewlett-Packard’s role.

All such comments probably reflect not the true significance of the HP/Microsoft deal, but the widespread tendency to tie Java’s fate with Sun’s. This association isn’t necessarily valid, and it becomes progressively less true as Java becomes more successful in its own right.

While the HP-Microsoft agreement is a feather in Hewlett-Packard’s cap, it probably isn’t as significant as some people suggest.

For one thing, HP says it has no plans to go beyond embedded systems with its own virtual machine. Although HP supports Java across its line, including on its HP-9000 enterprise systems, its other Java products use technology licensed from Sun.

Moreover, the HP-Microsoft agreement does not signify an insidious plot afoot by Hewlett-Packard to adopt Microsoft’s approach to Java. Unlike Microsoft, which has a demonstrated strategy of co-opting ideas for the benefit of Windows, HP’s move addressed the real needs of a market important to its success. Microsoft’s decision to use the Hewlett-Packard virtual machine is equally transparent. Microsoft needed a good virtual machine for Windows CE, and by licensing HP’s version, it got that without a lot of Sun strings attached.

However, Hewlett-Packard’s move does indicate a significant concern (problem is too strong a word just now) for Sun’s future with Java. If Sun wants to maintain control over Java, it must loosen the reins. Sun has gone to considerable lengths to become the sole master of Java’s fate, but as long as Java remains “open” there is a limit to what Sun can do. The more tightly Sun tries to tie up Java, the more likely it is that companies like HP will develop their own versions of Java or Java-like products. Sun may have the absolute legal right to decide Java’s future, but as a practical matter the company must develop an open, consultative style of guiding Java, at least where the major players are concerned.

As Dataquest’s Perlstein explains, “Hewlett-Packard has a reasonably large stake in the embedded market and views itself to some extent as a software company. They found themselves getting a little concerned about ceding their software strategy to Sun. This was a way to keep their destiny in their own hands.”

Finally, an observation every Java proponent should find encouraging: Hewlett-Packard’s action in cloning and licensing the virtual machine shows that Java is growing up. Java is no longer just Sun’s good idea. It is increasingly seen as an important technology that is making important contributions.