Friend or foe?
What does Intel really think about Java?
Does Intel even care about Java? Yes. But why? And how much should it care? Rick Cook examines the strategic impact of Java on the world's most successful microprocessor company. (2,100 words)
Intel is aware that Java exists. Take the recent JavaOS for Business announcement. IBM and Sun are codeveloping this Java-based thin-client operating system. However, IBM is also working with Intel to develop the Intel-specific version of JavaOS for Intel processors.
This isn't the only Java project Intel is supporting. In addition to helping companies such as Novell with their Java implementations for Intel, the microprocessor giant has also made an investment in WebLogic -- a San Francisco-based maker of Java application servers and Java-to-database integration software. Besides the investment, Intel is helping WebLogic tune its Tengah applications server for Intel's forthcoming 64-bit Merced chip.
Officially, Intel is Java-neutral. But being Java-neutral does not mean being Java-free. In fact, Intel has a number of other Java-related projects underway, primarily as a partner with companies developing Java on Intel platforms. "Our primary goal is to serve our customers by making sure Java runs well on the Intel architecture," explains Intel spokesperson Jane Rauckhorst.
Despite its low-key approach to Java, Intel needs to remain a player in the Java game. "There's a clear strategic requirement for Intel to pay close attention to Java," says Evan Quinn, director of Java research at International Data Corp. (IDC), a Framingham, MA, market research firm. The reason, Quinn says, is simple: "In the near term, Intel's primary objective is to make sure they provide effective marketing and to some extent engineering support to organizations who are driving servers that may be running Java."
In fact, Intel has a fairly well-developed Java strategy, in equal parts composed of 1) keeping up with the Joneses, 2) benign neglect, and 3) pushing for advantage wherever possible. It's a low-key strategy, but it is still having an important impact on Java.
Teaming up with Big Blue
The JavaOS announcement illustrates several aspects of Intel's Java strategy.
The most obvious one is that by working with IBM, Intel can help to extend the reach of its processors into the thin-client market. This is especially sweet for Intel because of IBM's initial commitment to the PowerPC architecture as the basis for its network computers (NCs). IBM says it still plans to use PowerPC for network computers, but it will offer Intel-based models as well. This firmly establishes Intel in the small-but-growing NC market.
Scoring off of the PowerPC is nice, but Intel has agreed to do similar work with a number of companies that want to make sure their software sings on Java. That is the essence of Intel's Java strategy today. "Basically they're focusing on partnerships right now," Quinn says. "They don't have an obvious approach to Java at this time. But wherever they believe there's a software solution that drives the sales of Intel-based systems -- servers for example -- they're looking to partner."
And Intel is a very good partner for major Java players to have. Two of the things Intel brings to the party are compiler technology and an intimate knowledge of the Intel architecture. Those are extremely important to Java because one of its fundamental problems is its speed, or lack thereof. Java may never be as fast as C code, but it can be made a lot faster with optimized compilers and better Java Virtual Machines (JVMs). This generally doesn't buy you as much speed as going to a compiled version of Java or a Java processor, but it can mean major improvements without violating the write-once-run-anywhere mantra of Java.
This strategy can be especially effective if you optimize your JVM for a particular architecture, such as Intel's. A modern processor has elaborate pipelining and simultaneous execution features that are best exploited by software designed to work with those features. Of course, if the people designing the JVM know the architecture intimately, this is all the more effective. And no one knows the Intel architecture better than Intel.
You can't be a world-class processor company today without some very heavy-duty compiler talent. Processors and the compilers that run on them are just too closely interlinked. And that makes Intel the logical company to work with if you want to make your JVM or compiler scream.
Enter Eric Schmidt
Intel is also busily at work with Novell to produce NetFire, its next-generation JVM for NetWare.
Eric Schmidt: Java-friendly
The NetFire partnership is particularly interesting because Novell already has a JVM in the soon-to-ship Version 5 of NetWare. In fact, Novell's current JVM is one of the fastest versions available for Intel processors. By working with Intel, Novell intends to make the next version of its JVM even faster.
"Java is hugely important to us on the server," says Ronald Palmeri, Novell's vice president of strategic relations. "It's important that we have a rich development environment on NetWare. [Novell CEO] Eric Schmidt clearly has an orientation towards Java."
While Palmeri points out that Novell isn't "betting the farm on Java," it is clearly an important part of his company's NetWare strategy. Over the last several years, Novell has been working to convert NetWare from a LAN operating system to a full-blown network and server operating system with an emphasis on the server part. That means offering services well beyond traditional file-and-print. This is why Novell now includes Oracle's database engine and Netscape's Web server with NetWare. It is also why Novell feels it must offer a comprehensive set of development tools to NetWare users, such as a JVM.
Palmeri describes Intel's position as "If Java, then Intel." In other words, if you're going to run Java, Intel wants you to do it on an Intel processor. One of the ways to make that happen is by making sure Java implementations on Intel architecture are as strong as they can be.
There's an added bonus for Intel here as well. Novell has been claiming that its current JVM (which runs on Intel processors) significantly outperforms Unix implementations. Anytime Intel architecture can produce comparable performance to a Reduced Instruction Set Computer (RISC) system, Intel likes it.
Tuning the NetWare JVM
Each optimization project is different, depending both on the architecture and the application. Part of the optimization is as simple as knowing what not to optimize for. The JVM in NetWare gives graphics a fairly low priority, for example, and that means it can speed up other operations.
"We have some unique opportunities in integrating the JVM with NetWare," says Mike McKay, Novell's vice president of corporate architecture. Referring to the faster calls the NetWare kernel makes running on the innermost, most trusted ring of an Intel chip, McKay says, "NetWare executes out of Ring Zero for all of its operations, so we aren't burdened with the transition. We've also done intensive optimization of our protocol stacks and the way we handle buffering and packet processing." "Network I/O benefits dramatically from this." Novell's thread model and virtual memory system (new on NetWare 5) are highly tuned to the server environment. "That pays off nicely with the Java Virtual Machine," says McKay.
There's a great deal more to optimizing a JVM for an architecture, but much of it is considered proprietary, and the people doing the optimizing aren't willing to talk about it.
Palmeri sees the cooperation with Intel on the JVM as a logical extension of its relationship with Intel. He notes that about the same time NetFire was announced, the company also announced it would work with Intel to optimize NetWare for Intel's Merced architecture.
At this point, Novell's Java effort is driven more by anticipation than by customer demand. "Our customers are still experimenting with Java on the server," Palmeri says. "Companies are beginning to develop some things. In this case we're trying to be a little ahead of the curve."
The P-system precedent: hard-wiring the virtual machine
If Intel decides Java is really important, the company is in a position to make major moves that could benefit Java. One possibility is for Intel to build a Java Virtual Machine into its processors.
The notion is compelling from Intel's point of view. For one thing, it would solve Java's performance issues. A hardware JVM gives about the best possible performance on standard Java, theoretically much better than Java compilers.
There is precedent for such a move. The P-system operating system of the early '80s was built around a virtual machine, and eventually at least one company produced a processor whose native language was P-code (the P-system's instruction set). However, the P chip didn't go anywhere, in part because the performance of P-system software dragged on machines of the time. This serves as a warning as well as a precedent.
The microprocessor business, however, has changed dramatically since the early '80s. One of the changes has been a proliferation of transistors. Where an Intel 286 had about 130,000 transistors, a Pentium II has millions, and the next generations will have millions more. That translates into the ability to have your cake and eat it too, as far speeding up Java performance is concerned. Technically, it would not be much of a feat for Intel to devote a couple of hundred thousand of those transistors to implementing a JVM.
But not yet. An on-processor Java Virtual Machine would be a major investment of time and talent for Intel, and the company would need to ensure that it would be attractive to its customers. At this point, a JVM on Intel is pure speculation, and it is likely to remain so for a while -- if for no other reason than the fact that such a move would require a very stable JVM.
To date, Java has been developing too fast for JVMs to have the kind of stability Intel would probably want. However, that is beginning to change with the latest round of JVMs, which are just coming out. (See the story in the August issue of our sister publication, Java World, on the latest Java Virtual Machines.) These new JVMs -- most of which are still in beta -- are about 10 times as fast, much more stable and much more scalable than their predecessors.
The Intel effect
Intel's involvement in Java is one of those cases where what's best for Java diverges from what's best for Sun. Java benefits from Intel's partnerships and other Java-related efforts. But Intel and Sun are rivals in the microprocessor business, and what helps Intel's processors is likely to hurt Sun's processor business.
Of course, trends in computer design can hurt Intel as well, especially the move to concentrate more intelligence and processing power in servers. Whether you call the client a network computer or a networked desktop, the fact remains that the processing action in the modern enterprise is shifting off the desk and into the servers. This is wonderful for server companies like Sun, but you don't move the kind of processor volumes Intel is used to by selling servers. Even if Intel could completely subsume Sun's processor business, it would only be a drop in the bucket to the chipmaker. If the trend toward server-centric computing grows, Intel will need something to juice up its desktop replacement market. Most network computers will not represent virgin territory. They will either replace legacy computers or run new software on those computers. To continue to generate the volume it needs to make its business model work, Intel would have to come up with a processor tuned to this environment. If Java becomes a mainstay of the new environment, that means a processor tuned to Java.
If the network computer or something like it sells in volume, and if Java is a significant part of those systems, we can expect to see Intel pay even more serious attention to Java.
About the author
Rick Cook divides his time between writing about the Web, computers and high technology. His most recent stories for SunWorld are "The Intelligent Storage Network" (May 1998), "Linux lines up for the enterprise" (January 1998), and "IBM bets on Java" (December 1997). Reach Rick at firstname.lastname@example.org.
If you have technical problems with this magazine, contact email@example.com