java最新版本是多少、java最新版本是多少版本 收藏 0

Java9 2016年发布，新特性抢先看

IT之家（www.ithome.com）：Java9 2016年发布，新特性抢先看

很显然，Oracle已正在开发Java 9。Java 9主要的增强内容之前已经出现在OpenJDK之上。而现在Oracle发布的是真正的新特性，前一个JDK 9的early access发行版被标注了“修复bug和小增强”。

新的APIs和性能特性：

1、轻量级的JSON API

2、HTTP 2Client支持HTTP 2.0和WebSockets，替代传统的HttpURLConnection

3、Process API更新提升对操作系统进程的控制和管理

此外还有一些小的特性和性能提升：

1、Improvecontended locking,提升访问对象时的线程竞争处理

2、Segmentedcode cache更好的性能、更短的扫描时间，更少的碎片

3、Smart Java compiler,或者叫sjavac,用于更大项目的构建

Java的本地接口也被重新作为Java Native Runtimeproject的一部分，将支持多GB堆和一个自调整的JVM。

模块化的源码

如果你对上述特性不感兴趣，Oracle还承诺modular source code，目的是重新组织JDK的源码，使之模块化，以及项目Jigsaw的结构化实现。

Jigsaw在Java 7的时候被移除，并在Java 9中回归，这是Oracle下一个Java版本最大的正义点。该项目主要的目的是为更小的设备提供可伸缩性，改进JDK和Java SE的安全性，对大型应用的性能提升以及更易于构建。与此同时PenroseProject用于探索Jigsaw和开源网关计划之间的互操作性。

Oracle的Java平台组的软件开发副总裁Georges Saab之前告诉JAXenter目前主要工作是在处理Jigaws项目，开发团队正在探索和制作一个简单方法的原型来确保能在Java 9发布时可用。

动荡的版本历史

不管怎么说，Oracle知道如何应对不守时的发布Java版本时的吐槽，向之前的Lambda项目和Applet的一些安全问题等等，这些使得Java 8的发布整整推迟了2年，甚至到现在还有Java 8的一些更新导致很多开发工具无法使用的问题

Java 9计划在2016年发布，留给Oracle只有不足2年的时间，但还有大量的时间来对这些特性进行讨论、请求公告等。

Java 20年，以后将往哪儿走？

在今年的Java 20周年的庆祝大会中，JavaOne 2015 的中心议题是“Java 的20年”。甲骨文公司Java平台软件开发部的副总裁Georges Saab的主题演讲就将关注点放在了java的发展历程、它主要的发展里程碑，并且深度关注于Java8及其更新。甲骨文公司Java平台首席架构师Mark Reinhold的主题演讲奠定了Java发展的路线图，并展示了定于2016年Q3季度发布的Java9 。

Reinhold提到Java成功的关键在于辨识到了痛点；找出了缺失的抽象类并添加了抽象类，以此方式来满足现有的解决方案。

Reinhold还说到“目标是随着时间的推移，要持续改善开发人员的开发效率，同时保留Java的可读性、简化性、通用性以及兼容性的核心价值。”

他推断，缺失的抽象类已经引领了Java5的泛型与Java8的lambdas表达式中的重大创新。2008年，Jigsaw项目引入了模块的概念，以此来解决两个不同的痛点：类路径地狱(Classpath Hell)和庞大的单体 JDK。

类路径地狱（Classpath Hell）

据Reinhold所称，类路径(Classpath)的根本问题在于它们不仅仅是类。他说“类路径是一种查找类的方式，不必关心组件、包甚至它们的预期用途。”

在类路径中，甚至都无法确定你们寻找的类就在jar文件内；我们也不知道是否有任何与应用开发接口相关的冲突。并且，当开发人员不知道或是不理解内部接口的目的，并对其进行改变时，内部接口就可能会暴露出一些安全问题。

• 关注InfoQ［ID：infoqchina］了解更多技术领域干货内容。

