Java Virtual Machine (JVM) is a subset of the Java Runtime Environment (JRE) developed by Sun Microsystems. The JVM runs the program once it accepts the .class file.
The .class file (actually a byte code) works on the host machine, after having converted it into a language compatible with the machine. JVM takes care of this conversion.
The Java Virtual Machine also takes care of security, and optimises the code. To do so, the JVM is loaded into the memory in order to run a Java program. Hence, a large JVM file will eat up system resources that might otherwise be available to the program to be executed. This may explain why Java programs feel slower.
Microsoft’s .NET applications cannot work without the Common Language Runtime (CLR). Most developers rely on languages such as C# or VB.NET to code using CLR. The Common Language Runtime (CLR) offers important functionalities like memory management, thread management, garbage collection and exception handling.
Although Common Language Runtime (CLR) and JVM are similar in many respects, most developers reckon CLR is the hands-down winner. JVM does not include features such as support for user-defined metadata. Support for versioning also means that when working with CLR, you can execute different versions of the same DLL side by side. CLR also provides multiple language support. JVM, on the other hand, supports only Java.
Neither does JVM provide support for boxing and unboxing. In other words, it does not support interaction between value and reference types. We experienced issues in implementing ‘byref’ values, as JVM prohibits compilers from taking addresses of local variables.
Another key difference we've observed is that CLR compiles source code twice while converting it to the native code.
Hence, the process of compiling is faster than that of interpreting. Java architecture, however, compiles and interprets the source code only once during the process of conversion to native code.