Reading, transforming and instrumenting MSIL has been something that has kept me interested (and sometimes over-wraught) since the .NET framework came out in 2000.

It's interesting to see the benefits that a common intermediary language and a virtual machine bring to the party: difficult problems can be dodged by programming language designers (such as garbage collection); languages can interoperate; compiled code can be platform independant, and JIT compiled when needed -- and doing fun stuff with compiled code is easier (and more fun!) with MSIL or Java bytecode.

A few interesting things have happened with Java bytecode over the past few years, with a couple of high profile cases recently. Java bytecode is no longer just the output of a java compiler and the input for the Java Virtual Machine:

• Google's new Android phone platform translates from Java bytecode to its own virtual machine -- which is not a JVM (via Miguel and Stefano)
• IKVM.NET, a runtime and set of libraries that convert Java bytecode to .NET MSIL
• Jython, a version of the python language that compiles to the JVM

Of course the same thing happens in the .NET land -- there are a multitude of languages that compile to MSIL, and MSIL can be run on the Microsoft .NET CLR, Mono's runtime engine and a few other runtimes built by Microsoft and third parties.

The angle taken by Google in developing an alternative virtual machine, rather than using the CLR or Sun's JVM is very interesting. On one hand, they have the benefit of full control of their platform, and this move means that they are not reliant on other vendors solutions. They promise to open source the platform, so the typical arguments about closed proprietary platforms may not apply, but it will still be interesting to see how another VM fits into the ecosystem.