我已经在Wikipedia和其他网站上阅读了有关OSGi的内容，但我没有真正看到大图。它说这是一个基于组件的平台，我们可以在运行时重新加载模块。 Eclipse插件框架也是到处都有的"实践示例"。

我的问题是：

• OSGi的明确定义是什么？
• 它可以解决哪些常见问题？

"常见问题"是指我们每天都会面对的问题，例如" OSGi能做什么以使我们的工作更高效/更有趣/更简单？"

解决方案

为清楚起见进行了编辑。 OSGi页面给出了比我更好的简单答案

一个简单的答案：OSGi服务平台提供了一个标准化的，面向组件的计算环境，用于协作网络服务。这种体系结构大大降低了构建，维护和部署应用程序的总体复杂性。
OSGi服务平台提供了无需重新启动即可在各种网络的设备上动态更改组成的功能。

在Eclipse IDE中说，在单一应用程序结构中，重新安装新插件并不重要。完全使用OSGi实现，我们应该能够在运行时添加插件，获得新功能，而不必完全重启eclipse。

同样，每天使用少量应用程序也没什么大不了的。

但是，当我们开始研究多计算机，分布式应用程序框架时，它便开始变得有趣起来。当关键系统必须具有100％的正常运行时间时，在运行时热交换组件或者添加新功能的功能将非常有用。当然，现在大多数情况下都具有执行此操作的功能，但是OSGi试图将所有内容捆绑到具有通用接口的漂亮的小型框架中。

OSGi是否可以解决常见问题，我不确定。我的意思是，可以，但是对于更简单的问题，开销可能不值得。但是，当我们开始处理较大的联网应用程序时，需要考虑一下。

我发现OSGi有以下好处：

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

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

我不太在乎OSGi模块的可热插拔性(至少目前是这样)。更多的是强制性的模块化。任何时候在类路径上没有数百万个"公共"类都可以很好地防止循环依赖：我们必须真正考虑公共接口，而不仅仅是Java语言结构" public"，还应该考虑库/模块：我们想让其他人使用哪些组件(正是)？实现功能所需的(其他模块的)接口到底是(什么)接口？

很好，它附带了热插拔功能，但是我宁愿重新启动我的常规应用程序，也不愿测试热插拔功能的所有组合...

它还被用于在移动端带来中间件和应用程序的额外可移植性。例如，移动端可用于WinMo，Symbian，Android。与设备功能的集成一旦发生，可能会变得支离破碎。

• 类似地，我们可以在不关闭汽车的情况下更换汽车的电动机。
• 我们可以为客户定制复杂的系统。请参阅Eclipse的功能。
• 我们可以重用整个组件。不仅仅是对象。
• 我们使用稳定的平台来开发基于组件的应用程序。这样做的好处是巨大的。
• 我们可以使用黑匣子概念构建组件。其他组件不需要了解隐藏的接口，只需看到已发布的接口即可。
• 我们可以在同一系统中使用几个相等的组件，但可以在不同的发行版中使用它们，而不会损害应用程序。 OSGi解决了Jar Hell问题。
• 使用OSGi，我们可以开发思想以使用CBD构建系统

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