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

　　[color=red]原帖地址：[/color][url=http://www.infoq.com/cn/news/2008/05/JSR-308]http://www.infoq.com/cn/news/2008/05/JSR-308[/url]

　　在上周举行的JavaOne大会中关于“被提议的Java SE7（“[url=https://www28.cplan.com/cc191/sessions_catalog.jsp?ilc=191-1&ilg=english&isort=&isort_type=&is=yes&icriteria9=TS-5581]TS-5581：即将到来的Java编程语言的变化[/url]”）语言新特性”的介绍中，JSR 308 （[url=http://jcp.org/en/jsr/detail?id=308]Java类型注解[/url]）的综述占了很重要的一部分。除此之外，[url=http://www.doc.ic.ac.uk/~abuckley/]Alex Buckley [/url](Sun Microsystems)、[url=http://people.csail.mit.edu/mernst]Michael Ernst [/url](MIT) 和 [url=http://www.gafter.com/~neal]Neal Gafter [/url](Google)等与会者还介绍了其他一些Java语言新特性：如 [url=http://www.javac.info/Multicatch.html]改进的catch子句[/url]（multi-catch）、 [url=http://www.javac.info/Rethrown.html]安全的re-throw[/url]，[url=http://openjdk.java.net/projects/modules]和Java模块[/url]（Java Modules）。

　　JSR 308想要解决在[url=http://jcp.org/en/jsr/detail?id=175]Java 1.5注解[/url]中出现的两个问题：
　　　　☆　[color=violet]在句法上对注解的限制：只能把注解写在声明的地方 [/color]
　　　　☆　[color=violet]类型系统在语义上的限制：类型系统还做不到预防所有的bug [/color]

　　JSR 308 通过如下方法解决上述两个问题：
　　对Java语言的句法进行扩充，允许注解出现在更多的位置上。包括：方法接收器（method receivers，译注：例public int size() @Readonly { ... }），范型参数，数组，类型转换，类型测试，对象创建，类型参数绑定，类继承和throws子句。
　　通过引入[url=http://www.nljug.org/pages/events/content/jspring_2008/sessions/00042/slides]可插拔的类型系统[/url]（pluggable type systems）能够创建功能更强大的注解处理器。类型检查器对带有类型限定注解的源码进行分析，一旦发现不匹配等错误之处就会产生警告信息。

　　针对上述有关JSR 308的内容，[url=http://www.michaelnygard.com]Michael Nygard[/url]写了一篇题为[url=http://www.michaelnygard.com/blog/2008/05/when_should_you_jump_jsr_308_t.html]Java程序员什么时候离身而去？JSR 308就是使大家离开Java的导火索[/url]的帖子，文章表明了他的观点：JSR 308对Java语言本身和Java开发者来说都有较大影响。在这篇帖子中，在给出了几个如何使用注解的例子之后，Nygard说JSR 308和Java 1.5中引入的范型技术一起都大大增加了Java语言的复杂性，但这些复杂性却没有为Java带来一点点益处：
　　[quote]每种语言都有复杂度预算。Java语言的复杂度预算一下就被Java 5引入的范型给打破了。再认真端详下面的代码：

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

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

　　更令Nygard不安的是，他注意到JSR 308出现的时间正好是软件开发者们对动态语言越来越感兴趣的时候：
　　[quote]所有这些都说明目前已到了对于Java语言来说可能是最糟糕的时候。目前，整个软件开发界都在对动态语言大加赞赏。上面代码兜了一大圈，如果换成采用动态语言，我们只须：

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

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


　　Nygard 相信：一旦JSR 308成为Java语言的一部分，Java开发者们就会转向其他语言。Nygard的结论是：
　　[quote]因此，对Java语言的升级、修订应该赶快回到Java开发者的主流技术认识上......看上去似乎只有两种选择：更动态或者更静态。要么更形式化、更严格，要么更随意、更简明。无疑，JSR 308将彻底加速这种分化。[/quote]

　　意料之中地，上面的观点招致了[url=http://java.dzone.com/articles/when-should-you-jump-jsr-308-t]很多评论员[/url]的不同反应。有评论员发现注解对于开发者来说是一条便捷的“迂回之路”，开发者不用再花大把力气去阅读大量的API文档，可以只集中精力关注思考他们自己的任务。对此，cfagan 作出了回应：
　　[quote]说到底，代码才是“最根本”的文档。代码中包含的注解清楚表明了代码编写者的意图。当没有及时更新或者有遗漏的时候，恰恰是注解中包含的意图信息，最容易在其他文档中被丢失。无论采用什么语言，我赞成“出众的才能产生上好的结果”这种说法。将运行时的错误转到编译阶段，不但可以加速开发进程，还可以节省测试时检查bug的时间。 [/quote]

　　[url=http://hr.reddit.com/r/programming/info/6iguh/comments]Josef谈到了[/url]注解其实是一种并不要求一定要使用的可选项，同时还谈了他自己关于注解被采纳的可能途径的看法。他讲到：
　　[quote]Nygard的观点似乎认为JSR 308被采纳后，注解就变成了必须使用的语言元素，所有Java开发者都必须马上开始书写带有注解的Java代码。但是我预计：一开始，几乎不会有Java程序员使用注解。只会有那些需要书写高确信性软件的公司才会立刻开始使用注解。因为这些公司需要注解所提供的功能来详细说明正确性条件，并对这些正确性条件进行自动检查或半自动检查。 [/quote]

　　Josef还解释了注解与范型的区别之处：
　　[quote]JSR 308中的注解是可以缺省的，这是件好事。对于范型来说这当然不行，否则你就不会知道程序中要使用什么类型。但是对于JSR 308中的注解来说，即使不关注它们，程序员也可以顺顺当当的往下写代码。只有在你使用检查器时，才需要真正考虑注解的事情。[/quote]
　　JavaOne大会上“即将到来的Java编程语言的变化”的介绍者们总结了一些主要原则，使用这些原则可以对那些加入Java语言中的新特性进行评估。这些原则如下：
　　　　[color=cyan]鼓励高级实践（作正确的事）
　　　　追求清晰（把事情做好）
　　　　静态类型优先（保持安全性）
　　　　语言与API分离（保持抽象性） [/color]

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