肖伯纳人生有两大悲剧:真正的猛男，敢于鄙视OSGi-回帖

真正的猛男，敢于鄙视OSGi

该帖已经被评为精华帖

作者

正文

• galaxystar
• 等级:
• 性别:
• 文章: 631
• 积分: 2483
• 来自: 杭州

   发表时间：2010-03-10   最后修改：2010-03-11

<>猎头职位: 北京: JavaEye招聘Java搜索工程师

相关文章:  

• 基于osgi开发大型的企业应用
• 想做个基于OSGI插件体系的web开发框架，欢迎大家拍砖
• web应用中加入osgi支持

推荐圈子: 博文视点
更多相关推荐

ADAM BIEN这位老兄，最近在他的blog上发表了一篇关于“如何杀死一个OSGi项目”(How to kill a OSGi projcet)的主题，引来了无数口水。
说实话，我个人还是很赞同老兄的部分观点。 单从它提出的10个问题来看，有一半是大多数公司和开发人员正面临要解决的问题。
看来这位老兄，私下也是做了不少功课的，人猛才是王道。

参考他提出的10个问题，来看我们公司的使用情况，大致有三个方面被他说中了：

1，有状态的bundle想要做平滑热替换，需具备一定复杂性。
最近，一位公司同事正在实验某个带状态bundle的热替换工作，开发期间碰到了多处棘手的问题（实例状态的同步转移），幸好人牛，从他描述的实现逻辑来看，必然包含很复杂操作在里面。
可见有状态bundle的平滑热替换，很难简单实现。

2，当OSGi的bundle数量达到一定规模时，维护成本必将成为瓶颈。
这是一个趋势，值得庆幸的是，从我们公司项目的bundle数量来看，还未迈入“成年”。对策尚可暂缓考虑。

3，多个版本或相互依赖bundle间的测试必然会显著提高复杂性。
谁能推荐个好用的OSGi测试框架？

问题中还提到分发包的增量更新，RCP应用程序的暴露问题，貌似我们公司没用到。但看得出来，OSGi也不是万能的。成熟度还有待提高。。。要知道JDK7的jigsaw(JSR294 and 277)已在养精蓄锐了，从language, compiler, vm等底层入手做modularity的jigsaw，对OSGi造成的压力可不小啊。
希望将来有位猛男能够趟一趟这浑水，像我这样的迷茫者就可以随波逐流了。。。

转自主博：http://kenwublog.com/look-reality-in-fault-of-the-osgi

声明：JavaEye文章版权属于作者，受法律保护。没有作者书面许可不得转载。

推荐链接

• 实用工具推荐，延长电池续航时间
• 入学不花1分钱学JavaEE+3G 就业"不做开发不还款"
•  

返回顶楼

• wl95421
• 等级:
• 性别:
• 文章: 284
• 积分: 633

   发表时间：2010-03-11  

你这是标题党

1、bundle的热更换，主要是口号，而不是实用，拿这个主要是忽悠人的，热替换，不管怎么做，都是复杂的。
2、bundle数量多了，难以维护，难道Jar多了，就好维护，这是个伪命题。
3、我主业做Eclipse开发，所以用Eclipse的JUnit Plugin还是比较好用的，不知道能满足要求不？
4、JDK7的Module，引发的问题，不见得比OSGi少。
5、目前，J2EE和OSGi的整合是比较困难的。

返回顶楼

     回帖地址

1 0 请登录后投票

• galaxystar
• 等级:
• 性别:
• 文章: 631
• 积分: 2483
• 来自: 杭州

   发表时间：2010-03-11  

wl95421 写道

你这是标题党

1、bundle的热更换，主要是口号，而不是实用，拿这个主要是忽悠人的，热替换，不管怎么做，都是复杂的。
2、bundle数量多了，难以维护，难道Jar多了，就好维护，这是个伪命题。
3、我主业做Eclipse开发，所以用Eclipse的JUnit Plugin还是比较好用的，不知道能满足要求不？
4、JDK7的Module，引发的问题，不见得比OSGi少。
5、目前，J2EE和OSGi的整合是比较困难的。

Yes,我就是标题党，：），此标题是第三人称。
1，3，5  clear

2，jar的粒度通常情况下大于bundle. jar的依赖管理有很成熟的工具-maven。
4，我断言Jigsaw要比OSGi发展稳健，腰板直，才能走得快。

返回顶楼

     回帖地址

0 0 请登录后投票

• freej
• 等级: 初级会员
• 性别:
• 文章: 443
• 积分: 40
• 来自: 北京

   发表时间：2010-03-11  

综上所述，OSGi是个很复杂的标准，并不建议一般应用去去实现它。

返回顶楼

     回帖地址

0 0 请登录后投票

• hzh0725
• 等级: 初级会员
• 性别:
• 文章: 19
• 积分: 80
• 来自: 上海

   发表时间：2010-03-11  

OSGI只是一个标准，或者说接口，说的更通俗一点，就是一个让各个模块组织方法，你不用去考虑怎么组织了，比如 生命周期，启动顺序，模块之间的关系（service,package）。

从上面来说OSGI又是一个平台，是一个很小的平台。

其实osgi很简单，用的不好，我觉得是你自己的项目大框架和模块本身就不太清晰，跟osgi没有太大关系。

