写点什么

OSGi 与 JSR 277 的争论日趋激烈

  • 2007-08-12
  • 本文字数:2490 字

    阅读完需:约 8 分钟

JSR 277 (Java 模块系统)与 OSGi JSR 291 )的争论再次变得白热化, JSR 316 (Java EE 6)的提交又一次引燃了关于 OSGi 与 JSR 277 互相重叠的争论。InfoQ 整理总结了其中的若干观点和论据。

Peter Kriens 写了一篇博客文章讨论 Java EE 6 中对 Profile 的使用,并展示了如何用组件结构来代替模块系统作为 Java EE 6 的基础。Kriens 还质疑了 Java EE 6 规范中对 JSR 277 的使用,他说:

JSR 316 仅仅在规范的需求部分,以一种相当间接的方式提到了 JSR 277。大致上是说 JSR 277 正在制定中,他们将推迟任何决定,直到 JSR 277 完成。看上去颇有道理,因为从编号上看 277 比 291 更老也更成熟?但实际上,277 仍然处在草案复审阶段,而 291 已经最终发布,因为 291 的基础是从 1999 年发布至今,已经经过 4 个主要修订版的非常成熟的 OSGi 规范。那么,应该有别的理由不提 JSR 291 吧?也许 277 提供了 291 缺少的特性?嗯,没有。从 JSR 277 规范的需求看,谁也没法说它的目标比 JSR 291/OSGi 更加远大:没有动态、没有类空间一致性、没有卸载、没有包引用等等。277 的初步草案仍然处在一种过于简单化的程度。即便是 277 唯一比 291 强的 Repository,也仍然有许多晦涩不明之处。JSR 277 最近开放了邮件列表,从里面的讨论中可以看出,似乎他们仍然被一些基本的模块性问题所困扰。不过,幸运的是,JSR 277 专家组已经承诺让 277 的模块系统与 JSR 291/OSGi 互操作。这就消除了选择 OSGi 的最后一丝风险,更不用提今天就可以在各种 VM(从 1.2 到 6,以及嵌入式设备)上运行 OSGi 的额外好处,而 JSR 277 只能运行在 2008 年下半年才会发布 Java 7 上。那么,为什么 JSR 316 要停下来等?我们已经有一个完美的方案,而且 JSR 277 承诺将会兼容?

Alex Blewitt 也质疑了 Java EE 6 选择 JSR 277 的决定

提交的草案声称:

为了更好地支持这个平台在扩展性方面的目标,应该有一个更加宽泛的模块概念。这项工作正由“JSR 277——Java 模块系统”展开,它的目标是 Java SE 7。我们预期 Java EE 7 将建立在这项技术的基础上,因此我们将推迟任何可能与将来的版本冲突的技术规范

也就是说,他们选择了 JSR 277 而非 JSR 291,并且拒绝在 JSR 277 随 Java 7 发布之前考虑任何其它选择。

InfoQ 也询问 Eric Newcomer 是否认为 SUN 应该接受 OSGi:

绝对应该,绝对合理。更重要的问题是关于 Java 的未来,关于 SUN 是会拥抱 OSGi 还是继续对抗,如果他们继续对抗 OSGi,对 Java 又会有什么影响。根据我最近有限的 OSGi 经验来说,它在许多方面都给 Java 带来了显著的改进——模块性、版本、增强的类装载。Sun 投票反对 JSR 291,不过 JSR 291 仍然获得了通过,正式成为 JSE 的一部分。不过这已经表明了 Sun 的立场。JSR 277 是由 Sun 提案的,内容是 Java 模块性,这看起来明显跟 OSGi 重叠。Sun 有过很好的机会拥抱 OSGi 并以之为基础构造 Java 7,不过,虽然没有正式的声明,但看上去他们更倾向于重复 OSGi 的工作而不是拥抱 OSGi。

我期望 Sun 能尽快理性地对待 OSGi。不过,也许 Sun 继续站在 OSGi 的对立面反而更好,因为至今 OSGi 都发展得很好。