据Reinhold所称，模块为jar文件提供了一个强有力的抽象类，模块是一个程序组件，它不仅能在java编程语言中实现，在java 虚拟机中同样也能。正如他所说的“模块是脱离类路径地狱(Classpath Hell)的关键。”

• 模块可被看做是包的容器，与此同时，该模块也表述了它与其他模块是如何联系的；

• 模块是包的容器；

• 模块为其依赖的其他模块命名；

• 一个模块不会对其他模块进行干扰；

• 模块只有通过其它依赖它的模块才能输出特定的包来使用。

为了在Java9中使用模块，所需的jar文件中的模块必须在module-info.java文件中进行声明。文件名不是一个类的名字，它是一个约定，就像package-info.java一样；但它仍可以通过javac进行编译。模块化的jar文件包含module-info.class。该模块化的jar文件可作为一个单独的产物进行传送；对于java9预先发布的版本来说，模块化jar文件就像常规jar文件一样运行。

Reinhold提到，通过允许终端用户以从下到上或从上到下的方式将现有的系统进行模块化，模块的采用就大大地简化了。

单体JDK

Jigsaw项目提供了很多新的用例，传统意义上来讲这些用例不适合庞大的单体Java SE JDK。某些用例包括：

• 小型设备——没有足够空间去存储所有的Java SE 包。

• 云应用——不需要复制整个的Java SE JDK。因为在云中，密度是主要因素。（注：密度指的是能为一套特定的软硬件进行交付的系统与服务的数量。）

• 维护与安全——庞大、整体化的JDK系统在子系统之间存在着千丝万缕的联系。并且，它缺乏内部接口的封装，这会导致安全问题。

据Reinhold所称，“模块为强有力的封装提供可依赖的配置。”

有了模块化，伴随着增强的安全性，开发人员只使用需要的功能。因此，在JDK 9中，所有非关键的内部接口将被封装。某些关键的内部接口例如sun.misc.Unsafe仍然可以访问。（绝大部分）内部接口封装的提出表明“JDK 9中引入的、替换掉原有版本的关键内部接口在JDK 9中将被弃用，或者被封装或者在JDK 10中被删除。”Reinhold 提到被封装后的内部接口仍可以在编译时和运行时通过命令行标志来进行访问。

在JavaOne 2015主题演讲上，甲骨文公司Java平台开发部的负责人Georges Saab、Mark Reinhold、Brian Goetz与其他人一起，谈论了Java20年来的发展历程。

在本文的第一部分，InfoQ介绍了Reinhold的主题演讲。现在，我们将介绍Brian Goetz，他是Java平台开发部的Java语言架构师，他窥见了Java10甚至更高版本的所有内在机理，尤其是谈论到Valhalla项目和Panama项目，而它们正是为Java 虚拟机和Java语言本身孕育重大进展的两个项目。这些进展旨在丰富Java虚拟机与底层硬件（包括操作系统）以及非Java应用编程接口之间的关联。

动机

随着时间的推移，越来越复杂的处理器核心设计已经影响了成本模型的时钟周期和底层硬件/中央处理器内核的分发槽问题。高速缓存缺失是非常昂贵的，尤其是当你还需要从主内存中读取数据的时候。因此急需Java和Java虚拟机具有更密集和平整的内存布局来提供更好的缓存和内存效率，从而跟上当今时代硬件的发展步伐。

Valhalla项目

Goetz提到Valhalla项目包括了一些Java语言和Java虚拟机的特色，这些特色用于与纯数据共同协作，而这些纯数据不包含对象强加的所有开销。他为我们举了以下的例子，并进行了相应的解释：

假设有一个简单的域对象 Point Class：

class Point { final int x; final int y; }

一个X-Y的实例数组会伴随着150%的内存开销，只为表示数据的两个词；一个两个词的对象头（通常用于所有的对象）及其元素，作为Point对象的引用，再加上每一个Point对象的头：

值类型

如果Point类不可改，我们就不要求它的身份；我们可以将Point类以数值类的形式定义为一个纯数据类型的Point。

value class Point { final int x; final int y; }

