OSGi会让你的代码莫名其妙地抛出NoClassDefFoundError和ClassNotFoundException(很可能是因为你忘了在OSGi配置文件中导出一个包);因为它有类加载器，它可以使你的类com.example.Foo不能转换为com.example.Foo，因为它实际上是由两个不同的类加载器加载的两个不同的类。它可以在安装Eclipse插件后将Eclipse引导到OSGi控制台。

对我来说，OSGi只是增加了复杂性(因为它为我增加了一个心理模型)，因为异常而增加了烦恼;我从未真正需要它“提供”的活力。它是侵入式的，因为它需要为所有模块配置OSGi包;这绝对不简单(在一个更大的项目中)。

因为我的糟糕经历，我倾向于远离那个怪物，非常感谢。我宁愿忍受jar依赖的地狱，因为这比OSGi引入的类加载器地狱更容易理解。

I don't care too much about the hotplugability of OSGi modules (at least currently). It's more the enforced modularity. Not having millions of "public" classes available on the classpath at any time protects well from circular dependencies: You have to really think about your public interfaces - not just in terms of the java language construct "public", but in terms of your library/module: What (exactly) are the components, that you want to make available for others? What (exactly) are the interfaces (of other modules) you really need to implement your functionality?

这很好，热插拔是附带的，但我宁愿重新启动我通常的应用程序，而不是测试所有的热插拔组合…

OSGi会让你的代码莫名其妙地抛出NoClassDefFoundError和ClassNotFoundException(很可能是因为你忘了在OSGi配置文件中导出一个包);因为它有类加载器，它可以使你的类com.example.Foo不能转换为com.example.Foo，因为它实际上是由两个不同的类加载器加载的两个不同的类。它可以在安装Eclipse插件后将Eclipse引导到OSGi控制台。

对我来说，OSGi只是增加了复杂性(因为它为我增加了一个心理模型)，因为异常而增加了烦恼;我从未真正需要它“提供”的活力。它是侵入式的，因为它需要为所有模块配置OSGi包;这绝对不简单(在一个更大的项目中)。

因为我的糟糕经历，我倾向于远离那个怪物，非常感谢。我宁愿忍受jar依赖的地狱，因为这比OSGi引入的类加载器地狱更容易理解。

它还被用于在移动端带来额外的中间件和应用程序的可移植性。移动端可用于WinMo, Symbian, Android等。一旦与设备功能集成，就会出现碎片化。

至少，OSGi让您考虑到模块化、代码重用、版本控制以及项目的一般管道。

我使用OSGi已经有8年左右的时间了，我不得不说，只有当你有业务需要在运行时更新、删除、安装或替换某个组件时，你才应该考虑使用OSGi。这也意味着您应该有一个模块化的心态，并理解模块化的含义。有一些争论说OSGi是轻量级的——是的，这是真的，但也有一些其他的框架是轻量级的，更容易维护和开发。同样的道理也适用于安全java等等。

OSGi需要一个可靠的体系结构才能正确使用，而且在没有任何OSGi参与的情况下，很容易使OSGi系统成为一个独立可运行的jar。