jdk17有可能代替 jdk8吗？

你是被豹哥带节奏带久了吗？天天焦虑

从目前发展趋势看，java 21大规模流行的可能性是最大的

虽然11和17已经啃下了不少份额，已经有相当一部分常用的工具/类库，已经升级到11或者17

比如spring今年的目标就是要把最低版本要求bump到17

es前一段我看他们已经做好了模块化处理，那模块化虽然是9的东西，但是鉴于9并非lts，所以一般认为最低版本要求是11

然后netty 5已经开始抛出alpha版本了，最低要求也已经升级到了11

其他的，尤其是这些年诞生的工具，什么helidon，micronaut（这个是Graal组在维护）就不用说了

但是，真正值得注意的是，loom即将于这个月，也就是下个星期发的jdk 19版本开始preview

虽然只是preview，但是发现，一大堆乱七八糟的java工具，尤其是服务器类的工具

都开始针对loom做升级，没办法，这个诱惑实在太大，虚拟线程对于客户端而言，需求还不算特别旺盛，但是对于服务器端软件而言，这几乎可以说是个服务器端软件，他就会考虑的升级

所以什么tomcat，jetty，vert.x都刷刷开始针对该产品做升级

而这些工具，在之前的大部分版本中，都还在坚持继续兼容8

也就是说11和17并没有直接冲击到这些工具

但是21就不一定了，因为19开始preview之后，只要不出特殊的意外情况

一年之后，也就是两个版本之后，就会真正转入生产特性，下发生产，那19之后两个版本，就是21

而21又恰好是lts版，所以应该就是为21真正下生产做准备的

那一旦下生产，像tomcat什么都会通过后续升级，以支持该特性

这个东西对于最低版本的刺激，就不是11和17能比的了，因为从现在的情况看，几乎所有的java服务器端工具，都对此做出了反应，几乎所有人都在忙着升级，为最低版本支持为21做准备

不信你自己去看最新的java服务器端软件的release note，随便选，只要提供服务器端服务的

比如各种servlet容器，还有undertow，jetty，netty，vert.x这些， 现在 都在干这事，你都能在他们最新版本的release note找到对应的升级标注，说，我们添加了什么什么支持，其中最重要的就是loom，或者叫做虚拟线程的支持，当然当前大部分情况下，都还是exeprimental，incubator等状态

其实我感觉，这些工具要是不干这事，似乎也没啥可干的了，程序员其实越来越给人一种redundant的感觉，就是过剩，你不干有的是人干，谁让老外如何乐于分享，喜欢开源呢？

那随着loom在21的真正成熟，这些工具也会逐步把该特性转为生产特性

那到那个时候，就会出现一种情况，就是，这些工具，就将会只支持21以上版本的维护

低版本（尤其是8）的维护，没人做了

你说中国人在用，是啊，我知道中国人在用，但是你也知道，中国人写java，有几个只用中国人自己写的类库的？对吧，基本上都是老外的类库用maven引入一下，然后就开始搞了

那老外的这些工具慢慢都停止维护了，难道你指望那些老的支持8的代码，靠国内这些人去维护吗？

算了吧，这根本不现实好吧，那些老代码就算你愿意，也没有资方愿意投入资金让你去维护

所以最后可能出现的结果就是，因为老外不再维护支持8的依赖

从而导致，国内这些系统，不得不跟着升级，或者干脆就是各种bugs频发，然后国内的人又没有力气去维护那些老代码，最终导致项目彻底失败或者成功升级

最终就会走向这条路

实际上你可以在一些公司了解一下，很多公司都已经在做，或者已经做了很多年的准备了，逐步升级，这个过程当然不是一蹴而就的，但是这个过程已经在逐年推进中

像netflix，前一段就宣布他们的代码都升级到了17，实际上真正难的就是从8到11+，只要升级成功，后面的升级其实并没有多大的问题，因为该有的破坏性更新，11都有了，其实最主要的破坏性更新就是jpms，模块化带来的，当年那么激烈反对jpms的ibm和red hat，现在不也从了么？

模块化的好处是显而易见的，有了模块化，后续剪裁runtime，aot这些才有了可能性，否则做aot，我要把整个jre都给aot掉？那多大啊，多慢啊，是不是

然后最新的一些jdk的模块，比如http client，web server这些，其实就已经取代了一些传统上的类库的作用，比如18加入的jwebserver，这个模块，你有了这个，其实tomcat存在的意义就下降了一丢丢，当然目前这个还不支持动态网页，但是后续string template这个功能做出来了，你用这个做个动态网页，还不是轻轻松松的事，然后这些模块的好处是，一开始就好了模块化，并且graal支持他们做aot/native image，所以在一些场景下，这些工具就比传统的第三方工具更顶用

比如你在javafx里面，想整个http访问的功能，复用web的一些功能，那这时候，jdk自带的http client就比那些乱七八糟第三方的http 或者web client更好用，该有的它有，虽然功能没有那么丰富，但是它可以做模块化剪裁运行时，可以做aot，编译成native，小巧的一个模块，为什么不？

所以从目前发展趋势看，21最有可能成为一个大的经典版本，导致现存的8的系统开始大面积升级，而这个原因是因为，21出来之后，会导致大量老外维护的，还在支持8的开源项目把最低版本刷刷升级到21，那低版本的代码没有人维护，你不想浪费时间去维护这种代码的话，那要么你也跟着升，要么你就被抛弃，你自己选吧，我相信聪明人不会天真滴以为自己可以去维护这么庞大的一个代码库，别说那么多乱七八糟的依赖，就一个简单的tomcat，源码就要看多久，你自己去试试吧，而且做这种事也没啥意义，老外都不维护的东西，你学了干什么？年轻人也不爱看，北洋那个 http:// injdk.cn 上看到的数据，大部分人还是下11和18（最新）的jdk，8其实没有多少人下