There has been a lot of discussions about the need for more dynamicity in Java, including the need to support scripting languages.
Most are around the suggestion of improving the HotSwap facility in Java.
For exampe:
* How badly do you want Hotswap to improve?
* PLEASE VOTE: the only JVM bug you'll ever really care about
* Gaining traction: HotSwap improvements,
etc.
I have to admit that a year ago I was probably one of the guys that were swearing the most over HotSwap's (and JVM(D/T)I's shortcomings when trying to stretch its (limited) boundries in AspectWerkz.
However, today I think that improving HotSwap and the APIs for bytecode instrumentation in general is a dead end road. It simply adds complexiety, memory overhead, performance overhead as well as introduces the multiple agents problem.
We need to raise the abstraction level and move away from bytecode instrumentation. There is a need for high level VM APIs similar to the one we have been working on in JRockit. For details on the problems with current approaches and how we solve this in a better way, read this article.
So, PLEASE, stop wasting time in discussing how to improve bytecode instrumentation (e.g. HotSwap, JVMTI etc.) and give us feedback on how to improve the high-level VM API in JRockit (the prototype is already available).
When on the subject on supporting scripting languages in Java is think that this proposal for adding a invokedynamic bytecode instruction is a step in the right direction.