3.2. Runtime Architecture
As mentioned earlier, both Java and C# differ from traditional languages such as C, C++, and Visual Basic because the code generated by Java and C# runs in a controlled execution environment. This execution environment provides infrastructure services such as memory management, security checks, and type validation to the compiled or interpreted code. Table 3.1 compares the runtime environments of Java and .NET.
Although the CLR and JVM look deceptively similar in their roles, you should note some key differences.
3.2.1. The JVM
The JVM runs only byte code, also called managed or safe code (code devoid of pointers).
Typically, a single JVM instance maps to a single operating system (OS) process. Multiple applications can run on a single JVM, but there is no logical partitioning of the applications inside a JVM. All applications inside a JVM share the same process resource. This makes interapplication communication inside a JVM (or in-process communication) fast and easy, but it has a major drawback: A single rogue application consuming a lot of memory can bog down the entire JVM instance, thereby affecting other applications running on the same JVM instance. Out-of-process communication is implemented through Remote Method Invocation (RMI) and serialization, which are the foundation of distributed computing in Java. EJBs distributed on different JVMs communicate with each other through RMI calls. A JVM instance is lighter than an OS process and can be embedded in devices. Alternatively, a JVM instance can be hosted by an application server or can be run as a stand-alone program.
| Environment Element | Java | .NET |
|---|---|---|
| Execution environment | Java Virtual Machine (JVM) | Common Language Runtime (CLR) |
| Executed instruction set | Byte code | Intermediate language (IL) |
| Runs what? | Managed code | Managed and unmanaged code |
| Multiple programming language support | Some noncommercial implementations, such as JPython and JACL, which compile to byte code | Visual Basic, C++, C#, JScript, COBOL, Perl, FORTRAN, and other languages |
| Runtime execution mode | Part interpreted mode and part JIT compiler | Always runs compiled native code |
| Unit of isolation of an application | Multiple applications can run on a single JVM. No logical partitioning between applications on the same JVM. They all share the same common OS process resources. | Multiple applications are separated by application domains inside a single OS process. Application domains provide logical partitioning of applications inside an OS process. |
| Operating system | Runs on a wide variety of operating systems. | Currently supported on Windows OS only, although there are noncommercial options for running .NET on other OSs (such as Mono on Linux). |
3.2.2. The CLR
The CLR runs managed MSIL code. The unmanaged code, which is pointer-based, runs outside the CLR. The Windows OS does not support running a CLR application out of the box. A CLR application that ends with an .exe extension is not the kind of true stand-alone EXE application you have come to know as a C, C++, or Visual Basic programmer. Instead, the EXE runs because the CLR is first loaded by the shell executable CLR host, which then runs the user program in that loaded CLR.
A CLR host is an application that sits between the CLR application and the OS process. The host is responsible for loading the CLR into the OS process and for creating logical partitions in the OS process so that individual applications can reside in those partitions. The .NET Framework ships with the following CLR hosts.
3.2.3. ASP.NET
An ISAPI (Internet Server Application Programming Interface) filter that ships with ASP.NET loads the CLR and does the initialization necessary to handle the Web request. (In Javaspeak, ASP.NET is a servlet engine.)
3.2.4. Internet Explorer
Internet Explorer (IE) is the equivalent of a having a JVM inside the browser to run Java applets. Similarly, IE has CLR hosting hooks to run managed code that is directly referenced in the HTML code.
3.2.5. Shell Executables
When a managed application is launched from a shell, a small piece of unmanaged code loads the CLR and transitions control of the application to the CLR.
Every CLR host comes with a piece of unmanaged code that must be run before it can load the CLR. To interact with the operating system for the first time, the CLR host must run some unmanaged code (pointer-based code). After this code is run, the CLR is loaded and the host creates a default partition for running managed code. A user's application is not run in this default partition; instead, the CLR host creates partitions for running these end user programs. As mentioned in Chapter 1, these partitions are called application domains.
Traditional applications are separated by OS process boundaries, and this means that for one application to share resources with another application you must make an out-of-process application. The .NET application domain is essentially a way to partition applications within a single process so that they do not directly share any resources, thereby preventing one application from affecting the execution of another application. Application domains are flexible in the sense that they allow individual applications to be started and stopped without affecting the other applications running in the same CLR instance.
The application domain concept is somewhat equivalent to the J2EE Web application isolation. The J2EE specification mandates that J2EE-compliant application servers partition Web applications by assigning them different class loaders. As a result, two Web applications cannot directly share resources even though they are in the same JVM instance and share the same process space. This ability to have multiple applications running independently in the same process space is what makes the .NET and the Java platforms most suitable for developing scalable applications.