The battle between Java and .NET is never ending, find out how differences at the VM-level affect this debate
We’ve written extensively on the differences between C# and Java, covering our favorite features in each that don’t have an equivalent in the other. With the fierce battle over which language is better than the other raging on, we’re diving deeper into the battleground to look at the differences and similarities between their respective Virtual Machines (VMs).
Let’s do it.
TL;DR: The Top 5 Similarities and Differences Between the CLR and the JVM
Top similarities between the CLR and JVM include:
- Both Virtual Machines (VMs)
- Both include garbage collection
- Both employ stack-based operations
- Both include runtime-level security
- Both have methods for exception handling
Top differences between the CLR and JVM include:
- CLR was designed to be language-neutral, JVM was designed to be Java-specific
- CLR was originally only Windows-compatible, JVM works with all major OSs
- CLR uses a JIT compiler, JVM uses a specialized JIT compiler called Java HotSpot
- CLR includes instructions for closures, coroutines and declaration/manipulation of pointers, the JVM does not
- JVM is compatible with more robust error resolution and production monitoring tools
Now that we’ve established the 5 top similarities and differences, let’s jump into what all of this means. Starting with the basics, and then diving deeper into what all of this means.
What’s a Virtual Machine?
It’s not hard to guess that a virtual machine (VM) is a virtual emulation of a computer operating system. Beyond that, though, there are two different implementations of this kind of system abstraction.
System virtual machines exist as fully-functional operating systems and are typically created as a substitute for using a physical machine. In this way multiple environments can run on the same machine simultaneously. But, that doesn’t sound like our beloved CLR and JVM.
The Common Language Runtime (CLR) and Java Virtual Machine (JVM) are both process virtual machines. That means that rather than executing an entire operating system, they are specifically designed to run a process or program without being dependent on the platform environment.
A Closer Look at the Similarities Between the CLR and JVM
The CLR and JVM are both virtual machines and they both perform platform-independent operations, namely, executing compiled source code. Essentially, these virtual machines both act as an intermediary step between the programmer’s source code and the system’s machine code, allowing for greater usability by various types of processors. In the image below, you can see how the high-level functions of the two are practically identical.
Beyond their basic functionality, both also include methods for garbage collection, runtime-level security and exception handling. And one last similarity to mention, both employ stack-based operations, the most common approach to storing and retrieving operands and their results.
But, of course, for every similarity that these VMs share, a difference in implementation can be found. Still, just as with programming languages, the development of these VMs advances in a kind of leapfrog-like motion. One implements something like the “mark-sweep-compact” approach to garbage collection, and the other is soon to follow.
And Now Some Major Differences
Language and Platform Compatibility
One potentially superficial difference between the CLR and JVM (though one that likely influenced the way they developed) is that the JVM was created to work specifically with Java, while the CLR was designed to be language-neutral. Conversely, the CLR was originally designed only to run on Windows OS whereas the JVM was always OS-neutral. Times have changed though, as we all know, now there is CoreCLR which runs on Linux and Mac, and many more languages have been developed to work with the JVM.
This leads to the fact that, for the most part, the differences between the CLR and JVM are also signifiers of the differences between the languages that employ them. Or, you can say that some of the most significant differences between languages (for argument’s sake, let’s say C# and Java) really are implemented at the VM-level.
JIT Compilation
A big difference that we see at the VM-level is that although both use JIT (Just-in-Time) compilation, the compiler isn’t called to run at the same time. The CLR compiles all MSIL code into machine code when it is called at runtime. The JVM uses a specialized performance engine called HotSpot to do JIT compilation of Java Bytecode into machine-readable code. This method only compiles the “hot spots” in the code that will actually be used.
Each of these compilation strategies has its own tradeoffs in terms of performance. Because the CLR compiles all of the machine code in advanced, execution time can improve in the long run. But on the other hand, if only a small portion of the code will be needed for a method to run, Java’s HotSpot compiler can save time.
Implementation of Language Features
Another smaller difference is that the CLR was built with instructions for dealing with generic types and for applying parametric specializations on those types at runtime. Basically, that means that the CLR recognizes the difference between, for example, List and List, whereas the JVM can’t. The CLR also allows users to define new value-types in the form of Structs, while value-types in JVM-based languages are fixed (byte, short, int, long, float, double, char, boolean), though there are plans in the works to change this.
There are a few more differences like this one that present more as differences at the language-level. Some of those include: closures, coroutines and pointers which are available in the CLR, and not in the JVM.
Production Monitoring and Exception Handling
Although both include methods for exception handling, overall differences between the two can affect compatibility with different exception- and error-monitoring tools. This, in turn, affects troubleshooting strategies and workflows.
For example, developers working with JVM-languages can take advantage of the full root cause analysis that OverOps provides, while .NET developers and other CLR-language developers won’t be able to use the tool until the .NET/CLR version is released in the near future (Sign up for the .NET BETA here).
Performance and Adoption
A 2003 study by a Jeremy Singer at the University of Cambridge looked at the performance differences between the CLR and JVM and found that, at least at that time, that their performance was practically identical.
The study found that the Java compiler produced smaller bytecode, which can have an impact on VM performance. However, when it came to running code, the execution times came out pretty much 50/50, with the CLR and JVM each executing faster about half of the time. Based on this study, when it comes to the fierce opposition between Java and .NET users, it looks like the VMs themselves play a bigger part in differentiating capability than they do in directly affecting application efficiency.
This also make sense when looking at adoption. In enterprise companies, it’s not uncommon for developers to work with both CLR- and JVM-based languages. This can happen especially in large companies with many different departments working on various projects and applications. For example, Accenture uses both .NET and Java, as does Intuit.
Community
Speaking of the competition, we know that .NET and Java both have strong communities backing them up. Within those communities, developers ask questions and engage in in-depth conversations on sites like StackOverflow. A quick search for the name of each VM reveals that CLR has been tagged 3,250 times compared to the JVM which has been tagged 8,628 times.
Outside of StackOverflow, there are also extensive communities that are cultivated by Microsoft and Oracle themselves. There, users can find additional information and resources related to more than just the CLR and JVM. Topics there include implementations in the cloud, troubleshooting questions and more.
Beyond this, though, the communities are definitely more centered around individual languages such as .NET, Java, C/C++, Scala, etc.
Final Thoughts
Looking at these VMs at the highest-level, the differences between the CLR and JVM seem almost negligible. However, in many (if not most) cases, the differences at the VM-level mirror the key differences between the languages that use them. Because of the way these VMs, and their corresponding languages, were built, each functions slightly differently in order to provide the functional capabilities that their creators wanted to provide.
What do you think about the differences between the CLR and JVM? Will you choose your next programming language based on which VM it uses? Let us know in the comments below!
| Published on Java Code Geeks with permission by Tali Soroker, partner at our JCG program. See the original article here: CLR vs JVM: How the Battle Between .NET and Java Extends to The VM-Level Opinions expressed by Java Code Geeks contributors are their own. |
This is written in 2018, so the first image is plain wrong. There is a clr for windows, linux, mac.