Last winter we had a meeting with various people who work on such languages - things like Groovy, Perl, Python/Jython. Our conclusion was that the most practicable thing was to support dynamically typed method invocation at the byte code level.
The new byte code, invokedynamic , is coming to a JSR near you very soon. I’m forming an expert group which I will chair (because of my deep fondness for standards, committees, meetings and process). This group will get to argue over various fine details of how this instruction should work.
Basically, it will be a lot like invokevirtual (if you don’t know what that is, either open a JVM spec and find out, or stop reading). The big difference is that the verifier won’t insist that the type of the target of the method invocation (the receiver, in Smalltalk speak) be known to support the method being invoked, or that the types of the arguments be known to match the signature of that method. Instead, these checks will be done dynamically.
There will probably be a mechanism for trapping failures (a bit like messageNotUnderstood in Smalltalk).
Does this do everything everyone wants? No, but that is not the point. It isn’t really feasible to accommodate the exact needs of a wide variety of disparate languages. Instead, one should provide a good general purpose primitive, that all these languages can build on.
If this comes to pass, my longstanding disdain for the JVM as a platform will have to be re-evaluated.