在这个例子里，这样的数值类型将不存在间接引用。因此，我们拥有一个友好的高速缓存布局，而这个布局不仅可以高效地使用内存，还具有更好的局域性。

据Goetz称：

数值类型就像类和基元之间的高速公路…从代码上来说，它们像类，但是从表现上来说，它们像整型变量。

特化泛型

有人提议通过增强Java语言和Java虚拟机来加强对超基元泛型的支持。关于数值类型的好消息就是它们可以向基元类型那样装箱了。结果，泛型被支持的程度最终也将超过所有数值类型。

据Goetz所称，即便你工作时用的是：

ArrayList<Integer>

但实际上你想要的是：

ArrayList<int>

因此现阶段核心Java库中无法实现你用前者工作却追求后者。但当你指定

ArrayList<Integer>

其内存控制和内存开销的低效性与之前x-y Point类数组的例子十分相似。

如果指定：T为整型，对T进行装箱（Box<T> for T=int）,并对值类型进行扩展，开发者就会实现之前数值类型的那个例子中说的巨大的成本效益。

Panama项目

接下来，Goetz继续讨论Panama项目，该项目旨在为本地数据（例如：本地堆中的数据）和本机代码（例如：C中的函数）以更快、更加可信和更加安全的方式提供Java虚拟机的访问权限。

在Panama项目中，名为jextract的本地头文件输入工具会提取布局元数据（例如：C的头文件），并生成Java接口去调用本地方法或访问本地结构。在运行时期间，Java虚拟机会生成与用户可能编写的JNI代码相似的代码。

Goetz为我们举了个例子，该例子需要将指针传递给结构，以便从time.h中调用gettimeofday。因此，我们采用jextract来解析头文件，同时也会得到机器类型的信息。所得到的jar文件具有结构的定义和方法的声明。

因此，所有需要调用上述方法的类与结构都是时间库的参考，同时也是一种结构的创造，正如以下代码所示。

正如上述代码所示，之后想要获取属性就像调用getter方法一样简单了。

Java 22 正式发布

作者 | Michael Redlich

译者 | 张卫滨

策划 | Tina

本周，Oracle 发布了 JDK 22，包含 12 项新特性，可以分为四类，即核心 Java 库、Java 语言规范、HotSpot 和 Java 工具。该公司还热衷于吸引新开发人员的关注，部分方法是改进对 Visual Studio Code (VS Code) 的支持。

JDK 22 是一个特性版本，这意味着 Oracle 将为其提供 6 个月的支持，直到下一个特性版本发布。LTS 版本（例如 JDK 21）则可获得长达 8 年的支持。下一个 LTS 版本将是 Java 25，计划于 2025 年 9 月发布。

Oracle 宣称 Java 是“当今科技趋势的排名第一语言”，并且它是“排名第一的企业/IT 组织使用语言”。 据 Oracle 称，目前有 630 亿个活跃的 Java 虚拟机 (JVM) 和 410 亿个基于云的 JVM 正在使用。

这些新特性中，有六个新特性归类在核心 Java 库下：

• JEP 454：外部函数和内存API（Foreign Function & Memory API）
• JEP 457：类文件API（Class-File API，预览）
• JEP 460：向量API（Vector API，第七轮孵化）
• JEP 461：流聚合器（Stream Gatherers，预览）
• JEP 462：结构化并发（Structured Concurrency，第二轮预览）
• JEP 464：作用域值（Scoped Values，第二轮预览）

四个新特性归类在 Java 语言规范下：

• JEP 447：super(…)前导语句（Statements before super(…)，预览）
• JEP 456：未命名变量和模式（Unnamed Variables & Patterns）
• JEP 459：字符串模板（String Templates，第二轮预览）
• JEP 463：隐式声明类和实例主方法（Implicitly Declared Classes and Instance Main Methods，第二轮预览）

一个新特性归类在 HotSpot 下：

• JEP 423：G1的区域锚定（Region Pinning for G1）

最后，还有一个新特性归类在 Java 工具下：

