约束是工具，还是枷锁？

刚接触OSGI时，感觉开发受到很大的约束，你不能随便就引用其它Bundle的类，你也很难控制你的Bundle的启动的先后次序，于是，千方百计地在Manifest.mf里动脑筋，又是Import-Package，又是Bundle-Classpath的，搞搞DynamicImport-Package，又或者试图通过Import-Package引用被依赖的Bundle，来达到被依赖的Bundle能够比依赖它的Bundle先启动... ...。

当很多手段都用尽，应用得以顺利运行后，却发现做这么多工作，和以往非OSGI环境下的应用并没有得到什么模块化、动态化的好处，应用还是不能顺利地热插拔！这样做，何苦呢？

当时OSGI对应用开发带来的约束就是枷锁：你辛辛苦苦做下来的事和没做一样，吃力不讨好。

但通过对OSGI的了解，我发现当你将OSGI的约束看作是枷锁，并想努力去突破它的约束时，这个约束确实就是枷锁。

OSGI的约束不是为了让你努力去突破，去解决的，而是该用它作为工具，来管理好你开发出来的应用的依赖关系。如果你突破了OSGI的“约束”，那么你的应用也就不是基于OSGI的应用了。做OSGI的应用，你需要利用的正是OSGI的这些约束，而不是那些绕开，避开这些约束的技巧。

禅宗有个公案：一个人一心向佛，于是离开家人，远行求佛，路遇一高僧，就求教佛在何方？高僧跟他说，你现在赶紧回家里去，当你到家时，那个反穿鞋，披着被子来给你开门的，就是你要求的佛。于是，他立即往家里赶，赶到家里时，已是半夜时分，他母亲听到儿子回来，高兴得来不及穿好衣服，直接披着被子，反穿着鞋子赶来开门。

评论

1 楼 java_林 2013-03-06  

公司之前是用OSGI，同样出现不能热插拔的情况，后来大家总结问题是各个模块间耦合太大，很多都是以角色等这样的分模块而不是以功能分模块