BT

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

Jigsaw项目延后的群众反响

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

不管哪个领域的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

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

这就是Oracle的做事风格 by q q

Oracle一向是定期推出新版本,不管版本的功能进步有多少。
Java恐怕在Oracle的带领下要走入坟墓了。

最后一句翻译很赞 by Dongbin Nie

最后一句翻译很赞

模块化还是看OSGI by soft wmz

模块化、插件化,OSGi已成为事实标准,这方面做得比较好的有JIRA、JXADF,有兴趣的朋友可以看看:osgi.help

允许的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通知我

3 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT