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

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

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

如果基于Java的应用程序需要添加或删除模块(扩展应用程序的基本功能)，而不需要关闭JVM，则可以使用OSGI。通常，如果关闭JVM的成本比较高，那么仅仅是为了更新或增强功能。

例子:

Eclipse:为插件的安装、卸载、更新和相互依赖提供了平台。 AEM: WCM应用程序，其中功能更改将由业务驱动，无法承担维护停机时间。

注意:Spring框架停止支持OSGI Spring包，认为它对于基于事务的应用程序或这些行中的某些点来说是不必要的复杂性。我个人是不会考虑OSGI的，除非绝对必要，比如在构建平台这样的大项目中。

You can, analogically speaking, change the motor of your car without turning it off. You can customize complex systems for the customers. See the power of Eclipse. You can reuse entire components. Better than just objects. You use a stable platform to develop component based Applications. The benefits of this are huge. You can build Components with the black box concept. Other components don't need to know about hidden interfaces, them see just the published interfaces. You can use in the same system several equal components, but in different releases, without compromise the application. OSGi solves the Jar Hell problem. With OSGi you develop thinking to architect systems with CBD

对于使用Java的每个人来说，有很多好处(我现在只提醒了这些)。

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页面给出了一个比我更好的简单答案

一个简单的答案:OSGi服务平台为协作网络服务提供了一个标准化的、面向组件的计算环境。这种体系结构显著降低了构建、维护和部署应用程序的整体复杂性。 OSGi服务平台提供了在各种网络的设备上动态改变组合的功能，不需要重新启动。

在单个应用程序结构中，比如Eclipse IDE，在安装新插件时重新启动并不是什么大问题。完全使用OSGi实现，您应该能够在运行时添加插件，获得新功能，而完全不需要重新启动eclipse。

同样，这不是每天都要做的大事，只是应用程序的小用途。

但是，当你开始研究多计算机、分布式应用框架时，这就是它开始变得有趣的地方。当关键系统必须有100%的正常运行时间时，热插拔组件或在运行时添加新功能的能力非常有用。当然，现在大多数情况下都有这样做的能力，但是OSGi正试图将所有东西捆绑到一个具有公共接口的漂亮的小框架中。

OSGi能解决常见问题吗，我不确定。我的意思是，它可以，但对于更简单的问题，开销可能不值得。但是当您开始处理更大的、网络化的应用程序时，需要考虑这一点。

我还不是OSGi的“粉丝”…

我一直在财富100强公司使用企业应用程序。最近，我们使用的产品已经“升级”为OSGi实现。

启动本地cba部署… [2/18/14 8:47:23 727 EST] 00000347 CheckForOasis

最终部署，“以下包将暂停，然后重新启动” 00000143 AriesApplicat I CWSAI0054I:作为应用程序更新操作的一部分

51分钟……每次代码改变…以前的版本(非osgi)在旧的开发机器上部署不到5分钟。

在一台有16g内存和40g空闲磁盘和Intel i5-3437U 1.9 GHz CPU的机器上

The "benefit" of this upgrade was sold as improving (production) deployments - an activity that we do about 4 times a year with maybe 2-4 small fix deployments a year. Adding 45 minutes per day to 15 people (QA and developers) I can't imagine ever being justified. In big enterprise applications, if your application is a core application, then changing it is, rightly so (small changes have potential for far reaching impacts - must be communicated and planned with consumers all over the enterprise), a monumental activity - wrong architecture for OSGi. If your application is not an enterprise application - i.e. each consumer can have their own tailored module likely hitting their own silo of data in their own silo'd database and running on a server that hosts many applications, then maybe look at OSGi. At least, that is my experience thus far.