我为什么要关心Java没有泛型泛型？

这是我最近在一次采访中提出的一个问题，候选人希望将其添加到Java语言中。人们通常认为Java没有通用化泛滥的痛苦，但是当Java 泛化后，候选人实际上并不能告诉我他在那里可以实现的目标。

显然，由于Java中允许使用原始类型（以及不安全的检查），因此有可能破坏泛型并以List<Integer>实际包含Strings的a结尾。如果类型信息得到证实，这显然变得不可能。但是肯定不止于此！

人们可以发布他们真正想做的事的示例吗？我的意思是，显然您可以List在运行时获取a的类型-但是您将如何处理？

public <T> void foo(List<T> l) {
   if (l.getGenericType() == Integer.class) {
       //yeah baby! err, what now?

编辑：对此的快速更新，因为答案似乎主要是担心需要将a Class作为参数传递（例如EnumSet.noneOf(TimeUnit.class)）。我一直在寻找一些不可能做到的东西。例如：

List<?> l1 = api.gimmeAList();
List<?> l2 = api.gimmeAnotherList();

if (l1.getGenericType().isAssignableFrom(l2.getGenericType())) {
    l1.addAll(l2); //why on earth would I be doing this anyway?

从我几次遇到这种“需求”开始，它最终可以归结为这种构造：

public class Foo<T> {

    private T t;

    public Foo() {
        this.t = new T(); // Help?
    }

}

假设T具有默认构造函数，则此方法在C＃中有效。您甚至可以通过获取运行时类型，typeof(T)并通过获取构造函数Type.GetConstructor()。

常见的Java解决方案是传递Class<T>as参数。

public class Foo<T> {

    private T t;

    public Foo(Class<T> cls) throws Exception {
        this.t = cls.newInstance();
    }

}

（它不一定需要作为构造函数参数传递，因为方法参数也可以，上面仅是一个示例，try-catch为简便起见也省略了）

对于所有其他泛型类型构造，可以在反射的帮助下轻松地解决实际类型。下面的问答阐明了用例和可能性：

• 获取java.util.List的通用类型
• 如何在运行时获取泛型？
• 获取抽象超类上泛型类型参数的实际类型

最让我困扰的是无法利用多种泛型类型的多重调度。以下是不可能的，并且在许多情况下这将是最佳解决方案：

public void my_method(List<String> input) { ... }
public void my_method(List<Integer> input) { ... }

想到类型安全。如果不使用泛型，则向下转换为参数化类型将始终是不安全的：

List<String> myFriends = new ArrayList();
myFriends.add("Alice");
getSession().put("friends", myFriends);
// later, elsewhere
List<Friend> myFriends = (List<Friend>) getSession().get("friends");
myFriends.add(new Friend("Bob")); // works like a charm!
// and so...
List<String> myFriends = (List<String>) getSession().get("friends");
for (String friend : myFriends) print(friend); // ClassCastException, wtf!? 

同样，抽象的泄漏将更少 -至少是那些可能对有关其类型参数的运行时信息感兴趣的抽象。今天，如果您需要有关一种通用参数类型的运行时信息，则也必须传递它Class。这样，您的外部接口取决于您的实现（是否对参数使用RTTI）。

您将能够在代码中创建通用数组。

public <T> static void DoStuff() {
    T[] myArray = new T[42]; // No can do
}

这是一个古老的问题，有很多答案，但是我认为现有的答案是不可能的。

“修饰的”仅表示真实的，通常仅表示与类型擦除相反的类型。

与Java泛型相关的大问题：

• 这种可怕的拳击要求以及原语和引用类型之间的断开。这与验证或类型擦除没有直接关系。C＃/ Scala修复了此问题。
• 没有自我类型。因此，JavaFX 8必须删除“构建器”。绝对与类型擦除无关。Scala修复了此问题，不确定C＃。
• 没有声明方类型差异。C＃4.0 / Scala拥有此功能。绝对与类型擦除无关。
• 不能超载void method(List<A> l)和method(List<B> l)。这是由于类型擦除引起的，但是非常小。
• 不支持运行时类型反射。这是类型擦除的核心。如果您喜欢在编译时验证并证明您的程序逻辑尽可能多的超高级编译器，则应尽可能少地使用反射，并且这种类型的擦除不会打扰您。如果您喜欢更多的修补程序，脚本，动态类型编程，并且不太在乎编译器是否证明了您的逻辑尽可能正确，那么您需要更好的反映，并且修复类型擦除很重要。

通过序列化，序列化将更加简单。我们想要的是

deserialize(thingy, List<Integer>.class);

我们要做的是

deserialize(thing, new TypeReference<List<Integer>>(){});

看起来丑陋，时髦。

在某些情况下，说出类似

public <T> void doThings(List<T> thingy) {
    if (T instanceof Q)
      doCrazyness();
  }

这些东西不会经常被咬，但是它们在发生时也会被咬。

我对Java Geneircs的了解非常有限，除了已经提到的其他答案以外，《Java Generics and Collections》一书还介绍了一种情况。 Maurice Naftalin和Philip Walder，其中泛化的泛型很有用。

由于类型不可更改，因此不可能有参数化异常。

例如，以下形式的声明无效。

class ParametericException<T> extends Exception // compile error

这是因为catch子句检查引发的异常是否与给定类型匹配。此检查与实例测试执行的检查相同，并且由于类型不可更改，因此上述语句形式无效。

如果以上代码有效，则可以按以下方式进行异常处理：

try {
     throw new ParametericException<Integer>(42);
} catch (ParametericException<Integer> e) { // compile error
  ...
}

该书还提到，如果Java泛型的定义类似于C ++模板的定义（扩展）方式，则可能会导致更有效的实现，因为这会提供更多的优化机会。但是除了提供更多解释之外，其他任何有经验的人的解释（指针）都将是有帮助的。

如果对数组进行了泛化，它们可能会对泛型起到更好的作用。

我有一个包装，它将一个jdbc结果集表示为一个迭代器，（这意味着我可以通过依赖注入轻松地对源自数据库的操作进行单元测试）。

API看起来像 Iterator<T> T是某种类型，只能在构造函数中使用字符串来构造。然后，迭代器查看从sql查询返回的字符串，然后尝试将其与类型T的构造函数进行匹配。

按照当前实现泛型的方式，我还必须传入将要从结果集中创建的对象的类。如果我正确理解，如果泛型得到了修正，我可以只调用T.getClass（）获得其构造函数，然后不必强制转换Class.newInstance（）的结果，这将变得更加整洁。

基本上，我认为它使编写API（而不是仅编写应用程序）变得更容易，因为您可以从对象中推断出更多内容，从而需要更少的配置...直到我意识到注释的含义，我才意识到看到它们被用于spring或xstream之类的东西，而不是大量的config。

一件好事是避免对原始（值）类型进行装箱。这在某种程度上与其他人提出的阵列抱怨有关，在内存使用受到限制的情况下，它实际上可能会产生很大的影响。

在编写框架时，还存在几种类型的问题，其中能够反映出参数化类型很重要。当然，可以通过在运行时传递类对象来解决此问题，但这会掩盖API并给框架用户带来额外负担。

这并不是说您会取得非凡的成就。它将更容易理解。对于初学者来说，类型擦除似乎很困难，并且最终需要对编译器的工作方式有所了解。

我的观点是，泛型只是一个额外的功能，可以节省大量的冗余转换。

遗漏所有答案的事情一直困扰着我，因为这些类型被删除了，您不能两次继承通用接口。当您要制作细粒度的接口时，这可能是个问题。

    public interface Service<KEY,VALUE> {
           VALUE get(KEY key);
    }

    public class PersonService implements Service<Long, Person>,
        Service<String, Person> //Can not do!!

这是今天引起我注意的一个问题：未经验证，如果您编写一个接受通用项目的变量列表的方法，则调用方可以认为它们是类型安全的，但无意中传入了任何旧的粗体，并破坏了您的方法。

似乎不太可能发生？...当然，直到...您将Class用作数据类型。此时，您的呼叫者会很高兴向您发送许多Class对象，但是一个简单的错字便会向您发送不遵守T的Class对象，以及发生灾难。

（注意：我可能在这里犯了一个错误，但是在“泛型varargs”周围进行搜索时，以上内容似乎正是您所期望的。使这成为实际问题的是我使用了Class，我认为-调用者似乎不太小心:(）

例如，我使用的范例将Class对象用作地图中的键（比简单的地图更为复杂-但从概念上讲就是这样）。

例如，这在Java泛型中很有效（简单的示例）：

public <T extends Component> Set<UUID> getEntitiesPossessingComponent( Class<T> componentType)
    {
        // find the entities that are mapped (somehow) from that class. Very type-safe
    }

例如，在Java Generics中没有经过验证的情况下，该对象接受任何“ Class”对象。而且这只是先前代码的微小扩展：

public <T extends Component> Set<UUID> getEntitiesPossessingComponents( Class<T>... componentType )
    {
        // find the entities that are mapped (somehow) to ALL of those classes
    }

上述方法必须在单个项目中写出数千次-因此，人为错误的可能性很高。调试错误被证明“不好玩”。我目前正在尝试寻找替代方案，但抱有很大希望。