The difference between Java and .Net.
Both do have a virtual machine. But the work differently. Both were made with portability in mind. The .Net CLI is a published standard and has been since release. The .Net CRR is the Windows implementation of the CLI.
Java code is compiled in to bytecode. The JVM's JIT then compiles that to native code on the fly.
.Net code is compiled in to the Intermediate Language (IL). For desktop apps, the IL is completley compiled to a native binary and then run. Optionally, you can just compile to native binary from Visual Studio. In ASP.Net it uses JIT.
The difference here is that to precompile Java to a native binary, you need to use some other compiler or a JVM that does that. I could be wrong, but IBM makes the only JVM that precompiled binaries but it costs money. There are many free Java native binary compilers though.
IL is an ASM like language. Bytecode by itself is not really a language.
Java was created with only compiling Java language in mind. The Java compilers doesn't provide a way of encoding type-unsafe features such as pointers, tagged pointers (pointers that hold type info with the address), unsafe type conversion etc. Also it does not allow compilers to take address of local variables; hence it is not possible to implement byref arguments directly. So that makes using other languages with it difficult and some are impossible.
.Net was created with multiple languages in mind. That is why there are over 30 languages on it right now, include the MS implementation of the Java language called J#.
The CRL also supports versioning and support for user defined metadata. The JVM does not.
The Java aims to be backwards compatible, .Net does not. When you install the latest .Net framework, all previous version get installed too (so if you have .NEt 3.5 installed you will have no problem running .Net 1.1 code). This has lead to some interesting things. Features are added more quickly to .Net and with better performance over Java. Such is the case with generics. When Java encounters a generic it actually removes the type (for backwards compatibility), incuring extra cast instructions on every access. .Net compiles the method and loads it once for reference types. It them maintains a a typed variable table for each instance. Value types each get loaded separately for each instance.
Sun has been trying to implement dynamic languages in to Java. MS has already done so. It is possible to call python code from C#, have that python code emit and compile some JavaScript code that calls a method from a VB.Net library.
Also, you get Visual Studio to work with .Net which is an amazing IDE (with not so neutered free versions available). There is a lot of value to using 1 debugger to debug VB.Net and C# code on the server side while debugging JavaScript on the client side all at the same time.
Java also has terrible naming conventions in its libraries. Something as simple as a button is named JButton. JButton as opposed to what? A button is a button, any distinction should be in the namespace. Java has already switched their standard UI widget toolkit once. Will the next button be JJButton? J2Button?