我最近发布了一个question，讨论了一种在客户端定义抽象服务实现的方法。
dfa 提到 java.util.ServiceLoader 作为我的问题的解决方案。
我最终采用了类似的方式，虽然没有直接使用 ServiceLoader，主要是因为我使用的是 JDK 5。但是当 dfa 提到 ServiceLoader 时，另一个 SOer 突然陷入恐慌。
我想知道 ServiceLoader 实现的主要问题是什么。虽然有限，但它似乎是解决此问题的好方法，而无需使用诸如 Guice 之类的第三方库。
【问题讨论】：
忽略各种performance complaints and class loader issues ServiceLoader 的真正架构问题基本上退化为Service locator pattern 以及服务定位器模式（静态初始化程序）带来的所有一般问题。因此，有些人认为服务定位器模式是邪恶的，最好使用完整的 DI 或插件框架，特别是因为 @Inject 现在已标准化。
因此一些替代方案是：
【讨论】：
ServiceLoader 不如 Spring 或 Guice 等完整的依赖注入框架通用。它旨在延迟加载服务，可以在运行时部署。因此ServiceLoader 对插件特别有用。
如需完整答案，请联系Tom Hawtin Tackline。
【讨论】：
在JDK6的java.util中增加了ServiceLoader，在此之前基本的技术是在Service类中使用的。
ServiceLoader 和 DI 框架解决了类似的问题，但不是等效的技术。 ServiceLoader 加载在类路径中找到的特定接口的实现。例如，如果您有一个读取 Excel 电子表格的程序，并且您找到了一个能够读取 CSV 文件的阅读器（实现了相同的接口），您可以将阅读器放入类路径中，并使其在您的程序中作为一个选项可用和可选。 （这意味着您的代码本质上更加灵活）。
依赖注入（至少在 Spring 方面）需要先验知识在其类路径中找到的类才能注入它。您的 Spring 配置文件需要修改以利用您添加到类路径的任何其他实现。它不能简单地通过重新启动服务器来选择它们。
【讨论】：
sun.misc.Service
http://www.docjar.com/docs/api/sun/misc/Service.html
注意，它不是标准 J2SE API 的一部分！它是 Sun JDK 的非标准部分。因此，如果您使用 JRockit，则不能依赖它。
【讨论】：