ServiceLoader，其中类型 parm 本身是通用的

Question

class ServiceLoader<S> implements Iterable<S> {
    // ...
}

interface Foo<T> {
    // ...
}

class FooRepository {
    void add(Iterable<Foo<?>> foos) {
        // ...
    }
}

FooRepository repo = new FooRepository();
repo.add(ServiceLoader.load(Foo.class));

这会产生编译器错误：“FooRepository 类型中的方法 add(Iterable>) 不适用于参数 (ServiceLoader)”。

我希望能够将 Iterable 视为 Iterable>，但它本身似乎不起作用。将 ServiceLoader.load(Foo.class) 的结果转换为可以提供给 FooRepository.add() 的最干净的方法是什么？

Answer 1

如果您正在谈论 java.util。 ServiceLoader，那么它的 Javadoc 说：

提供者类通常不是整个提供者本身，而是一个代理，其中包含足够的信息来决定提供者是否能够满足特定请求以及可以在其上创建实际提供者的代码。要求。 [...] 此工具强制执行的唯一要求是提供程序类必须具有零参数构造函数，以便可以在加载期间实例化它们。

结合使用反射明确实例化提供程序类的方式，这告诉我使用泛型类型参数声明的提供程序类实际上将被实例化为原始类型。

因此，因为您传递的是 Class 类型的对象，而 Java 中无法构造 Class> 类型的对象。 code> —— 那么你得到的就是你所要求的，一个 Iterable，其中 Foo 是从创建的原始类型Foo。

不幸的是，我认为简单的答案是：那就不要这样做！要么使您的提供程序类成为泛型类型的具体子类，要么使您的提供程序类只是一个可以构造适当泛型类型的新对象的工厂。

老实说，我想不出任何好的理由来创建一个通用的服务提供者类——你会在哪里提供类型参数？我认为工厂机制是你最好的选择。

Answer 2

这是因为泛型类型仅用于编译时。它们在运行时被擦除（类型擦除）。 Foo 接口的泛型类型 T 在运行时将不再为人所知，因此 Repo 类的“add”方法不会让您进一步（一般）输入参数类型（不会让您拥有 Foo，因为它不能保证在方法内部您能够实际将该参数视为 F 类型的参数。只知道它的类型 它不会让您进一步输入它。

Foo，因为这是一个实际类型，但如果您将方法更改为void add(Iterable foos)，

Answer 3

这一切都归咎于 Java 的类型系统。你需要残酷的演员阵容。

将 Foo.class 转换为 Class>，或将 ServiceLoader 转换为 ServiceLoader ？>>。两者显然都是无害的。