Just had another thought. We've got Jython, Rhino and Jacl (Python, JavaScript and Tcl? for the JVM).  So why can't the JVM be the non-proprietary common runtime platform for scripting languages to share? I wonder what extensions to the JVM would be required to really support all languages and all platforms. [James Strachan's Radio Weblog]

Yes, exactly.  I can't understand why there's this apparent bias against compiling other languages into Java bytecode.  I'm pretty ignorant of the details of the JVM, but my understanding is that it's fundamentally the same as the .NET CLR; a stack based register machine.  IIRC, both lack support for some fundamental constructs that functional languages find convenient, but these can be emulated, with a performance penalty.  So as it is, Java bytecode is OK as an IL.  The question is, what kind of support is there for bytecode generation?  It seems like a lot of the langagues (compiled ones, at least) generate Java code that has to be compiled and this is an obstacle.  Code makes a lousy IL, though JSP has done well with it, but JSP allows embedding literal Java, and really is a macro processor, not a language.  To me, one of the huge strengths of the .NET FCL is the support for dynamic code generation (CodeDom), compilation (ICodeCompiler) and most importantly for this topic, IL generation (System.Reflect.Emit).

It occurs to me that there's possibly another problem here.  While objects are baked into both VMs, I'm not sure if .NET requires all code to live inside an object.  I'll have to look into that.  Anyway, it seems like there's a problem with mapping non-OO languages into an OO VM.  There's probably a way to just map everything into a single global object though, the equivalent Java code wouldn't be pretty, but Java code isn't the point.