JSR 308：Java语言复杂度在恣意增长？

作者 Alexander Olaru 译者 祁飞 发布于 2008年5月19日 下午7时56分

社区

Java

主题

JCP标准,

语言

标签

Java SE,

JCP

在上周举行的JavaOne大会中关于“被提议的Java SE7（“TS-5581：即将到来的Java编程语言的变化”）语言新特性”的介绍中，JSR 308 （Java类型注解）的综述占了很重要的一部分。除此之外，Alex Buckley (Sun Microsystems)、Michael Ernst (MIT) 和 Neal Gafter (Google)等与会者还介绍了其他一些Java语言新特性：如 改进的catch子句（multi-catch）、 安全的re-throw，和Java模块（Java Modules）。

JSR 308想要解决在Java 1.5注解中出现的两个问题：

• 在句法上对注解的限制：只能把注解写在声明的地方
• 类型系统在语义上的限制：类型系统还做不到预防所有的bug

JSR 308 通过如下方法解决上述两个问题：

对Java语言的句法进行扩充，允许注解出现在更多的位置上。包括：方法接收器（method receivers，译注：例public int size() @Readonly { ... }），泛型参数，数组，类型转换，类型测试，对象创建，类型参数绑定，类继承和throws子句。
通过引入可插拔的类型系统（pluggable type systems）能够创建功能更强大的注解处理器。类型检查器对带有类型限定注解的源码进行分析，一旦发现不匹配等错误之处就会产生警告信息。

针对上述有关JSR 308的内容，Michael Nygard写了一篇题为Java程序员什么时候离身而去？JSR 308就是使大家离开Java的导火索的帖子，文章表明了他的观点：JSR 308对Java语言本身和Java开发者来说都有较大影响。在这篇帖子中，在给出了几个如何使用注解的例子之后，Nygard说JSR 308和Java 1.5中引入的泛型技术一起都大大增加了Java语言的复杂性，但这些复杂性却没有为Java带来一点点益处：

每种语言都有复杂度预算。Java语言的复杂度预算一下就被Java 5引入的泛型给打破了。再认真端详下面的代码：

@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>()>
 

这还像Java吗? 复杂度预算就像后视镜上淡淡的污渍一样被人忽视。现在，我们只是写出更冗长的代码以提供更详尽的语义信息给编译器，使它能高兴轻松的执行编译工作，可是我们却完完全全忘记了我们真正开发的项目本身到底是什么。

更令Nygard不安的是，他注意到JSR 308出现的时间正好是软件开发者们对动态语言越来越感兴趣的时候：

所有这些都说明目前已到了对于Java语言来说可能是最糟糕的时候。目前，整个软件开发界都在对动态语言大加赞赏。上面代码兜了一大圈，如果换成采用动态语言，我们只须：

var strings = ["one", "two"];

说实在的，上面两种代码，你希望选用哪一种？毫无疑问，动态语言版的不需要我们借助编译器的辅助去满足某些强制性条件。当然，使用动态代码确实需要进行更多的单元测试。可是我还是喜欢使用动态语言，我宁愿选择“不讲究繁文缛节”而不是“满嘴虚礼”。

Nygard 相信：一旦JSR 308成为Java语言的一部分，Java开发者们就会转向其他语言。Nygard的结论是：

因此，对Java语言的升级、修订应该赶快回到Java开发者的主流技术认识上......看上去似乎只有两种选择：更动态或者更静态。要么更形式化、更严格，要么更随意、更简明。无疑，JSR 308将彻底加速这种分化。

意料之中地，上面的观点招致了很多评论员的不同反应。有评论员发现注解对于开发者来说是一条便捷的“迂回之路”，开发者不用再花大把力气去阅读大量的API文档，可以只集中精力关注思考他们自己的任务。对此，cfagan 作出了回应：

说到底，代码才是“最根本”的文档。代码中包含的注解清楚表明了代码编写者的意图。当没有及时更新或者有遗漏的时候，恰恰是注解中包含的意图信息，最容易在其他文档中被丢失。无论采用什么语言，我赞成“出众的才能产生上好的结果”这种说法。将运行时的错误转到编译阶段，不但可以加速开发进程，还可以节省测试时检查bug的时间。

