皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

Java 10 新特性解密,引入类型推断机制

Java

随着 Java 开发工具包 (JDK)9 的发布,大量的注意力都集中在 Java 的最新特性上,包括引入模块 (通过集成项目 Jigsaw)。尽管最近的很多关注都集中在这些强大的新功能上,但下一个版本的 Java:JDK 10 已经开始准备了。在本文中,我们将粗略地介绍一下 JDK 10 的主要特性,并探讨 JDK 10 中可能包含的一些特性。

请注意,本文中所包含的信息在写本文时是准确的。但是到发布时,JDK 10 特性组预计将会增加。

新功能

与之前的 JDK 版本一样,对于即将到来的 JDK 10 也有一些主要特性。这些特性可以分为两个主要类别:(1) 目标发布,(2) 建议发布。前者表示某些特性已计划在 JDK 10 中发布,后一种类型表示这些特性还需要增加支持和成熟度。一旦条件允许,它就可以升级为一个目标发布状态。

目标发布

目前有两个主要功能针对 JDK 10:

  • 局部变量类型推断, 这将删除大部分对象实例化所需的冗长的包含手动类型信息
  • 整合源树 source tree 的 JDK 库, 即不同的 JDK 库将被合并成一个单一的存储库。

1. 局部变量类型推断

强类型编程语言有很多优点,包括在编译时发现类型错误,但是它们也引入了大量的样板代码,特别是在定义局部变量时。例如,当我们希望实例化一个对象时,我们被迫在赋值的左侧提供显式类型,并在赋值的右边提供实现类型,如下面的片段所示:

MyObject value = new MyObject();

但是,当这个过程重复出现大量任务时,对象实例化可能变得令人沮丧和乏味。许多最流行的强类型的编程语言, 比如 C++, C#以及 Go, 在定义过程中,提供一种局部变量类型推断的功能 (例如 C++提供了 auto 关键字,C#提供 var 关键字)。但是,Java 仍缺乏这样的功能, 它要求开发人员显式声明变量的预期清单类型。

为了解决这个问题,Java 开发工具包 (JDK) 改进建议 (JEP)286 提出了一个上下文敏感的关键字 var,允许局部变量被以下方式初始化:

var value = new MyObject();
var list = new ArrayList<MyObject>();

由于 var 关键字是上下文敏感的,它的使用有下面的规则定义:

代码使用 var 作为一个变量、方法或包名称时将不受影响; 而使用 var 作为类或接口名称的代码将受到影响。

同样,类型推断将受到以下方式的约束:

推断类型将被限制在局部变量的初始化, 增强的 for 循环索引, 以及传统的 for 循环中声明; 它 (将) 不用于方法形式、构造函数形式、方法返回类型、字段、捕获形式,或任何其他类型的变量声明。

考虑到所有的限制和细微差别,这个特性将有助于在开发人员创建的应用程序 Java 代码中减轻大量的单调无聊的动作,并简化 JDK 代码库。更多信息可以在官方的 JEP 286 规范中找到。

2. 整合的 JDK 库

目前,有 8 个不同的 Mercurial 存储库用于存储包含 JDK 的大量源代码:

  • root
  • corba
  • hotspot
  • jaxp
  • jaxws
  • JDK
  • langtools
  • nashorn

虽然过多的存储库提供了对组成 JDK 的各种组件并清晰分离,但管理多个存储库存在一些主要的缺点。

其中最重要的一点是,在 JDK 的两个不同部分,单个错误修复程序不能被原子跟踪。例如,如果一个 bug 修复需要对独立存储库中包含的系统的两个部分进行更改,那么必须提交两个提交: 每个存储库中一个。这种不连续性很容易地降低项目和源代码管理工具的可跟踪性和复杂性。

为了解决这个问题,JEP 296 建议将所有现有存储库合并到一个 Mercurial 存储库中。这种合并的一个次生效应是,这个单一的 Mercurial 存储库比现有的 8 个存储库要更容易的被镜像 (作为一个 Git 存储库)。

