之前版本最低版本要求仅仅是 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之类的特性
文章评论