• JEP 458：启动多文件源码程序（Launch Multi-File Source-Code Programs）

我们对其中的一些新特性进行研究，并将其归类到四个主要的 Java 项目中，即Amber、Loom、Panama和Valhalla，这些项目旨在通过精巧的合并，孵化一系列组件，以便最终将其纳入到 JDK 中。

JEP 463，隐式声明类和实例主方法（Implicitly Declared Classes and Instance Main Methods，第二轮预览），以前被称为未命名类和实例主方法（Unnamed Classes and Instance Main Methods，预览）、灵活主方法和匿名主类（Flexible Main Methods and Anonymous Main Classes，预览）和隐式类和增强的主方法（Implicit Classes and Enhanced Main Methods，预览），该 JEP 包含了对前一轮预览反馈的增强，即 JEP 445，未命名类和实例主方法（预览）。这个 JEP 建议“演进 Java 语言，这样学生们就可以编写他们的第一个程序，而不需要理解为大型程序所设计的语言特性”。这篇 JEP 延续了甲骨文的 Java 语言架构师Brian Goetz在 2022 年 9 月发表的博客文章Paving the on-ramp。甲骨文的技术顾问Gavin Bierman已经发布了规范文档的初稿，供 Java 社区审查。关于 JEP 445 的更多细节可以在 InfoQ 的新闻报道中找到。

JEP 459，字符串模板（String Templates，第二轮预览），提供了对第一轮预览的再次预览，即 JDK 21 交付的 JEP 430, 字符串模板（String Templates，预览）。这个特性通过字符串模板对 Java 编程语言进行了增强，字符串模板是包含嵌入式表达式的字符串常量，可以在运行时进行解释，嵌入的表达式将在运行时进行计算和校验。关于 JEP 430 的更多详细信息可以参见 InfoQ 的新闻报道。

JEP 456，未命名变量和模式（Unnamed Variables & Patterns），建议在上一轮的预览后最终确定该特性，即 JDK 21 交付的 JEP 443, 未命名模式和变量（Unnamed Patterns and Variables，预览）。这个特性建议“用未命名的模和未命名变量来增强语言，前者与记录组件相匹配，但无需说明组件的名称和类型，后者可以被初始化但不使用”。 这两者均由下划线字符表示，如r instanceof _(int x, int y)和r instanceof _。

JEP 447，super(…)前导语句（Statements before super(…)，预览），该 JEP 建议允许构造函数中不引用正在创建的实例的语句出现在this()或super()调用之前，并保留现有的安全性和初始化保证。Bierman 提供了该特性的初始规范，供 Java 社区评审和反馈。

JEP 464，作用域值（Scoped Values，第二次预览），以前被称为范围局部变量（Extent-Local Variables，孵化），这个 JEP 建议在 JDK 22 中进行第二轮预览，不做任何更改，以便于从上一轮预览中获得额外的经验和反馈，即 JDK 21 交付的 JEP 446, 作用域值（预览）和 JDK 20 交付的作用域值（孵化）。该特性允许在线程内部和线程之间共享不可变数据。这种方式优于 thread-local 变量，特别是在使用大量虚拟线程的时候。

JEP 462，结构化并发（Structured Concurrency，第二次预览），这个 JEP 将提议进行第二轮预览，不做任何变更，以便于从上一轮预览中获取更多的反馈，即 JDK 21 交付的 JEP 453，结构化并发（Structured Concurrency，预览）。这个特性通过引入结构化并发性来简化并发编程，“将在不同线程中运行的相关任务组视为单个工作单元，从而简化错误处理和取消，提高可靠性并增强可观测性。”

JEP 460，Vector API（第七轮孵化），吸收了对前六轮孵化反馈的改进，即 JDK 21 交付的 JEP 448，Vector API (第六轮孵化)、JDK 20 交付的 JEP 438，Vector API (第五轮孵化)、JDK 19 交付的 JEP 426，Vector API (第四轮孵化)、JDK 18 交付的 JEP 417，Vector API (第三轮孵化)、JDK 17 交付的 JEP 414，Vector API (第二轮孵化)以及在 JDK 16 中以孵化器模块交付的 JEP 338，Vector API（孵化）。JEP 448 最重要的变更包括对JVM编译器接口（JVM Compiler Interface，JVMCI）的增强，以支持 Vector API 值。

