即将在2022年第四季度发布的Spring6框架,要求Java最低版本为JDK17,如何看待这一改变?

2022年1月5日 633点热度 0条评论

之前版本最低版本要求仅仅是 8

而 spring 6 将会重构内部架构,以适应 graal 的 aot 的要求,同时把最低java版本要求改为17

另外 spring boot 3 也将要求最低 java 版本为 17

同时Spring小组也承诺会持续维护Spring5和Springboot 2.x 

怎么看从8到17这一巨大飞跃?

v2-35f38d06a3b0bd02c64b3e3e277e5e85_xs

想明白Java8为什么升不上去后,就会明白,Spring框架将来也会面对几乎同样的问题。

为什么Java8占比这么多

Java8提供了很多特性,比如Lambda 表达式、Optional 类,加上Java8超长的支持时间,都导致Java8。

令很多人意外的是,Java11支持的时间到2026年9月,Java8的支持时间到2030年12月,从这个层面上来说Java8比Java11都要“长寿”。

Java 8之后的版本,现在看来吸引力不是很大,模块化有break changes,异步接口有netty,AOT/GraalVM在后端也是不必要的。唯一比较期待的Project loom还遥遥无期,只能拿wisp2凑合用。

Java 8之后的分发策略,支持方式的变更,也会让开发者在升级前要仔细考虑。比如Java11你用哪个发行版?Oracle会有潜在法律问题;AdoptOpenJDK的支持能不能跟上等等。

Spring为什么要凑这个热闹呢?

开源主要做的是宏大而优雅的事情,所以Spring的开发者会觉得,我都用Java 17的新API写代码,简化逻辑,使用新特性,很棒;但是为了支持Java8,需要写很多workaround,那就很不爽,很不优雅。

但是站在工程的角度,作为Spring框架的使用者,自然是希望Spring框架能够支持更多的Java版本。最好不用改代码,最好不用升级Java版本,最好啥都不用改就能用。

本质上来说,这个反映了框架维护者和框架使用者的矛盾。

技术栈升级成本

关于技术栈升级,有一个规律:越贴近底层,越会有标准化的抽象接口,独立升级会越容易。

比如linux kernel升级,只需要升级下,验证下没有问题就可以了(最多改一些应用配置)。

但是 Java 版本升级,就需要仔细检查各个depdency的依赖,然后还要做大量的业务测试才能升级。

如果是Spring升级,就会更加麻烦,需要改代码,需要测试验证;甚至会发现旧的使用方式不能用,需要修改核心逻辑等。

在这种情况下,Spring要新推出一个大版本,必然需要一些杀手特性才可以让使用者升级。

要不然就只能万年Spring 5.x了,Spring社区自然也不希望这种事情发生。

总结和展望

Spring 6出来后,会有新公司、新项目使用,但是对于旧的项目,会依然在旧的版本上继续运行。

到时候大家又会开始抱怨为什么还有这么多旧项目仍然坚持使用Spring 5.x,甚至你在StackOverflow上搜索问题的时候,发现找到的答案是Spring 6.x版本的,而自己的项目却用的是Spring 5.x。

v2-ea3ac0222577a3d515b61c499014a42d_xs

那句话怎么说来着?

留给java 8用户的时间不多了

spring社区可谓是java社群里面最顽冥不灵的一群人

如果没有外力推动的话,估计可以坚持java 8几十年不动摇

那现在好了,spring自己站出来说,我要升级,而且升级的跨度很大,直接从8跳到17,跳过11

这样其实也为第三方依赖拉出了巨大的升级空间

如果spring只是升级到11的话,那么像record这种特性,还得等

但是一下跳到17之后,第三方依赖库大可以用上record之类的特性

harry

这个人很懒,什么都没留下

文章评论