计算机专业外文文献论文翻译

本科毕业设计

外文文献及译文

文献、资料题目：Evolving Java Without Changing

the Language

文献、资料来源：https://www.360docs.net/doc/6717986741.html,/articles/

evolving-java-no-lang-change 文献、资料发表（出版）日期：

院（部）：

专业：

班级：

姓名：

学号：

指导教师：

翻译日期：

外文文献：

Evolving Java Without Changing the Language In "The Feel of Java" James Gosling stated that: Java is a blue collar language. It's not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea.

The extraordinary success of Java offers weight to the notion that this was a sensible approach, and if it remains an important goal for Java today, then it makes sens e that the language should continue to evolve relatively slowly. In addition to this, the fact that Java is a mature, widely used language causes its evolution to be fraught with difficulty. For one thing, each feature added to the language can change the way it feels in subtle and often unpredictable ways, risking alienating developers who have already adopted it as their language of choice. For another, a feature that makes perfect sense on its own may interact with other features of the language in awkward or unexpected ways. Worse, once a language feature has been added it is all but impossible to remove even if it turns out to be detrimental to the language as a whole. To justify adding a new feature, a language designer must be highly confident that it will be of long term benefit to the language rather than a short term or fashionable solution to a problem that rapidly becomes redundant. To mitigate the risk a language designer will typically experiment by creating a separate language or branch, such as the Pizza language used to experiment with Java's generics, prior to their implementation. The problem with this approach is that the audience for such experiments is both small and self-selecting; obviously they will all be interested in language features, and many may be academics or researchers. An idea which plays well to such an audience may still play badly when it is incorporated into the main language and general programmers start to work with it.

To get a sense of this, consider the closures debate that became so heated for Java 7. Implementations for the main proposals (and some others) have been available for some time but no consensus has emerged. In consequence Sun decided that JDK 7 will not get full closures support. The core argument came down to whether Java had become as complex as it could afford to be when generics (and in particular the wildcard syntax) were added to Java 5; and

whether the addition of full support for closures was justified when Java already has a more limited form through anonymous inner classes. Two important use cases for adding full closures support were to simplify working with the fork/join API that is being added to JDK 7 to improve multi-core programming, and to help with resource clean-up. Josh Bloch's ARM block proposal, which is now expected to be in JDK 7 via Project Coin, offers an alternative solution to the latter problem. Dr. Cliff Click's research on a scalable, non-blocking programming style for Java offers an alternative approach to fork/join that may be more appropriate as the number of processor cores increases. If this were to happen, then the uses for closures in Java may arguably be too limited to justify their inclusion.

It remains important though that a programming language continues to develop at some level. This article therefore examines three alternative techniques for adding new language features to Java that don't require changes to the language itself - using a custom Domain Specific Language, exploiting the Java 6 annotation processor to add optional language features via a library, and moving the syntactic sugar from the language to the IDE. Each offers the potential to allow a wide audience of mainstream developers to experiment with the new features over the medium term in a non-invasive manner, and the best ideas can then filter down for inclusion in the core language.

Custom DSLs

The most widely discussed of the three is the Domain-Specific Language or DSL. There is some disagreement on exactly what the term means, but for the purposes of this discussion we'll refer to it simply as a language that has been created with a narrow focus to solve a particular problem, rather than as a general purpose language designed to solve every computing problem. As such we would expect a DSL to be non-Turing complete and for the most part this is the case. There are edge cases of course. Postscript, for example, is a Turing complete language but also qualifies as a DSL using our definition.

As the above example also illustrates, the idea of a DSL is not new. Other familiar DSLs include Regular Expressions, XSLT, Ant, and JSP, all of which require some sort of custom parser to process them. Martin Fowler also suggests that fluent interfaces/APIs can be considered a second type of DSL, which he refers to as an internal DSL. His definition is that an internal DSL is developed directly within the host language. This was a common practice amongst both

Lisp and Smalltalk programmers, and more recently the Ruby community has been popularising the technique.