JEP 454，外部函数和内存API（Foreign Function & Memory API），建议在经历了两轮孵化和三轮预览之后确定该特性，即 JDK 17 中交付的 JEP 412, 外部函数和内存API（Foreign Function & Memory API，孵化器）、JDK 18 中交付的 JEP 419，外部函数和内存API（Foreign Function & Memory API，第二轮孵化）、JDK 19 中交付的 JEP 424，外部函数和内存API（Foreign Function & Memory API，预览）、JDK 20 中交付的 JEP 434，外部函数和内存API（Foreign Function & Memory API，第二轮预览）和 JDK 21 中交付的 JEP 442，外部函数和内存API（Foreign Function & Memory API，第三轮预览）。自上一个版本以来的改进包括：新的Enable-Native-Access manifest 属性，允许可执行 JAR 包中的代码调用受限制的方法而无需使用–enable-native-access标志；允许客户端通过编程的方式构建 C 函数描述符，避免使用特定于平台的常量；改进了对本地内存中可变长度数组的支持；支持多字符集本地字符串。关于 JEP 454 的更多细节请参见 InfoQ 的新闻报道。

JDK 23计划于 2024 年 9 月正式发布，目前只有一个 JEP 列入了目标之中。不过，根据一些候选和草案 JEP，尤其是那些已提交的 JEP，我们可以推测还有哪些 JEP 可能被纳入 JDK 23。

JEP 455，模式、instanceof和switch中的原始类型（Primitive Types in Patterns, instanceof, and switch，预览）已经成为 JDK 23 的 Targeted 状态。 该 JEP 位于 Amber 项目下，建议通过允许在所有模式上下文中使用原始类型来增强模式匹配，并扩展instanceof和switch以允许使用原始类型。甲骨文公司的核心技术人员Aggelos Biboudis 最近发布了该功能的最新规范草案。

JEP 468，派生记录创建（Derived Record Creation，预览），已经从 JDK Draft 8321133提升到了 Candidate 状态。该 JEP 建议通过派生创建记录来增强 Java 语言。由于记录是不可变的对象，开发人员经常会根据旧记录创建新记录，以建立新数据模型。派生创建可从现有记录派生出新记录，只需指定不同的组件即可，从而简化代码编写。

JEP 467，Markdown文档注释（Markdown Documentation Comments），已经从 JDK Draft 8316039提升到了 Candidate 状态。该特性建议支持 JavaDoc 文档注释以 Markdown 格式编写，而不仅仅是 HTML 和 JavaDoc @标记的混合体。这将使文档注释更易于编写，也更易于以源代码形式阅读。

JEP 466，类文件API（Class-File API，第二轮预览），已经从 JEP Draft 8324965 状态提升到了 Candidate 状态。该 JEP 建议进行第二轮的预览，以便于获取上一轮预览的反馈，也就是 JDK 22 即将交付的 JEP 457，类文件API（Class-File API，预览）。该特性提供了一个 API 来解析、生成和转换 Java 类文件。它最初作为 JDK 中ASM的替代品，ASM 是一个 Java 字节码操作和分析框架，并计划将其作为公开 API 对外开放。甲骨文的 Java 语言架构师Brian Goetz将 ASM 描述为“带有大量遗留包袱的旧代码库”，并提供了关于该草案如何发展并最终取代 ASM 的背景信息。

JEP 465，字符串模板（String Templates），已经从 JEP Draft 8323333 状态提升到了 Candidate 状态。该 JEP 建议在两轮的预览之后最终确定该特性，也就是 JDK 22 即将交付的 JEP 459，字符串模板（String Templates，第二轮预览）和 JDK 21 交付的 JEP 430，字符串模板（String Templates，预览）。这个特性通过字符串模板对 Java 编程语言进行了增强，字符串模板是包含嵌入式表达式的字符串常量，可以在运行时进行解释，嵌入的表达式将在运行时进行计算和校验。关于 JEP 430 的更多详细信息可以参见 InfoQ 的新闻报道。