比如你自己写一个eclipse plugin,在eclipse里面没有work properly,跟eclipse没有太大的关系。

返回顶楼

     回帖地址

0 0 请登录后投票

• wl95421
• 等级:
• 性别:
• 文章: 284
• 积分: 633

   发表时间：2010-03-11  

2、bundle和jar的粒度问题和公司，还和设计风格，规范都有关系，事实上两者并没有必然大或小的联系。

4、这个没有什么争论的，就象weblogic和websphere谁好一样，背景，应用都不同，比较是没有意义的。我只能说对于现有系统,OSGi可能更好处理一些，而于新的系统，则不好说。

返回顶楼

     回帖地址

0 0 请登录后投票

• xyz20003
• 等级:
• 性别:
• 文章: 798
• 积分: 1427
• 来自: 唐山

   发表时间：2010-03-11   最后修改：2010-03-11

2，jar的粒度通常情况下大于bundle. jar的依赖管理有很成熟的工具-maven。

这点不敢苟同，业务系统中的bundle应该是jar的集合，只想把jar转换成bundle就当做依赖管理完全是本末倒置。

4，我断言Jigsaw要比OSGi发展稳健，腰板直，才能走得快。

对jigsaw不熟悉，但是根据以往经验，java官方的标准都是巨复杂，巨难用，好用的东西都是从先从社区得到了实践锻炼，再慢慢一步一步向标准化发展，就像OSGi这样。


最后一个问题：到底应不应该用OSGi？

要说这个问题，首先要问：“能力够不够啊？”OSGi这东西对大多数业务应用来说，完全是鸡肋，吹嘘动态模块热插拔，最后项目却是按照紧耦合设计的，业务相互之间复杂依赖，最终得到的只有高昂的技术难度代价。

然后要问：“你用的项目真的需要动态模块化吗？”实际上大多数都是不需要的，那为啥还要用OSGi？忽悠概念，就像BPM，SOA一样，本来用不着，但是为了添名词，所以就加上了。

最后可以回答上面的问题了，“既然你能力够牛，实际又真需要动态模块化，那么为何不用OSGi呢？”至少人家把规范都写好了，帮你省去不少的功夫，这种东西还是有一定技术难度的，手工去造个轮子的难度也不小。

返回顶楼

     回帖地址

0 0 请登录后投票

• galaxystar
• 等级:
• 性别:
• 文章: 631
• 积分: 2483
• 来自: 杭州

   发表时间：2010-03-11  

wl95421 写道

2、bundle和jar的粒度问题和公司，还和设计风格，规范都有关系，事实上两者并没有必然大或小的联系。

4、这个没有什么争论的，就象weblogic和websphere谁好一样，背景，应用都不同，比较是没有意义的。我只能说对于现有系统,OSGi可能更好处理一些，而于新的系统，则不好说。

3，clear，使用习惯不同。

4，比较怎么能说没意义呢？至少能够让我们看到两个不同标准之间各有什么优缺点。
要是jigsaw release了，我还是有兴趣做一下对比的。(网上已有很多对比)

返回顶楼

     回帖地址

0 1 请登录后投票

• galaxystar
• 等级:
• 性别:
• 文章: 631
• 积分: 2483
• 来自: 杭州

   发表时间：2010-03-11   最后修改：2010-03-11

xyz20003 写道

2，jar的粒度通常情况下大于bundle. jar的依赖管理有很成熟的工具-maven。

这点不敢苟同，业务系统中的bundle应该是jar的集合，只想把jar转换成bundle就当做依赖管理完全是本末倒置。

4，我断言Jigsaw要比OSGi发展稳健，腰板直，才能走得快。

对jigsaw不熟悉，但是根据以往经验，java官方的标准都是巨复杂，巨难用，好用的东西都是从先从社区得到了实践锻炼，再慢慢一步一步向标准化发展，就像OSGi这样。

3，clear, 你所有bundle都是jar的集合？貌似我只把sharable的jar做了聚合。当然粒度这个确实是看风格的。
4，我感觉java版OSGi(eqinox, felix, your own)在目前language层面上，已经把模块化发挥得淋漓尽致了。要想有更大的作为，不得不走邪门歪道。jigsaw旨在提供更多OSGi标准无法解决的问题的一些实现方案，标准复杂我感觉关系不大，可以优化（有OSGi标准作为参考，未必很复杂），但这应该是个趋势。

返回顶楼

     回帖地址

0 0 请登录后投票

• xyz20003
• 等级:
• 性别:
• 文章: 798
• 积分: 1427
• 来自: 唐山

   发表时间：2010-03-11  

当然也不是所有bundle都是粗粒度的，但是请考虑一个问题，如果bundle都是以jar为单位，那么怎么体现classLoader隔离不同版本依赖的效果呢？

比如一个模块依赖jar-1.0，另一个模块依赖jar-2.0，如果没有osgi，想解决这个问题就只能把其中一个模块改掉。用了osgi就可以考虑，把jar-1.0作为模块一的classpath，jar-2.0作为模块二的classpath，每个模块向外暴露自己的接口，内部管理本身的依赖。

java本身对模块化支持确实有限，所以osgi才跑出来了嘛，个人感觉osgi现在就挺好的了。或许举出几个osgi难以实现的场景来，会比较便于大家讨论。上边说的这些都是设计上的问题哦。