Whilst many well-known DSLs are commercially developed and maintained, some enterprise development teams have used the technique to create a language that allows them to rapidly explore aspects of their problem domain. It isn't however as common as it might be, perhaps because DSLs have a fairly intimidating barrier to entry. The team has to design the language, build the parser and possibly other tools to support the programming team, and train each new developer that joins the team on how the DSL works. Here the emergence of tools to specifically support DSL development could significantly change the landscape. Intentional Software's Intentional Domain Workbench, which has been in development longer than Java has been around, is the first significant implementation of such a tool. The project started life at Microsoft Research, and Dr. Charles Simonyi's 1995 paper "The Death of Computer Languages, the Birth of Intentional Programming" describes his vision. In 2002 Simonyi founded Intentional Software to continue working on his ideas and a hugely impressive video demo of the system is available. The product itself is at 1.0 status, but access is restricted to very limited partners.

Other software houses are also exploring the concepts, amongst them JetBrains, well respected for their IntelliJ IDEA Java IDE, who have recently released the 1.0 version of their Meta Programming System (MPS). MPS doesn't use a parser, instead working with the Abstract Syntax Tree (AST) directly. It provides a text-like projectional editor which allows the programmer to manipulate the AST, and is used to write languages and programs. For each node in the tree a textual projection is created - as the programmer works with the projection, the change is reflected in the node. This approach allows you to extend and embed languages in any combination (often referred to as language composing) promoting language re-use. JetBrains are using the product internally and have recently released YouTrack, a bug tracking product developed using the system.

The Java 6 Annotation Processor

Whilst DSLs are less common in more mainstream languages such as Java than they are in Ruby, Smalltalk and Lisp, recent developments in the Java language, in particular the annotation processor which was added in Java 6, offer new possibilities for developers looking to use them in Java. The JPA 2.0 criteria API that will ship as part of Java EE 6, itself a DSL, offers an

example. Here the annotation processor builds up a metamodel type for each persistent class in the application. Whilst it would be perfectly possible for the developer to hand craft the metamodel in Java, it would be both tedious and error prone. The use of the annotation processor eliminates that pain and, since the annotation processor is built into Java 6, the approach requires no specific IDE support – an IDE delegates to the annotation processor triggered by the compiler, and the metadata model is generated on the fly.

Using the annotation processor it is also possible for a library to add a new language feature. Bruce Chapman's prototype "no closures" proposal, for example, uses the technique to provide a mechanism for casting a method to a Single Abstract Method (SAM) type which compiles on top of Java 6. During our conversation Chapman pointed out that the SAM type also supports free variables, a key aspect of a closure:

The method body can declare additional parameters beyond those required for the Single Abstract Method using the @As.Additional annotation. These parameters can have values bound to them at the point where you obtain an instance of the SAM type, and are then passed to the method each time it is invoked.

Chapman also set up the Rapt project to explore other uses of the technique, and has added implementations for two language changes - Multiline Strings and XML literals - that were considered for JDK 7 but won't now make it into the final release. Java could even get a form of closures support using this approach. When asked about this, Chapman said: We are just finishing a Swing project which we used it for. We have found a couple of minor bugs around generic types, one recently discovered remains to be fixed but other than that it seems quite nice to use, and nobody has been wanting to rush back to use conventional anonymous inner classes.

Project Lombok, another project exploring the the annotation processor, pushes the technique still further. In effect Lombok uses annotation processing as a hook to run a Java agent that re-writes various javac internals based on the annotations. Since it is manipulating internal classes it is probably not suited to production use (internal classes can change even between minor releases of the JVM) but the project is an eye-opening example of just what can be done using the annotation processor, including:

?Support for properties using a pair of @Getter and/or @Setter annotations with varying access levels, e.g. @Setter(AccessLevel.PROTECTED) private String name;

?The @EqualsAndHashCode annotation, which generates hashCode() and equals() implementations from the fields of your object

?The @ToString annotation, which generates an implementation of the toString() method ?The @data method, which is equivalent to combining @ToString, @EqualsAndHashCode, @Getter on all fields, and @Setter on all non-final fields along with a constructor to initialize your final fields

Other language experimentation, such as removing checked exceptions from Java, can also be done using this approach.

Whilst the annotation processor technique opens up a welcome new route to language experimentation, care needs to be taken that the generated code can be easily read by developers, not just by the machine. Chapman made a number of suggestions during our conversation:Generate source code not bytecode, and pay attention to formatting (indenting especially) in the generated code. The compiler won't care whether it is all on one line or not, but your users will. I even sometimes add comments and javadoc in the source code generated by my annotation processors where appropriate.