Hani Suleiman ,JSR 291 专家组的成员之一,对这场争论有不同看法。在回答关于 JSR 277 和 OSGi 有什么共同基础时,他说:

[……]JSR-277(在某种程度上)是一个共同的基础。它从 JDK 这一面着手解决问题,这让 OSGi 和其他类似方案(Maven、Ivy 等)的任务变得更加容易。组件包(Bundle)/ 模块成为 JVM 层次的一等公民。除此之外,(OSGi 或其它)框架可以按照自己的意思添加任何增值功能。277 并没有限制。OSGi 支持者们感到不高兴只是因为基础标准用的不是他们的实现,而且还考虑了很多其它方面的东西。

用 Hibernate 来打比方,请想象这样的情形:JBoss 一直攻击 JPA 规范,说它是重新发明轮子,所有人都应该把 Hibernate 当作标准。这就是 OSGi 支持者们正在做的。

其他人,如 Neil Bartlett ,也就 JSR 277 专家组的讨论内容提出了他们的担心

请看看 JSR 277 的专家组邮件列表,它已经向公众开放(虽然是只读的)。从这些讨论来看,很难认为他们有倾听两位 OSGi 专家(Glyn Normington 和 Richard Hall)的意见。在 JSR 277 草案的规范定义和应用举例中,有很多地方跟 OSGi 是不可调和的:Sun 拒绝学习任何 OSGi/JSR 291 的经验。OSGi 支持者们并不是因为我们最中意的模块系统没被选中就大发牢骚。这太孩子气了。我们鼓噪是因为原则问题,JSR 277 这个模块系统正在迈向失败!如果在 JVM 里绑死了一个残缺的模块系统,这会给整个 Java 社区造成巨大的破坏。

Chris Custine 从另一个角度看这场争论的起源:

我认为 Sun 和 OSGi 的激烈冲突纯粹是关于控制权和许可证的政治斗争。根本和技术无关!Java 社区的政治又一次无视了每个理智的人都具备的常识和逻辑。我一向非常期待 Java 能够再次复兴它在创新和进化上的能力,但正是这些东西让我担心……

Glyn Normington ,JSR 277 专家组成员和 JSR 291 的规范带头人,试图谨慎地表达他的观点。除了两者的特性对照,Normington 还就争论中涉及的问题写了一篇详细的介绍。他解释说“这两项JSR 的目标是非常不同的,虽然背后的概念很接近。JSR 277 和294 是在Java SE 平台之中加入基本支持;而JSR 291 是纯Java 的,它建立在Java 平台之上”。

Normington 认为在 JSR 277 中重用 OSGi 并不容易,他也讨论并推翻了放弃 JSR 277 的想法,最后提出了他认为最合适的解决方案:

最佳方案很清楚:JSR 277 应该接受 JSR 291,为此应该在 JSR 294 里加强语言和 VM 上的支持,并且加入 JSR 277 的 Repository 架构。这样可以让 JSR 277 的进程提前数年,还保证了 JSR 277 和 JSR 291 之间完美的互操作性。但要想实现这个最佳方案,需要 Sun 转一个 180 度的大弯。也许,只是也许,Sun 为了保证 Java 的成功,终究会做这件事。也许,只是也许,将来 Java 社区可以回顾今天,并且模仿丘吉尔的话说:“在穷尽了所有选择之后,总是可以指望 Sun 做正确的事”。

社区里面对于什么是这个困境的最佳解决方案肯定也是争论不休——您的看法呢?

查看英文原文: OSGi and JSR 277 debate continues to grow

2007-08-12 22:44928
用户头像

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

关注

评论

发布
暂无评论
发现更多内容

2023-07-11:给定正整数 n, 返回在 [1, n] 范围内具有 至少 1 位 重复数字的正整数的个数。 输入:n = 100。 输出:10。

福大大架构师每日一题

Go 算法 rust 福大大架构师每日一题

三问三答:细数GaussDB迁移的核心技术

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 7 月 PK 榜

