Java JVM会被扩展以处理泛型吗？

你觉得怎么样？JVM会得到泛型的支持吗

很可能这不仅需要对JVM进行重大更改，还需要对类文件格式进行重大更改， 但是在虚拟机上运行的语言将从中受益匪浅

编辑：Java语言实际上支持某种泛型作为编译时特性，它向字节码中添加了一些强制转换，以前人们必须手动添加

在这些时候，不向JVM或类文件规范引入更改的决定是可以理解的，因为他们不想破坏向后兼容性，Java是目前JVM唯一重要的语言

虽然这个决定可能适合Java语言，但它大大减少了其他语言选择如何在VM上实现泛型的自由度

---

考虑到Sun/Oracle已经宣布让JVM成为另一种语言更友好的地方，他们会做他们承诺或考虑的事情吗？他们认为“调用动态”的低成本添加就足够了。p> 如果将这些更改应用到Java语言中，那么会造成太大的破坏。语言和运行时向后兼容两种不同的泛型模型将是设计者的噩梦

如果没有Java驱动对JVM的更改，很难看出Oracle如何/能够证明所需的工作是合理的

我看到的唯一可能性是：

• Oracle决定开发Java的后继语言（不向后兼容），该语言可以更好地处理泛型、闭包和一大堆事情。这将是一个非常勇敢的商业决策，我认为甲骨文没有能力做到这一点

• 一群其他人/公司聚在一起，讨论JVM规范和代码库。这也是一个勇敢的举动

---

我认为Oracle不可能仅仅为了支持他们不感兴趣的语言而对JVM进行重大更改。我们在这里谈论的是甲骨文。。。在那里，业务类型对工程类型要做什么的控制比在垂死的阳光下要严格得多。（嘿……我们可以在这里开始一个完整的杰克·万斯主题：-）

你的意思是删除类型擦除并直接使用泛型类型吗？“但运行在VM上的语言将从中受益匪浅”确切程度如何？我的物理CPU不支持泛型，它们在那里似乎工作得很好。@Stephen p：好吧，我希望你永远不必将已擦除的双倍列表的性能与已擦除的双倍列表进行比较具体化的仿制药。删除的列表将对您访问的每个元素执行运行时检查，将取消对元素的装箱，可能会对其进行更改并将其重新装箱到列表中。具体化列表知道，它只包含字节，然后可以不装箱存储：没有运行时检查，没有装箱。可能的重复