Hopefully if the technique becomes more prevalent IDEs will also make it easier to view the code that is to be generated at compile time.

Syntactic Sugar in the IDE

Bruce Chapman also touches on our third technique - moving the syntactic sugar from the language to the IDE - in his blog and he elaborated on his ideas during our conversation. It is already routine for Java IDEs to create portions of boilerplate code for you such as the getters and setters of a class, but IDE developers are beginning to push the concept further. JetBrains' IntelliJ 9 offers a terse code block syntax for inner classes similar to a closure, which a developer can also type. Acting like code folds, these can then be expanded into the full anonymous inner classes which the compiler works with - this allows developers who prefer to stick with the standard anonymous inner class syntax to do so. A similar plug-in for Eclipse also exists. The key point here is that the "alternate" syntax is just a view of the actual code which the compiler and any source management tools continue to work with. Thus the developer should be able to switch

views between either form (like expanding or collapsing a code fold), and anyone without access to the definition of the sugar just sees the normal Java code. Chapman writes:There are many details to work out in order to make this easily accessible, but long term I see developers relatively easily defining a two way sugaring/desugaring transformation (jackpot is a good start for how this might be done), trying them out, evolving them and sharing the good ones with colleagues and the community. The advantages of this are almost the same as for a language change, without the disadvantages. The very best could become ubiquitous and then form the basis of an actual language change if necessary to get rid of any remaining "noise" not possible with this approach.

Since syntactic sugar has to map to another (more verbose) language feature it cannot offer complete closure support; there are some features of BGGA closures for example that cannot be mapped to anonymous inner classes, and so they couldn't be implemented through this approach. Nevertheless the idea opens up the possibility of having various new syntaxes for representing anonymous inner classes, similar to BGGA syntax or FCM syntax, and allowing developers to pick the syntax they want to work with. Other language features, such as the null-safe Elvis operator, could certainly be done this way. To experiment further with the idea this NetBeans module also developed by Chapman, is what he describes as a "barely functional" prototype for Properties using this approach.

Conclusion

In language development there is always a trade-off between stability and progress. The advantage that all of these techniques bring is that they don't affect the platform or the language. In consequence they are more tolerant to mistakes and are therefore more conducive to rapid and radical experimentation. With developers freely able to experiment we should begin to see more people separately tackling the poor signal to noise ratio of some common boilerplate such as the anonymous inner class syntax, mixing and evolving these ideas to some optimum form that adds the most value in the most cases. It will be fascinating to see how developers use these different approaches to push the Java platform in new directions.

中文译文：

不改变语言的前提下推进Java演进

James Gosling在“The Feel of Java”中说过：Java是一种蓝领语言，它并不是博士的论文材料而是可以完成工作上的语言。很多不同的程序员都非常熟悉Java，因为我有一种趋势去选择普及的东西，这是一个不错的选择。

Java的这种成功证明了它的这种方法是正确的，如果Java今天仍然以这个为目标，那么它的语言演进将变得很缓慢。Java作为一个成熟，使用广泛的语言也将导致其演进过程充满了困难。一方面，每个特性添加到语言中都有可能造成不可预知到后果，这么做会疏远那些熟悉Java的人，另一方面，本身很完美的特性可能在与其他特性进行交互时产生未知的影响。更糟的是，一旦增加了某个语言特性，几乎就不可能再将它移除，即使这个特性会对整个语言产生危害也没办法。语言设计者为了证明某个特性是正确的，应该从长远的角度来考虑，不应该在短期内解决这个问题，而之后就变成了多余的。为了降低风险，语言设计者一般会创建单独的一种语言或者分支来进行试验，比如Pizza语言就是在完成前用来测试Java泛型的。这种方式的问题在于试验的参与者是比较少的人群，并且是自愿的。他们对语言特性很感兴趣，很多人是学者或者研究员。但是，在普通的程序员使用这些特性时，那些学者或是研究员认为很好的特性可能变得很糟。

