很可能不仅需要对JVM进行实质性更改，还需要对类文件格式进行大量更改， 但是在VM上运行的语言将从中受益匪浅。
编辑： Java语言实际上支持某种泛型作为编译时功能，它会在字节码中添加一些强制转换，人们必须在之前手动添加。
在这些时候很容易理解不对JVM或类文件规范引入更改的决定，因为他们不想破坏向后兼容性，而Java是目前JVM唯一重要的语言。
虽然这个决定可能适用于Java语言，但它显着降低了其他语言选择如何在VM上实现泛型的自由度。
考虑到Sun / Oracle已经宣布让JVM成为替代语言更友好的地方，他们是否真的会做他们承诺的事情，或者认为他们认为“InvokeDynamic”的低成本添加就足够了？
答案 0 :(得分：4)
在我看来这不太可能。
将这些更改应用于Java语言简直太具有破坏性。与两种不同的泛型模型的语言和运行时向后兼容性将成为设计师的噩梦。
如果没有，Java推动对JVM的更改，很难看出Oracle如何/可以证明完成所需工作的合理性。
我看到的唯一可能性是：
Oracle决定开发一种Java的后继语言（不向后兼容），它可以更好地处理泛型，闭包和一大堆事务。这将是一个非常勇敢的商业决策，我认为甲骨文没有能力做到这一点。
许多其他人/公司聚在一起，分叉JVM规范和代码库。这也是一个勇敢的举动。
我认为Oracle不太可能为JVM提供重大改变，只是为了支持他们没有商业利益的语言。我们在这里谈论Oracle ......业务类型更加紧张控制工程类型可以做什么，而不是在垂死的太阳时代。 （嘿......我们可以在这里开始一个完整的Jack Vance主题： - ）