BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

JSR 308:Java语言复杂度在恣意增长?

| 作者 Alexander Olaru 关注 0 他的粉丝 ,译者 祁飞 关注 0 他的粉丝 发布于 2008年5月20日. 估计阅读时间: 7 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

在上周举行的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?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

与其这样增加复杂度,不如另起炉灶 by 曹 云飞

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

Re: 与其这样增加复杂度,不如另起炉灶 by blogbin avatar

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

generics还是译为泛型为好 by 刘江 图灵

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

现在的Java还是Java么?下个版本改名叫JAll。 by Kong Fanbin

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

Re: generics还是译为泛型为好 by 宋 玮

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

不赞同文章的观点 by Li Brice

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

JSR 308,就是Design by Contract的语言级支持吧? by mouse avid

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

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

7 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT