In some of the comments to my AI-Coder idea, people said they’d rather have the game engine implemented in .Net than in Java. And they’ve made a good point.

Even though I think Java’s a great language, the CLR is a pretty compelling platform as well. There are dozens of different languages that compile to the CLR, and only a handful of languages that compile to the JVM.

But what if “Java bytecode” could be treated as a language that could be compiled for the CLR? And what if CLR assemblies could be compiled for the JVM?

I know both VMs are stack-based (with no registers) and that they both perform tasks like classloading and reflection. The VMs are also similar in the object-oriented heritage of their instruction-sets (including opcodes for invoking methods from an object’s vtable).

So there are a lot of similarities. After all, the .Net virtual machine is supposedly a descendant of the old Microsoft JVM.

So I started researching a few more details about the differences between the two platforms, and I discovered that the CLR is technically superior to the JVM, for many reasons:

• Since all allocated objects in the JVM are managed by a generational copying collector, you can never rely on an object existing at the same memory location where it was originally allocated. The CLR also uses a generational copying collector, but the CLR also includes special opcodes for allocating memory outside the GC heap. That’s why the CLR can host pointer-based languages and the JVM can’t.
• The CLR supports signed and unsigned integer types, while the JVM only supports signed types.
• The CLR supports stack-allocated structs. The JVM does not.
• The CLR supports unions, with explicitly defined field layouts. The JVM does not.
• The CLR includes a “tailcall” opcode capable of performing tail-recursion optimization at runtime. The JVM includes no such functionality.
• The JVM will supposedly be getting an “invokedynamic” opcode in some future release, to support invoking methods on objects by dynamically checking for type-safety, rather than making the bytecode verifier responsible for ensuring type-safety. The CLR already has such an opcode.

So, the CLR is basically a superset of functionality in the JVM.

In addition, there are few implementation details that would make it easier to build a JVM-to-CLR translator than one for CLR-to-JVM translations:

• The CLR uses a single opcode (”callvirt”) for invoking methods from an object’s vtable. In the JVM, there are two different opcodes (”invokevirtual” and “invokeinterface”) for methods defined in a class or an interface, respectively.
• The JVM has more instructions than the CLR. Each JVM instruction operates only on a single primitive type, whereas CLR instructions are polymorphic.

Even if the CLR-to-JVM translation process was possible (and I doubt that it is), it looks like it would be really difficult.

Market Analysis

Actually, I’m going to temporarily skip the market analysis portion of this idea. I’ll revisit it later, if I decide the idea has enough merit. This was just something I was thinking about tonight, so I decided to do a little bit of preliminary research.

However, I will say this much: there’s probably a market for a JVM-to-CLR compiler (more-so than for a CLR-to-JVM compiler). There are far more open-source Java projects than .Net projects, and I bet a lot of .Net developers would benefit from using those resources.

Pros and Cons:

I’m also going to temporarily skip my usual enumeration of pros and cons.

Mainly because it’s late.

And I’m sleepy.

…

This is the eighth of 30 business ideas that I’ll be writing about over the course of 30 days. Some of them are grounded in good business sense and practical experience. Other ideas are just technical curiosities that struck my fancy. One of them will become a product over the next six months, and the foundation of my new software business.

This entry was posted on Friday, June 23rd, 2006 at 2:57 am and is filed under biz. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.