动态的Java (Dynamic Java)

动态的Java（翻译）(很潦草)

《Dynamic Java》      http://www.tbray.org/ongoing/When/200x/2004/12/08/DynamicJava#p-4 

     Tim Bray, Sun's XML evangelist, recently hosted a "summit" to discuss whether and how Java mught provide better support for dynamic languages

 

       相当的清楚，在软件开发世界，动态语言（dynamic languages）是一个热点，或许是最热的热点。我们需要做更多的工作，使处于Java环境（ecosystem、生态系统）的人们容易使用它们。因此在星期二我们在Sun召开了高端会议，有我们内部的Java领袖人物中一些人，而在动态语言那边，Larry Wall和 Dan Sugalski (Perl and Parrot), Guido van Rossum, Samuele Pedroni和Sean McGrath (Python),以及James Strachan (Groovy)。这是我们的一个受教育的日子；下面有一些take-aways和图片。

 现在开始

      在Java方面（Javaverse）我们已经相当认同动态语言。这是Sean McGrath用Jython写的使用servlets的应景代码（write-up），and over at O’Reilly Marc Hedlund has a nice little demo of building an RSS aggregator in Groovy. Gotta love this：

       class Item { title; contents; String toString() { return title; } }

      然而，Jython和Groovy(还有另外的语言、others) 是在几乎没有Sun的帮助或者鼓励下开发的，我们很可能能够使他们的开发活动（implementors’ lives）更容易些。

       Java有一个PR问题（公共关系 、public relation？），而微软公司一开始就将.NET定位成多语言平台。实际上，Java是一个三腿凳（语言、JVM和类库），所有这些都记在“Java”一个大名之下（gets lost under the enveloping carpet of the one-word name “Java”.）。某种程度上，这是Sun的失误。在早期岁月，Java传教士一般保留这种偏见，以Java以外的语言写代码的都是二等公民。真的有些愚蠢。Java是一种好语言但我经常喜欢用Perl和Python做事情，许多开发者也是这样。

高端会议

       即使Sun不赞同在Java平台上使用另外的语言，无论如何，它们还是出现了。我是赞同的，当我跑到Sun公司，发现我问的每一个人也是赞同的。于是，我询问Graham Hamilton——他一直处于Java世界的中心，将一屋子的动态语言专家引进来帮助我们断定如何把Java营造成更好的家园，他是否认为是一个好主意。他肯定了，并且指出我们刚刚踏上1.5“Tiger”版本又处于下一步计划编制阶段的早期，立刻办这事儿正是时候。

       于是，我去找了位居Sun的Software公司 CTO办公室的我们的主管Juan Carlos Soto，他也认为这是一个好主意并同意资助。

表演者

       Java团队，我们有Graham Hamilton——一个VP和Sun Fellow并且是主要的J2SE架构师；Gilad Bracha——处理Java语言和JVM规范；Martin Buchholz——资深的Java维护者（一度是XEmacs的维护者）。

       在Perl方面，我们有Larry Wall——他正忙于定义Perl 6；Dan Sugalski——编写了Parrot（新的Perl VM）。

       在Python阵营，有Guido van Rossum, Samuele Pedroni，当今Jython的领袖；和Sean McGrath——他的公司Propylon雇佣了一小群程序员正在为真正付款的客户编写Jython应用程序。

       Groovy方面的代表是其领袖James Strachan.。

       他们给了我们一个非常小的会议室，显得很拥挤。我从来没有宣称自己是世界上最好的程序员，但我很少遇到这种情况：与一群人共处一室讨论软件问题而他们的起点超过我的理解力（they start going right over my head）。唉，这种事情竟然发生了几次，甚至当要求我记录讨论内容时，都有问题。 
    为了先睹为快（a touch of flavor），这里列举了Larry事先准备的将要讨论的主题的一部分：anonymous code/closures, lvalue methods/functions, variadic call/return, constant/rw/copy/ref/lazy parameters, wrappers/AOP, eval, exception handling/undef/nil/unthrown exceptions, exception handlers with lexical access, temporization/hypotheticality, efficient regex with complete semantics, access to dynamic context/want/caller, redispatch of methods (fallback upon "fail"), efficient switch statement?, versioned modules/classes, virtual classnames, continuations。（不知道怎么处理这些咚咚，yqj2065）

议题：动态调用（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.net project，在这个领域构建某种共享的基础结构。

琐录（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.