从零开始构建一个电影知识图谱,实现KBQA智能问答[上篇]:本体建模、RDF、D2RQ、SPARQL endpoint与两种交互方式详细教学

汀丶人工智能

人工智能 自然语言处理 nlp 知识图谱 本体建模

GPT-4被破解!数智时代大突破!低代码开发平台揭秘:AI模型架构演进的利器

不在线第一只蜗牛

人工智能 低代码 模型调参 ChatGPT GPT-4

昇腾AI创新大赛2023开发者套件创新赛道专题解读篇

彭飞

软件测试/测试开发丨Selenium环境安装配置

测试人

Python 程序员 软件测试 selenium chromedriver

为什么选择美国虚拟主机是你的明智之选?

一只扑棱蛾子

美国虚拟主机

科兴未来|“追光逐电 才聚紫琅”光电产业创新创业大赛

科兴未来News

创新引领!矩阵起源荣获中国信通院双重认可!

MatrixOrigin

数据库 分布式 云原生 超融合 矩阵起源

直播预告 | 博睿学院:海量数据实时可信认证

博睿数据

智能运维 博睿数据 数据要素 博睿学院

一个提高go开发效率的秘密武器,一天开发完成一个极简版社区后端服务

vison

crud gorm gin #go 代码自动生成

谁能真正替代你?AI辅助编码工具深度对比(chatGPT/Copilot/Cursor/New Bing)

快乐非自愿限量之名

工具 ChatGPT AI赋能 AI工具

从零开始构建一个电影知识图谱,实现KBQA智能问答[下篇]:Apache jena SPARQL endpoint及推理、KBQA问答Demo超详细教学

汀丶人工智能

人工智能 自然语言处理 知识图谱 智能问答 KBQA

对象存储、数据库、NAS、标注数据集,均支持元信息配置|ModelWhale 版本更新

ModelWhale

人工智能 数据库 云计算 数据分析 大模型

HDC.Cloud 2023 |华为云5大开源项目发布与更新,助力开发者实现应用创新

华为云开源

开源 云原生 HDC.Cloud

小程序开发这么简单,还需要App吗?

FinFish

小程序生态 APP开发 小程序开发

开启时空大数据新纪元:JNPF快速开发平台引领AI与自然资源融合

EquatorCoco

人工智能 AI 数据 时空大数据

重塑未来的1课:组装式交付新引擎——华为云智能化低代码平台

华为云PaaS服务小智

云计算 低代码 华为云 华为开发者大会

如果AI能帮我 | 社区征文

六月的雨在InfoQ

AIGC ChatGPT 年中技术盘点 通义听悟

接口文档阅读方法:程序员必备的技术指南

Liam

程序员 接口文档 API

Boundless Hackathon @Stanford 主题黑客松活动闭幕,一文回顾

股市老人

Cloud Kernel SIG月度动态:ANCK 5.10-016将落地kABI机制,5.10-015版本规划发布

OpenAnolis小助手

操作系统 内核 anck 龙蜥sig 版本规划

MatrixOne悲观事务实现

MatrixOrigin

数据库 分布式 云原生 矩阵起源

大学生活动社交小程序开发笔记(1)

CC同学

开源铸剑,五载匠心!Zilliz Cloud云服务盛装登场,引领向量数据库云时代!

Zilliz

阿里云 SaaS 云服务 Zilliz zillizcloud

浅谈如何向上管理

光毅

团队管理 向上管理

分布式系统常见问题

互联网工科生

分布式

实例分享| anyRTC 部署安徽某市应急实战指挥平台

anyRTC开发者

音视频 快对讲 融合会议 视频监控 综合调度

低代码技术分享官丨inBuilder使用有向无环图助力元数据工程依赖管理

inBuilder低代码平台

数码时代的奇迹:低代码开发助力数字经济的蓝海探索

快乐非自愿限量之名

人工智能 低代码 数字化 数字经济

OSGi与JSR 277的争论日趋激烈_Java_Ryan Slobojan_InfoQ精选文章