https://blog.csdn.net/agonie201218/article/details/127916729?spm=1001.2101.3001.6650.2&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EAD_ESQUERY%7Eyljh-2-127916729-blog-109105729.pc_relevant_aa&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EAD_ESQUERY%7Eyljh-2-127916729-blog-109105729.pc_relevant_aa&utm_relevant_index=5

背景

2022年Spring6和 SpringBoot3相继推出,在此之前,Java社区一直是"新版任你发,我用Java 8",不管新版本怎么出,很少有人愿意升级。

这一次,Spring 直接来了个大招,SpringBoot3和Spring6的最低依赖就是JDK17!跨过 JDK 8-16,直接升级到 JDK 17。那么为什么是 JDK 17呢?

为什么是JDK17

这么多新版本的 JDK,而且2022年还会推出 JDK 18 和 JDK 19,为什么 Spring 选择了 JDK 17呢。

主要是因为他是一个 Oracle官宣可以免费商用的LTS版本,所谓 LTS,是 Long Term Support,也就是官方保证会长期支持的版本。

图片

上面这张图是 Oracle 官方给出的 Oracle JDK 支持的时间线。可以看得到,JDK 17 最多可以支持到 2029 年 9 月份。按照技术更新迭代的速度,这次免费商用 8 年可谓是良苦用心,为的就是让使用者放心大胆地将 JDK 升级到 JDK 17(不过JDK 8 支持的时间更长,可以延长到 2030 年 12 月,JDK8可谓是YYDS!)

从 JDK 诞生到现在,还在长期支持的版本主要有 JDK 7、JDK 8 、JDK 11以及 JDK 1,JDK 17 将是继 Java 8 以来最重要的LTS版本,是 Java 社区八年努力的成果。

一直以来,Java8 都是 Java 社区心头的痛,Java8提供了很多特性,比如Lambda 表达式、Optional 类,加上Java8超长的支持时间,都导致了JDK8的使用至今。它代表着以稳定性为主的企业管理层与拥抱变化为主的程序猿之间的拉锯战。不升!成为各大厂心照不宣的选择。现在,这种平衡或将打破。因为 Java 届的霸主框架 SpringBoot,选择了最小支持的 Java lts 版本,就是最新的 Java17。

那么接下来,让我们看看,从JDK8到JDK17,Java 社区八年努力的成果有哪些?

从JDK8到JDK17的新特性

JDK9新特性(2017年9月)

  • 模块化
  • 提供了List.of()、Set.of()、Map.of()和Map.ofEntries()等工厂方法
  • 接口支持私有方法
  • Optional 类改进
  • 多版本兼容Jar包
  • JShell工具
  • try-with-resources的改进
  • Stream API的改进
  • 设置G1为JVM默认垃圾收集器
  • 支持http2.0和websocket的API

重要特性:主要是API的优化,如支持HTTP2的Client API、JVM采用G1为默认垃圾收集器。

JDK10新特性(2018年3月)

  • 局部变量类型推断,类似JS可以通过var来修饰局部变量,编译之后会推断出值的真实类型
  • 不可变集合的改进
  • 并行全垃圾回收器 G1,来优化G1的延迟
  • 线程本地握手,允许在不执行全局VM安全点的情况下执行线程回调,可以停止单个线程,而不需要停止所有线程或不停止线程
  • Optional新增orElseThrow()方法
  • 类数据共享
  • Unicode 语言标签扩展
  • 根证书

重要特性:通过var关键字实现局部变量类型推断,使Java语言变成弱类型语言、JVM的G1垃圾回收由单线程改成多线程并行处理,降低G1的停顿时间。

