Mark Reinhold 在 jigsaw-dev 邮件列表上发言表示,Jigsaw 项目将在一个新的 Hg 仓库上另起炉灶,再次尝试解决让 JDK 实现模块化的难题。新仓库位于 http://hg.openjdk.java.net/jigsaw/jake 。
Jigsaw 项目迁延日久,向前可追溯到最初的 JSR 277 和和稍晚的 JSR 294 ,原本设定的目标是将 Java 的核心运行时库解耦,拆分为若干模块。如果成功实现的话,纯服务器端的 JVM 运行的时候将终于可以不必带着用不上的 AWT 支持。
对 JDK 进行模块化拆分,这件事情很不简单。例如按照现在的设计,java.beans
、java.applet
和java.awt
包之间依次存在依赖关系。即使我们真的能够在那么多年后推翻原来的设计决策,取消它们的依赖关系,也很难不顾此失彼。
Java 其实老早就有一个模块系统,起初叫做 JSR 8 ,也就是现在的 OSGi 和 JSR 291 。这个系统被所有的主流 Java EE 应用所采用,在其他领域的系统和应用中也运用得非常广泛(如 JIRA、Eclipse),还进入了某些特定的垂直市场(如嵌入式系统、家庭自动化)。在这样的背景下,Jigsaw 项目学习java.util.Date
、Java IO NIO NIO2 NIO2.2、java.logging
包等前辈的榜样,丢开最佳实践,存心凑合一套给 JDK 自己用的系统。(好在 Java 8 总算收拾了java.util.Date
这个怪胎,纳入了 Joda-Time,也就是新的 java.time 包来作为对java.util.Date
的修正的修正。)
每一回 JSR 277/Jigsaw 推倒重来,目标都要打一点折扣。最早的时候,它是一个适用于任何应用的通用模块系统,且具备解析链和仓库存储机制。(照 Java 的惯例,系统会设计成可插拔的,我们会见到 ModuleFactory 和 ModuleResolverFactory。)差不多 5 年前的 2008 年 12 月,JSR 277 好像走进了死胡同。于是项目的目标经过重新评估,一种可以聚合多个包,但只对外暴露单一个包或单一组 API 的“超级包”概念被提了出来,从而诞生了 JSR 294。
到了 JSR 294 也徘徊不前的时候,又诞生了 Jigsaw 项目,目标相应地变更为实现一个主要为 JVM 本身服务的模块系统(但同时为用于其他系统留有余地)。Jigsaw 放弃了一些理所当然的特性,如模块解析链,只定位在给 Java 提供基本的模块定义能力。Jigsaw 提出的方案犯了一个关键错误,它让模块通过执行代码的方式,而非声明式的方式来表达依赖关系,其结果造成我们不可能通过静态分析来确定一个模块系统成立与否。(不能静态检查约束条件是否满足的模块系统,有一个现成的例子,也就是我们熟悉的“classpath”,现在通常可以在小规模的应用和一些 IDE 中见到。)
大约 1 年前,Mark Reinhold 撰文“ Project Jigsaw: Late for the Train ”,宣布 Jigsaw 项目将错过 Java 8 的发布日程。这件事情的反响毁誉参半,OSGi 的支持者和反对者们各自宣告胜利或失败;Jigsaw 推迟到 Java 9 才定案,好歹让该项目有机会修正一些错误决策。
这一次另起炉灶,Mark Reinhold 希望拿出一个不那么雄心勃勃的系统原型,一方面保留现有的由解析代理来提供各种 JAR 的方式,另一方面新增一种静态描述元素间模块依赖关系的手段。眼下新仓库中的代码仅仅是从 JDK8 拷贝过来的一个分支,但按照打算,这次会抛弃那些一直以来拖后腿的包袱,在上一轮尝试中成为问题根源的一些设计决策,将得到重新审视。
我们的计划之一,是避免像当前原型那样引入专门的“模块模式”(此模式与一些由来已久的习惯做法向左,会导致某些不普遍、但有深刻影响的兼容问题),也不负责解析依赖关系(因为这件事情 Maven、Ivy、Gradle 等构建工具已经做得够好了),在这样的前提下验证可行的方案。 我们的新原型会从旧的原型中借鉴合理的代码,但最重要的还是借机重估原来的一些设计决策,并且做一次全面的清理。
尚待决断的重要设计决策有:
- 版本号是遵守一种现成的版本号格式系统,如 Semantic Versioning ,还是编到哪算哪
- 模块系统是(像 Ivy、Maven 和 Gradle 那样)声明式地表述依赖关系,还是必须通过执行代码来确定依赖关系(并因此阻碍静态分析和事先核验)
- 模块系统是(像 OSGi 那样)动态的,还是(像 Maven 那样)静态的;换言之,模块可以随增随减,还是只进不出
- 赖关系的元数据是放在 JVM 能理解的.class 文件里,还是用 JSON、YAML、Manifest.MF 之类的文本格式来保存
以 Oracle 对外来方案的排斥,选择 OSGi 作为 Jigsaw 实现基础的可能性很低。另一方面,OSGi 作为一种完全动态的方案,用作 JVM 的模块化机制也显得过火。最好的折中方案可能是一种近似于 OSGi,具有版本化的依赖项管理和 bundle 机制,但去除动态特征(及因此导致的多重 classloader)的系统。用 Java 来实现类似系统的可能性,已经在 pojosr 项目中得到证明,我们也许会见到一个皆大欢喜的结果。
InfoQ 将持续密切注意 Jigsaw 项目重启的情况,并跟进报道其最新进展。
查看英文原文: Jigsaw, Second Cut
评论