Java OSGi的盈亏平衡点

OSGi似乎是当今的热门词汇。其中许多被调用：

• 降低复杂性
• 再利用
• 易于部署
• 版本控制

（等）

我要求提供一个非常具体的用例——中小型web应用程序。OSGi将为这些用户带来什么好处？这真的值得吗？

我会一如既往地说“视情况而定”

您的环境

考虑一个没有OSGi经验的团队（他们自豪地认为自己是一个经验丰富的开发人员），他们有可能经历一个大的痛苦或一个缓慢的开始。 许多（比您想象的要多）开发人员不熟悉或之类的构建工具，当他们熟悉时，他们只使用这些构建工具的有限功能

创建OSGI捆绑包最好使用脚本或手动编写的jar归档清单来完成

小型应用程序

对于小型应用程序，OSGI引入了不必要的复杂性，而您可以使用动态语言（如等）或插件框架（如或）。您还可以直接使用反射和简单的自定义类加载器

大型应用程序

大型应用程序可能会从OSGI中受益，特别是当它们是从头开始编写的时候。IMHO将OSGI集成到现有应用程序中更像是引入一个补丁来提供模块化架构

根据我的经验，在重写了许多应用程序之后，最好在项目的早期考虑模块化

其他问题

部署： 这在任何应用程序中都是一样的。如果您习惯于部署Java Web Start应用程序，则不必担心部署。如果您习惯于OSGI，则不必担心部署

在任何应用程序中，在生产环境中部署应用程序时总会出现问题，这是很自然的

版本控制： 在应用程序中提供版本控制的方法有很多。但是，如果只将版本控制用作“信息”而不是工具（管理依赖项要求），那么版本控制就不成问题

重复使用： 当使用OSGI时，您倾向于编写代码以供重用，但任何编写良好的API在设计时都考虑到了代码重用

Eclipse是使用OSGI编写的成功大型应用程序的第一个例子。还有其他不使用OSGI的模块化大型/优秀工具

结论

在许多模块化框架中，如果不重新启动应用程序，很难在运行时处理依赖项、停止/启动/卸载/安装功能。您可以使用自定义类加载器、关闭和启动挂钩等

---

OSGI以较小的成本为您提供了这样的灵活性。

尽管我是OSGI的忠实粉丝，但我还是会冒险拒绝。除非您正在使用其他OSGI捆绑包，或者您有一个特定的问题，如果没有这个大锤，您无法轻松解决

好处是优雅的类路径分离（IMHO）。如果你需要同一个JAR/类的不同版本，比如说因为你正在升级应用程序运行时的某些部分，或者因为你正在组合许多第三方模块，那么OSGi就很棒了

这不是一件容易做到的事情，OSGi也不容易做到。它变得干净了，但代价是环境堆栈中的另一层。还有很多工作要学习和维护

更不用说文档对初学者不是特别友好

---

我建议了解它——构建Eclipse插件是一种非常好的方法——但在您熟悉它之前，不要将其构建到您的开发计划中。

这是主观的，但不是CW材料。我将选择具有最佳参数的答案。与部分Cloudy的答案一致，“降低复杂性”是有争议的。