BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Jigsaw项目另起炉灶

| 作者 Alex Blewitt 关注 4 他的粉丝 ,译者 郭晓刚 关注 0 他的粉丝 发布于 2013年9月3日. 估计阅读时间: 6 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

Mark Reinhold在jigsaw-dev邮件列表上发言表示,Jigsaw项目将在一个新的Hg仓库上另起炉灶,再次尝试解决让JDK实现模块化的难题。新仓库位于http://hg.openjdk.java.net/jigsaw/jake

Jigsaw项目迁延日久,向前可追溯到最初的JSR 277和和稍晚的JSR 294,原本设定的目标是将Java的核心运行时库解耦,拆分为若干模块。如果成功实现的话,纯服务器端的JVM运行的时候将终于可以不必带着用不上的AWT支持。

对JDK进行模块化拆分,这件事情很不简单。例如按照现在的设计,java.beansjava.appletjava.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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

JAVA模块化经典开源开发平台JXADF by soft wmz

JAVA模块化,目前还是OSGi作为实事标准,Jigsaw前途未知。

OSGi的开源开发平台,比较经典的当属JXADF,osgia.com 有在线演示,相当不错。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT