之前版本最低版本要求仅仅是 8
而 spring 6 将会重构内部架构,以适应 graal 的 aot 的要求,同时把最低java版本要求改为17
另外 spring boot 3 也将要求最低 java 版本为 17
同时Spring小组也承诺会持续维护Spring5和Springboot 2.x
怎么看从8到17这一巨大飞跃?
想明白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。
那句话怎么说来着?
留给java 8用户的时间不多了
spring社区可谓是java社群里面最顽冥不灵的一群人
如果没有外力推动的话,估计可以坚持java 8几十年不动摇
那现在好了,spring自己站出来说,我要升级,而且升级的跨度很大,直接从8跳到17,跳过11
这样其实也为第三方依赖拉出了巨大的升级空间
如果spring只是升级到11的话,那么像record这种特性,还得等
但是一下跳到17之后,第三方依赖库大可以用上record之类的特性
文章评论