运行在JVM之上的语言已经存在了很长的时间,几乎与 JVM 拥有同样悠久的历史。比较早的例子就是 Beanshell 或 Jython 语言。Java 泛型的概念起源于 Java 的超集,如 Pizza 和 GJ。不同于 Sun 公司,微软拥有.NET 框架,将.NET 虚拟机作为其通用语言运行时(Common Language Runtime,CLR),把它打造成多种语言的支持平台。从开始的 C#、VB.NET、Cobol 和 EiffelSharp,到之后的 F#、 IronPython ,和其它更多的语言比如 Delphi ,都能在它之上运行。
许多运行在JVM 之上的语言获得了小范围的认可,主要专注于像Jython 或Beanshell 这样的项目,除了一小圈技术狂热者之外,很少有其他的人知道。
微软已经先行一步拥有了动态语言运行时(Dynamic Language Runtime, DLR), 并且为(动态)语言应用于 CLR 提供了更多通用的基础设施,这是一直以来在 JVM 所独缺的。JVM 语言的实现者不得不自食其力找到每一个技巧或者解决方案,这将是一个对于大多数语言实现都会重复出现的过程。相关的例子参见文章编写没有PermGen 内存泄漏的代码。
目前,这一切因为JRuby 的Charles Nutter 与其他JVM 语言团队(如Jython、Groovy 等等)的沟通而发生着变化。首先是创建 JVM 语言的 Google Group ,在这里 JVM 语言实现者可以拥有一个共同论坛,来讨论 JVM 语言实现方面的问题或解决方案。 仅其自身并没有什么特别的报道价值——但是,这个小组的第一次协作已经一枪打响了。Jython 的开发团队提供了Jython 的包缓存机制的代码并使其对于所有开发者都可使用。为了能让人们有一个公用的地方存放这样的代码, Java 语言运行时(JLR)项目就应运而生了,并且项目的源码仓库中已经纳入了上面说的缓存机制的代码。
未来的开发计划将会在 JVM 相关语言的邮件列表上进行讨论,不过我们已经可以从 DLR 目前提供的机制中借鉴到今后可能的发展方向。比方说,字节码生成工具就是目前所需的,工具将包含生成元数据的逻辑,就像在生成的字节码中包含源代码语言行数确切位置的调试信息。尽管这并不是一项高精尖科研活动,但是所有的语言实现都不得不从头开始解决这个问题。其它的通用代码则将会包含与 Java 语言的集成,例如查找重载的方法或是具有varargs 方法的逻辑实现。
这不仅是一项可以从实现者肩头卸下的基础设施工作,同时,还会有一个团队来指出哪个字节码对于多种语言特征来说表现最为出色,例如动态方法调用、闭包或者Continuations。因为这些语言拥有不同的语义,所以到底有多少特性可以被共用或改进并放进已有的代码库中,还有待观察。尽管如此,可运行的代码或者概况代码实例还是非常有用的,除此之外,已经证明的可以在当前JVM 后端(即由字节码生成本地机器码的即时编译器)进行良好地处理的字节码序列也很有帮助。
评论