|By Rick Palkovic, October 2008|
The 2008 JVM Language Summit took place September 24 through 26, 2008, hosted by Sun Microsystems at its Santa Clara campus.
|Charles Nutter||The summit featured technical presentations about programming languages and the Java Virtual Machine, and featured language experts, OpenJDK engineers, and Java luminaries both as attendees and presenters. The summit was billed as a chance to help shape the future of programming languages on the JVM. About 70 people attended.
If you missed the summit, you also missed the social networking and fruitful discussions between formal talks. But slides and videos for many of the presentations are available through the links at the end of this article.
I spoke about the summit with one of its organizers, Charles Nutter. Nutter is best known as the JRuby guru at Sun. A Java developer since 1996, he started working on Ruby in the fall of 2004. He now works full-time as a core developer on JRuby.
Rick Palkovic: So, how did the big summit go? Did it meet your expectations?
Charles Nutter: It was great. We had a lot of the right people there, and a lot of great discussion came out of it.
RP: What were you hoping to get out of it?
CN: The goal was to bring together a lot of different language and JVM implementers and get them talking, to let everyone know who was working on what and give them the opportunity to help each other with the various challenges that they faced.
RP: Was the summit focused entirely on the JVM, or was there talk of "The Great Multi-Lingual Virtual Machine In The Sky"?
CN: There was talk of a Multi-Language Virtual Machine, mostly as an experiment — a test bed — that some of us at Sun are working on for multiple languages. And, it could prove very useful for VM research and language research going forward, for trying this stuff out, to see if it fits future versions of the JVM and the languages that will want to build on top of it.
RP: Were there any surprises?
CN: I was especially pleased that discussions between formal talks went so smoothly. People just naturally got into their own groups, stuck around after each day's presentations, and communicated easily.
The only real surprise for me was that it all went as well as we had hoped. It could have fallen apart logistically, but everything seemed to move along pretty smoothly.
John Rose, Brian Goetz, and I instigated the conference and covered some of the logistics. Penni Henry helped a lot with management. Brian and I work outside of California, which made handling details a bit of a challenge as the conference date approached. Only John and Penni were in the Bay Area during the planning of the event.Charles Nutter
RP: You're known as the JRuby guy at Sun. How high was the interest level in Ruby and JRuby?
CN: Ruby and JRuby still generate a lot of enthusiasm. More and more Ruby programmers are looking at JRuby as their Ruby projects mature — when they move into heavier loads, larger systems, more cores, more processors. Most significantly, as Ruby development branches out into larger enterprises where deployment on Java servers is important, JRuby is seen as the solution.
RP: Is the ability of JRuby to run Ruby programs on Java servers and to call into Java libraries the main reason for adoption?
CN: At this point, I would say that Java compatibility is the most obvious reason. All of those organizations out there with Java already in place can start using JRuby today.
A less obvious advantage to JRuby is that it may already be a better Ruby implementation. Certainly that's where it's headed — faster, better use of memory, better use of resources. Many Ruby programmers are starting to see these advantages.
RP: Are you seeing any resistance to JRuby from hard-core Rubyists?
CN: A little bit. I think the resistance is because of that evil "J for Java" connection. But when it comes to actually running Ruby, people do appreciate that we're doing a better job than the standard implementation.
So, people are beginning to understand that whether it's based on Java or the standard implementation, JRuby is better at handling resources, better at taking advantage of multi-core processors, and so on. This is the impetus for people to try JRuby, and to stay with it once they've tried it.
RP: What other languages caught your interest?
CN: It was interesting to hear more about Scala. I admit I haven't had much time to try it, and it still seems a bit academic to me. I'll need to spend some time playing with the language to see if it's something I really want to get into.
Another one that came up was Clojure. This one looks very interesting, from a Lisp-y standpoint [ it is in fact a Lisp dialect — RP ]. It is a very high-performance implementation, and it has an interesting perspective on making concurrency safer, more reliable, and better performing.
RP: What's the word on Fortress?
CN: The word on Fortress is 'Fortran.' I hadn't actually recognized the connection in the name before the conference, but Fortress is designed to replace Fortran as a high-performance language for the scientific community. Not being a mathematician or Fortran developer, Fortress has features not really targeted at me, so I've pretty much been out of the loop.
RP: Sounds like the conference had a little something for everybody.
CN: Yes, I think that everyone who attended got something out of it — and most got exactly what they were looking for.
RP: So, is this the first annual JVM Language Summit, or was it a one-shot event?
CN: Actually, John Pampuch [ Director, VM technology, Sun Client Software Group] came out and declared that we will do this again next year. John could sense that everyone there really wanted it to happen again, and it sounds like it will.
RP: Any parting thoughts about the whole experience?
CN: One thing I'd like the larger language developer community to know is that real steps are being taken to make the JVM a better home for multiple languages. And now is the best time ever — maybe the perfect time — to consider creating your own language, contributing to an existing language, and helping to influence the future direction of the JVM.