动态java_动态的Java (Dynamic Java)

议题：动态调用(Dynamic Dispatch)

当你从一个Java方法调用另一个Java方法时，其语义远远比你想象的要微妙和复杂，当然所有的这些事情都由编译器和JVM处理了而且它(指Java-to-Java method dispatch？)还非常高效。而调用——从Groovy到Jython到 Java再返回，则复杂的多，Groovy和Jython程序员必须编写成吨的代码以断定：呼叫那个方法、按顺序get所有的参数以使得方法调用发生。不管对Java还是对一门动态语言，(消息)发送都是棘手的，特别是当该动态语言在Java的类外面，设计一些meta-classes的时候。(原文：It’s tricky dispatching both to Java and to a dynamic language, especially since the dynamic languages tend to keep meta-classes around for the Java classes。)

所有的这些都是效率低下的。也许值得在JVM中添加一些字节码，帮助一下至少一部分的这类杂耍和家务管理，特别是考虑到添加一些字节码的花费似乎并不那么昂贵。If this idea holds up after a bit more thought there’d have to be a JSR so the whole community can kick it around, but it looks plausible.

议题：生产字节码(Bytecode Generation)

这段时间，很多人在生产字节码——不仅仅是Jython和Groovy，还有AOP工具和XPath / XSLT 工具和另外的一些东西。他们全都用手做这件事而没有依靠抽象的帮助(是不是指用手不用脑啊？)，这(生产字节码)是艰难而且混乱的，他们似乎也不像在干一番大事情。

如果有一个高级(高级语言的高级、higher-level)方式——就像AST级别，让人们生产字节码，很多人会感到它超级方便，你就可以为一些常见的语言现象(比如switch、循环等等)自动生成字节码。但它比你想象的更棘手，因为一些东西的语义，即使如给一个变量赋值这么明显地简单的事情，在动态语言中也会变得非常地复杂。

看来，Janino对这方面感兴趣，而且在Kawa中的一些工作似乎可以复用，同时在.NET-land中有一个称为CodeDom的东西，明显地，也在忙于相似的难题。所以啊，或许正确的做法是搞一个java.netproject，在这个领域构建某种共享的基础结构。

琐录(Odds & Ends)

我们在closures, continuations, and tail recursion上面进行了冗长、激烈而有趣的争论。增加字节码以支持这些东西应该是合理的想法(尽管做好集群可能非常昂贵)，因此问题就成了：这样对动态语言的实现者(implementors)有多大的帮助，例如，Jython’s implementation of Python generators 工作得非常好。并没有一些暴徒为tail recursion吵吵闹闹，只有Dan Sugalski给我们展示了一些好的例子(scenarios)，它的确有助于实现一些非常自然而有用的算法。

展望(Going Forward)

There were a couple of action items to report back on this or that, but the take-aways were pretty clear. For my money, the important thing about the meeting was bridge-building; the dynamic-language guys now know who to shout at in Javaland, and the Java guys know who in dynamic-language land to pester about what works and what doesn’t.

And I confidently predict that as time goes by, more and more of the code written in the Java ecosystem won’t be in Java. This is a good thing.