| 方法出现时,这个方法可以很快被采用。基于JVM的方法将在很长一段时间内保持不变,因为JVM常常会有一个很长的使用周期(作为参考:Java 1.3现在还在被许多公司所采用)。JVM真的会采用这种字节码,并且改进动态方法调用的速度吗?这也还有待观察。
另一个问题是官方对基于JVM的语言的支持和认可。目前,JRuby有两名开发人员在领着Sun的薪水。其中一位是Charles O. Nutter,他已经加入了Jython和Groovy的社区当中,这些努力是否会开始还有待于观察。考虑到微软有致力于IronPython、IronRuby、JavaScript以及动态VB支持等各种动态语言的紧密合作的开发团队,微软在这方面具有一定的优势。毕竟,DLR是一个不同团队合作的产品,这些团队在分享他们的经验并将这些经验融入一个通用的类库和知识库中,与之相反的是,基于JVM的开发团队经常不得不重复吸取重要的教训。
举例而言,JRuby的特色之一就是它的即时(Just In Time,JIT)编译器,这个编译器将在运行期将Ruby代码转化为Java字节码。问题在于:在当前版本中,这样的代码会使基于set_trace_func的调试器(这些调试器使用回调的方法来实现调试器功能)不能正常工作,因为代码不再调用这个回调。这意味着,JRuby的调试要受到这种方式的影响。而同样的问题肯定要在每种语言中得到处理和解决,因此,共享哪怕是这样的一小部分经验或者代码,都会帮助其他人节省时间和工作。
补充观点:微软的DLR还有待证明自己,目前集成了IronPython的DLR已经可以在网上下载到。IronRuby还没有发布,并且它的真实速度以及通用互操作能力还有待检验。比起。NET,Java仍然还有被认为是更加开放,并且能运行在更多平台上的优势。不过,Miguel de Icaza看起来确信,Mono在今年结束之前将能提供对Silverlight的支持。 上一页 [1] [2]
|