After J#, why would Internet Explorer still need a JVM?

by Brian Jepson

One of the tools that comes with Visual J# is jbimp, the Java Binary to .NET Assembly Converter. It turns Java bytecode into MSIL (Microsoft Intermediate Language). Sounds like an innocent tool to help Visual J++ developers expose their .jars and .classes to .NET applications.

As of this writing, .NET doesn't support applets: I can't develop a .NET application and run it in my browser. But I am sure that such a thing will come to pass. A .NET applet would look more like an ActiveX control than a Java applet, since there is no VM per-se (IL is JIT-compiled to native code and enjoys extensive runtime support from .NET).

Consider this:

  1. J# only supports JDK 1.1.4. This may seem like a major shortcoming, but see #2 and #3.
  2. Microsoft is already shipping versions of Windows without a Java VM. If you want to, you can install Microsoft's VM into IE. That Java VM is also limited to JDK 1.1.4 (the plot thickens).
  3. When someone writes a Java applet for general consumption, they want it to run on Internet Explorer and Netscape. Per #2, that applet is going to be targeted to JDK 1.1.4, since that is the latest Java version that supports both browsers!

So, why does Microsoft need a Java VM for Internet Explorer anymore? They
can just add .NET runtime support to IE, and incorporate jbimp into IE. When
IE downloads an applet, it can convert it to MSIL, pre-JIT it into native
code, and then cache it. There will be a penalty the first time an applet is ever loaded on a computer, but subsequent visits to the same applet will be very fast, even if those visits occur between reboots.

Is this phase one of embrace, extend, and extinguish?

See also A First Look at Visual J#.