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