InfoQ

News

Java Language Runtime (JLR) project created

Posted by Werner Schuster on Jul 31, 2007

Community
Java,
Ruby
Topics
JRuby ,
Dynamic Languages ,
Reuse
Tags
JRuby ,
DLR ,
CLR ,
Languages
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).
Just to clarify by Charles Nutter Posted Jul 31, 2007 1:14 PM
It will be interesting... by Joseph Then Posted Nov 26, 2007 8:40 AM
  1. Back to top

    Just to clarify

    Jul 31, 2007 1:14 PM 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.

  2. Back to top

    It will be interesting...

    Nov 26, 2007 8:40 AM by Joseph Then

    It will be interesting how MS is going to intergrate that with their own ASP.NET stuff.
    ---
    Open Source

Educational Content

Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development

Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).

Are You a Software Architect?

The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?

Agile – A Way of Life and Pragmatic Use of Authority

The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.

Getting Started with Grails, Second Edition

"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?

Using ITIL V3 as a Foundation for SOA Governance

Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.

Adrian Colyer on AspectJ, tc Server and dm Server

SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.

Adam Wiggins on Heroku

Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.

SOA as an Architectural Pattern: Best Practices in Software Architecture

For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.