In response to a column last month on the language-agnosticism of Microsoft's forthcoming Common Language Runtime, several people wrote to point out that the Java Virtual Machine already in many ways achieves this vision.
There is no reason that a future JavaVM couldn't perform the
same full translation to native code that the CLR does. Sun has
been emphasizing JIT-compilation. This track may pay off with
future HotSpot technology. It doesn't have to stay on that track though. The JavaVM on AS/400 compiles (and caches).class files to native code on demand. Oracle has [promised?] a full native-code compiler for Oracle8i -- but I believe that it compiles when you "install/deploy" the Java .class files. There are some commercial Java accelerators that do it as a deployment option on Windows. Also, GNU gcc has a Java backend that does it too.
There is a good amount of "metadata" available about objects
available from the JavaVM. The Java Reflection API could be used to expose non-Java objects to a Java program.
Chui Tey:
An alternative to .NET is to use the JVM as the CLR,
and then compile different languages to Java bytecodes.
There is real value in this, although I'm not sure if Sun is up to this philosophically.
There's the rub. Since Java appeared, it has been clear that Java-the-language was, theoretically, just the preferred interface to the Java Virtual Machine, in the same way that C# is a preferred interface to the .NET Common Language Runtime. Yet, Sun, itself, has never chosen to emphasize this point. It's been left to an intrepid band of independent developers to work out ways to integrate other languages with the JVM.
In this volume of Best of BYTE, we explore the emergence of some heuristic algorithms. Although we have only scratched the surface of this intriguing subject, we hope we've suggested the potential of the synthesis of heuristics and algorithms.
