Jython was one of the first successful dynamic language projects on the JVM. The project faded in the later years because of the lack of development and allowed other projects (languages) to take all the headlines. Now Sunemployed Frank Wierzbicki, a lead Jython developer, so it seems that after JRuby they will put their resources in to Jython as well. This will certainly revive Jython and is a good news for all developers wanting to mix Java and Python code.

It’s been an interesting period for “dynamic languages on JVM” technologies. Here’s a couple of news and interesting articles:

• Grails 1.0 has been released – with support for GORM, REST services and so on
• Speaking of GORM (Grails Object-Relational Mapping), you can find a good article on the technology here
• JRuby 1.1 RC2 has been released and as Charles says
  

  If you haven’t looked at JRuby, now’s the time to do so.

There’s an interesting discussion in community these days on issues of dealing with large code bases and how dynamic languages can help Java projects in that manner. I summarized some of these thoughts (with links to original posts here)

Groovy 1.5 has been released. It’s practically 1.1 release, but due to volume of changes introduced by the release it has been re-branded. Some of the most important features of the new Groovy version are Java 5 features, such as:

• Annotations
• Enums
• Static Imports
• Generics

but there are a lot more new features.

The official release note can be found here.
You can also find an excellent introductory article by Guillaume Laforge on InfoQ

OpenJDK community has a new project, Multi-Language VM (or just mlvm). It is announced by John Rose, from Sun, on the announcement list. The focus of the project will be to prototype JVM features beneficial for dynamic languages and remove “pain points” that current dynamic language developers have with standard JVM.

Here’s the snippet from the announcement:

This project will be open for prototyping
JVM features aimed at efficiently supporting
languages other than Java.

The emphasis will be on completing the existing
bytecode and execution architecture with general
purpose extensions, as opposed to a new feature
for just one language, or adjoining an unrelated
new execution model.

The emphasis will also be on work which removes
“pain points” already observed by implementors
of successful or influential languages, as opposed
to more speculative work on unproven features or
niche languages.

It is definitely a step in the right direction for making Java a true multi-language development platform.

Graeme Rocher explains new meta-programming API improvements added to Groovy 1.1.

Groovy 1.1 beta 3 has been released a few days ago, bringing emplacements like Java5 enums, new shortcut replacement for ternary operator, Groovy shell and Swing console emplacements and more. Full announcement can be found here and you can download it here.

It seems like today is dynamic JVM languages release day. First, JRuby 1.0.1version is released and plans for 1.1 version are out. Next, Jython project releases version 2.2 a long awaited update implementing Python 2.2 and 2.3. There is certainly a lot of activity in dynamic JVM languages community.

Steve Yegge wrote a blog post about his work on porting the Rails framework to JavaScript (Rhino). It is definitely an interesting project and I would like to see it open-sourced. Here are a few interesting quotes from the text:

* On Jython

Jython seemed like the obvious choice at first, except that it hasn’t had much momentum since around 2001. It used to be arguably the best non-Java JVM language around; Jim Hugunin did an amazing job with it. Unfortunately it’s had almost no love in the past six years, and it’s now lagging the Python spec by several major versions (2.2 vs. soon-to-be 2.6).

* On Rhino

The Rhino code base reads almost like C code: it avoids allocation and does as much as possible with jump tables to avoid the overhead of virtual method lookups. It has two code paths: a bytecode interpreter that runs in a tight loop, and an optimizing Java bytecode compiler that turns many expensive-ish JavaScript property lookups into Java local or instance-variable lookups. It’s a pretty serious piece of software.

* On open-sourcing the framework

We’ve talked about open-sourcing our “Rhino on Rails”, but so far it’s been no more than idle chit-chat. For one thing, work on the framework plays second fiddle to work on the actual application, so it’s progressing slowly, mostly as 20% work. For another, we’re dependent on various other Google infrastructure components that are themselves in the process of being open-sourced, although I don’t know if any of them have been announced yet.

JRuby 1.0 has been released. Here are some notes made by Charles Nutterabout future plans:

Once you have a working Ruby implementation, what next? I believe we’ve shown that the correct way to approach Ruby is to get it right first. The next step is making it run as well as possible.

…

The second item for any working implementation would have to be platform integration. Our platform is Java (and of course we’ve cheated a bit here by doing additional work to make Java integration really useful and usable), so integration involves making Ruby a better citizen of the Java platform.

…

And then what? Well, there are many options, all very attractive. I personally would like to see time spent implementing potential Ruby 1.9/2.0 features, to provide a second testbed where people can try those features out.