MS的Fusion组成员Junfeng Zhang在其中文版本BLog上发表了一篇文章，CLR Loader and Java Class Loader Compared，简要地比较了CLR Loader和Java Class Loader。得出的结论是Java Class Loader在CLR中并不存在等价的东西，而且他在分析过程中详细地评述了Java Class Loader 的弱点，非常精彩，呵呵，感谢 Zhang 的努力 :)
不过就我个人观点来看，CLR和JVM只是通过两个不同的思路实现了相同的概念，各有千秋。
Java Class Loader与CLR Loader相比，实际上最大的缺陷就是对类型和版本的控制粒度不足，如此一来就造成Zhang所说的类型载入上的共享、安全和版本控制问题。这个问题一方面因为JVM设计目标就和CLR有所不同；另一方面可能因为Sun没有经历过MS的Dll Hell，处理这种问题经验不足和重视程度不够，呵呵
从设计目标和指导思想来说，JVM的结构可以归结于两个S：Simple and Small。毕竟JVM最初是为嵌入家电系统设计的，各种资源都非常有限，而对不同来源不同版本类型的side by side运行，可以说基本上没有什么需求。分析过Java Class和CLR Metadata格式的朋友就会发现，两者结构上的复杂度可以说相差几个数量级，呵呵。而这种Simple and Small的设计思路，可以说是Java早期成功的最大助力，但也随着Java的飞速发展成为其硬伤之一。
与此同时，JVM实现结构的简单也促使Java在设计上肯下功夫，通过设计上的复杂性和灵活性来弥补实现上的简单带来的缺陷。例如 Zhang 所说JVM Class Loader的很多问题，除了不同Class Loader之间类型共享外，其实都可以通过定制Class Loader来实现，而且我记得已经有类似的解决方案，只是并没有归纳进标准中去。而类型共享和安全方面的一些问题，就我的理解，JVM中Class Loader实际上有点象一个为类型和安全定制的轻量级AppDomain，是一个独立的隔离域。因此并不能完全将两个Class Loader的类型之间的问题，等同于一个AppDomain的不同类型之间的问题来比较看待。
而对于CLR来说，功能点一级的实现可以说比较完美了，长期以来对Dll Hell和类型共享的强烈需求，促使MS从COM到CLR一直在完善版本和类型控制系统。但是结构上感觉还是有些松散，缺乏一个类似Class Loader的组件，将分散在多个基础类上的功能聚合到一起。CLR把太多的细节隐藏在底层实现中，甚至过于依赖对实现的控制，秉承了MS作为操作系统厂商一贯的风格，呵呵。
这也体现了Java和MS两大阵营的风格不同：前者注重于开放性的设计；后者注重于实用性的实现。
如果Java能将CLR的版本和签名吸收进去，CLR多提供一些面向应用而非面向实现的工具类，这个世界将会美好得多 :P
btw: 技术方面的观点近期补上 :)
