Head of HP's Embedded
Java VM Project Speaks Out
In the week following HP's announcement that it would develop its own Java for consumer devices, HP World talked to Jim Bell, general manager of Internet Embedded Software, part of the Internet Software Business Unit (ISBU), about HP's new direction for embedded devices.
On the reasons why HP developed its own Java Virtual Machine and libraries...
Bell: We are a manufacturer of a diverse set of products, some of which are very high volume--for example, printers, VeriFone financial terminals, and instruments. So we're talking about volumes that in the aggregate, over HP's product line, are many tens of millions per year. HP makes about one-third of all the instruments in the world. That gives us a real customer perspective on needs in the embedded-device market. Now issues actually are typical rather than unique for that market, so a manufacturer of consumer devices--for example, microwave ovens or office appliances, like telephones and fax machines--faces many of the same problems HP does in the embedded-device space.
The needs of the embedded-device market drove our desire to have a Virtual Machine targeted specifically for the small-footprint-embedded market. The concept of write once, run anywhere (which is central to enterprise Java) really applies only to general-purpose machines.
You don't expect to run SAP on a microwave oven--microwave oven manufacturers aren't willing to pay to put all the libraries necessary to do that in an oven, and the consumer isn't going to pay for the manufacturer to do it. So the issue is really about how one subsets the full set of libraries to fit into the smaller number of resources available in an embedded application. That's really the whole controversy.
On the value of Java as a technology for embedded devices...
Bell: Let's look at the simplest case first--where a device is not connected to the Internet. Take a refrigerator, for example. Here, what you get is the greater productivity and robustness of the Java language working with tools available in terms of producing what today can be quite large embedded applications. A television set quite likely has several million lines of microcoding in it, and you wouldn't care to have to reboot it several times a day. The word appliance means "turnkey"--you don't have to think about it.
The way to build these more complex turnkey systems is with Java. Now this is worth a factor of two or three perhaps, but the big payoff is in the next step, the interconnected step.
Once you are interconnected, you then have the ability to download things over the Internet. So you are able to add new functionality, and you are able to update and invoke programs, etc. These are the capabilities that have the most dramatic impact.
On Java-enabled printers...
Bell: One example we've been using involves LaserJets. This is a hypothetical function, not necessarily one that would appear in first release. It's quite feasible that when the toner runs low on a LaserJet, a notification appears on the screen on your browser to tell you what the situation is so you can get a spare toner. At that same time, the LaserJet could contact the purchasing department to place an order for a replacement backup order. Or, if stocks were running low, it could place a direct order to the inventory-management machine at Fed Ex in Memphis, and the backup would arrive via Fed Ex. That's just one tiny example.
On HP's Virtual Machine, and how it's different from Sun's...
Bell: It's neither identical nor very similar to Sun's. It was developed totally independently through a rigorous clean-room procedure, the results of which were verified by third parties. From the point of view of the user (a programmatic user or a human user), however, no differences are visible at the interface level. A program that runs on HP's Virtual Machine would run on any compliant [existing Sun Java] VM.
The differences are in other dimensions. Our VM, for example, is only half a megabyte; it's smaller than anything Sun is shipping. Our VM is less expensive than Sun's, and, perhaps most important for our own internal users who have pressing needs, ours is shipping and Sun's isn't.
On developing HP's Java clone...
Bell: We are very careful to use other people who had no previous exposure to the Sun VM, for example. Physical isolation, if that makes sense. And in the final stage we hired a team associated with universities in European countries who weren't familiar with the technology from either us or Sun and who went through line by line to make sure there was no similarity between the two implementations.
On whether HP's Java will fragment standards...
Bell: We support the goal of compatibility. If people who talk about possible fragmentation of Java mean there is not a monopoly anymore in terms of providing compatible products, well, we plead guilty to that. But fragmentation really is about compatibility for the benefit of the customer, not for the benefit of the producer.
Actually, the idea of competition in implementing standards is normal, both in the computer field, where nobody expects there to be just one COBOL compiler or one company that makes COBOL compilers, and within society in general, where you go to your corner garage and buy some SAE 40 motor oil for your car, and nobody claims that you are the only one who can use that oil. As a matter of fact, the whole idea of standards is that customers can get both the benefits of compatibility and the benefits of diverse competition at the same time.
On enforcing compatibility...
Bell: What enforces compatibility? Suppose someone wanted to do his own alternative to, say, HTML. What would stop him? Other people wouldn't write to it. If that person wrote stuff, other browsers wouldn't be able to read it. In any network standard, particularly as the installed base grows and inertia sets in, the value of being interconnected in a standard way becomes clear.
Being interconnected in a nonstandard way has no value. If you have a telephone that is the best in the world--with a three-dimensional, full-color picture of whoever you are talking to--but it doesn't plug into a socket, and you and your friends are the only ones to have it, it is almost worthless.
We're happy to work with Sun. We believe by far the best outcome is to have a single, universally accepted standard for the full Java library. In particular, our energies are focused on having the right things happen with respect to standards for embedded applications. That's a green-field area. The kinds of knowledge needed to do that are very widely distributed among different classes of consumer- and office-appliance manufacturers, television set makers, fax makers, and so on. And we feel it's important that the full set of accumulated expertise and wisdom of the full community be brought to bear on that, rather than that any one company be in the position of making and retailing those decisions.
On comparing splits in Java to splits in UNIX...
Bell: UNIX represented a quite different situation. The UNIX discussion was about extensions, and this is about subsetting. It's heading in the opposite direction.
Remember that our Java is for embedded applications, so it is a separate question from the load of commonality in the general business computer, and we've already mentioned absolute compatibility there (write once, run anywhere). In the case of embedded devices, we think that it's useful for there to be natural limitations. The program you'd like for your telephone may not run on your microwave oven, and vice versa.
We want to let Virtual Machines talk to each other, let everything talk to each other on the Web. You can imagine a piece of code running inside your telephone, inside your microwave oven, and inside lots of different things. We want the kind of compatibility that would let you move things that can reasonably be moved.
On HP's decision to license its embedded VM to third parties...
Bell: I need to give you a little background on how we got to
where we are. Really, our original plan was to license technology from Sun.
But for the reasons that I've talked about--the functionality, the economics,
and the timing--that did not turn out to be possible. So we had to do it
ourselves. While we were doing
So our announcements last week really reflected a turning point, in which we announced our plans to the world and our willingness to license it to others on a selective basis. This is not the kind of product that's going to be shrinkwrapped and [sold] in the computer store. I don't want to give any of the names of our prospective partners without their permission, but I can tell you the nature of some of these companies. One category is made up of software companies, and obviously the first one to be announced was Microsoft. Another consists of the real-time operating system companies. Another category is made up of chip makers. And a fourth would be large, big-name appliance manufacturers.
You can imagine that similar companies are coming to us. The same issues we have with the JavaSoft license are also ones other companies have. They're looking for an alternative.
The estimates at JavaOne were that in 10 years there will be roughly 5 billion objects with embedded Virtual Machines. Looking at America, there are now 13 small motors per household, and I think in that same way in not too many years in every household there will be several devices with embedded Virtual Machines.
On Java as enabler of HP technology versus as a source of revenue...
Bell: The goal of the entire ISBU, headed up by Joe Beyers, is
In this regard, what HP is doing with Java is similar to what we're doing in areas like security, imaging, Changengine technology, and so on, all of which could have been thought of as accelerators of HP systems sales but have a much broader value than that. And so all are targeted to the outside world.
As a competitor of Sun's...
Bell: I just want to reiterate in the strongest possible terms that the enterprise systems are absolutely and completely devoted to total compatibility with Sun products. For the enterprise, write once, run everywhere is very practical and not at all controversial.
And we'd like to see very large acceptance of Java across the enterprise, just as we would within the embedded space, but there are differences. The way to think of HP's strategy is as a single strategy--a fork with two separate prongs on the tactical end.
For embedded devices, we have a product that's smaller [than Sun's] and is shipping today.
How HP's licensing agreement differs from Sun's...
Bell: Without getting into a lot of detail, let's say that the specific things Sun licensees complained about turned out to be the ones we complained about in terms of intellectual property. These terms are different in our licensing agreement. We feel that if somebody invents something, then it certainly might be nice for that to come back to them and give them a general product for others to use, and we'd be willing to consider paying for that. But that is their own business decision as to whether they want to make that available. It's not ours by right.
Regarding pricing, the Sun licensing has no cap. For a very high-volume manufacturer, our licensing would be much lower than Sun's.
Information Appliance Shipments
Send email to Interex or to the