Oracle Java Platform Group 的首席架构师 Mark Reinhold 向 JCP 执行委员会提交了一封公开信。在公开信中，他表示对 IBM 投了 JSR 376 反对票一事感到震惊，并争辩说，Red Hat 之所以也投反对票，是出于“保护他们自家的非标准模块化系统，而这个系统在 JBoss/Wildfly 之外的生态系统并没有多少用武之地”。他进一步辩解说：
在你们考虑如何投出你们手中宝贵的一票之前，我建议你们先对这一规范的价值做一个考量，并仔细考虑你们的投票将会对未来带来的深远影响。
因为专家组缺少统一的意见就投反对票，这无异于在反对 JCP 本身。JCP 的存在并不是为了强制达成统一意见，它需要正当充分的理由。它赋予规范制定者充分的决策权，防止专家组成员因为自己的个人兴趣而妨碍到整个进程。如果你们放弃了你们的权利，那么未来的 JSR 就变成了“专家团”的自我表演。
很多失败的技术都是这么来的。
我不希望 Java 的未来会是这个样子。
作为回应，来自 Red Hat 的 David Lloyd 提出了一些比较突出的问题，简单概括如下。
- 在运行时允许模块间存在环。
- 模块原始补丁（虽然很小）会被重新计算（在必要情况下进行分阶段）。
- 在模块路径间提供了包命名隔离。
Lloyd 补充说：
我们担心针对反射所做的变更对于社区来说太过剧烈，而且还有可能对执行委员会和专家组造成很大影响。我认为，在专家组达成一致意见之前，我们还是保持现状。
在模块路径命名方面，Reinhold 提交了一个更新提案 #AutomaticModuleNames，为了更好地与 Maven 兼容，如果 JAR 包里包含了 pom.properties，可以将 Maven 的 group identifier 包含进来，这样模块命名就不太可能发生冲突。
#AutomaticModuleNames 允许开发者将他们的代码拆分成多个模块，而无需等待他们所使用的类库或框架支持 Jigsaw。
这一提案的关键之处在于， JAR 包里的一个 manifest 属性 Automatic-Module-Name。当 JAR 被放进模块路径时，这个属性的值会被用作模块的名字。如果模块路径里的 JAR 包没有提供这个属性，那么模块的名字就需要通过基于文件名的算法来计算得出。Reinhold 建议说：
通过这种机制，类库的维护者就可以很方便地维护一个稳定的模块。例如，在 Maven 里，通过 “pom.xml”里的几行代码就可以添加 manifest 属性。类库维护者在一开始就声明一个稳定的模块名，不需要等待它的依赖库实现模块化，而依赖该类库的软件包和应用可以立即实现模块化。
Oracle 已经在 Java 模块系统提案上进行了大量的工作，从 JSR 277 开始，至今已经有 12 年的时间。最初计划在 Java 7 里发布，后来延期到 Java 8，现在是 Java 9。这一提案从一开始就饱受争议。不过，到目前为止，社区方面已经对 Jigsaw 方案达成广泛的共识，Jigsaw 为分解 JDK 提供了必要的方案。问题在于，如果在 Java 9 里加入 Jigsaw，那么很多 Java 工具就无法工作。
查看英文原文： Reinhold Publishes Open Letter to JCP Pleading That JPMS (Jigsaw) Is Approved
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论