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

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

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

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

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

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

为清晰起见，经过编辑。OSGi页面给出了一个比我更好的简单答案

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

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

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

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

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

我发现OSGi有以下好处:

每个插件都是一个版本化的工件，它有自己的类加载器。 每个插件都依赖于它所包含的特定jar和其他特定版本的插件。 由于版本控制和隔离的类加载器，同一工件的不同版本可以同时加载。如果应用程序的一个组件依赖于插件的一个版本，而另一个组件依赖于另一个版本，那么它们可以同时加载。

这样，您就可以将应用程序构建为一组按需加载的版本化插件构件。每个插件都是一个独立的组件。就像Maven帮助您构建构建，使其可重复，并由创建它的工件的一组特定版本定义一样，OSGi帮助您在运行时完成这一点。

OSGi的组件系统给你带来了什么好处?嗯，这里有一个相当长的清单:

Reduced Complexity - Developing with OSGi technology means developing bundles: the OSGi components. Bundles are modules. They hide their internals from other bundles and communicate through well defined services. Hiding internals means more freedom to change later. This not only reduces the number of bugs, it also makes bundles simpler to develop because correctly sized bundles implement a piece of functionality through well defined interfaces. There is an interesting blog that describes what OSGi technology did for their development process.

重用——OSGi组件模型使得在应用程序中使用许多第三方组件变得非常容易。越来越多的开源项目为OSGi提供了现成的jar。然而，商业库也可以作为现成的包使用。

Real World - The OSGi framework is dynamic. It can update bundles on the fly and services can come and go. Developers used to more traditional Java see this as a very problematic feature and fail to see the advantage. However, it turns out that the real world is highly dynamic and having dynamic services that can come and go makes the services a perfect match for many real world scenarios. For example, a service could model a device in the network. If the device is detected, the service is registered. If the device goes away, the service is unregistered. There are a surprising number of real world scenarios that match this dynamic service model. Applications can therefore reuse the powerful primitives of the service registry (register, get, list with an expressive filter language, and waiting for services to appear and disappear) in their own domain. This not only saves writing code, it also provides global visibility, debugging tools, and more functionality than would have implemented for a dedicated solution. Writing code in such a dynamic environment sounds like a nightmare, but fortunately, there are support classes and frameworks that take most, if not all, of the pain out of it.

Easy Deployment - The OSGi technology is not just a standard for components. It also specifies how components are installed and managed. This API has been used by many bundles to provide a management agent. This management agent can be as simple as a command shell, a TR-69 management protocol driver, OMA DM protocol driver, a cloud computing interface for Amazon's EC2, or an IBM Tivoli management system. The standardized management API makes it very easy to integrate OSGi technology in existing and future systems.

动态更新——OSGi组件模型是一个动态模型。可以安装、启动、停止、更新和卸载包，而不会导致整个系统瘫痪。许多Java开发人员不相信这可以可靠地完成，因此最初没有在生产中使用它。然而，在开发中使用它一段时间后，大多数人开始意识到它实际上是有效的，并显著减少了部署时间。

Adaptive - The OSGi component model is designed from the ground up to allow the mixing and matching of components. This requires that the dependencies of components need to be specified and it requires components to live in an environment where their optional dependencies are not always available. The OSGi service registry is a dynamic registry where bundles can register, get, and listen to services. This dynamic service model allows bundles to find out what capabilities are available on the system and adapt the functionality they can provide. This makes code more flexible and resilient to changes.

Transparency - Bundles and services are first class citizens in the OSGi environment. The management API provides access to the internal state of a bundle as well as how it is connected to other bundles. For example, most frameworks provide a command shell that shows this internal state. Parts of the applications can be stopped to debug a certain problem, or diagnostic bundles can be brought in. Instead of staring at millions of lines of logging output and long reboot times, OSGi applications can often be debugged with a live command shell.

Versioning - OSGi technology solves JAR hell. JAR hell is the problem that library A works with library B;version=2, but library C can only work with B;version=3. In standard Java, you're out of luck. In the OSGi environment, all bundles are carefully versioned and only bundles that can collaborate are wired together in the same class space. This allows both bundle A and C to function with their own library. Though it is not advised to design systems with this versioning issue, it can be a life saver in some cases.

简单——OSGi API非常简单。核心API只有一个包和不到30个类/接口。这个核心API足以编写包、安装它们、启动、停止、更新和卸载它们，并且包括所有侦听器和安全类。很少有API能够为如此少的API提供如此多的功能。

小——OSGi Release 4框架可以在大约300KB的JAR文件中实现。对于通过包含OSGi而添加到应用程序中的功能而言，这是一个很小的开销。因此，OSGi可以在各种各样的设备上运行:从非常小的设备到小型设备，再到大型机。它只要求运行一个最小的Java VM，并且在上面添加了很少的内容。

快速——OSGi框架的主要职责之一是从bundle中加载类。在传统Java中，jar是完全可见的，并放置在一个线性列表中。搜索类需要搜索这个列表(通常很长，150个也很常见)。相反，OSGi预先连接捆绑包，并确切地知道每个捆绑包是哪个捆绑包提供的类。缺乏搜索是启动时显著的加速因素。

懒惰——软件中的懒惰是好的，OSGi技术有许多适当的机制，只在真正需要的时候才做事情。例如，包可以被急切地启动，但也可以配置为仅在其他包使用它们时才启动。服务可以注册，但只有在使用时才创建。规范已经优化了几次，以支持这种可以节省大量运行时成本的懒惰场景。

Secure - Java has a very powerful fine grained security model at the bottom but it has turned out very hard to configure in practice. The result is that most secure Java applications are running with a binary choice: no security or very limited capabilities. The OSGi security model leverages the fine grained security model but improves the usability (as well as hardening the original model) by having the bundle developer specify the requested security details in an easily audited form while the operator of the environment remains fully in charge. Overall, OSGi likely provides one of the most secure application environments that is still usable short of hardware protected computing platforms.

非侵入性——OSGi环境中的应用程序(包)被留给它们自己。他们几乎可以使用VM的任何工具，而不受OSGi的限制。OSGi中的最佳实践是编写普通旧Java对象，因此，OSGi服务不需要特殊的接口，甚至Java String对象也可以充当OSGi服务。这种策略使应用程序代码更容易移植到另一个环境。

Runs Everywhere - Well, that depends. The original goal of Java was to run anywhere. Obviously, it is not possible to run all code everywhere because the capabilities of the Java VMs differ. A VM in a mobile phone will likely not support the same libraries as an IBM mainframe running a banking application. There are two issue to take care of. First, the OSGi APIs should not use classes that are not available on all environments. Second, a bundle should not start if it contains code that is not available in the execution environment. Both of these issues have been taken care of in the OSGi specifications.

来源:www.osgi.org/Technology/WhyOSGi