在标准Java SE API中，设计人员通常选择一个与类型参数的含义/目的有关的单字母标识符：
Iterator<T>
- 的Javadoc其中T
装置键入。其他例子是ListIterator<T>
，Iterable<T>
，Comparable<T>
，Comparator<T>
和Class<T>
。Collection<E>
- 的Javadoc其中E
装置元件。使用其他各种收集类和接口E
。Map<K,V>
- 的javadoc哪里K
手段键，V
手段的价值。Enum<E>
- 的javadoc哪里E
手段枚举。
这些往往反驳你的断言，有一个一般的（普遍）
T，
U，
V约定，至少为Java。显然，在没有具体指导的情况下，一些个体设计师将采用明显的指导扩展
T（请参阅下面的链接），但这似乎是个体选择的结果。（这些团体可能会认为这不值得讨论。）
（如果要进行详尽搜索，请访问每个javadocs索引AZ页，然后在其中搜索所有出现的“ <”。）
我希望链接到最初讨论该约定的旧讨论/提交/邮件列表。
对于Java，我怀疑您会发现这一点。讨论和邮件列表将是私有的，并且在将泛型以及上述所有示例添加到Java语言后，Java源代码仍然关闭。
@Lew布洛赫已经发现了几个例子（见下文）的
T，
U，
V在加入到Java SE中的Java
8作为流支持的一部分的API。我断言这并不能证明是一种通用模式，并且大量先前存在的类都不能证明这一点。
一般模式或惯例的其他负面证据：
- http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-type-variables中没有提及
U
和V
。 - http://docs.oracle.com/javase/tutorial/java/generics/types.html其中建议使用的
S
，U
并V
作为第二，第三和第四类型参数。（不U
，V
，W
…）
最后，JLS（JLS
6.1）建议：
类型变量名称应精简（如果可能，应使用单个字符），但应令人回味，并且不应包含小写字母。这使得区分类型参数与普通类和接口变得容易。
容器类型应使用名称
E作为其元素类型。映射应使用K其键V的类型和其值的类型。该名称X应用于任意异常类型。T每当类型没有更具体的区别时，我们都会使用type。（在通用方法中通常是这种情况。）如果有多个表示任意类型的类型参数， 则应使用
T在字母表中相邻的字母，例如S。或者，
可以使用数字下标（例如T1，T2）来区分不同类型的变量。在这种情况下，所有带相同前缀的变量都应下标。
总之，
U而
V没有明确的提到JLS，但其他的替代品。
