Java Language Runtime (JLR) project created
- Share
-
- |
Read later
My Reading List
Languages running on the JVM have been around for ages, nearly as long as the JVM. Old examples are Beanshell or Jython. Java Generics came out of Java supersets like Pizza and GJ. With .NET, Microsoft, unlike Sun, marketed the .NET VM as a Common Language Runtime (CLR), designed to support multiple languages. The initial C#, VB.NET, Cobol and EiffelSharp were followed by F#, IronPython, and many more such as Delphi.
The many languages for the JVM received little publicity, mostly focussed on projects like Jython or Beanshell, with the others little known outside of a small circle of enthusiasts.
With the Dynamic Language Runtime (DLR), Microsoft has gone further and provides even more common infrastructure for (Dynamic) Languages targetting the CLR. This is something that has been sorely missing on the JVM. JVM language implementers had to find out every trick and workaround or solution on their own, a process repeated for most language implementations. Examples are creating code on the fly without leaking memory into the PermGen.
This is now changing due to JRuby's Charles Nutter talking to other JVM language teams, such as Jython, Groovy and others. One step was the creation of the JVM languages Google Group, where JVM language implementers could have a common forum to discuss common problems or solutions for them.
This by itself wouldn't be newsworthy; however, the the first collaboration has now come out of it. The Jython team provided the code for Jython's package caching mechanism and made it generally available. To have a common place for code like this, the Java Language Runtime (JLR) project was created, and it already has the caching code available in it's source repository.
Future developments will be discussed on the JVM languages list, but some possible directions can be found by glancing at what the DLR provides. Tools for bytecode generation, for instance, are needed. This includes logic to generate metadata like debug information that maps from the source language's line numbers to the right locations in the generated bytecode. While this might not be rocket science, it's not a problem that every language implementation should have to tackle from scratch. Other common code would be Java integration, such as an implementation of the logic for looking up overloaded methods or methods with varargs.
It's not just basic infrastructure work that can be taken off of the implementors shoulders. It would also allow a group to figure out which bytecode works best for various language features such as dynamic method invocations, closures, or maybe continuations. The languages have different semantics, so it remains to be seen just how much can be shared or retrofitted into existing code bases. Still, working code or profiled code samples are useful, as well as bytecode sequences that are shown to be handled well by current JVM backends (the Just In Time Compilers that generate native code from bytecode).
2 comments
The many languages for the JVM received little publicity, mostly focussed on projects like Jython or Beanshell, with the others little known outside of a small circle of enthusiasts.
With the Dynamic Language Runtime (DLR), Microsoft has gone further and provides even more common infrastructure for (Dynamic) Languages targetting the CLR. This is something that has been sorely missing on the JVM. JVM language implementers had to find out every trick and workaround or solution on their own, a process repeated for most language implementations. Examples are creating code on the fly without leaking memory into the PermGen.
This is now changing due to JRuby's Charles Nutter talking to other JVM language teams, such as Jython, Groovy and others. One step was the creation of the JVM languages Google Group, where JVM language implementers could have a common forum to discuss common problems or solutions for them.
This by itself wouldn't be newsworthy; however, the the first collaboration has now come out of it. The Jython team provided the code for Jython's package caching mechanism and made it generally available. To have a common place for code like this, the Java Language Runtime (JLR) project was created, and it already has the caching code available in it's source repository.
Future developments will be discussed on the JVM languages list, but some possible directions can be found by glancing at what the DLR provides. Tools for bytecode generation, for instance, are needed. This includes logic to generate metadata like debug information that maps from the source language's line numbers to the right locations in the generated bytecode. While this might not be rocket science, it's not a problem that every language implementation should have to tackle from scratch. Other common code would be Java integration, such as an implementation of the logic for looking up overloaded methods or methods with varargs.
It's not just basic infrastructure work that can be taken off of the implementors shoulders. It would also allow a group to figure out which bytecode works best for various language features such as dynamic method invocations, closures, or maybe continuations. The languages have different semantics, so it remains to be seen just how much can be shared or retrofitted into existing code bases. Still, working code or profiled code samples are useful, as well as bytecode sequences that are shown to be handled well by current JVM backends (the Just In Time Compilers that generate native code from bytecode).
Community comments
Just to clarify
by
Charles Nutter
Posted
It will be interesting...
by
Joseph Then
Posted
Just to clarify
by
Charles Nutter
The project's official name is "JVM Language Runtime", rather than "Java Language Runtime", and it's intended to target *all* varieties of languages for the JVM. And yes, the name is a direct nod to the DLR (Dynamic Language Runtime) for the CLR, which is both a good idea and a good name. But we'd like to be all-inclusive, providing tools and frameworks for all varieties of languages. And rather than starting right away building a common base all languges must conform to, we'll generalize existing solutions to common JVM language implementation challenges, drawing from the large existing base of already-implemented languages for the JVM.
It will be interesting...
by
Joseph Then
It will be interesting how MS is going to intergrate that with their own ASP.NET stuff.
---
Open Source
---
Open Source
Educational Content
Large-Scale Continuous Testing in the Cloud
John Penix May 24, 2013
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think