VMKit furthermore has performance comparable to the well established open source MREs Cacao, Apache Harmony and Mono, and is 1.2 to 3 times slower than JikesRVM on most of the DaCapo benchmarks

Going through VMKit to get improved JVM performance seems a little redundant.

As an example, the IKVM project acts as a Java runtime within the .NET environment, and lets you create .NET classes that wrap java classes so you can use them from within .NET. My understanding is that IKVM works by translating Java bytecodes/signatures to the .NET equivalents.

Note that while translation in one direction - Java to .NET - is relatively easy (mostly due to the fact that .NET offers almost all the features that Java has), the other direction is more difficult due to the large number of features in .NET that don't have direct Java equivalents. One simple example: .NET APIs make heavy use of delegate types, which would all have to be translated into listener interfaces or something similar to be Java-friendly. Translating .NET structs would also be difficult, since their value-type behavior would be somewhat hard to reproduce using Java classes.

I would be a bit more worried about handling generics. The CLI has true generics while Java's generics are syntactic sugar for casting to and from object.

No, there are many differences, both at the language and at the VM level, although you could emulate the behavior of delegates. You should look at the new MethodHandler from the JDK7 InvokeDynamic proposal ... they've added it for a reason ;)

> The CLI has true generics

The jury is still out on what constitutes "true generics" ... IMHO the C++ templates are more true than their C# equivalent ;)

But yeah, the Java generics system is a far cry from what it should've been. And it also sucks because there are exceptions ... arrays are reified, and the new MethodHandler from JDK7 is also reified.

That said ... you can add reified generics on top of the JVM. It is just a lot of hard work because you can't reuse the current generic types.

There are other features that are difficult to implement ... stack allocated values, the primitives that aren't mapping to the JVM types (decimal, ulong), pointers / unsafe code, PInvoke, tail-calls (although I know of a way to have tail-calls, but it's heavy).

You can implement anything on top of the JVM, but you will lose efficiency (not to mention of interoperability with Java code).

Note that neither the Microsoft C# compiler nor the Mono one emit tail calls. In practice, the MS .NET Just-In-Time compiler however transforms tail recursion to loops even if the compiler didn't ask for it if a number of conditions are met. I'm no JVM expert by any means but I don't see why the JVM couldn't do something similar, in theory or in practice.

The F# compiler does, and not just for self-recursive calls.

> the MS .NET Just-In-Time compiler however transforms tail recursion to loops

The hard problem is to have mutually recursive functions ... A() calls B() calls C() calls A().

I'm currently working on a compiler that behind the scenes implements trampolines, so if you had something like ...

  int methodA() {
      // does something here
      return methodB("calling B");
  }

  int methodA(TailCallException ex) {
      // do something here

      ex.method = methodB;
      ex.args   = [ 'calling B' ];
      throw ex;
  }

  // trampoline implemented for any method with tail-calls
  int methodA() {
      int result;
      has_next = true;
      method = reference to methodA;
      args   = []

      // reusing the same TailCallException instance
      exc = new TailCallException(); 

      while (has_next) {
          try {
              result = method.invoke(args, exc);
              has_next = false;
          }
          catch (TailCallException ex) {
              method = ex.method;
              args   = ex.args;
          }
      }

      return result;
  }

No that's not entirely true. There are a lot of similarities but there are essential differences as well. Delegates in .NET are truly functions as first class objects while single-method anonymous classes is Java are first class object wrappers around functions. This means that while in Java an anonymous class is a tuple with a reference to the instance of the anonymous class and a reference to the instance of the container class, in .NET it is a tuple with a reference (pointer actually) to a method and a reference to the instance of the owner class (if not static).

This is a subtle but important difference and is entrenched all the way down in the .NET type system, not just on syntax level.