- Introduction
- .NET Framework Architecture (CLR)
- Java Architecture (JVM)
- NET
- J# Versus Java, Example by Example
- Advantages and Disadvantages
- Conclusion
- Acknowledgments
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
.NET Framework Architecture (CLR)
Microsoft's .NET Framework provides an amazing aspect of development, called cross-language development, which includes cross-language inheritance, cross-language debugging, and cross-language exception handling. More generally, we can visualize cross-language development as follows. Code written using any .NET-compliant language (such as C#) should be usable in any other .NET-compliant language (such as VB). Later on, these code modules should be usable in yet another language (such as JScript, J#, and so on). To make this possible, you need a common runtime environment that can understand all these languages.
One of the main design goals of .NET is to encourage cross-language development. The advantage is that the developer can choose the language that best suits for delivering a given module/unit (each language has its own strengths) and still be able to integrate into a single application. The end result is that the language becomes equal. Even employers feel more comfortable with cross-language development, as they have more resources and options at hand.
The .NET Framework also eliminates "DLL hell" and allows for side-by-side deployment of components because registration information and state data are no longer stored in the Registry, where this information can be difficult to establish and maintain.
Next, let's explore the cross-language capabilities of CLR (the Common Language Runtime Environment) and see how IL (Intermediate Language) becomes the core of all .NET-compliant languages. In particular, I'll discuss how to program for the CLR and show some examples that demonstrate the cross-language capabilities of the .NET Framework.
Common Language Runtime
The Common Language Runtime (CLR) Environment provides a rich set of features for cross-language development and deployment. CLR supports both object-oriented languages and procedural languages. CLR manages the execution of code and provides various services such as security, garbage collection, cross-language exception handling, cross-language inheritance, support for the Base Class Library (BCL), and so on. These are the main constituents of the CLR:
The Common Type System (CTS) supports object-oriented programming languages as well as procedural languages. Basically CTS provides a rich type system that's intended to support a wide range of languages.
The Common Language Specification (CLS) is a subset of the Common Type System, to which all language compilers targeting CLR must adhere.
All compilers under .NET will generate a uniform, common language called Intermediate Language (IL), no matter what language is used to develop the application. In fact, CLR will not be aware of the language used to develop an application. For this reason, IL can be considered the language of CLR—a platform for cross-language development.
The Just in Time (JIT) compiler converts the Intermediate Language code back to a platform/device-specific code. In .NET you have three types of JIT compilers:
Pre-JIT (compiles entire code into native code at one stretch)
Ecno-JIT (compiles code part by part, freeing when required)
Normal-JIT (compiles only that part of the code when called, and places it in the cache)
Type safety is ensured in this phase. In all, the role of a JIT compiler is to bring higher performance by placing the once-compiled code in cache, so that when the next call is made to the same method/procedure, it's executed at a faster speed.
The Virtual Execution System (VES) implements the Common Type System. VES loads links and runs Portable Executable (PE) files. VES also ensures loading of the information contained in metadata.
Metadata describes and references the datatypes defined by the VOS type system, lays out instances of classes in memory, resolves method invocation, and solves versioning problems (DLL hell).
Figure 1 depicts the .NET architecture.
){kind=link}
Figure 1 .NET architecture.
The Windows operating systems run on the Intel family of microprocessor chips. To generate platform-neutral code, two things should happen:
Elimination of hardware dependencies such as microprocessor instruction sets, etc.
Elimination of software dependencies such as operating-system-naïve API, etc.
Once the code is compiled using any of the .NET-compliant language compilers, it gets converted to IL (Intermediate Language), as shown in Figure 1. This code is not compiled to machine-native code, but to an intermediate form that doesn't contain any specific information about hardware or software dependencies. When you run this code, since it's not in machine-specific form, it fails to execute. A runtime environment is required that understands and converts the IL code to machine-specific code. This is the role played by CLR (along with the many other functions discussed earlier). I won't talk about these issues in detail here, but will instead concentrate on implementation of cross-language capabilities of the .NET Framework.
Common Language Features
All languages use the same library, the Base Class Library (BCL). However, the syntax used by these languages remains the same as that of the original language.
No language under .NET has its own library.
Garbage collection is the responsibility of the CLR environment and not a language.