JEP 401，Null-Restricted值对象存储（Null-Restricted Value Object Storage，预览），以前被称为原始类（Primitive Classes，预览），位于 Valhalla 项目中，它引入了开发人员声明的原始类（Primitive Classes），即由值对象 API 定义（Value Objects API）的特殊类型的值类，它们定义了新的原始类型。

甲骨文的 Java 架构师Paul Sandoz提交了 JEP Draft 8326878，Vector API（孵化器）。经历了从 JDK 16 到 JDK 22 的七轮孵化后，本 JEP 建议在 JDK 23 中重新孵化 API，与 JDK 22 相比，不会对 API 进行更改，也不对实现进行实质性的变更。该特性将引入一个 API，用于“表达向量计算，这些计算可在运行时可靠地编译为所支持 CPU 架构上的最佳向量指令，从而实现优于同等标量计算的性能”。

Bierman 和 PatientEXP 的创始人兼 CEOArchie Cobbs提出了 JEP Draft 8325803, 灵活的构造函数方法体（Flexible Constructor Bodies，第二轮预览），该 JEP 建议进行第二轮预览并更改名称，以获取对上一轮预览的反馈，也就是 JDK 22 即将交付的 JEP 447：super(…)前导语句（Statements before super(…)，预览）。该特性允许构造函数中不引用正在创建的实例的语句出现在this()或super()调用之前，并保留现有的安全性和初始化保证。该 JEP 中的变更包括：对本地类的处理；将在显式构造函数调用前不能访问字段的限制进行了放宽，即在显式构造函数调用前不能读取字段的要求。Bierman 提供了该特性的初始规范，供 Java 社区评审和反馈。

JEP Draft 8307341，准备限制对JNI的使用（Prepare to Restrict The Use of JNI），建议限制使用本质上不安全的 Java 本地接口(Java Native Interface，JNI)，同时在外部函数和内存 (Foreign Function & Memory，FFM)API 中使用受限方法，该 API预计将在JDK 23中成为最终特性。从 JDK 23 开始，除非 FFM 用户在命令行上启用了不安全的本地访问，否则 Java 运行时将显示关于使用 JNI 的警告。预计在 JDK 23 之后的版本中，使用 JNI 将抛出异常而非警告。

JEP Draft 8313278，Java虚拟机的预先编译（Ahead of Time Compilation for the Java Virtual Machine），建议“增强 Java 虚拟机加载编译为原生代码的 Java 应用程序和库的能力，以加快启动和基线执行”。

JEP Draft 8312611，已计算常量（Computed Constants，预览），引入了已计算常量的概念，它被定义为最多初始化一次的不可变值持有者。它具有final字段在性能和安全性方面的优势，同时在初始化时机方面具有更大的灵活性。该功能将作为预览API 首次亮相。

JEP Draft 8283227，JDK源码结构（JDK Source Structure），这是一个信息型的 JEP，描述了 JDK 源代码的整体布局和结构以及 JDK 仓库中的相关文件。该 JEP 建议帮助开发人员适应 JDK 9 中交付的 JEP 201，Modular Source Code（模块化源代码）所描述的源代码结构。

JEP Draft 8278252，JDK打包和安装指南（JDK Packaging and Installation Guidelines），这是一个信息型的 JEP，建议提供在 macOS、Linux 和 Windows 上创建 JDK 安装程序的指南，以降低不同 JDK 提供商之间安装 JDK 发生冲突的风险。其目的是通过规范安装目录名称、软件包名称和安装程序中可能导致冲突的其他元素，使得在安装 JDK 更新版本时获得更好的体验。

我们预计甲骨文将很快开始为 JDK 23 制定更多 JEP。

原文链接：

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com