为了感受一下这种情况，请考虑Java7闭包特性的激烈争论。很长时间以来有人在提案中给出了闭包的实现，但最终却还是没有达成共识。然后，Sun公司不在JDK7中添加完整的闭包支持。争论的焦点转向为添加泛型会不会导致Java变得越来越复杂，在Java中已经通过匿名内部类部分实现该功能的情况下，完整闭包还是正确的吗。需要完整闭包支持的是简化fork/join API(添加到了JDK7中以改进多核编程)的使用以及清理资源。Josh Bloch的ARM block提案对第二个问题给出了另一种解决方案。Cliff Click博士在面向Java的可扩展，非阻塞变成风格的研究中给出了关于fork/join的另一种方案，这种方案随着核心处理器的不断增加看起来也很合理，如果这种成为可能的话，那么Java中使用闭包的地方将会很少了，语言就不需要提供这个特性了。

虽然这样，但是对编程语言来说。不断的平稳发展还是非常重要的。因此下面讲了3种技术，向Java中增加新的语言特性而又不改变语言本身，他们是客户化领域特定语言（DSL）、Java6的注解处理器（用库来添加可选择的语言特性）以及将语法糖从语言般向IDE。每个技术都能让主流开发者用非侵入方式体验这些新特性，好的想法可以融合到语言

核心当中。

客户化DSL

在这3个技术中，讨论最多的还是特定领域语言或者说是DSL。关于DSL的定义有很多争议，但是为了方便我们讨论，我们把它当作一个简单的语言而不是一个解决计算机问题的语言。那样DSL就不是图灵完备的了。当然也有边缘情况，例如，Postscript是图灵完备的语言但是也可以作为DSL来定义。

正如上面的例子，一个DSL也不是新的想法。其他熟悉的DSL包括正则表达式，XSLT，Ant和JSP，所有这样都需要一个定制的分析器排序，来处理他们。Martin Fowler也指出interfaces/API可以被认为是一个第二种类型的内部DSL。他认为一个内部DSL应该被开发语言直接开发，这是Lisp和Smalltalk程序员普遍的做法，以及最近Ruby社区也一直致力推广这一技术。

虽然很多知名的DSL是为了商业上的开发和维护，但是一些企业已经使用这项技术来创造一种语言，但还是小部分人，可能是DSL门槛较高吧。这个小组必须设计语言，建立解析器和其他可能的工具来支持这个程序，以及培养一个新加入者如何用DSL。这是出现来可以支持DSL开发的工具，这大大的改变了局面。Intentional Software所开发的Intentional Domain Workbench比Java还要久，它首先实现了该工具的功能。该项目开始于微软研究院，Charles Simonyi博士在1995年所发表的论文“The Death of Computer Languages，the Birth of Intentional Programming”中描绘了其愿景。2002年，Simonyi 创建了Intentional Software以继续实现他的想法，一个巨大的系统中获得的令人印象深刻的视频。该产品现在是1.0版本，但访问权仅限于有限合伙人。

其他的一些公司也开始研究这项技术，其中包括一IntrelliJ IEDA Java IDE而出名的JetBrains，它最近发布了Meta Programming System（MPS）1.0版。MPS并没有使用分析器，而是直接使用Abstact Syntax Tree（AST）。他提供了一个可以允许程序员来操作的AST以及可以编写语言和程序的文本编辑器。当程序员使用投影时就会为树上的每个借点创建一个文本，这样变化就会反映到节点当中。开发者能通过这样的方法开任意组合。JetBrains正在内部使用这个产品，最近发布了bug追踪产品YouTrack就是使用该系统开发的。

Java6注解处理器

在很多主流语言像Java中，DSL远不如Ruby Smalltalk 和Lisp普遍，最近在Java 语言中出现的变化特别是Java 6中新增的注解处理器为开发者提供了新的机遇去使用

Java。Java EE 6中的JPA 2.0，某些API本身就是 DSL，这就是一个例子。这种处理器会在应用中建立一个持久的元模型。虽然开发者可以很好的用手工去处理Java元模型，但是它会很枯燥无味而且容易出现错误。注解处理器的使用解决了这种痛苦，因为这种处理器是建立在Java内部，而且不需要特殊的IDE支持--IDE会代理处理器自己建立元模型。

使用这种注解处理器也可以为程序库增加新的语言特性。举个例子来说，Bruce Chapman 的原型“no closures”提案就是凭借这种技术将方法转换为 Single Abstract Method（SAM）类型，然后在Java 6上编译。在我们的会话中Chapman指出SAM类型还支持自由变量，这是一个封闭的关键方面：这种方法本身除了Single Abstract Method所需的参数外还可以使用@As.Additional注解声明额外的参数。在获得SAM类型的实例时，这些参数可以带有绑定值，然后在每次调用时传递给方法。

