Differences between MSIL and Java bytecode?

First off let me say that I don't think that the subtle differences between Java bytecode and MSIL is something that should bother a novice .NET developer. They both serve the same purpose of defining an abstract target machine which is a layer above the physical machine being used in the end.

MSIL and Java bytecode are very similar, in fact there is a tool called Grasshopper which translates MSIL to Java bytecode, I was part of the development team for Grasshopper so I can share a bit of my (faded) knowledge.Please note that I stopped working on this around when .NET framework 2.0 came out so some of these things may not be true any more (if so please leave a comment and I'll correct it).

• .NET allows user defined types that have value semantics as apposed to the regular reference semantics (struct).
• .NET supports unsigned types, this makes the instruction set a bit richer.
• Java includes the exception specification of methods in the bytecode. Although exception specification is usually only enforced by the compiler, it may be enforced by the JVM if a class loader other than the default one is used.
• .NET generics are expressed in IL while Java generics only use type erasure.
• .NET attributes have no equivalent in Java (is this still true?).
• .NET enums are not much more than wrappers around integer types while Java enums are pretty much fully fledged classes (thanks to Internet Friend for commenting).
• .NET has out and ref parameters.

There are other language differences but most of them are not expressed at the byte code level, for example if memory serves Java's non-static inner classes (which do not exist in .NET) are not a bytecode feature, the compiler generates an additional argument to the inner class's constructor and passes the outer object. The same is true for .NET lambda expressions.

CIL (the proper name for MSIL) and Java bytecode are more the same than they are different. There are some important differences though:

1) CIL was designed from the beginning to serve as a target for multiple languages. As such, it supports a much richer type system including signed and unsigned types, value types, pointers, properties, delegates, events, generics, an object-system with a single root, and more. CIL supports features not required for the initial CLR languages (C# and VB.NET) such as global functions and tail-call optimizations. In comparision, Java bytecode was designed as a target for the Java language and reflects many of the constraints found in Java itself. It would be a lot harder to write C or Scheme using Java bytecode.

2) CIL was designed to integrate easily into native libraries and unmanaged code

3) Java bytecode was designed to be either interpreted or compiled while CIL was designed assuming JIT compilation only. That said, the initial implementation of Mono used an interpreter instead of a JIT.

4) CIL was designed (and specified) to have a human readable and writable assembly language form that maps directly to the bytecode form. I believe that Java bytecode was (as the name implies) meant to be only machine readable. Of course, Java bytecode is relatively easily decompiled back to the original Java and, as shown below, it can also be "disassembled".

I should note that the JVM (most of them) is more highly optimized than the CLR (any of them). So, raw performance might be a reason to prefer targeting Java bytecode. This is an implementation detail though.

Some people say that the Java bytecode was designed to be multi-platform while CIL was designed to be Windows only. This is not the case. There are some "Windows"isms in the .NET framework but there are none in CIL.

As an example of point number 4) above, I wrote a toy Java to CIL compiler a while back. If you feed this compiler the following Java program:

class Factorial{    public static void main(String[] a){    System.out.println(new Fac().ComputeFac(10));    }}class Fac {    public int ComputeFac(int num){    int num_aux ;    if (num < 1)        num_aux = 1 ;    else         num_aux = num * (this.ComputeFac(num-1)) ;    return num_aux ;    }}

my compiler will spit out the following CIL:

.assembly extern mscorlib { }.assembly 'Factorial' { .ver  0:0:0:0 }.class private auto ansi beforefieldinit Factorial extends [mscorlib]System.Object{   .method public static default void main (string[] a) cil managed   {      .entrypoint      .maxstack 16      newobj instance void class Fac::'.ctor'()      ldc.i4 3      callvirt instance int32 class Fac::ComputeFac (int32)      call void class [mscorlib]System.Console::WriteLine(int32)      ret   }}.class private Fac extends [mscorlib]System.Object{   .method public instance default void '.ctor' () cil managed   {      ldarg.0      call instance void object::'.ctor'()      ret   }   .method public int32 ComputeFac(int32 num) cil managed   {      .locals init ( int32 num_aux )      ldarg num      ldc.i4 1      clt      brfalse L1      ldc.i4 1      stloc num_aux      br L2   L1:      ldarg num      ldarg.0      ldarg num      ldc.i4 1      sub      callvirt instance int32 class Fac::ComputeFac (int32)      mul      stloc num_aux   L2:      ldloc num_aux      ret   }}

This is a valid CIL program that can be fed into a CIL assembler like ilasm.exe to create an executable. As you can see, CIL is a fully human readable and writable language. You can easily create valid CIL programs in any text editor.

You can also compile the Java program above with the javac compiler and then run the resulting class files through the javap "disassembler" to get the following:

class Factorial extends java.lang.Object{Factorial();  Code:   0:   aload_0   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V   4:   returnpublic static void main(java.lang.String[]);  Code:   0:   getstatic   #2; //Field java/lang/System.out:Ljava/io/PrintStream;   3:   new #3; //class Fac   6:   dup   7:   invokespecial   #4; //Method Fac."<init>":()V   10:  bipush  10   12:  invokevirtual   #5; //Method Fac.ComputeFac:(I)I   15:  invokevirtual   #6; //Method java/io/PrintStream.println:(I)V   18:  return}class Fac extends java.lang.Object{Fac();  Code:   0:   aload_0   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V   4:   returnpublic int ComputeFac(int);  Code:   0:   iload_1   1:   iconst_1   2:   if_icmpge   10   5:   iconst_1   6:   istore_2   7:   goto    20   10:  iload_1   11:  aload_0   12:  iload_1   13:  iconst_1   14:  isub   15:  invokevirtual   #2; //Method ComputeFac:(I)I   18:  imul   19:  istore_2   20:  iload_2   21:  ireturn}

The javap output is not compilable (to my knowledge) but if you compare it to the CIL output above you can see that the two are very similar.

They are essentially doing the same thing, MSIL is Microsoft's version of Java bytecode.

The main differences internally are:

1. Bytecode was developed for both compilation and interpretation, while MSIL was developed explicitly for JIT compilation
2. MSIL was developed to support multiple languages (C# and VB.NET, etc.) versus Bytecode being written for just Java, resulting in Bytecode being more similar to Java syntactically than IL is to any specific .NET language
3. MSIL has more explicit delineation between value and reference types

A lot more information and a detailed comparison can be found in this article by K John Gough (postscript document)