If you were to trace the origins of the excitement about Java, you might go back to May of 1995 when Sun first announced Java at SunWorld '95. The sexiest part of the show was HotJava, a browser written entirely in Java and capable of downloading smart content to the desktop.

Remember Java applets? From a business perspective, the most interesting part of the show was an announcement that Netscape, then the hottest technology company in the world, was going to put support for Java in Navigator, then the world's dominant Web browser. Microsoft, many speculated, was dead. It had missed the boat on the Internet by trying to emulate AOL with MSN. Netscape, Sun, and the combined forces of the open standards community were going to bring the Windows "hairball," as Sun's CEO called it, down.

It has been not quite 10 years, but two things are clear: Microsoft and Windows are still here, and Java has become the most important thing to happen to computing in 25 years. The real revolution happened, and it happened on the server, not on the client. The advent of servlets, JDBC, and the worldwide adoption of J2EE as the standard for enterprise computing has changed the way the world does business. Clients have also changed a lot: whereas 10 years ago a typical software vendor would have written its front ends as a heavy-client application using VB or PowerBuilder, now more often than not they will write a Web front end. But make no mistake: the real revolution happened on the server side.

Java in the Enterprise
While the focus on Java enterprise technologies is often on technologies like Web services, messaging, or EAI, here we'll focus on a part of the enterprise stack that is often overlooked: the Java Virtual Machine. At the heart of every Java application is a Java Virtual Machine, or JVM. A JVM is like a microprocessor, but implemented in software. A microprocessor is capable of executing a program written in machine code. That machine code is made up of machine instructions that are implemented by the microprocessor, in silicon. Likewise, a JVM is capable of executing Java classes that are made up of Java bytecodes, the equivalent of machine instructions. Unlike a microprocessor however, Java implements these bytecodes in software in a program called the Java Virtual Machine. This is what makes Java portability possible: you need to write a Java Virtual Machine for a specific architecture such as Macintosh OS X, or Microsoft Windows, or IBM's AS/400 (and associated chipsets) only once and then you can run any Java program, usually with no changes whatsoever. Java is now such a widespread and successful platform that most modern computing platforms, from handhelds to big iron, have at least one Java Virtual Machine available to them, usually several.

Because of an early focus on the client side, the first JVMs were focused on issues paramount to client-side performance, such as graphics rendering and event handling. Enterprise applications have different requirements. BEA Systems conducted a survey of the most important requirements in a Java Virtual Machine.

Reliability
Any time a server application goes down, possibly thousands of clients and often many other applications are adversely affected. This can create angry customers, lost time and revenue, and much anxiety for IT personnel. By contrast if a client application fails, the damage is almost always easily contained. Indeed, the most successful client platform of all times, Microsoft Windows, has never been particularly reliable. Not so on the server side.

Scalability
Client software typically has one user. Server software may have thousands of clients, both users and applications. It must be able to handle large loads, and more important, it needs to be able to grow and accommodate added load with additional software. For example, if you know that a server can handle 1000 users, you'll be able to handle 3000 users with 3 servers. This is called linear scaling.

Nondisruptiveness
Anyone who's been using Java for a long time knows about garbage collection pauses. The Java program simply stops, the disk grinds as the JVM reclaims unused memory, and the program then restarts. A nondisruptiveness requirement means that the infrastructure must never get in the way of the application. In the case of a JVM it means no long pauses. In a server environment, with potentially gigabytes of memory, this is a formidable technical challenge.

High Performance
High performance is like motherhood and apple pie: no one can argue with it and everyone wants it. But in a server environment this is especially important because it makes for a lower Total Cost of Ownership (TCO). TCO is a key concern of IT today, and when possible it is always better to use one machine rather than two. In addition, high performance is often a prerequisite to good scaling.

Client vs Server
Since enterprises require reliability, scalability, and performance from their server infrastructure, to provide these things we need to look at the specific needs of the applications that run on these servers. Server applications and client applications differ in fundamental ways. Figure 1 shows these differences.

Several things jump out right away. First, server applications make vastly greater use of threads and I/O, while client applications make greatest use of code compilation (just-in-time compilation, or JIT.) This makes sense because the role of servers is usually to perform many different tasks for many different clients (many threads), and to send back the result of these tasks (lots of I/O) while clients tend to do a lot of graphics-intensive work (lots of drawing and computation.)

Java Virtual Machines designed in the early days of Java, including the Sun Classic JVM, HotSpot, and HotSpot derivatives like the IBM JVM, were designed with a client focus. HotSpot, as its name implied, was the first JVM to focus on code compilation by detecting "hot spots," or sections of code that run often, and compile these sections on the fly - just-in-time compilation. In 1999, students from the prestigious Royal Institute of Technology in Sweden attended a session on JVMs at JavaOne in San Francisco. Joakim Dalhstedt remembers his "Eureka" moment: "As we were listening to the talk, I thought to myself: this is all for the client - what if we were to design a JVM really optimized for the server?"

Appeal Virtual Machines AB was born shortly thereafter and in 1999, JRockit 1.0 came out. In 2001, BEA Systems hired the entire Swedish team and acquired JRockit. In a constant effort to ensure the broadest possible customer choice of platforms, BEA teamed up with Intel to make certain that a truly world-class JVM would be available for customers to use with Intel architecture servers.

From the very beginning BEA WebLogic JRockit incorporated unique technology features for optimized server performance, such as multiple garbage collection mechanisms.

Different applications use memory in different ways. Because Java shifts the burden of memory management from the developer to the JVM, it is important that the JVM be as intelligent as possible about how to manage memory. One application for example may create lots of short-lived objects, while another may create mostly large, long-lived structures. One application may require 100 MB of heap while another requires 2 GB or even more. For JVM buffs, BEA WebLogic JRockit supports:

• Generational garbage collection
• Concurrent garbage collection
• Parallel garbage collection

JRockit also takes adaptivity further than most other JVMs. For example, based on how often a particular section of code is used it will spend more or less time optimizing it, thereby spending compiler cycles more effectively. Another area where the JRockit team is hard at work is GC adaptivity. Today the type of garbage collection must be determined manually, through the usual process of application performance testing. The JRockit engineers are currently hard at work on a mechanism that will automatically determine which garbage collection scheme is optimal and set it without user intervention.

Management, Management, Management
One of the ongoing frustrations of developers and IT operations personnel alike has been the black-box nature of JVMs up to now. WebLogic JRockit goes a long way toward addressing some of these grievances. The BEA WebLogic JRockit Management Console lets users find out a wealth of information about what goes on in the JVM, such as detailed memory and thread usage information. In addition, the user can configure the JVM to send warnings when suspicious or critical conditions are reached, all entirely configurable. Most important, this monitoring capability comes basically free of charge.

When the user turns off metrics collection, there is virtually no overhead. And to make it all even easier, the console is able to manage multiple JVMs at the same time.

One of the shortcomings - overcome in the most recent version of BEA WebLogic JRockit, 8.1 - is the lack of support for JVMPI, the standard profiling interface for JVMs.

Fastest JVM Anywhere
JRockit is not only exceptionally well architected, robust, and manageable, it is also the fastest JVM available in the lab as well as in the field. BEA WebLogic JRockit consistently received the highest marks in industry-standard benchmarks such as SpecJBB and SpecJVM, as well as more specialized benchmarks such as SPECjappserver. That success, says Arvind Jain, product manager for WebLogic JRockit, translates into real TCO gains: "In today's budget-constrained IT environments, customers are not only placing a high value on raw performance but also price-performance."

Customers seem to agree. At BEA's eWorld user conference in February 2003, Bank of New York presented their most recent efforts to test their existing infrastructure on JRockit and Intel-based servers. They found dramatic cost savings, on the order of 70% in some cases.

The moral of the story is that while some of the most exciting developments, like XML, EJBs, and Web services happen at the top of the stack, some of the most important ones happen deep down, in the JVM.

JRockit is available at www.jrockit.com.