The battle between Java and C# is never ending, find out how differences at the VM-level affect this debate

clr-vs-jvm

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.

clr-vs-jvm
CLR vs JVM High-Level Functionality

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. It differs in that it compiles and optimizes the “hot spots” in the code that are used most frequently.

Each of these compilation strategies has its own tradeoffs in terms of performance. Because the CLR compiles all of the machine code once when it’s called at runtime, execution time can improve in some circumstances. But on the other hand, if a small portion of the code will be needed at a high frequency, Java’s HotSpot compiler can improve efficiency over time with additional optimization.

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<int> and List<String>, whereas the JVM can’t (Java implemented Generics as part of the compiler). 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.

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 C# 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 C# 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 and platforms 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!

Tali studied theoretical mathematics at Northeastern University and loves to explore the intersection of numbers and the human condition. In her free time, she enjoys drawing and spending time with animals.
  • drdamour

    got a formatting issue around List and List guessing thsi should present as List and List

    • Tali Soroker

      Thank you for pointing that out! It was supposed to be List and List. I’ve adjusted that now (:

  • drdamour

    “Java’s HotSpot compiler can save time” would be less confusing as “Java’s HotSpot [JIT] compiler can save time [at startup]”

    • Tali Soroker

      I’ve also adjusted this section to be more clear, thanks again!

  • Matthias Schuster Scharmer

    To your information: .NET is not a language. C# and F# is. Plus: .NET Core is so crossplattform as the JVM is, so this is a match today. Why do you show it otherwise in the graph? And the JVM is more oriented towards dynamic typing, while the .NET platform is static typing oriented. (Rich Hickey)

    • Tali Soroker

      Thank you for your comment, I definitely see how the graph can be misleading. You’re absolutely correct that CLR Core has crossplatform compatibility, I did mention it in the post but it’s not reflected well in the image. Sorry about that!

    • javierbds

      However .Net Core is a couple of years old (evolving fast), while the JVM (and .Net) have existed, improved and evolved for decades … I see no match at all! ( I still see Scala as not stable enough, btw).
      Another meme I take issue with it the supposedly multi-language nature of .Net: last time I checked the number of languages, compilers etc. that have been developed in the JVM is orders of magnitude higher that in .Net. So, while in theory that may be the case, in practice is the other way around.

  • http://zud.io/ markrendle

    This post contains much that is wrong.

    For example, both the CLR and JVM JIT compilers only compile methods to machine code when they are called. Java’s HotSpot is a JIT feature that analyzes execution as the program is running, and re-compiles frequently-used code (i.e. “hot-spots”) with more optimal machine code than the first pass produces.

    Your comparison of generic handling is muddled, and misses the primary difference: that the CLR supports reified generics whereas in Java they are a compiler feature, more like C++ templates. Conversely, co-routines and closures are features of the C# compiler, rather the CLR.

    And your assertion that “Production Monitoring and Exception Handling” are better on the JVM seems to be based entirely on the fact that your product supports it. There are many and various excellent production monitoring and exception logging tools and libraries for .NET.

    Honestly, you should take this post down and research it better. It is misinforming people and doing your company a disservice.

    • Tali Soroker

      Hi Mark, we’re sorry you feel this way, and thank you for getting in touch. I’ve made adjustments in the article RE your comments about the difference between the JIT compilers and co-routine/closures being implemented by the compiler rather than at runtime. Thank you for your help with that.

      You’re right that there is a rich ecosystem of monitoring tools available for .NET, we were referring to our tool in this section which is currently available for JVM-languages and will soon be available for .NET as well.

      • Elliott Beach

        The post says that all of the machine code in CLR is compiled in advance. That can’t be true if the CLR is using just-in-time compilation. Right?

        • Tali Soroker

          Yes, I’ve updated that sentence to be more clear. The difference between the JIT compilers in the CLR and the JVM is not that machine code in the CLR is compiled in advanced, but that the machine code is compiled once, when it’s called at runtime. The JVM uses what’s called the HotSpot compiler which recompiles frequently run code (or, hot spots) to optimize its performance.

      • http://zud.io/ markrendle

        Hi Tali,

        Sorry, I only just saw your reply. Thank you for taking the time to respond and for clarifying the original post 🙂

    • javierbds

      Last time I checked, Java generics were not like C++ templates in that a generic Java class does not generate new object code per instantiation as C++ templates did. The main feature of Java generics is that you can generify a class (with care) and all existing compiled client code will still keep working (backwards compatibility).