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
评论