作为一个对依赖过敏的人，我什么时候会使用像 OSGi 这样的东西而不是内置的 java 6 http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html (我想让插件 jars 被放入)。
(仅供引用，这是一个 Scala 应用程序，可以接受任何建议，ServiceLoader 非常接近我想要的)。
最佳答案
如果 ServiceLoader 最能满足您的需求，则表示您正在通过类路径上的文件来寻找服务发现。这只是 OSGi 提供的一小部分。
OSGi 将允许您在应用程序运行时动态安装 bundle 、广告服务、撤销广告和卸载 bundle 。此外，作为服务的消费者，您可以热切地查找它们——使用过滤谓词查询——并检测提供的服务提供者何时来来去去。这些包不需要位于类路径中，它们可以以各种形式提供； Jar 文件和“分解目录”是我记得的两个。
相比之下，ServiceLoader 只做一件事:它公开可发现的工厂。通常您会创建一个工厂风格的接口(interface)，它采用一些参数来决定该提供者是否可以提供适当的服务，例如将给定的字符集名称映射到 CharsetDecoder。没有用于从此类提供商处获取和发布服务的正式协议(protocol)。 OSGi 确实规范了消费者与服务的绑定(bind)和解除绑定(bind)。消费者可以在新的提供者上线时收到通知，而提供者可以在消费者获取和释放服务实例时收到通知。如果此生命周期控制对您的服务很重要并且您放弃了 OSGi，那么您将不得不自己构建它； ServiceLoader 没有走那么远。
或者，您可以采用一种更加被动的声明式方法，让其中一个 OSGi 依赖项管理器将您声明的需求与可用的服务提供者相匹配，而不是急切地查找和使用服务。有许多依赖管理器可供选择。 Spring Dynamic Modules 是最有能力的人之一。
OSGi 提供了许多其他“中间件”设施。我不会在这里向您推销它们，因为您的问题主要集中在选择 ServiceLoader 会错过什么。
关于java - 什么时候使用 ServiceLoader 而不是像 OSGi 这样的东西，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1959991/