JDK11新特性(2018年9月)(LTS版本)

  • 增加一些字符串处理方法
  • 用于 Lambda 参数的局部变量语法
  • Http Client重写,支持HTTP/1.1和HTTP/2 ,也支持 websockets
  • 可运行单一Java源码文件,如:java Test.java
  • ZGC:可伸缩低延迟垃圾收集器,ZGC可以看做是G1之上更细粒度的内存管理策略。由于内存的不断分配回收会产生大量的内存碎片空间,因此需要整理策略防止内存空间碎片化,在整理期间需要将对于内存引用的线程逻辑暂停,这个过程被称为"Stop the world"。只有当整理完成后,线程逻辑才可以继续运行。(并行回收)
  • 支持 TLS 1.3 协议
  • Flight Recorder(飞行记录器),基于OS、JVM和JDK的事件产生的数据收集框架
  • 对Stream、Optional、集合API进行增强

重要特性:对于JDK9和JDK10的完善,主要是对于Stream、集合等API的增强、新增ZGC垃圾收集器。

JDK12新特性(2019年3月)

  • Switch 表达式扩展,可以有返回值
  • 新增NumberFormat对复杂数字的格式化
  • 字符串支持transform、indent操作
  • 新增方法Files.mismatch(Path, Path)
  • Teeing Collector
  • 支持unicode 11
  • Shenandoah GC,新增的GC算法
  • G1收集器的优化,将GC的垃圾分为强制部分和可选部分,强制部分会被回收,可选部分可能不会被回收,提高GC的效率

重要特性:switch表达式语法扩展、G1收集器优化、新增Shenandoah GC垃圾回收算法。

JDK13新特性(2019年9月)

  • Switch 表达式扩展,switch表达式增加yield关键字用于返回结果,作用类似于return,如果没有返回结果则使用break
  • 文本块升级 “”" ,引入了文本块,可以使用"""三个双引号表示文本块,文本块内部就不需要使用换行的转义字符
  • SocketAPI 重构,Socket的底层实现优化,引入了NIO
  • FileSystems.newFileSystem新方法
  • ZGC优化,增强 ZGC 释放未使用内存,将标记长时间空闲的堆内存空间返还给操作系统,保证堆大小不会小于配置的最小堆内存大小,如果堆最大和最小内存大小设置一样,则不会释放内存还给操作系统

重要特性:ZGC优化,释放内存还给操作系统、socket底层实现引入NIO。

JDK14新特性(2020年3月)

  • instanceof模式匹配,instanceof类型匹配语法简化,可以直接给对象赋值,如if(obj instanceof String str),如果obj是字符串类型则直接赋值给了str变量
  • 引入Record类型,类似于Lombok 的@Data注解,可以向Lombok一样自动生成构造器、equals、getter等方法;
  • Switch 表达式-标准化
  • 改进 NullPointerExceptions提示信息,打印具体哪个方法抛的空指针异常,避免同一行代码多个函数调用时无法判断具体是哪个函数抛异常的困扰,方便异常排查;
  • 删除 CMS 垃圾回收器

JDK15新特性(2020年9月)

  • EdDSA 数字签名算法
  • Sealed Classes(封闭类,预览),通过sealed关键字修饰抽象类限定只允许指定的子类才可以实现或继承抽象类,避免抽象类被滥用
  • Hidden Classes(隐藏类)
  • 移除 Nashorn JavaScript引擎
  • 改进java.net.DatagramSocket 和 java.net.MulticastSocket底层实现

JDK16新特性(2021年3月)

  • 允许在 JDK C ++源代码中使用 C ++ 14功能
  • ZGC性能优化,去掉ZGC线程堆栈处理从安全点到并发阶段
  • 增加 Unix 域套接字通道
  • 弹性元空间能力
  • 提供用于打包独立 Java 应用程序的 jpackage 工具

JDK16相当于是将JDK14、JDK15的一些特性进行了正式引入,如instanceof模式匹配(Pattern matching)、record的引入等最终到JDK16变成了final版本。

JDK17新特性(2021年9月)(LTS版本)

  • Free Java License
  • JDK 17 将取代 JDK 11 成为下一个长期支持版本
  • Spring 6 和 Spring Boot 3需要JDK17
  • 移除实验性的 AOT 和 JIT 编译器
  • 恢复始终执行严格模式 (Always-Strict) 的浮点定义
  • 正式引入密封类sealed class,限制抽象类的实现
  • 统一日志异步刷新,先将日志写入缓存,然后再异步刷新

