剛剛看完csdn上的文章介紹java虛擬機,覺得講到java 6的一點新功能,我們必須知道的,要不我們就out了...
文章是一篇Danny Coward訪問;英文的原連接 http://www.artima.com/lejava/articles/dynamic_languages.html
我把一些重要的地方截下來：
Java SE 6 is no longer only about the Java language: SE 6 can be used to execute dynamic scripting language code as well. According to Danny Coward, Sun's Java SE platform lead, scripting language support is merely the first step in turning the JVM into the best possible execution platform for any dynamic language.
a new bytecode, invokedynamic, explicitly designed to support dynamic languages, about hot-swapping—the ability to change or add a method to a class at runtime—and about the goal of turning the JVM into an ideal target for dynamic language implementation.
JSR 292 is going to provide an additional bytecode that we will probably call invokedynamic. This provides an instruction to the JVM to make a method invocation, but without the types of the return value and the method parameters to be known in the bytecode.
大概是講java 6的JSR 292的技術，加入了新的字節碼invokedynamic，用來給其他動態語言實現，而實現了不需要知道返回類型和參數而調用方法。。。。
下面是他講的一個例子：
Suppose what you're doing is growing a collection by a certain size, and the return type [of that method] is Collection. In JRuby, for example, that kind of method might be implemented without having a specifically typed return value. Developers may understand in their heads that what's going to be returned is a collection, but there is not a specific type of the return [value], because [Ruby] is not a statically typed language.
Creators of dynamic language engines are in the business of taking, say, Ruby code and turning that into Java bytecode. When today's JRuby engine tries to convert that method call into bytecode, it has to create a synthetic interface to represent the return type. That isn't an interface a developer creates, but is one purely created by the JRuby engine [so] that it can take that method invocation and [turn that into] the bytecode. And that was just the return type—the same holds true for method parameters and exceptions.
JSR 292 removes the need for that synthetic interface. Today, dynamic language interpreters must output the methodinvoke bytecode, even when interpreting, say, a piece of Ruby code. Tomorrow, with JSR 292, they will be using the invokedynamic version. It will streamline the engine implementations because a lot of today's engines are worrying about creating new synthetic types and doing lots of book-keeping: when a method is called in seven or eight different places, they have to re-use that synthetic type all over the place.
Interestingly, this is not a feature of the language, but a feature of the bytecode. Java developers won't ever knowingly use a feature of JSR 292—it's something that goes on under the covers. What's most fascinating about this additional bytecode is that it will be the first bytecode [in Java] that isn't used by the Java language. We're proposing to add this bytecode purely for languages like Ruby, Groovy, BeanShell, Python, and so on. We have high hopes that those languages will run more quickly on the JVM than they do today as a result.
好長。。。
JRuby是java 和 Ruby的聯合的引擎。。。