70+专家分享实战经验,2024年度AI最佳实践都在AICon北京 了解详情
写点什么

Jigsaw 项目延后的群众反响

  • 2012-08-09
  • 本文字数:2111 字

    阅读完需:约 7 分钟

不管哪个领域的 Java 开发者,听到 Mark Reinhold宣布 Jigsaw 项目被延后,都很难保持平静。 Oracle 规划的这个 Java 模块化框架,将被延迟到 Java 9 的时候才推出, InfoQ 之前报道过相关消息。Jigsaw 最初计划 2011 年和 Java 7 一起推出,随即被延后到 Java 8,现在再次被延后到至少 2015 年。

在 Mark Reinhold 博客上收集到的反应大致可分为三个阵营:

  1. 敏捷角度:及早发布,频繁发布;如果 Jigsaw 进度落后了,把它推到下一次迭代是对的,这样可以保证 Java 8 按时发布。
  2. 没有 Jigsaw 的 Java 8 简直浪费硬盘空间,只等 Jigsaw。
  3. Jigsaw 已经推迟两次了,谁知道还有戏没戏。还是算了吧 Oracle,用你的巨大身板支持下现成的方案。

Jigsaw 项目的目标是满足以下两方面的需求:

  1. 将 Java 平台划分为清晰的、独立的模块,允许用户灵活排除不需要的模块。
  2. 为模块化的应用提供一个构建和交付平台。

对此消息的反应看上去取决于人们对哪方面的需求更为看重:

OSGi 支持者觉得 OSGi 已经是久经考验的 Java 应用模块框架,对 Oracle 决定的发展方向感到不满。

Peter Kriens 曾在 OSGi 担任 Technical Director,他告诉 InfoQ,到了这种时候,别再等 Java 模块化特性了,直接上 OSGi 比较快:

如果 Sun/Oracle 没有浪费七年时间犯他们的“Not Invented Here”病,今天这个行业会有效率的多;显然 OSGi 的推广饱受 FUD——“恐惧、不确定和怀疑”——的阻挠。如果新“计划”靠得住的话,我们将在 2015 年前后得到一个具备(有限)模块化能力的 VM。时间距离 JSR 277 整整十年,距离 OSGi 创立 17 年。如果你曾经苦盼 Jigsaw,现在该考虑收下 OSGi 送上门的模块化能力。理由之一是根本没有别的选项,理由之二是 bndtools 提供了强大工具支持。

OSGi Enterprise Expert Group 前主席 Eric Newcomer 对 InfoQ 说了当初的事情:

四年前我们邀请 Jigsaw 团队一起合作。他们拒绝了,现在所有人都在为不幸的决定付出代价,很可惜。

模块化本质上是一个非常复杂的问题(Jigsaw 团队刚刚承认了这一点)。我认为当时根本没有认真评估过 OSGi 成为通用方案的潜力。

来自 Paremus Ltd 公司的 OSGi 专家组成员 Neil Bartlett,觉得这是一个错失的机会

估计至少要等到 2015 年,我们才能享受到一个模块化的 JRE。正在用 OSGi 的开发者会觉得这事不像话,任何开发者都会觉得这事不像话。首先,假如可以把 JRE 精简到只剩下必要的核心功能,这种能力谁不想要呢?其次,当前 OSGi 与 JRE 的交互方式还留下了很大的改进空间。假如 JRE 被模块化,OSGi bundles 就可以给 JRE 设定条件,要求 JRE 包含某些版本化的模块。然后我们可以做编译期验证,确保 bundle 内只用到规定的 API。还可以进一步运用 OSGi R5 Resolver 来做规划,判定 bundle 要求安装哪些 JRE 模块。我仍然希望有一天能做到这些。

担任 Eclipse Foundation Executive Director 的 Mike Milinkovitch 给 InfoQ 的回复比较悲观:

不管是建立一个模块化模型,还是对本身进行模块化,显然都对 Java 平台有极大的好处。可惜这么重要的工作,交付时间被推迟到 2015 年。我特别担忧这件事情影响到 Java 在嵌入式和移动领域的发展步调。对于进展如此之快的领域,停步两年,整个 Java 平台都可能变得无足轻重。一个开发平台拿不出美妙的业务和技术前景来吸引嵌入式和移动开发者,随时可能被扫到一边。

这件事情给了“其他”Java 模块化技术绽放的机会。OSGi 想长期生存下去,需要进一步提高,这两年的空档给了 OSGi 支持者一个机会。具体来说,OSGi 社群需要在工具和易用性方面狠下功夫,才能吸引更多 Java 开发者。

Eclipse 受这件事情的影响非常大,毕竟有 65% 到 70% 的 Java 开发者使用 Eclipse。我们 Eclipse 社群是和 OSGi 绑在一起的,它是 Eclipse 插件模型的基础。Eclipse 社群的未来,与这两种技术能否健康发展息息相关。

作为另一方的声音,担任 Oracle VP of Development 的 Cameron Purdy从敏捷的角度发言

Jigsaw 推迟发布令人失望,但是把事情做对更重要,如果那意味着推迟,就推迟吧。急急忙忙给 Java 塞一个半成品,岂不是更糟糕?这么说吧,把事情做对总是要花比预计更多的时间。

这种事情还要来几回?这是很多人共同的疑问。Markus Karg 在给 Reinhold 的留言中说得很到位

从 JDK 8 刷下 Jigsaw 有点荒谬,JDK 7 的时候已经刷下来一次了。以后什么打算?再从 9 推迟到 10,从 10 推到 11 吗?干脆推倒用 Maven 算了吧,人家都已经上岗多少年了。

Guillaume Laforge 在 Spring Source 任 Groovy 开发主管,他说

我们没有太下功夫在 Groovy 2 的模块性方面……因为不希望与 Java 8 计划中的特性发生重叠。现在好了,开发者要空手等两年,投入实用则要等三年。:-( 就算 Jigsaw 按时发布,也用了五年以上的开发时间。不管这特性有多重要,开发时间实在太长。

Kirk Knoernschild 给 Oracle 提了一些实际的建议:

我不是开玩笑。为什么不考虑在 Java 8 推出模块系统,等到 Java 9 再对 JDK 本身进行模块化。为什么非要一步到位?

开发者们除了失望,还必须想想在 Oracle 交付 Jigsaw 项目之前,应该干等着,还是骑驴找马为好。

查看英文原文: Reactions to Mark Reinhold’s Recent Announcement of Project Jigsaw’s Delay

2012-08-09 16:133766
用户头像

发布了 225 篇内容, 共 63.4 次阅读, 收获喜欢 50 次。

关注

评论

发布
暂无评论
发现更多内容
Jigsaw项目延后的群众反响_Java_Victor Grazi_InfoQ精选文章