CLR vs JVM: Taking the Never-Ending Battle Between Java and .NET to the VM Level – JAXenter

Weve all heard the arguments for the age-old debate between Java and .NET, and as with many things, there are many factors to consider to determine what best suits your application. But what if we take it a bit deeper to the virtual machine level?

There are a handful of similarities between the CLR and JVM both are high performance software run times, both include methods for garbage collection, code-level security and rich frameworks and open source libraries. Both also employ stack-based operations, the most common approach to storing and retrieving operands and their results.

But there are also some very stark differences.

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. Below Ive broken down a few of the biggest distinctions.

SEE ALSO: A hands-on tutorial on how to test against 12 different JVMs using TestContainers

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 primarily with Java, while the CLR was designed to be language-neutral. Conversely, the CLR was originally designed only to run on the Windows OS and hardware, whereas the JVM was designed to be transportable into multiple OS and hardware architectures 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 arguments sake, lets say C# and Java) really are implemented at the VM-level.

A big difference that we see at the VM-level is that although both use JIT (Just-in-Time) compilation, the compiler isnt called to run at the same time. The CLR compiles MSIL code into machine code when the method is first invoked during runtime. The JVM uses a specialized JIT compiler engine HotSpot to compile Java Bytecode into machine code. This method compiles the hot spots in the code that will actually be used in order to prevent long compile times at run-time.

Each of these compilation strategies has its own tradeoffs in terms of performance. Because the CLR compiles all of the machine code before it is executed, 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, Javas HotSpot compiler can save time. Hotspot can also apply advanced optimizations that have to do with adjusting the resulting machine code the dynamic behaviours of the code as it is executing.

All that said, there are actually dozens of ways to configure the JVM and CLR we are just scratching the surface in this article.

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 cant. 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.

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. The JVM has very robust bytecode instrumentation frameworks that support both both Java and C++ agents, and also allows for multiple agents to execute side by side. This enables developers to run multiple profilers, APMs as well as writing their own custom agents to fully understand and optimize the behaviour of their appications. The CLR agent is more limited and only allows for one .NET profiler to be attached to the CLR at run-time. The JVM even supports attaching and detaching agents at run-time via a built-in Java API.

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.

SEE ALSO: 7 JVM arguments of highly effective applications

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.

View original post here:

CLR vs JVM: Taking the Never-Ending Battle Between Java and .NET to the VM Level - JAXenter