啊哈哈哈哈，这题我会！2018年我有一大部分工作都在和Java 9 作斗争！Java 9是2017年9月发布的，而我们一直到2018年9月——花了整整一年的时间——才切换到Java 9，又花了三个月的时间切换到Java 11。
反观JetBrains，似乎花了两年多才把runtime升级到11（假设他们是从Java 9一发布就升了），我们和JB的代码规模差不多，都是百万级别的，现在你应该对升级这事的周期有一个基本的认识了吧？
总结一下，就是Java 9各种奇怪的改变+业界长久积累的库中的瞎JB用法导致了大部分项目被迫停在Java 8上。我强烈建议把题目改成「为什么还有那么多人被迫使用Java 8」，因为，这真的是客观原因啊。
我举几个栗子让你们看看迁Java 9/11这件事情有多蛋疼，算是给想迁移的你们提前打个预防针。
Java 9之前，Java的版本号用的是这个标准，也就是我们常见的1.8.0_213这种字符串。 Java 9之后，大家一拍大腿，反正已经做了这么多改变，不差这一个！来人啊！给我把这个版本号字符串换掉！于是有了JEP223，一个山寨版的语义化版本号，从此以后，版本号大概长这个样子：9.0.0.4。平心而论，这个变更是非常必要的，但是一众依赖以前的版本号字符串的库就都哭了……谁能想到你丫的连这种东西都变啊。
（据说当年还有人提议以后Java的版本号跟业界保持一致，用18.1/19.1之类的年份+次序命名 ，后来就没声音了，应该是被打死了。）
那些广为人知的大库还好说，改的还算及时，一些小作坊生产的三无库就惨了，一调用就给你丢个Illegal version number 9.0.0.4出来， 还找不到人修，来来来你说咋办？
Java 8之前对反射没有限制，只要setAccessible(true)，你连JVM的底裤都可以掀掉。我们都知道，一旦给用户自由，用户就会瞎JB用。大家都知道JVM初始化的时候传进来的环境变量是不可变的，存在ProcessEnvironment的一个不可变Map里。但是没关系，我有反射啊……
其他的栗子还包括，通过反射调用各种私有的API……在你升级之前，你永远不知道有多少地方在用这种鬼鬼祟祟的操作……升级就好像你面前的一条康庄大道，你开开心心地踏上去准备走，咚！一个地雷炸了！piaji！你掉坑里了！二十米的路你走了三个月！黑着脸从坑里爬出来，瞅瞅前面……这特么还有多少个地雷在等着我啊……在爆炸之前你永远不知道到底有多少库在用反射偷偷摸摸调私有API，我管它叫薛定谔的反射。
这都是业界的库里的骚操作（其实我们的代码里也有……捂脸），Java 9对反射添加了限制。JDK团队最初计划在Java 9中全面限制反射，但最后因为影响太大没能实行……
还有最常用的一个操作叫做defineClass，用来把魔改后的字节码注入ClassLoader。ClassLoader的这个方法是protected的，没关系，我们有反射啊……另外一些小伙伴直接用反射调用Unsafe.defineClass——看名字你就知道有多不安全，Java 11之后这个方法直接被干掉了。
能用到这些方法的库通常都是大厂生产的有售后的库，所以通常都能得到很好的解决。但是紧接着问题就来了——你把一个库从2011年的版本直接升到了2018年的版本，你心里慌不慌？
更别提有些小作坊的库偷偷摸摸地从裤裆里掏出来一个Unsafe.defineClass跟你哭丧着脸说，哥，这个方法我找不到了，咋办……
在升Java 9成功之后，怀抱着升级成功的窃喜，我们又趁热打铁想升Java 10。然后碰到了IDEA的一个bug：IDEA错误地理解了一个还未生效的草案JEP182，编译器给出了不正确的结果，我花了一上午时间调试IDEA的源代码才发现是IDEA的锅。IDEA尚且如此，其他项目碰到兼容性问题，真的只是时间问题。
业界的很多工具不支持Java 9，最广为人知的应该是FindBugs了。还好，它还算后继有人，SpotBugs挑起了它的大梁，那些小作坊库可就惨了，过去的十年是Java生态系统迅猛发展的十年，你的项目只要沾到一点“在自己的代码里瞎JB使用Java 8/断言自己使用的是Java 8”的库，可能就要花上几天时间去调试、去尝试解决。
最后，最重要的一点是，我们的代码是有严格的自动化测试覆盖的，所以我们在升级之后能非常有底气地说我们升级成功了！对于没有测试覆盖的祖传代码，你升级完事，跑一下，似乎没问题，但是真的没问题么？去问老天爷吧……没有完善的测试覆盖的项目请勿轻易尝试。
其实升级不是什么非常困难的事情，主要是费时费力，收益可能却没有那么明显。对于一个成熟的公司来说，代码只是辅助业务的手段，而非目的。如果没有十分的利益保证，别说升级，连bug都是可以不修的。就酱。
我也是最近才把prestodb从java8升级到11，前后拖了很久，但总共也就花了三五天的开发时间，不难，六七个很简单的commit就搞定了。在语言层面的确有一些behavior改变了，比如说下面这两个，如果项目够大，多少会碰到几处。
说整体性能大幅提升是不客观的。我本来也没有期望有很大的提升。但可喜的是，我还是观察到了p99的改善，平均大概有10%～20%。可p50的改善就几乎观察不到了，或者可以说大多数的访问延时并没有明显改善。GC时间的确变得更平滑，spike少了很多，这可能是p99改善的主要原因。当然，还有进一步优化的空间，jvm组的大哥也给了很多建议，但我懒得弄了，提升都不明显。
其实latency并不是我的主要优化方向，我用这个指标只是它比较好观察和比较。我这里还是使用G1GC而不是zgc，因为我对latency的要求并不强烈, 我刚看中的其实是吞吐量。
（我还有两个cluster一个开着zgc，一个开着graal，如果有时间我可以分享一些我在这些上面的观察，或者我会在今年的prestocon上分享。）
所谓剪裁的特性对我更是没啥吸引力，用不上。你要真那么在意runtime分发包的大小，用golang不好吗。。。
总体来说，我觉得升级的益处并不大，属于可升可不升，如果继续用java8其实并没有什么问题，要不要升级就看个人爱好吧。如果有力气，还是应该放在application的优化上。
说实话，这种频繁的发布有点儿让人审美疲劳，每次我看到介绍Java新版本，新特性的文章也没兴趣点开看了。
在这么多的版本中，只有Java 8, Java 11 和未来的Java 17 是长期支持版本（LTS），Oracle会支持3年，其他的只会支持6个月，新版本一出，就放弃老版本的技术支持。
有 ！ 小步快跑一直是我们软件开发的利器，采用迭代的方式，每次发布一部分功能，推向开发人员去验证，典型的敏捷思路。
但是这种好处更有利于JDK的开发者，对使用Java的个人和公司来说，想要跟上每六个月就要升级的步伐，实在是太难了。JDK是个非常核心的基础设施， 除了安全漏洞，谁没事去升级生产环境的JDK啊？出了问题谁负责？
所以，按道理讲大家都会去找那些LTS的版本来升级，例如Java 11， 但是事实证明大部分人还在固守Java 8 :
这个调查显示，使用Java 8的公司和程序员高达80%， 这是为什么呢？大家为什么不升级到Java 11呢？
在过去的十几年中，Java相继引入的泛型、注解、NIO、函数式编程等核心功能，极大地影响了应用程序开发的方式，你能想象现在的Java中没有注解会是什么样子吗？
注意黑体的这几项， Java 9引入了模块化系统，这是个看起来很美的特性，可是对程序员来说，这是一个破坏性的更新，因为JDK做了模块化，但是很多第三方库没有做模块化， 如果想让自己的项目也模块化，很有可能是一次不断填坑的经历，尤其在使用第三方库的时候。
Java 11的ZGC是个有吸引力的特性，它的设计目标是：支持TB级内存容量，GC暂停时间低（10ms），对整个程序吞吐量的影响小于15%，确实挺让人激动的！如果真的实现了，程序员就可以可劲儿造对象，而不用考虑GC了，可惜这仍然是个实验性质的版本。
一个JDK的版本如果想被广泛采用，一定得能提升开发效率（如泛型、注解），带来变革，这样才有吸引力， 如果给程序员们带来了麻烦， 大家就会用脚投票了。
版权声明：本文为CSDN博主「码农翻身」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
在 JDK 版本的世界里，从来都是 Oracle 发他的新版本，我们继续用我们的老版本。4 年之前用 JDK 7，后来终于升级到了 JDK 8。自从升级了没多久，JDK 就开始了半年发一个新版本的节奏，陆续发布了 9 、10、11、12、13，别着急，还有 14，直到前几天(2020年5月28日) 日，连 JDK 15 的抢先试验版都出来了，不禁要说，Java 你线月，由 Snyk 和 The Java Magazine 联合推出发布的2020 JVM 生态调查报告显示有 34% 的用户使用 Oracle JDK，57% 的用户使用 OpenJDK。其中 Java 8 的使用者依然维持在 64% 过半数的水平。
这都两年过去了，可见 Oracle 的收费政策吓走了不少开发者，转而投向 OpenJDK 的怀抱。而 Java 8 的使用者减少了 15 % ，也不算很多，这 15% 应该是开始使用 JDK 9 或 JDK 11 去了。但 Java 8 依然过半啊，所以说，现在用 Java 8 也不用慌，毕竟大多数人和我一样也都还在用 Java 8，真香。
不瞒各位说，用 Java 8 已经算是非常优秀，非常有上进心的了，有的公司还在使用 7，更有甚者还在用 6，你说是不是很 6。不是道听途说，我认识的人里面就有用 JDK 1.6 的，感觉不是在同一个世界。
之所以会出现这种状况，是因为升级版本耗时费力，最重要的是有可能影响服务的稳定性，虽然说 Java 是向后兼容的，但是谁知道是不是有坑在里面。在没有重大安全漏洞或重大性能提升的情况下，大多数公司还是以稳定性为主，既然 Java 8 已经能满足业务需求了，那就用它好了。
现在又增加了原因，就是从去年 1 月份开始对 Oracle JDK 的商业用途收费了，用着 Oracle JDK 的厂子更有理由不升级了，为了节约成本啊，对不对。
从去年1月份开始，Oracle JDK 开始对 Java SE 8 之后的版本开始进行商用收费，确切的说是 8u201/202 之后的版本。如果你用 Java 开发的功能如果是用作商业用途的，如果还不想花钱购买的话，能免费使用的最新版本是 8u201/202。当然如果是个人客户端或者个人开发者可以免费试用 Oracle JDK 所有的版本。
在 JDK 9 发布之前，Oracle 的发版策略是以特性驱动的，只有重大的特性改变才会发布大版本，比如 JDK 7 到 JDK 8，中间会发多个更新版本。而从 JDK 9 开始变为以时间驱动的方式。发布周期为6个月一个大版本，比如 JDK 9 到 JDK 10，3个月一次补丁版，3年一个 LTS(长期支持版本)。
发版时间稳定了，使用者就可以相应的根据发版节奏调整所使用的 Java 版本了。但是付费使用好像又增加了成本，一直免费使用的东西，突然收费了，好像有点接受不了，尤其对于小公司而言。
上面所说的都是 Oracle JDK 。那么如果既想要更新版本又不想花钱怎么办呢，当然也是有办法的。可以选择 Open JDK。
有些现象就更有意思了，虽说很多公司都已经在用 JDK 8了，但是呢，很多同学还是把它当做 JDK 1.7 来用，为什么这么说呢，JDK 8 的新特性，对不起，一个不用。
− 方法引用提供了非常有用的语法，可以直接引用已有Java类或对象（实例）的方法或构造器。与lambda联合使用，方法引用可以使语言的构造更紧凑简洁，减少冗余代码。
−新添加的Stream API（java.util.stream） 把真正的函数式编程风格引入到Java中。
就说 Stream API 吧，这么好用的 API，对集合的过滤、筛选、类型转换简直是友好方便到不行，结果呢，还是很多同学压根儿就没用过。
另外，日期的处理，比如 LocalDate、LocalTime 等，也都比之前的 API 好用很多，可是呢，还是很多同学不用，宁愿用着之前已经用 @Deprecated 注解为过期的方法。
只要你使用的库里有一个不支持java11，你就没法升级啊。或者有替代的库，但你得改代码啊，一堆祖传代码没人想碰，或者说根本不敢碰，就算能编译过，也能启动，你敢保证行为没变化吗？这怎么搞
你看redhat和amazon都维护自己的openjdk8 build了，就知道大厂怎么看这事了。还有一大堆人停留在6甚至4呢，你问为啥有人还在用8？
在Java 8之前，用户接受更高版本的Java的过程非常缓慢，特别是在企业中，因为在生产环境中接受新版本Java非常困难。而引入了Lambda表达式和流的Java 8对许多开发人员来说都非常有吸引力。同时，微服务、持续发布实践和更好的自动化测试也让接受新版本语言变得更容易，风险比以前更小。
那么，鉴于这些因素，为什么从Java 9开始每年两次发布新版本的情况下，开发人员还在坚持使用Java 8呢？目前Java最新的版本是Java 12，然而很少有人使用9～12的版本。
估计你能猜到这其中的原因：“很复杂”。Java 8之后的版本发生了很多变化，这可能会导致各个公司在Java升级上举棋不定。
在新的发布节奏下，不会再出现每几年发布一大堆功能的情况（伴随着风险极高的大型升级），而是在预定的日期内推出更小的发布。当然，这些发布包含的功能会少很多，但这种方式有几个好处：
更频繁的发布意味着如果某次发布中某个功能没有做好，就会被推迟到下一次发布。因此，语言开发者的压力更小，不需要赶工完成功能，因此每次发布的质量更高。
以前是每三年一次巨大的更新，而现在可以持续地获得更新，包括语言特性、垃圾收集器的变化和性能改善。
如此快的发布节奏也可能造成的负面影响，例如许多组织根本跟不上六个月一次的升级节奏。这一点也在考虑中，因为Oracle也会受到这个影响。
这意味着每六个月就要使用最新版本。这样做的好处是能够立即获得新的语言特性，但这种方式通常只适合那些习惯于迅速升级技术栈的人们。
对于Java开发人员来说这种节奏更为熟悉。这种升级有三年一次大型升级的缺点，但人们有更多时间来评价这种升级带来的风险。
也许还有一个折中的办法：在生产环境中使用LTS版本，同时在CI中确保应用程序能在每六个月一次的新版本上运行。这样既能将大型升级的风险降到最低，同时还能维护生产环境要求的稳定性。
但是，Oracle也认识到并不是每个人都愿意付费，而且许多人更喜欢用开源的方式工作，所以他们现在有两个版本的JDK，其特性完全一样，但授权不同。商业版JDK可以在开发和测试中免费使用，但在生产环境中使用则需要付费；还有一个完全免费的OpenJDK版本。后者采用了开源的GPLv2+CPE授权，但其生命周期只有六个月。
从竞争的观点来看，这其实是好事。Oracle始终会将JDK中的功能移植到OpenJDK中，甚至还包括那些曾经用于商业版的功能，如Java Flight Recorder和Java Mission Control等。所以，由OpenJDK产生的一切JDK（也是绝大部分人都在使用的JDK）会包含你曾经用过的一切特性，甚至还会包括一些你没用过的特性。
虽然这些变化让人头晕目眩，但其目的是为了给世界上最流行的语言提供高质量、频繁且在计划内的更新，同时让负责该语言的人能够持续做下去。
因为 Java 9 进行了相当有破坏性的更改，虽然大部分问题可以轻松解决，但是生态没有完全跟上。目前完全进行模块化的库实际并不多，大部分库只是提供一个
便于在 module-info 中引用，本质还是 automatic module（jlink 不接受 automatic module，不过 Gradle 的Badass Jlink Plugin可以自动解决这个问题），可能掩藏看很多模块化相关的问题。
不建议升级不是让你完全无视新版本，如果一直忽视新版本的更新，最终一个个问题总会积累成厚厚的技术债。
Automatic-Module-Name。在未来（2024 年左右）OpenJDK 8 的支持结束之后，安全问题只会越积累越多，Java 升级带来的性能提升也会越积累越大，新功能会越来越多支持 Java 8 的库和框架越来越少，对更新的需求也会越来越大，Java 8 也会越来越接近真正被淘汰。做好随时有可能更新的准备，才不会为自己或者接手的人埋更多的坑。
很多人想的是：Java 11的新特性我都不了解，更不会用，为啥要升级？等我学习了之后再升级就行啦。其实，新开产品线升级到新版JDK，你可以继续用以前的语法写。Lambada、Stream不了解，你可以继续用老写法，没问题的。这样做有两个优势：
升级JDK，相当于留了一条路，为以后全面使用新特性做好了基础准备。继续“执着”于老版本，等于堵死了将来升级的可能性。
升级了JDK，但是你继续用老写法。但是JVM、跟着同时升级的其他开源框架和库，在性能上都有提升。相当于你不用怎么努力，但是却用上Java生态其他人的共同努力成果。
真的会有人因为省几十兆或者几百兆磁盘空间而升级吗? 随便搜了下，硬盘好像差不多一块钱人民币1G吧。码农的工资比这个高的多了吧??
我现在这个项目，也不算大，50万行代码，大概总共3,400个左右的dependency吧。当年从6升到8差不多两三个人全职干了半年左右。虽然已经测试的算充分了，真的上线以后还是出过一些幺蛾子，过了几个月才算完全稳定。
尽管 Java 被称为编程语言界的“老马”，但它仍然能够一直流行，并且还在不断发展。那么，2019 年 Java 的发展如何呢？Baeldung 调查了 6707 名开发经验丰富的技术人员，并从中获得了一些结论，以下为重点内容。
从 Java 8 之后，Java 的发布周期明显快了很多，现在已经快要到 Java 14 了。而根据调查显示，80% 的受访者仍然在使用 Java 8，并未更新。为什么即使有了新版本，Java 8 仍然最受欢迎呢？这其中有很多原因：
第四，在 2019 年 1 月份之后，Java SE 8 的公共更新需要商业许可，这也是 Oracle JDK 与 OpenJDK 之争的开始。此外，在不同的供应商那里是否可以得到免费更新的相关计划，以及 (新的和现有的) 付费的支持模型，这些都是人们考虑是否更新的因素。
在框架的采用方面，Spring 占据了主导地位。与传统且臃肿的 Java EE 相比，Spring 是现代化的、基于 Java 的企业应用程序的轻量级框架。Spring Boot 的采用率也很高。
在 IDE 的调查中，IntelliJ 以将近 60% 的份额占据了第一的位置。为什么 IntelliJ 如此受欢迎呢？Jetbrains 市场总监安德烈·切普索夫（Andrey Cheptsov）曾在一篇博客中这样写道：“在你编写代码时，IntelliJ IDEA 也忙着在构建它的语法树，在类、变量、字段、方法和它们的用法之间创建引用，分析执行流，利用这些信息，它可以提供补全功能，帮助你快速浏览代码，提供错误分析和方便的快速修复。”而传统的 Eclipse 则有点不妙，其占比从去年的 38% 下降到 32.8%。
MySQL 和 PostgreSQL 是前两名，Oracle 排名第三，第四、第五名分别是 MongoDB 和 MS SQL 。这里有两个值得注意的趋势，与 Percona 的数据库管理系统流行度调查结果一致，关系型数据库管理系统胜过 NoSQL，而开源数据库管理系统则比大型商业数据库管理系统做得更好。就像前文中的 Web 服务器一样，人们寻求的也是更轻量级的等价物，尤其是 PostgreSQL。
根据调查结果显示，Java 不会被取代，在未来几年也将继续保持 Top 3 的位置。不过，尽管人们仍然坚持使用 Java 以及围绕它的生态系统，但人们也在试图远离 Oracle 的产品，如 IDE(JDeveloper)、服务器 (WebLogic)、JDK 及其旗舰数据库。MySQL 是个特例，因为它基本上不受 Oracle 所有权的影响。大多数 Java 用户正在寻找更轻量级、更高效、更便宜、对开发人员和许可更友好的等价物。
