最近，我举办了一个“将应用程序迁移到JDK 9 ”的网络研讨会。 为此，我使用了我在较早的博客文章中研究过的一些材料以及从不同来源收集来的新材料。 我没有关注将应用程序从类路径移动到一组模块的细节，而是关注JDK 9中的更改，这些更改可能导致现有应用程序停止工作。 事实证明，即使不使用任何内部API（例如臭名昭著的sun.misc.Unsafe类），也可能会发生很多小变化，导致应用程序无法在JDK 9上启动。
在网络研讨会期间，我对观众进行了调查，以了解他们将应用程序迁移到JDK 9的过程。在网络研讨会的标题下，我认为这是一个很好的小组。 结果既有趣又有趣。 我进行了两次网络研讨会：一次是针对EMEA地区的开发人员，一次是针对美洲地区的开发人员。
我问的问题是“您迁移到JDK 9的计划是什么？” 结果在下面的图中以百分比形式显示。
EMEA受众的结果：
美洲听众的结果：
综合结果：
现在，我知道这里有“谎言，该死的谎言和统计数据”，确实样本量小于150，但是我认为这可以合理地表明JDK 9的采用。 作为另一个数据点，在本周末于基辅Java Days上的主题演讲中，我询问了使用JDK 9的800位开发人员。没有一个人举手。
我相信JDK 9在生产中很少采用的原因有很多：
- 从JDK 8或更早版本迁移应用程序时，不兼容更改的数量。 尽管从标准API中删除的六个方法不会影响很多人，但是诸如将阻止JVM启动的命令行选项之类的事情将成为一个障碍。
- 内部JDK API封装的效果。 同样，直接受此影响的开发人员的数量将不重要，而受到间接影响的开发人员的数量将受到影响。 我的意思是，大多数开发人员在开发应用程序时都使用第三方库和框架。 这些库和框架中有很多确实使用封装的API。 尽管已经进行了大量测试，并提供了特定的JDK 9版本，但仍有许多尚未这样做。 对于未积极维护的库，这无疑是一个问题，无疑会阻碍向JDK 9的转移。
- 长寿的支持。 最近宣布了新的六个月JDK发布节奏，这意味着通过公开更新获得支持的问题是开发人员在决定要部署哪个Java版本时需要牢记的。 JDK 8已被归类为所谓的长期支持（LTS）版本。 LTS发行版将进行三年的公共更新，尽管对于JDK 8而言，这将更像是四年半。 JDK 9不是LTS发行版，这意味着它将仅公开更新，直到2018年3月的下一个发行版为止。
我最近与之交谈的大多数开发人员都表示，他们将继续在生产环境中使用JDK 8，直到至少下一个LTS版本（将于2018年9月发布）为止。共识似乎是JDK 9和10（至少这就是本周所称的内容），将用于弄清楚如何在JDK 11到来时转移到它。
Oracle的既定计划将使LTS版本之间的过渡对开发人员而言非常具有挑战性。 问题在于公开更新不会重叠。 JDK 11发布时，它将包含可能会影响应用程序兼容性的新功能。 由于JDK 8将不再具有公共更新，因此用户将面临两种选择，要么支付商业支持合同的费用，要么跳到下一个LTS版本，并希望他们的应用程序不会中断或需要进行实质性的更改以使其正常工作。
该帖子最初发布在Azul Systems博客上 。