虽然JDK17也是一个LTS版本,但是并没有像JDK8和JDK11一样引入比较突出的特性,主要是对前几个版本的整合和完善。

重要特性详解总结

1. Java 模块化

JPMS(Java Platform Module System)是Java 9发行版的核心亮点。它也被称为Jigshaw项目[1]。模块是新的结构,就像我们已经有包一样。使用新的模块化编程开发的应用程序可以看作是交互模块的集合,这些模块之间具有明确定义的边界和依赖关系。

JPMS包括为编写模块化应用程序提供支持,以及将JDK源代码模块化。JDK 9 附带了大约 92 个模块(在 GA 版本中可以进行更改)。Java 9 Module System有一个"java.base"模块。它被称为基本模块。它是一个独立的模块,不依赖于任何其他模块。默认情况下,所有其他模块都依赖于"java.base"。

在java模块化编程中:

  • 一个模块通常只是一个 jar 文件,在根目录下有一个文件module-info.class。

  • 要使用模块,请将 jar 文件包含到modulepath而不是classpath. 添加到类路径的模块化 jar 文件是普通的 jar 文件,module-info.class文件将被忽略。

典型的module-info.java类如下所示:

module helloworld {     
    exports com.alibaba.eight; 
} 
module test {     
    requires helloworld; 
}

EdDSA 算法

EdDSA (Edwards-Curve Digital Signature Algorithm) 是在 Java 15 中通过JEP 339添加的另一种附加数字签名方案。与其他可用的签名方案相比,它提供了更好的性能和安全的签名。

总结和展望

总结

1.Spring带头猛冲,直接上JDK17。 如果Spring6还支持Java8的话,那很多技术框架都要跟着Java8的兼容,与其这样不如由Spring带头,一起飞升Java17,不过有些框架还不支持JDK17。

2.性能升级,光从java8换到java11,啥也没干性能直接就提升了10%(nio底层的重写),更何况一路到jdk17过程中的JVM相关优化。不过光是性能的优化还不足以吸引企业进行JDK升级,毕竟加机器就能解决,费不着各种升级改造,还可能有安全问题。

3.JDK21可能成为真正的经典版本。 目前还没有Project loom功能,代表着没有协程,性能方面比有协程jdk差远了。比如阿里开源的jdk8,11,就有非侵入式协程。

从发展趋势看,Project loom功能在JDK19已经可预览了,可以发现该版本许多的java工具都开始针对loom进行升级,Project loom大概在JDK21进行正式推出,而JDK21又是一个长期支持版本 (LTS) ,值得期待。

各种servlet容器,还有jetty,netty,vert.x等,在它们最新版本的release note找到对应的升级标注,说,我们添加了某某支持,其中最重要的就是loom,或者叫做虚拟线程的支持, 可以预见一旦JDK21发行,很多软件都会跟上投入生产!

Project loom参考:https://open.atatech.org/articles/249741

展望

JDK的升级是必然趋势。

不升级的人说,目前来说国内很多程序猿可能觉得升级会造成额外工作,出了问题费力不讨好,要是出了安全问题,更是头疼。也有说没有实质性的好处,而且还有风险,还有从企业角度说,未来也不升级,因为去Oracle化。但考虑到未来oracle不再维护JDK8,Spring也不再维护过去版本的时候,为了跟上时代,使用最新技术,必然会助推JDK的升级。

当越来越多的公司加入到JDK17以上的大军中,未来更多的框架新版本都会最低支持JDK17,因为兼容旧JDK实在不值得,当大部分框架和社区、论坛都是讨论JDK17的技术和各种解决问题的方法时,必然会反推企业进行升级。

参考链接:

[1]https://zhuanlan.zhihu.com/p/480293185

[2]https://blog.oxings.com/article/31.html

[3]https://blog.csdn.net/best_luxi/article/details/122543074

 

Logo

开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!

更多推荐