InfoQ

新闻

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?

与其这样增加复杂度,不如另起炉灶 发表人 cao yunfei 发表于 2008年5月19日 下午10时28分
Re: 与其这样增加复杂度,不如另起炉灶 发表人 avatar blogbin 发表于 2008年5月20日 上午8时43分
generics还是译为泛型为好 发表人 图灵 刘江 发表于 2008年5月20日 上午11时17分
Re: generics还是译为泛型为好 发表人 玮 宋 发表于 2008年5月20日 下午8时21分
现在的Java还是Java么?下个版本改名叫JAll。 发表人 kong xx 发表于 2008年5月20日 下午7时32分
不赞同文章的观点 发表人 Brice Li 发表于 2008年5月20日 下午8时37分
JSR 308,就是Design by Contract的语言级支持吧? 发表人 avid mouse 发表于 2008年5月20日 下午9时15分
  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的目标及适用的是企业级应用,如果非要用牛刀杀鸡(现在很多人这么做),还怪牛刀太重,是不是应该自问下,是不是拿错刀了?

深度内容

和Google互补的搜索引擎Wolfram|Alpha

Wolfram|Alpha与Google究竟是什么关系,Wolfram|Alpha自己是如何定位的?Wolfram|Alaph在多大程度上是语义网搜索呢?InfoQ中文站就等等这些问题采访了Wolfram研究公司中国区商务经理王翔。

SOA契约成熟度模型

本文说明了所推荐的契约版本管理设计策略是如何与SOA成熟度模型发生联系的。文章目的是为实现版本管理和可组合性提供一个路线图。

数据服务简介

Vijay Narayanan在这篇文章中对数据服务的几个方面进行了介绍,它们都是SOA实践者和数据架构师感兴趣的内容。本文对数据服务的几个方面进行了介绍,包括需求定义,基本原理和好处、范围、开发以及消费模式。

分块云计算

在本文中,Jimmy Nilsson描述了一种他在过去数年间观察到的一种正在缓慢成长的架构风格,他把这种风格称为“分块云计算”。

豆瓣网技术架构变迁

罗马不是一天建成的,豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。在本次演讲中,豆瓣的首席架构师洪强宁将与大家一起分享从上线时的单台服务器架构开始一直到现在的豆瓣架构变迁历程。

融合思想:深入探索S#arp架构

Billy McCafferty展示了S#arp架构,它在ASP.NET MVC框架的基础上,荟萃了当今的最佳实践,应用在ASP.NET Web应用程序的架构设计中。

王雷谈开源以及新兴市场计划

中国作为新兴市场中的新兴市场,是Sun在美国之外实施SSE(SUN Startup Essentials)项目重点关注的地区。在QCon Beijing 2009期间,InfoQ中文站有幸对此项目的负责人王雷先生进行了采访,探讨了关于开源、新兴市场、SSE等话题。

使用HTML5构建下一代的Web Form

HTML5 是由 WHATWG发起的,最开始的名称叫做Web Application 1.0,而后这个标准吸纳了Web Forms 2.0的标准,并一同被W3C组织所采用,合并成为下一代的HTML5标准。