Evolving the JRE @ JDJ

When Java was first released, it was immediately attractive due to its ease-of-use and the promise of WORA (write once, run anywhere). As it evolved, the value of the JRE abstraction has manifested itself in many ways not immediately apparent from the days of animated applets. For example, the widespread adoption of Java on the server helped to drive the development of several performance profiling and application monitoring tools and techniques. These tools and techniques bring great value to the Java platform but some also have significant limitations and drawbacks. This article surveys current tools and techniques and looks at new initiatives to evolve the JRE into a truly manageable runtime.

Managed Runtime Environments
One of the original key goals of Java was to provide a layer of abstraction that allowed a programmer to write code that was portable to many different hardware/OS platforms. However, the Java Virtual Machine (JVM) doesn't just offer programmers a machine-independent way to run their code, it dynamically manages executing code. The JRE was the first mainstream Managed Runtime Environment (MRTE) with characteristic properties such as:

• Bytecode: A machine-independent executable representation of application code
• Automatic memory management: Object allocation, garbage collection, dynamic heap resizing, and compaction
• Program security and correctness: Bytecode verification, sandbox for applets, no pointers, type checking, array bounds checks, and null pointer checks
• Dynamic optimization: The VM can adapt to the characteristics of the running application and selectively optimize the code it generates
• Exception handlers: Deal with unusual situations and errors

These things are not unique to Java. Some are also characteristics of Smalltalk (developed in the early 1970s) and there are also close similarities to Microsoft's .NET CLR. Interestingly, at least one MRTE implementation supports both Java and Microsoft's Common Language Infrastructure (CLI), with only a relatively small amount of customization required to handle the different bytecode formats of CLI and Java.

MRTEs have emerged rather quietly. When Java was first released by Sun in 1995, most of us weren't really framing the benefits of Java in terms of managed code, rather we were struck by the promise of WORA and the benefit of a powerful JDK API, which made it pretty straightforward to start developing your own applications, even if you were new to the world of object orientation. Many of the intrinsic benefits of an MRTE were initially secondary to a new breed of programmer but proved key to Java's expansion to the server, where it became easier to write secure, robust, multithreaded, memory-intensive applications. It was soon also widely recognized that the abstraction required to handle an intermediate binary format need not come at the cost of performance, as MRTEs can use a dynamic code optimizer to react to the runtime characteristics of an application. Look at what Microsoft is doing with .NET, or the work Intel is doing to evolve its new range of 64-bit Itanium processors, and it's clear that the (inevitable) migration to MRTEs is widely recognized by both software and hardware vendors. In fact, the proliferation of MRTEs is seen by many as the biggest paradigm shift in software since the move from assembler to high-level programming languages.