编辑：我改变了一个例子来获得这个想法：
喜欢
<Integer or Float>
...无需创建公共接口并为Integer和Float创建子类来实现它
如果没有，这样的事情可能更有意义并且有用
<E extends Number> <E = (Integer|Float)>
如果？是一个通配符为什么我们不应该允许限制某些类型？
答案 0 :(得分：9)
这是不可能的，我几乎看不到任何价值。您使用泛型来限制类型，例如在收藏中。使用or运算符，您可以尽可能多地了解类型，在这种情况下，您知道两种类型的最具体的超类型Object。那么为什么不使用Object？
假设：
List<E extends String or Number> list = //...
list.get(0)的类型是什么？是String 还是 Number？但是你不能拥有这种类型的变量。它不能是String，也不能是Number - 它只能是...... Object。
更新：因为您将相关示例更改为：
<Integer or Float>
你为什么不这么说：
<Number>
？请注意，Number包含的方法可让您轻松提取floatValue()和intValue()。你真的需要确切的类型吗？
请注意，您可以使用and运算符：
<E extends Serializable & Closeable>
这很有道理 - 您可以使用E类型的变量，其中需要Serializable或Closeable。换句话说，E必须同时延伸Serializable和Closeable。另见：Java Generics Wildcarding With Multiple Classes。
答案 1 :(得分：4)
在非常极端的情况下（没有AutoCloseable的Java 7之前版本），我也希望能够做到这一点。例如。
<E extends Connection or Statement or ResultSet>
无论实际类型是什么，这都可以让我拨打E.close()。换句话说，E将包含所有提供类型的“API交集”。在这种情况下，它将包含close()以及java.sql.Wrapper和java.lang.Object中的所有方法。
但不幸的是，你做不到。相反，使用方法重载，例如
void close(Connection c);
void close(Statement s);
void close(ResultSet r);
或普通的instanceof
if (obj instanceof Connection) {
((Connection) obj).close();
}
else if (obj instanceof Statement) { //...
或者修复你的设计，因为你可能不需要交叉任意类型的API
答案 2 :(得分：1)
我没有看到它的实际用途......但无论如何，我相信你最接近它的是为可能的实现扩展通用接口。