Chapman还建立了Rapt工程来探索这种技术的其他用途，为两种语言的变化提供应用--Multiline Strings和XML--它们是为JDK7使用的但却不会把它放在最终的发布中。Java 也可以通过这种方法来实现自我封闭。当问及这个时Chapman说：我们刚刚使用这个完成了一个Swing项目。我们发现了一种小型的bug,最近其中一种还没有修复，但是其他都还好，没有人想去使用内部等级的。

Lombok项目是注解处理器的另一个项目，它将技术又向前推进了。Lombok将注解作为回调以运行Java agent，后者会根据注解重写各种javac内核。由于它是内部操作，所以它不适合产品使用（JVM各个小版本中的内部类也可能不一样），但是这个项目究竟能做什么还是很有启迪作用的，包括：

?通过@Getter和@Setter注解定义各种访问级别的属性，如@Setter(AccessLevel.PROTECTED) private String name;

?@EqualsAndHashCode注解会根据对象中的属性实现hashCode()和 equals()方法?@ToString注解会实现toString()方法

?@data方法相当于 @ToString、@EqualsAndHashCode、所有属性的@Getter以及所有非final属性的@Setter的集合，可以使用 @data方法和构造方法初始化final属性还可以通过这种方法进行其他的语言试验，比如移除Java中的异常。

虽然注解处理器为语言实验开发了一条新路线，但仍要注意新代码可以被探索者很容易的理解，而不是被机器。在我们的会话中，Chapman给出了很多建议：要生成源代码而不是字节码，注意生成代码的格式（尤其是缩进）。编译器不在乎代码是不是在同一行，但使用者在乎，我甚至还在使用注解处理器在适当的地方加入一些注释。

如果这个技术普遍流行起来，通过IDE可以更容易的查看编译代码。

IDE中的语法糖

Bruce Chapman还提到了第三项技术——将语法糖从语言迁移到IDE中——他在博客中说过这个问题。对于Java IDE来说。生成部分代码已经是不可缺少的了，不如说getter 和setter方法，但是IDE开发者刚刚开始挖掘这个概念。JetBrains的IntelliJ9提供了一个内部类相似，其中开发人员可以输入简短的代码块，如代码折叠代理，这些可以被扩展到完整的匿名内部类——这样坚持使用标准的匿名内部类的开发者就很容易适应了。Eclipse也有一个类似的插件。关键的是这种语法仅仅是代码的另外一种形式罢了，编辑器和任何源代码管理工具都能够像以前那样处理他们。开发者可以在两个方式之间来切换，没有权限访问该语法糖衣的人依然只能看到正常的Java代码。Champman说过：要想实现使用起来好用的目标还有很多工作要做，但是从长远来看，我发现开发者很容易实现加糖/脱糖的转换，不断尝试，不断与同事和社区分享好的点子，这么做的好处与语言的演进没有区别。最好的东西会流行起来并形成实际语言演进的基础，如果必要的话还可以随时去除这种方法无法实现的“噪音”。

由于语法糖衣已经映射到另一个（更详细）的语言功能，不能提供完整的闭包支持。比如说BGGA闭包就有一些特性无法匹配匿名内部类，因此不能通过这种方式实现。话虽如此，这种想法却展示了通过各种新语法来表示匿名内部类的可行性，类似于BGGA语法或是FCM语法，开发者也可以选择自己喜欢的语法。其他的语言特性（如null-safe Elvis operator）可以通过这种方式实现。要想进一步验证该想法，可以体验一下这个NetBeans module（由Chapman开发），这正是他所说的用于 Properties的原型。

结论

在语言的发展中总是有有一个权衡的稳定和进步。这些技术所带来的优点是他们根本不影响平台或者语言。这样可以包容更多的错误，有益于我们进行快速的试验。由于开发者可以进行随意的试验，所以我们看到越来越多的人开始解决常见的样板代码“噪音”问题，例如匿名内部类语法等，同时将这些想法整理出来已获得价值。看看开发人员如何使用这些不同的方法开推动新的方向Java平台，这将是很有趣的。