Type Erasure造成的限制还有不少，如果您是一个C#程序员，可能难以相信以下的Java代码都是不合法的：
public static void myMethod(Object item) {
if (item instanceof E) { // Compiler error
...
}
E item2 = new E(); // Compiler error
E[] iArray = new E[10]; // Compiler error
}
}
由于JVM不提供对泛型的支持，因此对于JVM上支持泛型的语言，如Scala，这方面的压力就完全落在编译器身上了。而且，由于这些语言以JVM 为底，Type Erasure会影响JVM平台上几乎所有语言。以Scala为例，它的模式匹配语法可以用来判断一个变量的类型：
case x:String => println("Value is a String")
case x:HashMap[String, Int] => println("Value is HashMap[String, Int]")
case _ => println("Value is not a String or HashMap[String, Int]")
}
猜猜看，如果value变量是个HashMap[Int, Object]类型的对象，上面的代码会输出什么结果呢?如果是C#或是F#这样运行在.NET平台上的语言，最终输出的一定是“Value is not ...”。只可惜，由于JVM的Type Erasure特性，以上代码输出的却是“Value is HashMap[String, Int]”。这是因为在运行期间JVM并不包含泛型的类型信息，HashMap[K, V]即是HashMap，无论HashMap[String, Int]还是HashMap[Int, Object]都是HashMap，JVM无法判断不同泛型类型的集合之间有什么区别。不过还好，Scala编译器遇到这种情况会发出警告，程序员可以了解这些代码可能会出现的“误会”。
因此，为什么有IKVM.NET这样的项目可以将Java语言编译成.NET程序集(也可以将Java的jar包转化成.NET程序集)，却没有项目将C#编译到JVM上(或是将C#程序集转化为jar包)。这是因为，JVM不足以支撑C#语言所需要的所有特性。而从运行时的中间代码角度来说，JVM Bytecode的能力也是.NET IL的子集——又有什么办法可以将超集塞入它的子集呢?
此外，如CLR的值类型可能也很难直接落实在JVM上，这也是JVM上运行C#的又一阻碍。由于这些因素存在，我想如F#这样的.NET语言也几乎不可能出现在JVM上了。
当然，如果真要在JVM上实现完整的C#也并非不可以。只要在JVM上进行一层封装(例如还是就叫做CLR，CLR Language Runtime)，一定可以满足C#的全部要求。但是这个代价太高，即使实现了这点可能也没什么实际意义。
(凡署名“IT168”的稿件均为本站原创，请在转载时注明出处及作者。非上述媒体稿件均系转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。转载者自负版权等法律责任。)
查看原文
