I add a few points that are valid:
- the .NET VM supports indeed "value types", which can be on the stack (when needed, e.g. if a local variable is declared or during parameter passing to methods)
- OTOH in Java lots of types are also value types ... they are just hand implemented and they are always allocated on the heap (just to make this clear, java.lang.String is a good example)
- the .NET VM supports signed and unsigned primitive types, working with "bytes" etc. in Java is a true nightmare if you do serious low level stuff
- the .NET VM supports unsave code
- however also the JVM can integrate C/C++ code via JNI
Both are stack based VMs, in contrast to Parrot or Dalvik, which simulate a register processor. That means the former do stuff like "push @A" "push 12" to place the value of varibale A and the literal 12 on the stack and then e.g. an op like "add" to replace the top two stack positions with the sum of them. Register based VMs do a "load A to R1" and "load 12 to R2" and an "add R1,R2 to R3".
The JVM recently added a new call instruction (in Java 7) to support dynamic calls in languages like smalltalk or groovy, I'm not sure if the current .NET VM already supports that as well. (Note, that only means you don't have to do the dynamic dispatch yourself, it does not mean it is not possible. For .NET it is at least planend to also support such calls in future, e.g. see Iron Python.)
There is absolutely nothing in the current JVM implementation that makes any high level language difficult to implement, with one notable exception: inheritance. If you want to use native java byte code (that means java class file format) based inheritance you are stuck with one parent class. However a few languages that support MI circumvent this problem by generating their own method dispatch code or generating artificial interfaces and using hidden delegation.
The .NET VM had for a long time the same limitation, I'm not sure if that got changed meanwhile.
The fact that there are 100ds of languages compiled to the JVM indicates that it is a very well adopted environment.
New languages usually target the JVM first as it is much wider used than the .Net VM which is stuck to windows.