Day 1 of the JVM Language Summit
JVM Language Summit - Day 1
Day 1 of the JVM language summit in Santa Clara has come and gone. The agenda can be found at Agenda.
The highlight of day 1 for me was John Rose talking about invokedynamic. A lot of attendees really liked the talks about Fortress and multiple dispatch, but invokedynamic was the most relevant to me. And best of all a Sun employee said that invokedynamic would be part of Java 7. Now, that doesn't mean anything, but it is encouraging to hear that Sun is committed to getting it included in Java 7.
The surprise of the day for me was the presentation on Fan. I had not heard of fan prior to signing up for the event. It seems like it is still pretty immature, but it is interesting. The language is being created from the ground up to run on the JVM and CLR. They have spent most of their time making libraries that can be built on top of both platforms. The big problem is that you can't call out to the multitudes of libraries available on those platforms. This is a show stopper for now.
Stu's lightning talk started the best conversation of the day. The open sessions, or unconference or whatever term you prefer, were not nearly as successful at getting people talking about issues as Stu's presentation. The conversation focused on how libraries can be provided on the JVM in the best of breed language for that particular problem and just as importantly how the library can be used by other languages on the JVM. This second part is the part that there is no clear answer for right now. Clojure's collections and the regex library in JRuby were used as examples of libraries that could be shared by lots of languages implemented on the JVM.
Summary
- Hotspot - Just an intro to the event.
- invokedynamic - Read headius' blog if you'd like to know more.
- Maxine - An experimental VM. Not compliant yet. Has an API.
- Fan - new language to run on JVM and CLR.
- Groovy - Intro to Groovy
- Scala - Focused on one aspect of Scala
- Fortress - Fortran on the JVM with concurrency, lots of it. They came the most prepared to make recommendations to Sun of features that could be added to the JVM. The list contained things like continuations, value objects, etc.
- Multiple dispatch - Professor's implementation of how multiple dispatch could be done on the JVM quickly and without too much disruption.
3 Comments
Leave a comment
0 TrackBacks
Listed below are links to blogs that reference this entry: Day 1 of the JVM Language Summit.
TrackBack URL for this entry: http://www.nearinfinity.com/mt/mt-tb.cgi/411
Thanks for posting this, have been interested in getting the details on the conference. Re: Fortress, I have been wondering what their future plans out. My understanding was that they were targeting a JVM-bytecode compiler for this year, but that in the future they were considering other hosting options (perhaps a post-JVM VM?). Did you get a sense of whether they were trying to push for improvements for the JVM, or looking to build on top of something new.
Also interested if you have any sense of the status, plans, and practical goals for the Maxine VM.
Cheers!
Patrick
Patrick,
Fortress came the most prepared with their list of "would like to have" features for the JVM. I understand that they are still fairly early in the process of really having a usable product. It seems to me that they very well could target a post JVM VM, but I would imagine that it is more than a year off at least, based on what I heard. Their list of changes for the JVM was by far the most drastic and I can't imagine that they will all be implemented in the next five years if ever. They probably will find workarounds for several things, but not all. Value objects, for example, I think would be very difficult to work around. All that said, I did get the impression that their plans included the JVM.
Maxine VM seems to really be an experimental sandbox for new JVM features from what I can tell. I don't anticipate that it will ever really be released into the wild on its own as a production platform unless it had some breakthrough that was so significant that the JVM couldn't implement it for backwards compatibility reasons.
Bryan--
thanks for the addtional info.
Patrick