Java社区计划量化Java 9使用情况

在发送给Java冠军列表的邮件中，伦敦Java社区负责人Martijn Verburg宣布：

我们想要弄清楚哪些流行的库在与Java 9+相关的工作上落后了，又有哪些以最小化（自动模块）或完全的方式使用了模块系统。

LJC宣布了一个众筹项目，旨在“资助Java OSS，最小化Java 8/9+分裂”，新的社区工作将帮助确定LJC所开展的这项活动的众筹目标。

这项工作获得了Java冠军的支持，包括Sander Mak、Ray Tsung、Robert Schulte和Rabea Gransberger，他们还开展了一项调查，邀请尽可能多的Java开发人员参与进来，从而对实际的实践活动有一个更好的理解。

为了了解有关这项活动的更多信息，InfoQ采访了Martijn Verburg。

InfoQ：你们为什么推出了这项新活动？你们在社区里看到了你们认为供应商无法解决的具体问题吗？

Verburg：我们之所以推出这项活动，是因为Java 9带来的变化需要一些库和框架对代码做大幅的修改，而且，Java新的发布节奏也需要一些库和框架为了保持兼容性而做修改。

Oracle清晰传达Java 9的变化和新的发布节奏已经有段时间了，他们已经协助完成了许多升级流行库和框架的工作。

不过，我们相信，仍然有许多的库和框架没有正确地开展与Java 9相关的工作，或者，他们由于维护者/志愿者少或者缺少商业支持而无法跟上新的发布节奏。

因此，我们希望找出那些项目，帮助他们实现兼容，以便应用程序迁移时可以依赖于这些流行的库和框架。

InfoQ：您是否已经发现什么重要的Java技术在向模块迁移上可能存在问题？

Verburg：这个问题其实可以分为三个部分：

1.这项重要的技术是在Java 9/10上运行吗？

有许多总要的技术是这样的。例如，IntelliJ是，Apache Maven是（需要修改POM），JUnit 5是，Spring 5也支持，诸如此类。不过，也有一些值得注意的疏漏。

Java EE / Jakarta EE就没有提供开箱即用的支持，有多个Apache通用库也是还在添加这种支持，等等。

我们会扫描Maven中央仓库，通过一连串的测试查看它们的兼容程度（尤其是流行项目）。我们推测，结果会不错，而且兼容性会稳步提高。

2.这项重要的技术是使用Automatic-Module-Name在模块路径上运行吗？

等我们完成对Maven中央仓库的数据挖掘后，我们可以给出更好的答案，但是，据我们推测，这个数值虽然不大但会不断增加。

3.这项重要的技术是使用module-info.java完全采纳了模块系统吗？

我还得说，等我们完成对Maven中央仓库的数据挖掘后，我们可以给出更好的答案，但是，据我们推测，这个数值不大，而且增长缓慢。Oracle以及我们中的大多数都参与了这项工作，恰当的模块化很难！

InfoQ：自动模块呢？您觉得那是库的一种长期可行的解决方案吗？或者更多地，我们只能把它们视为权宜之计？

Verburg：它们本来就是权宜之计，但是，我担心，由于程序员默认是“懒惰的”，大多数库和框架的维护者会仅仅添加自动模块，而不考虑使用模块系统模块化它们的应用程序（利用模块系统带来的好处）。

我个人认为，我们需要更多的最佳实践和工具支持，帮助开发人员在日常的工作中针对高难度的模块设计做决策及重构。如果我们都依赖的流行的依赖项完全模块化，那么我们很可能就会看到应用程序跟进，否则就不可能。

显然，模块系统对于JDK本身及供应商都是一个重大利好，他们可以由此派生出更小的客制化打包特性。不过，在应用开发人员的日常工作中，它可能不会获得很大的心理份额或者很多的使用，时间会证明一切。

InfoQ：您是否觉得Java社区也面临着“Python 2/3的问题”？

Verburg：我认为，Java会遇到一点Python 2/3的挑战，有两个原因：

1) 使所有通用/流行依赖项都兼容Java 9+的工作。这显然是一个可以解决的问题，我们会加速前面提到的众筹工作。

2)市场对Oracle JDK LTS支持计划的反应未知。在此提醒一下， 即使是LTS版本，公共更新也会在6个月之后停止。之后，如果你希望技术停留在Oracle的那个LTS版本上，并获得安全和稳定性修复补丁，就需要付费来获得Oracle提供的（Oracle JDK）技术支持，否则就得在6个月的窗口期之后迁移到Java 12，诸如此类。

Java 9使用情况调查现已开放，欢迎参与。

查看英文原文：Java Community Aims to Quantify Java 9 Adoption