Josef谈到了注解其实是一种并不要求一定要使用的可选项，同时还谈了他自己关于注解被采纳的可能途径的看法。他讲到：

[...]Nygard的观点似乎认为JSR 308被采纳后，注解就变成了必须使用的语言元素，所有Java开发者都必须马上开始书写带有注解的Java代码。但是我预计：一开始，几乎不会有Java程序员使用注解。只会有那些需要书写高确信性软件的公司才会立刻开始使用注解。因为这些公司需要注解所提供的功能来详细说明正确性条件，并对这些正确性条件进行自动检查或半自动检查。

Josef还解释了注解与泛型的区别之处：

JSR 308中的注解是可以缺省的，这是件好事。对于泛型来说这当然不行，否则你就不会知道程序中要使用什么类型。但是对于JSR 308中的注解来说，即使不关注它们，程序员也可以顺顺当当的往下写代码。只有在你使用检查器时，才需要真正考虑注解的事情。

JavaOne大会上“即将到来的Java编程语言的变化”的介绍者们总结了一些主要原则，使用这些原则可以对那些加入Java语言中的新特性进行评估。这些原则如下：

• 鼓励高级实践（作正确的事）
• 追求清晰（把事情做好）
• 静态类型优先（保持安全性）
• 语言与API分离（保持抽象性）

用以上的原则来衡量，JSR 308看上去与Java语言的未来方向很“合拍”。最近这些关于“JSR 308新特性的加入”的讨论或许表明对于上述四条原则的解释存在某种程度的分歧。另一方面，这些讨论或许也能充分说明大家对引领Java语言前进的四条原则的关心。

查看英文原文：JSR 308: Unwarranted Increase in Java Language Complexity?

1. 返回顶部

   与其这样增加复杂度，不如另起炉灶

   2008年5月19日 下午10时28分 发表人 cao yunfei

   这样下去，我宁愿学一门新语言

   回复

2. 返回顶部

   Re: 与其这样增加复杂度，不如另起炉灶

   2008年5月20日 上午8时43分 发表人 avatar blogbin

   Java应该定位在构建代码高可分享、高可维护的系统，而不应该融入许多华而不实的特性。

   回复

3. 返回顶部

   generics还是译为泛型为好

   2008年5月20日 上午11时17分 发表人 图灵 刘江

   范型很多人对应paradigm。而且中文的意思和generics不太对应。

   回复

4. 返回顶部

   现在的Java还是Java么？下个版本改名叫JAll。

   2008年5月20日 下午7时32分 发表人 kong xx

   现在的Java还是Java么？下个版本改名叫JAll。

   回复

5. 返回顶部

   Re: generics还是译为泛型为好

   2008年5月20日 下午8时21分 发表人 玮 宋

   谢谢提醒，这一处确实疏忽了。已经修正。

   回复

6. 返回顶部

   不赞同文章的观点

   2008年5月20日 下午8时37分 发表人 Brice Li

   目前只有javascript和java相对较多的经验,不敢苟同文章的观点,从现在的经验上来看,工程规模打大起来了编写相同的代码必然会更加复杂,也许不是java本身带来的,就是为了管理和维护会认为的加上很多代码规范.javascript两三个人写出来大量的代码然后维护,如果事先没有相应的规范和统一的规范是件比较痛苦的事,而有了规范也是同样也是增加的一种复杂性,只不过不是语言级别的增加而是认为的增加.一些小东西的快速开发当然不需要这些复杂性,不过多半也不会使用java来做,或者就是着规范的好处在已有的一套框架上做增量开发

   回复

7. 返回顶部

   JSR 308，就是Design by Contract的语言级支持吧？

   2008年5月20日 下午9时15分 发表人 avid mouse

   首先，这个特性可以写出更清晰的代码，当然代码会更多； 其次，这个特性是可选的； 所以，我认为这个特性无伤大雅。 作为一个工业语言，java需要的是简单、清晰、可组织性、运行效率，那么java的进化到目前为止应该是合理的。 语言不是万能的，java的目标及适用的是企业级应用，如果非要用牛刀杀鸡（现在很多人这么做），还怪牛刀太重，是不是应该自问下，是不是拿错刀了？

   回复

• 更早的 >