DotGNU doesn't want to lock you into a single bytecode system

The plan to support Java and JVM

From a marketing strategy perspective, Microsoft's primary goal with the .NET platform is to "kill" Java. If this should succeed it would be a significant boost to their monopolistic ambitions; the DotGNU project definately has no desire to promote C# over Java. We made the decision early on that we would like to equally support both Java and C#, and both bytecode systems (JVM and CLR).

A significant amount of work has been done in this direction. Our compiler suite is not only able to emit bytecode for the Microsoft-designed CLR, but it can also be used to generate bytecode for the JVM. We also have a Java-compiler front-end. Unfortunately, both of these areas of coding work are currently dormant for lack of volunteers.

These Java efforts will probably remain dormant until someone steps forward and volunteers to champion them.

Support for future innovative bytecode systems

There can be no doubt that technological innovation in the area of bytecode systems will continue. In particular, Parrot, the bytecode system of the Perl 6 project, looks very interesting.

The architecture of DotGNU allows to add back-ends for additional bytecode systems to the cscc compiler system, and additional VMs to the DGEE webservice server.

Migration between bytecode systems

Since both the compiler suite and the webservice server are designed to support a choice of multiple bytecode system, migration from one bytecode system to another can be done gradually, one program at a time. This could be described as "stereo" of two bytecode systems.