Java – Different approaches to dynamic typing in the CLR and JVM

\clrdynamic-typingjavajvmnet

.NET 4.0 introduces new support for dispatching invocations on dynamically typed objects. As far as I can make out, this involves:

  • no change to the CLR
  • new types in the BCL
  • new compilers that convert new syntax into usages of the new types

In the Java space, folks are discussing adding a new dynamicinvoke bytecode to the JVM such that the dispatch is handled by the JIT, behind the abstraction of the intermediate language.

The Java approach has support from many significant parties.

These seem like two fundamentally different approaches. What are the merits of each, and why did both camps choose to take different paths? I'm especially interested in the flexibility and runtime performance of both solutions. Are both VMs ultimately trying to achieve the same thing?

Best Answer

Saving intermediate language instruction set is very important for managed system, since it can make new apps incompatible with installed runtime.

E.g. Sun avoided changing while introducing generics, that's why implementation of generics in Java is half-baked. At the same time MS introduced new instructions for generics.

Theoretically, introducing new instructions for dynamic invoke opens possibilities for more optimal method lookup (e.g. inline caching).

BTW, .NET 4.0 will contain version of CLR, although AFAIK this version change would be caused by updated system libraries.