在发送给 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 使用情况调查现已开放，欢迎参与。
评论