虽然在这个整合过程中,外部开发人员有一些阻力,但是 JDK 开发团队似乎已经致力于使这一更改成为 JDK 10 的一部分。有关更多信息,请参见 JEP 296,并提议整合由 Michael Redlich 发布的 JDK 10 OpenJDK Mercurial 存储库声明。

建议发布

除了两个目标特性之外,JDK 10 目前还有三个建议,其中两个主要是对 JDK 的垃圾收集器部分进行升级,另一个侧重于对 JDK 的本地线程功能进行升级。

1 . 清理垃圾收集接口

在当前的 JDK 结构中,组成垃圾收集器 (GC) 实现的组件分散在代码库的各个部分。尽管这些惯例对于使用 GC 计划的 JDK 开发者比较熟悉,但对新的开发人员来说,对于特定 GC 的源代码,或者创建一个新的 GC 常常会感到困惑。更重要的是,随着 Java modules 的出现,我们希望在构建过程中排除不需要的 GC,但是 GC 接口的当前横切结构排除了这种增强。

JEP 304 被设计为解决此问题的方案,并建议整合并清理 GC 接口,以便更容易地实现新的 GC,并更好地维护现有的 GC。本建议完成后,GC 执行将负责提供以下内容:

  •  heap,CollectedHeap 的子类
  •  barrier set,BarrierSet 的子类,它实现了运行时的各种障碍
  •  一个 CollectorPolicy 的实现
  •  GCInterpreterSupport 的实现,它实现了解释器的 GC 的各种障碍 (使用汇编指令)
  •  GCC1Support 的实现,它为 C1 编译器实现了 GC 的各种障碍
  •  GCC2Support 的实现,它为 C2 编译器实现了 GC 的各种障碍
  •  最终 GC 特定参数的初始化
  •  设置 MemoryService、相关的内存池、内存管理器等。

有关这些更改的更多信息,请参见 JEP 304 规范; 有关 Java GC 的更多信息,请参阅 Oracle 提供的垃圾收集器基础指南。

2. G1 垃圾收集器并行化

随着 JDK 9 的发布,Garbage-First(G1)GC 取代了 Parallel Collector 作为默认 GC。为了减少 JDK 9 之外的 JDK 版本中垃圾收集的影响,G1 收集器将被并行化 (以匹配并行收集器的特征)。虽然目前还没有关于这个并行化的实现细节的信息,但是可以在 JEP 307 规范中找到关于此更改的更多细节。

有关 GC 实现的更多信息,请参阅 Oracle 的 G1 指南和并行收集器指南。

3. 项目线程局部握手

当前,停止 Java 线程是一个“全部或没有”的过程,需要一个 Java 虚拟机 (JVM) 的安全点,以使一个线程停止。为了让单独的线程停止,JEP 312 提议将回调包含到线程中。这一更改受到了限制,因为它显著地提高了现有 JVM 功能的性能开销,并且改变了到达 JVM 全局安全点的现有时间语义。有关这个建议的更多信息,请参阅 JEP 312 的 Thread-Local Handshake OpenJDK 讨论。

结论

尽管 JDK 9 对于许多 Java 开发人员非常新鲜,但它的发展并没有停止。特别是,JDK 10 承诺为局部变量实例化引入类型推断机制,并将现有的 JDK 存储库合并到一个 Mercurial 存储库中。

此外,在更成熟和更支持的情况下,JDK 10 还可能包括一些重要的升级到 GC 接口和默认的 GC 实现,以及升级到 JVM 中单个线程的可寻址能力。虽然 JDK 10 的发布在未来仍然相对较远,而且包含的特性很可能会成为 Java 时间轴上的一个重要里程碑。

来源:CodeBay

转自 http://www.oschina.net/news/91377/java-10-new-features

分享到:更多 ()