In the standard Java SE API's, the designer have typically chosen a one-letter identifier that is related to the meaning / purpose of the type parameter:
Iterator<T> - javadoc where T means type. Other examples are ListIterator<T>, Iterable<T>, Comparable<T>, Comparator<T> and Class<T>.Collection<E> - javadoc where E means element. Various other collection classes and interfaces use E.Map<K,V> - javadoc where K means key, and V means value.Enum<E> - javadoc where E means enum.
These tend to disprove your assertion that there is a general (widespread) T, U, V convention, at least for Java. Obviously, in the absence of specific guidance, some individual designers will adopt what is an obvious extension to the guidance to use T (see links below) but that would appear to be a result of individual choice. (And the groups probably would have treated this as not worthy of discussion.)
(If you want to do an exhaustive search, visit each of the javadocs index A-Z pages, and search them for all occurrences of "<".)
I'm hoping for a link to an old discussion/commit/mailing list where the convention was first discussed.
In the case of Java, I doubt that you will find this. The discussions and mailing lists would have been private, and the Java source code was still closed when generics were added to the language, along with all of the examples above.
@Lew Bloch has found a few example (see below) of T, U, V in the APIs added to Java SE in Java 8 as part of the streams support. I assert that this does not prove a general pattern, and the large number of preexisting classes disprove it.
Other negative evidence of a general pattern or convention:
- http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-type-variables which doesn't mention
U and V.
- http://docs.oracle.com/javase/tutorial/java/generics/types.html which recommends use of
S, U and V as 2nd, 3rd and 4th type parameters. (Not U, V, W ...)
Finally, the JLS (JLS 6.1) recommends:
Type variable names should be pithy (single character if possible) yet evocative, and should not include lower case letters. This makes it easy to distinguish type parameters from ordinary classes and interfaces.
Container types should use the name E for their element type. Maps should use K for the type of their keys and V for the type of their values. The name X should be used for arbitrary exception types. We use T for type, whenever there is not anything more specific about the type to distinguish it. (This is often the case in generic methods.)
If there are multiple type parameters that denote arbitrary types, one should use letters that neighbor T in the alphabet, such as S. Alternately, it is acceptable to use numeric subscripts (e.g., T1, T2) to distinguish among the different type variables. In such cases, all the variables with the same prefix should be subscripted.
In short, U and V are not explicitly mentioned in the JLS, but others alternatives are.
