@lsmn
2018-06-25T13:45:16.000000Z
字数 1955
阅读 1647
语言 Java 模块化
由伦敦Java社区领导的Java社区和几名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使用情况调查现已开放，欢迎参与。