显式指定通配符的上限时是否有区别？

从字面上看你最初的问题，和之间是否“有明显的区别”，答案一定是，它们不是等价的。Generic<?>Generic<? extends BaseType>

JLS §4.5.1 明确规定：

通配符等效于无界通配符 。? extends Object?

因此，它仅等效于 is ，但即使这样，它们也是等效的，但仍然具有显着的差异，例如，在没有发生捕获转换的地方：? extends BaseTypeBaseTypeObject

boolean b1 = new Object() instanceof Supplier<?>; // valid code
boolean b2 = new Object() instanceof Supplier<? extends Object>; // invalid

Supplier<?>[] array1; // valid declaration
Supplier<? extends Object>[] array1; // invalid

值得注意的是，与第一种直觉相反，给定一个声明，指定与等效的一样有效。通配符的边界是有效的，只要它们不能证明与类型参数的边界不同，并且由于边界始终是 的子类型，因此始终有效。Generic<T extends BaseType>Generic<? extends Object>Generic<?>Object? extends Object

因此，如果我们有一个类型声明，例如

interface NumberSupplier<N extends Number> extends Supplier<N> {}

我们可以写

NumberSupplier<? extends Object> s1;
NumberSupplier<? extends Serializable> s2;
NumberSupplier<? extends BigInteger> s3;

甚至

NumberSupplier<? extends CharSequence> s4;

^{我们甚至可以在没有实际类型的情况下实现它，使用（）-> null扩展Number和CharSequence。}

但不是

NumberSupplier<? extends String> s5;

作为 和 可证明是不同的。StringNumber

当涉及到赋值时，我们可以使用问题中已经引用的子类型规则来得出结论，它是 的子类型，因为包含（并且还包含 ），因为 是 和 的子类型，但正如您正确指出的那样，这不适用于类型参数不是通配符的参数化类型。NumberSupplier<? extends BigInteger>NumberSupplier<? extends Object>? extends BigInteger? extends Object? extends NumberBigIntegerObjectNumber

因此，如果我们有类似 、 或 的声明，并且想要根据 §4.5.1 的包含规则来推理任何一个是否是其他子类型的子类型，则唯一可以适用的规则是，当类型参数是相同的类型 （） 时，但是，我们不需要子类型规则，因为这样，所有这些列表类型都是相同的类型：List<NumberSupplier<?>>List<NumberSupplier<? extends Object>>List<NumberSupplier<? extends Number>>T <= T

如果两个引用类型具有相同的二进制名称 （§13.1），并且它们的类型参数（如果有）相同，则它们是相同的编译时类型，并以递归方式应用此定义。

包含规则仍然有用，例如，它允许得出的结论是 的子类型，因为对于第一个类型参数适用，并且第二个类型参数的类型参数被通配符特定的包含规则所覆盖。Map<String,? extends Number>Map<String,Integer>String <= String

所以剩下的问题是，哪个规则允许我们得出结论，，或是相同的类型，以便，或可以相互分配。NumberSupplier<?>NumberSupplier<? extends Object>NumberSupplier<? extends Number>List<NumberSupplier<?>>List<NumberSupplier<? extends Object>>List<NumberSupplier<? extends Number>>

它似乎不是捕获转换，因为捕获转换意味着计算有效边界，但也为每个通配符创建一个“新鲜类型变量”，这绝对是不同的类型。但是没有其他规则涵盖通配符兼容性。或者我没有找到它。尝试将规范与的实际行为相匹配，得到了一些非常有趣的结果：javac

鉴于

interface MySupplier<S extends CharSequence&Appendable> extends Supplier<S> {}

以下声明显然是有效的：

List<MySupplier<? extends CharSequence>> list1 = Collections.emptyList();
List<MySupplier<? extends Appendable>>   list2 = Collections.emptyList();

由于在这两种情况下，通配符的绑定作为匹配绑定之一是多余的，因此我们可能会猜测它们实际上是相同的类型。S

但认为他们不是javac

list1 = list2; // compiler error
list2 = list1; // dito

尽管任何涉及捕获转换的操作确实得出兼容类型的结论，例如

list1.set(0, list2.get(0)); // no problem
list2.set(0, list1.get(0)); // no problem

并且间接执行被拒绝的分配工作：

List<MySupplier<?>> list3;
list3 = list1;
list2 = list3; // no problem
// or
list3 = list2;
list1 = list3; // again no problem

但在这里，并不等同于：?? extends Object

List<MySupplier<? extends Object>> list4;
list4 = list1; // compiler error
list2 = list4; // dito
// or
list4 = list2; // dito
list1 = list4; // dito

但同样，间接分配是有效的。

list4 = list3 = list1; // works
list1 = list3 = list4; // works
list4 = list3 = list2; // works
list2 = list3 = list4; // works

因此，无论规则在这里使用什么，它都不是可传递的，这排除了子类型关系，以及一般的“它是同一类型”规则。看起来，这确实是未指定的，并且直接影响实现。而且，按照当前实现，无边界是特殊的，允许使用任何其他通配符类型都不可能的赋值链。javac?