无法在泛型类型T 上调用静态方法是type erasure 的副作用。类型擦除意味着泛型类型信息在编译后从 Java 字节码中删除或擦除。执行此过程是为了保持使用 Java 5（其中引入了泛型）之前的代码编写的向后兼容性。最初，我们在 Java 5 及更高版本中使用的许多泛型类型都是简单的类。例如，List 只是一个包含 Object 实例的普通类，需要显式转换以确保类型安全：
List myList = new List();
myList.add(new Foo());
Foo foo = (Foo) myList.get(0);
在 Java 5 中引入泛型后，其中许多类都升级为泛型类。例如，List 现在变成了List<T>，其中T 是列表中元素的类型。这允许编译器执行静态（编译时）类型检查，并消除了执行显式转换的需要。例如，上面的 sn-p 使用泛型简化为以下内容：
List<Foo> myList = new List<Foo>();
myList.add(new Foo());
Foo foo = myList.get(0);
这种通用方法有两个主要好处：(1) 消除了繁琐和不守规矩的强制转换；(2) 编译器可以在编译时确保我们不会混合类型或执行不安全的操作。例如，以下内容是非法的，并且会在编译过程中导致错误：
List<Foo> myList = new List<Foo>();
myList.add(new Bar()); // Illegal: cannot use Bar where Foo is expected
尽管泛型对类型安全有很大帮助，但将它们包含在 Java 中可能会破坏现有代码。例如，在没有任何泛型类型信息的情况下创建 List 对象应该仍然有效（这称为将其用作原始类型）。因此，编译后的泛型 Java 代码仍必须等同于非泛型代码。换句话说，泛型的引入不应影响编译器生成的字节码，因为这会破坏现有的非泛型代码。
因此，决定只在编译时和之前处理泛型。这意味着编译器使用泛型类型信息来确保类型安全，但是一旦 Java 源代码被编译，这个泛型类型信息就会被移除。如果我们查看您问题中方法的生成字节码，则可以验证这一点。例如，假设我们将该方法放在一个名为 Parser 的类中，并将该方法简化为：
public class Parser {
public <T extends ParsableDTO<T>> List<T> getParsableDTOs(String table, Class<T> clazz) {
T dto = null;
List<T> list = new ArrayList<>();
list.add(dto);
return list;
}
}
如果我们编译这个类并使用javap -c Parser.class检查它的字节码，我们会看到以下内容：
Compiled from "Parser.java"
public class var.Parser {
public var.Parser();
Code:
0: aload_0
1: invokespecial #8 // Method java/lang/Object."<init>":()V
4: return
public <T extends var.ParsableDTO<T>> java.util.List<T> getParsableDTOs(java.lang.String, java.lang.Class<T>);
Code:
0: aconst_null
1: astore_3
2: new #18 // class java/util/ArrayList
5: dup
6: invokespecial #20 // Method java/util/ArrayList."<init>":()V
9: astore 4
11: aload 4
13: aload_3
14: invokeinterface #21, 2 // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
19: pop
20: aload 4
22: areturn
}
14: invokeinterface #21, 2 行表示我们使用Object 参数在List 上调用了add，即使我们的源代码中参数的实际类型是T。由于泛型无法影响编译器生成的字节码，因此编译器将泛型类型替换为Object（这使得泛型类型为Tnon-reifiable），然后，如果需要，执行转换回对象的预期类型.例如，如果我们编译如下：
public class Parser {
public void doSomething() {
List<Foo> foos = new ArrayList<>();
foos.add(new Foo());
Foo myFoo = foos.get(0);
}
}
我们得到以下字节码：
public class var.Parser {
public var.Parser();
Code:
0: aload_0
1: invokespecial #8 // Method java/lang/Object."<init>":()V
4: return
public void doSomething();
Code:
0: new #15 // class java/util/ArrayList
3: dup
4: invokespecial #17 // Method java/util/ArrayList."<init>":()V
7: astore_1
8: aload_1
9: new #18 // class var/Foo
12: dup
13: invokespecial #20 // Method Foo."<init>":()V
16: invokeinterface #21, 2 // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
21: pop
22: aload_1
23: iconst_0
24: invokeinterface #27, 2 // InterfaceMethod java/util/List.get:(I)Ljava/lang/Object;
29: checkcast #18 // class Foo
32: astore_2
33: return
}
29: checkcast #18 行显示编译器添加了一条指令来检查我们从List（使用get(0)）收到的Object 是否可以转换为Foo。换句话说，我们从List 收到的Object 实际上是运行时的Foo。
那么这个因素如何影响您的问题？在 Java 中进行诸如 T.parse(rs) 之类的调用是无效的，因为编译器无法在运行时知道在哪个类上调用静态方法 parse，因为泛型类型信息在运行时会丢失。这也限制了我们创建T（即new T();）类型的对象。
这个难题是如此普遍，以至于它实际上可以在 Java 库本身中找到。例如，每个Collection 对象都有两种方法将Collection 转换为数组：Object[] toArray() 和<T> T[] toArray(T[] a)。后者允许客户端提供预期类型的数组。这在运行时为Collection 提供了足够的类型信息，以创建并返回预期（相同）类型T 的数组。例如，如果我们查看 AbstractCollection 的 JDK 9 源代码
public <T> T[] toArray(T[] a) {
// ...
T[] r = a.length >= size ? a :
(T[])java.lang.reflect.Array
.newInstance(a.getClass().getComponentType(), size);
// ...
}
我们看到该方法能够使用反射创建T 类型的新数组，但这需要使用对象a。本质上，提供了a，以便该方法可以在运行时确定T 的实际类型（询问对象a，“你是什么类型？”）。如果我们不能提供T[] 参数，则必须使用Object[] toArray() 方法，该方法只能创建Object[]（同样来自AbstractCollection 源代码）：
public Object[] toArray() {
Object[] r = new Object[size()];
// ...
}
toArray(T[]) 使用的解决方案适合您的情况，但有一些非常重要的差异使其成为糟糕的解决方案。在toArray(T[]) 的情况下使用反射是可以接受的，因为创建数组是Java 中的标准化过程（因为数组不是用户定义的类，而是标准化的类，很像String）。因此，构造过程（例如要提供哪些参数）是先验已知的并且是标准化的。在对一个类型调用静态方法的情况下，我们不知道静态方法实际上是否会出现在所提供的类型中（即没有等效的实现接口来确保静态方法出现方法）。
相反，最常见的约定是提供一个函数，该函数可用于将请求的参数（在本例中为 ResultSet）映射到 T 对象。例如，getParsableDTOs 方法的签名将变为：
public <T extends ParsableDTO<T>> List<T> getParsableDTOs(String table, Function<ResultSet, T> mapper) {
/* ... */
}
mapper 参数只是一个Function<ResultSet, T>，这意味着它使用ResultSet 并产生T。这是最通用的方式，因为可以使用任何接受ResultSet 对象并产生T 对象的Function。我们也可以为此创建一个特定的接口：
@FunctionalInterface
public interface RowMapper<T> {
public T mapRow(ResultSet rs);
}
并将方法签名更改为以下内容：
public <T extends ParsableDTO<T>> List<T> getParsableDTOs(String table, RowMapper<T> mapper) {
/* ... */
}
因此，获取您的代码并用映射器函数替换非法调用（对T 的静态调用），我们最终得到：
public <T extends ParsableDTO<T>> List<T> getParsableDTOs(String table, RowMapper<T> mapper) {
List<T> rtn_lst = new ArrayList<T>();
ResultSet rs = doQueryWithReturn(StringQueryComposer
.createLikeSelectQuery(table, null, null, null, true));
try {
while(rs.next()) {
rtn_lst.add(mapper.mapRow(rs)); // <--- Map value using our mapper function
}
rs.close();
} catch (SQLException e) {
System.err.println("Can't parse DTO from "
+ table + " at " + dateformat.format(new Date()));
System.err.println("\nError on " + e.getClass().getName()
+ ": " + e.getMessage());
e.printStackTrace();
}
return rtn_lst;
}
此外，因为我们使用@FunctionalInterface 作为getParsableDTOs 的参数，我们可以使用lambda 函数将ResultSet 映射到T，如下所示：
Parser parser = new Parser();
parser.getParsableDTOs("FOO_TABLE", rs -> { return new Foo(); });