Java Language Runtime (JLR) project created

Posted by Werner Schuster on Jul 31, 2007

Sections

Development,

Architecture & Design

Topics

Java ,

Reuse ,

Dynamic Languages ,

Ruby ,

JRuby

Tags

Languages ,

CLR ,

JRuby ,

DLR

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).

1. Back to top

   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.

   Reply

2. Back to top

   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

   Reply

• Older >