java - 在java中声明双重使用通配符

Question

我在为方法的输出声明完全通用类型时遇到问题。情况是这样的:

class A<S,T>{
public Callback<B<S,T>,C<S,T>> method();
}

在我的代码中我有其中之一；

A<String, ?> instance;

但是，当我调用

result = instance.method()

让编译器高兴的唯一方法是声明

Callback<?, ?> result = instance.method()

但我真的很想更具体地说明我的泛型并声明

Callback<B<String, ?>,C<String, ?>> result = instance.method()

然而，由于每个通配符都是独立的，编译器会提示这是不正确的，声明它不能从

Callback<B<String,capture#3-of ?>,C<String,capture#3-of ?>>

有什么方法可以正确声明这种情况？

仅供引用，A、B 和 C 类来自外部库。我试图将我的实例声明为

A<String, Object>

但这也是我无法控制的第四类方法的结果:

class D<T>{
public A<T, ?> getObject();
}

D<String> start = new D<String>();
A<String, ?> = start.getObject();
...

Answer 1

这确实是一个尴尬的情况，这是通配符捕获的局限性和来自 D.getObject 的不太理想的返回类型的结果。 .

有一些解决方法，但没有一个很好。第一种是简单地进行未经检查的转换:

@SuppressWarnings("unchecked") //it's okay for the two captures not to match
Callback<B<String, ?>, C<String, ?>> result =
        (Callback<B<String, ?>, C<String, ?>>)instance.method();

编辑:一些编译器将(更正确地)要求通过 Callback<?, ?> 进行双重转换。 :

@SuppressWarnings("unchecked") //it's okay for the two captures not to match
Callback<B<String, ?>, C<String, ?>> result =
        (Callback<B<String, ?>, C<String, ?>>)(Callback<?, ?>)instance.method();

您还可以使用辅助方法 - 这是通配符捕获问题的常见解决方案:

static <T> void helper(A<String, T> a) {

    Callback<B<String, T>, C<String, T>> result = a.method();

    //logic
}

...

helper(instance);

更新:

事实上，您可以将这两种方法结合起来，至少将丑陋隔离到一个辅助方法中:

static <S, T> Callback<B<S, ?>, C<S, ?>> disentangleCallback(
        Callback<B<S, T>, C<S, T>> callback
) {
    @SuppressWarnings("unchecked") //it's okay for the two captures not to match
    final Callback<B<S, ?>, C<S, ?>> withWidenedTypes =
            (Callback<B<S, ?>, C<S, ?>>)(Callback<?, ?>)callback;
    return withWidenedTypes;
}

然后像这样使用它:

Callback<B<String, ?>, C<String, ?>> result =
        disentangleCallback(instance.method());

或者一个类似的方法，只需要一个 A<S, T>并返回 Callback<B<S, ?>, C<S, ?>>调用method本身，然后类型转换。

---

另一个想法:如果 A 的第二个类型参数总是是一个未知数，删除它并扩大 method 的返回类型可能更容易:

class A<S> {
    public Callback<B<S, ?>, C<S, ?>> method() { ... }
}

我意识到这将是一个不幸的让步，但如果 T 是有道理的从来没有真正有用过。