jdk17有可能代替jdk8吗？

 算一算Java8也是快10年前的老古董了，很多人经常把你发任你发，我用Java8挂嘴边，我觉得吧，迫于工作用Java 8没毛病，但你要是连自己写代码还用这低版本，只能说是故步自封。

    2021年9月14日，Oracle JDK17发布，目前也是最新的Java LTS版本。有意思的是，Oracle竟然"朝令夕改"，OracleJDK17竟然是免费的开源协议，并支撑长达8年的维护计划。目前公司内部使用的OracleJDK8最高版本为1.8.0.192，而Oracle在JDK8上开源协议支持的最高免费版本为jdk1.8.0_202。2022年Spring6和SpringBoot3相继推出，而支持的最低版本为JDK17。综上所述，JDK8为目前绝大多数以稳定性为主的系统第一选择，但是升级到高版本JDK也只是时间问题。

    JDK8到JDK17包含大量新特性，为Oracle在Java近5年来的智慧结晶。目前市面上的公司还是只有少数系统会选择JDK11或者JDK17作为线上技术选型，如果选择从JDK8升级到JDK17必然会有非常大的挑战和较多需要填的坑。

      下面这一段是 Spring Boot 3.0 的更新日志。

    

Spring Boot 3.0 requires Java 17 as a minimum version. If you are currently using Java 8 or Java 11, you'll need to upgrade your JDK before you can develop Spring Boot 3.0 applications.

Spring Boot 3.0 需要 JDK 的最低版本就是 JDK 17，如果你想用 Spring Boot 开发应用，你需要将正在使用的 Java 8 或 Java 11升级到 Java 17。选用 Java 17，

概括起来主要有下面几个主要原因：

1、JDK 17 是 LTS (长期支持版)，可以免费商用到 2029 年。而且将前面几个过渡版（JDK 9-JDK 16）去其糟粕，取其精华的版本；

2、JDK 17 性能提升不少，比如重写了底层 NIO，至少提升 10% 起步；

3、大多数第三方框架和库都已经支持，不会有什么大坑；

所以，请注意!!!!!

根据目前掌握的信息，Java最可能流行的是Java21或者Java25，不会是Java17，这个是过渡版本。

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

es前一段我看他们已经做好了模块化处理，那模块化虽然是9的东西，但是鉴于9并非lts，所以一般认为最低版本要求是11然后netty 5已经开始抛出alpha版本了，最低要求也已经升级到了11其他的，尤其是这些年诞生的工具，什么helidon，micronaut就不用说了,但是，真正值得注意的是,虚拟线程对于客户端而言，需求还不算特别旺盛，但是对于服务器端软件而言，这几乎可以说是个服务器端软件，这个诱惑就实在太大，他就会考虑的升级所以什么tomcat，jetty都刷刷开始针对该产品做升级而这些工具，在之前的大部分版本中，都还在坚持继续兼容8也就是说11和17并没有直接冲击到这些工具，但是21就不一定了，那一旦下生产，像tomcat什么都会通过后续升级，以支持该特性。

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

      如果不信，你自己去看最新的java服务器端软件的release note，随便选，只要提供服务器端服务的比如各种servlet容器，还有undertow，jetty，netty这些，现在都在干这事，你都能在他们最新版本的release note找到对应的升级标注，说，我们添加了什么什么支持，其中最重要的就是虚拟线程的支持，当然当前大部分情况下，都还是exeprimental，incubator等状态。

   随着JDK在21的真正成熟，这些工具也会逐步把该特性转为生产特性，那到那个时候，就会出现一种情况，就是，这些工具，就将会只支持21以上版本的维护，低版本（尤其是8）的维护，就很少或者几乎没有人做了。

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

    随着老外的这些工具慢慢都停止维护了，难道你指望那些老的支持8的代码，靠国内这些人去维护吗？这根本不现实，那些老代码就算你愿意，也没有资方愿意投入资金让你去维护，所以最后可能出现的结果就是，因为老外不再维护支持8的依赖从而导致国内这些系统，不得不跟着升级，或者干脆就是各种bug频发，然后国内的人又没有力气去维护那些老代码，最终导致项目彻底失败或者成功升级。

     升级到JAVA8以上版本，这或是大家最终就会走向这条路。

     实际上你可以在一些公司了解一下，很多公司都已经在做，或者已经做了很多年的准备了，逐步升级，这个过程当然不是一蹴而就的，但是这个过程已经在逐年推进中像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，源码就要看多久，你自己去试试吧，而且做这种事也没啥意义，老外都不维护的东西，你学了干什么。

以上为全部内容。