当Java最后降生的时候，它可以说是其他言语的退化版。不仅因为Java很复杂，而且这一退化的言语还是一个可以运转第三方硬件字节码的虚拟机。它还是渣滓收集站，从而令存储管理和内核转储（core dump）不再是麻烦。当然还有它相当全面的类库。虽然它没有什么惊世的新性能，但它把许多言语的优点基于一身。
原本Java是一个复杂独一的言语，但是Sun在长期运营Java的过程中出现了很多错误，比如将言语与runtime合用一个名字，从而使得用户在辨认JVM言语项目如Jython、JRuby时难以从思想上隔离Java。最主要的是这样对runtime很不公，因为Java Virtual Machine (JVM)有很多本人的独特之处。
缺陷
没有一种技术是完满的，JVM也不例外。假设你工作在一个没有Java言语配置的设备上，JVM便无用武之地。JVM为其他言语提供了基础，但JVM最后不是为这个理念设计的。比如我们作为分配对象来维护我们的堆栈时，通常我们会直接操作实时堆栈并添加我们维护所需的其他字段，除此之外再没有控制堆栈的更好的办法。
还有，当我们创立一个Ruby Fixnum时也很麻烦，我们把这些值用一个Java对象包装。Ruby的C implementation不过只是传递tagged ints，因为没有包装他们就不会符合各种列表，所以Java 基元（Java primitives）也不会切割它。
特地说一下：JVM的启动时间也挺长。
那些为JVM编写高性能代码的开发者会觉得经常被JVM的black box特性所折磨，一旦你加载你的字节码，你就觉得像是摇动老虎机的游戏手柄一样忐忑，不知道后果如何，black box就是意味着不可知。
优点：
Hotspot
对于初学者来说，虽然Hotspot有些神秘，但是性能方面它的确很棒，因为动态建模（dynamic profiling）是优良性能的捷径。HotSpot从运转使用中采样数据，从而可以优化代码，进而失掉良好性能。它相当于以模仿人工的办法停止优化。在程序运转的开端，Java代码仍然解释执行，但HotSpot引擎开端停止采样(Profiling)。HotSpot引擎可以集中精神来对HotSpot代码停止深度优化，从而使这部分代码的执行愈加迅捷。因此当Hotspot优化时，它为优化设立了一层维护来确保优化的基本原理无效；但当这层维护失效时，优化就会很慢。
这里是Hotspot在使用中的一个演示：
在图表中我们运转了一个Mandelbrot Generator很屡次，然后测绘它每次生成的时间。你会看到JRuby 1.4.0明显比Ruby 1.8.7以及1.
记忆枕9.2preview2表现更好。假设只看JRuby的起点，会发现比1.8.7慢，但当Hotspot运转后时间曲线迅速下降。
