我什么时候应该使用像 OSGI 这样的平台，什么时候必须避免使用它？
我的问题非常简单：应用程序的哪些功能迫使开发人员利用类似 OSGI 的系统？在什么情况下不需要这样的实用程序？
My question is pretty straightforward: What are the features of an application that force the developer to exploit OSGI-like system? What are the cases, when such a utility is unneeded?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我刚刚发布了另一个问题的以下链接（OSGi 解决了什么），但是我我认为这里更合适。 Hal Hildebrand 撰写了一篇博客，介绍了他认为 OSGi 为何以及何时可以帮助您的开发/产品。
这篇（相当长的）帖子的核心本质是，它在处理长期运行的复杂企业项目时尤其有帮助。特别是从长远来看，拥有强制结构的好处将会得到回报，但是 自己阅读
编辑：修复了损坏的链接。
I just posted the following link to another question (What does OSGi solve), but I think here it is an even better fit. Hal Hildebrand wrote a blog about why and when he thinks OSGi is helping your development/product.
The core essence of the (pretty long) post is that it helps especially when dealing with long running, complex enterprise projects. In particular in the long run, the benefit of having an enforced structure will pay out, but read for yourselves
EDIT: fixed broken link.
如果您需要以下功能，请使用 OSGI：
Use OSGI if you want some of:
OSGi 于 2000 年代初设计，旨在支持嵌入式设备的用例。使用 OSGi，您可以在 java 程序中交换捆绑包（显示的 jar），而无需重新启动 java 进程。这个简单的事情增加了很多灵活性和复杂性。
如今，OSGi 似乎已经失去了它的相关性，尤其是在企业和云原生领域。
OSGi was designed in the early 2000s to support use cases around embedded devices. With OSGi you can exchange bundles (manifested jars) in a java program without restarting the java process. This simple thing adds lots of flexibility and complexity.
It seems nowadays OSGi has lost its relevance, especially in the enterprise and cloud native world.