有趣的是，接口
java.lang.reflect.WildcardType看起来支持通配符arg的上限和下限。每个都可以包含多个边界
Type[] getUpperBounds();Type[] getLowerBounds();
这超出了语言所允许的范围。源代码中有一个隐藏的注释
// one or many? Up to language spec; currently only one, but this API// allows for generalization.
该界面的作者似乎认为这是偶然的限制。
您问题的罐头答案是，泛型本身已经太复杂了；增加更多的复杂性可能被证明是最后一根稻草。
为了使通配符具有多个上限，必须通读规范并确保整个系统仍然有效。
我知道的一个麻烦是类型推断。当前的推理规则根本无法处理交集类型。没有减少约束的规则
A&B << C。如果我们减少到
A<<C or A<<B
当前任何推理引擎都必须进行大修，以允许这种分歧。但是真正的严重问题是，这允许有多种解决方案，但是没有理由偏爱一个解决方案。
但是，推断对于类型安全性不是必不可少的。在这种情况下，我们可以简单地拒绝推断，并要求程序员显式填充类型参数。因此，推理的难度并不是反对干涉类型的有力依据。
