Java 7新特性 (一)

原创|其它|编辑:郝浩|2009-04-20 09:19:31.000|阅读 595 次

概述:当Java SE 6在2006年12月发布之后,开发者就已经立即开始关注哪些JSR有可能被包含在Java SE 7中。在2007年1月份,我开始就这个问题与业界同仁展开讨论,现在已经过去近两年的时间,当时的观点中有些被证明是正确的,也有一些已经被人们所逐渐淡忘。

# 界面/图表报表/文档/IDE等千款热门软控件火热销售中 >>

当Java SE 6在2006年12月发布之后,开发者就已经立即开始关注哪些JSR有可能被包含在Java SE 7中。在2007年1月份,我开始就这个问题与业界同仁展开讨论,现在已经过去近两年的时间,当时的观点中有些被证明是正确的,也有一些已经被人们所逐渐 淡忘。

从成熟度、重要性和社区认可度等方面分析,现在我们或许可以更清楚的看到,哪些JSR和语言改进将有可能被包含在Java SE 7中。但是,在Sun公司Java SE首席架构师丹尼·考沃德(Danny Coward)正式提交Java SE 7平台JSR以前,一切变化都有可能发生。所有的Java类库和语言变化都将被作为平台JSR的一部分而被通过,新JSR与现有JSR共同组成新平台的完 整功能集合。Java SE 7目前预计推出时间是2010年初。明年第一季度我们有望看到其平台JSR。

本篇文章的其余部分,将重点介绍最有可能包含在Java SE 7中的功能,同时以代码示例来证明其相对于我们今天编程方式所带来的改变。我今天所介绍的所有JSR都具有详细说明和工作原型,因此它们已经相当成熟。

更强大的依赖关系管理

现在的Java程序员,或者说所有语言的程序员,都面临着日益增多的开源和商业类库,往往要花费很长时间来管理其依赖关系。今天的一个普通企业应用 程序往往要依赖数十个外部JAR文件,其本身往往就能包含数十个不同团队开发的更小内部工程。我们一直在坚持寻找更好的方式来管理日益复杂的依赖关系,以 使我们的开发更具重用性,部署更加完整。现在出现了越来越多的类似Maven的依赖关系管理系统,以及诸如OSGi之类的运行时部署系统,这一点正是反应 了这种需求的增长趋势。

在Java SE 7发展初期,两个重要的JSR曾经试图解决依赖关系管理问题,分别是JSR 294:Java编程语言中的改进模块性支持(Improved Modularity Support in the Java Programming Language)和JSR 277:Java模块系统(Java Module System),两者分别关注Java模块概念的开发和部署方面。一个模块(module)就是多个实现相同目标且相互存在联系的类的集合,与JAR类 似,但是,根据开发和部署的需要,一个模块的范围可以是一个JAR的一部分,也可以是几个JAR的集合。在2008年中期,JSR 294被简化并合并到JSR 277中,以便同一个专家组能够先后研究这两个方面。

在2008年12月份,Sun再次重新审视这一计划,宣布在OpenJDK社区中创建Jigsaw项目,以在明年实现JDK 7模块化。JSR 277和Java模块系统的研究将被放到Java SE 7推出之后进行,而JSR 294将被重新恢复研究。Sun已经声明了此举的意图是,与OSGi联盟更紧密的配合,以便JSR 294模块可以被OSGi所使用。

Jigsaw项目和‘module’关键字

在Java SE 7中有一个问题将得到解答,即Sun将如何来使用module关键字,它是最初的JSR 294中的一个重要概念,预计将包含在下一平台版本中。

假定有一个名为Flapjack的项目由几个Java包(package)组成,该项目包含在基包(base package)中的一个public APIs,和实现这个API的几个内部包:

◆org.flapjack - public API classes

◆org.flapjack.impl - 实现类

◆org.flapjack.util - 实用类

在Java SE 6中,如果你需要在基包中放置一个工厂类(factory class),以实例化内部执行包中的API类,你需要将这个实现类设为public,这样它们才可以从API包中被看到。由于跨越了不同的包,没有办法 既允许API以factory方法对类实例化,又不允许外部类直接执行它。

JSR 294模块将允许你声明整个包集合为一个模块,你只需要在源程序中加入以下一个新的声明:

module org.flapjack;

你可以将这个声明加在你的项目中每一个源程序文件中,也可以将其增加到package-info.java文件中,然后一次将其应用到整个包。虽然 module是一个新关键字,它是一个“限制性”关键字,只有在特定位置时才被作为关键字来处理;因此,它可以在任何其它地方作为普通Java标识符来使 用。这使得它扩展了语言的功能,同时又保持了其向后兼容性。

除了新的声明外,你还可以把module关键字当作一个新的可见性修饰符使用,你可以用它来定义一个类,使其仅对同一个模块中的其它类可见,Listing 1演示了module关键字的这种用法。

Listing 1

module org.flapjack;

package org.flapjack.impl;

import org.flapjack.Flapjack;

module class FlapjackImpl implements Flapjack {

}

最后,你可以定义一个新的module-info.java伪类,使用元数据来注释该模块,增加诸如版本、主类、导入的依赖模块、导出资源和许多其 它预定义或特定的模块注释等。值得注意的是,与现有的package-info.java文件一样,这个新的module-info.java文件使用了 一个无效Java源文件名称,可以避免与已经存在的文件可能发生冲突。

在编译时,JSR 294让你可以使用javac来编译你的类。至于在JVM中,Jigsaw项目将如何规定模块的组成、加载和验证,尚需拭目以待。

更多NIO APIs

JSR 203:NIO 2扩展和实现了在Java 1.4中加入的最初NIO功能。在NIO 2中最明显的新增功能就是文件访问API的全面改进。多数开发者都用过java.io.File,对其存在的众多缺陷自然心中有数:

◆不支持符号链接(symbolic links )

◆不支持简单移动和拷贝操作

◆目录漫游和过滤API非常复杂

◆对文件属性和访问权限的支持非常有限
◆没有查看目录或文件的API
◆有限的错误处理功能
幸运的是,JSR 203不仅改进了以上所有缺点,而且实现了更多功能。这个API从一开始就设计为具备可扩展性,除了支持默认文件系统外,还支持嵌入式文件系统,还具有诸多灵活选项设置,可以实现诸如打开和拷贝文件、系统属性定义等操作。
Listing 2演示了JSR 203是如何被用来实现一些通用操作。Path是这个API的核心;你可以把它看作新建文件。
Listing 2

import java.nio.file.*;

// FileSystems -> FileSystem -> Path
FileSystem fileSystem = FileSystems.getDefault();
Path homeDir = fileSystem.getPath("/Users/lskywalker");

// Shortcut with Paths helper class
Path homeDir = Paths.get("/Users/lskywalker");
Path secrets = homeDir.resolve("secrets.txt");

// Steal secrets
secrets.moveTo(Paths.get("/Users/dvader/secrets.txt"));

除了文件系统API外,JSR 203还实现了许多在第一版NIO中提出的API,提供了对组播的更多支持,提供了在Socket和文件上进行异步I/O操作的API。


标签:

本站文章除注明转载外,均为本站原创或翻译。欢迎任何形式的转载,但请务必注明出处、不得修改原文相关链接,如果存在内容上的异议请邮件反馈至chenjj@evget.com

文章转载自:自互联网

为你推荐

  • 推荐视频
  • 推荐活动
  • 推荐产品
  • 推荐文章
  • 慧都慧问
扫码咨询


添加微信 立即咨询

电话咨询

客服热线
023-68661681

TOP