您所在的位置:主页 > JAVA技术 >

JDK 10计划什么?

时间:2018-01-02 14:25来源:未知 作者:os 点击:

  

  好了,Jigsaw和JShell项目已经出来了,更不用说所有其他的JDK 9功能了,但是让我们来看看Java 10的表格。

  随着最近发布的Java开发工具包(JDK)9,人们非常关注Java的最新特性,包括引入模块(通过合并项目拼图)。尽管近期大部分关注都集中在这些强大的新功能上,但下一个Java版本JDK 10的工作已经开始。在本文中,我们将粗略看一下JDK 10的主要功能,以及JDK 10中可能包含的JDK 10的一些功能。

  请注意,JDK 10的世界变化很快,本文中包含的信息在编写本文时是准确的。预计JDK 10特性组将增加,特性提议可能会在JDK 10最终发布之前增长。

  新功能

  和以前的JDK版本一样,JDK 10还有一些主要特性。这些特性可以分为两个主要类别:(1)发布目标和(2)发布建议。前一类是那些已经被大量吸引的功能,并且已经计划在JDK 10中发布。后一类是那些在被包含在JDK 10中之前已经获得了增长动力并且需要增加支持和成熟度的功能。后一类中的一个功能已经获得了这些先决条件,可能会升级为释放 状态的目标。

  针对发布

  目前有两个针对JDK 10的主要功能:(1)本地变量类型推断,它将删除对象实例化所需的大量冗长的包含手册类型信息,以及(2)整合源代码树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的大量源代码:(1)root,(2)corba,(3)热点,(4)jaxp,(5)jaxws,(6) jdk,(7)langtools,和(8)nashorn。尽管这些过多的存储库为构成JDK的各个组件提供了明确的分离关注点,但管理多个存储库还是有一些主要的缺点。

  其中最重要的是无法在JDK的两个不同部分自动跟踪单个错误修复。例如,如果单个错误修复需要更改包含在不同存储库中的两个系统部分,则必须提交两个提交:每个存储库一个提交。这种不连续性很容易导致项目和源代码管理工具的易处理性和复杂性的降低。

  为了解决这个问题,JEP 296建议将所有现有的存储库合并到一个Mercurial存储库中。这种整合的一个次要影响是,这个单一的Mercurial仓库也可以比现有的八个仓库更容易被镜像(作为一个Git仓库)。尽管在这个整合过程中外部开发人员已经受到一些阻碍,但看起来JDK开发团队已经承诺将此更改作为JDK 10的一部分。有关更多信息,请参阅JEP 296和 建议的JDK 10 OpenJDK Mercurial存储库整合由Michael Redlich发表。

  建议释放

  除了两个目标特性之外,JDK 10目前还有三个提案 - 其中两个专注于升级到JDK的垃圾收集器部分,一个专注于升级到JDK的线程本地功能。

  1.清洁垃圾收集界面

  在当前的JDK结构中,构成垃圾收集器(GC)实现的组件分散在代码库的各个部分。尽管熟悉JDK所使用的GC方案的人员都熟知这些约定,但是对于新开发人员来说,找到特定GC的源代码或创建新的代码通常是令人困惑的。而且,随着Java中模块的出现,希望从构建过程中排除不必要的GC,但GC接口的当前交叉结构排除了这种增强。

  JEP304被设计成解决这个问题的方案,并提出整合和清理GC接口,从而更容易实现新的GC,并更好地维护现有的GC。在完成这个建议之后,地理信息系统的实施将负责提供以下内容:

  堆,是的一个子类 CollectedHeap

  障碍集,它的一个子类BarrierSet,实现了运行时的各种障碍

  执行 CollectorPolicy

  一个实现GCInterpreterSupport,为解释器实现GC的各种障碍(使用汇编指令)

  一个实现GCC1Support,为C1编译器实现GC的各种障碍

  一个实现GCC2Support,为C2编译器实现GC的各种障碍

  初始化GC特定的参数

  设置一个MemoryService相关的内存池,内存管理器等

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

  2.垃圾收集器的并行化

  随着JDK 9的发布,Garbage-First(G1)GC取代了Parallel Collector作为默认的GC。为了减少垃圾收集在JDK 9之外的JDK版本中的影响,G1收集器将被并行化(以匹配Parallel Collector的特性)。尽管迄今为止这种并行化的实现细节信息很少,但关于这种变化的更多细节可以在JEP 307规范中找到。有关GC实现的更多信息,请参阅Oracle 的G1指南和“ 并行收集器”指南。

  3.线程局部握手

  目前,停止Java线程是一个全有或全无的过程,需要达到Java虚拟机(JVM)安全点才能停止单个线程。为了允许单个线程被停止,JEP 312建议包含对线程的回调。这种变化受限于明显增加现有JVM功能的性能开销以及改变达到JVM全局安全点的现有时态语义。有关此提议的更多信息,请参阅JEP 312上的Thread-Local Handshake OpenJDK讨论。

  结论

  尽管许多Java开发人员认为JDK 9的发布是新鲜的,但是这个工作并没有停止在未来的JDK版本上。特别是,JDK 10承诺为局部变量实例化引入类型推断机制,并将现有的JDK存储库合并到一个Mercurial存储库中。另外,在更成熟和支持的情况下,JDK 10还可能包含对GC接口和默认GC实现的一些重要升级,以及JVM中单个线程的可寻址性升级。虽然JDK 10的发布在未来还是相对较远的,而且包含的功能很有可能会增加,但它已经承诺会带来很多好处,并且可能成为Java时间表中的一个重要里程碑。