I attended about half of the
the JVM Language Summit, from
Wednesday through Friday at Sun’s Santa Clara campus. I’m not really an
expert on the deep
nuances of JVM constructs like call sites and permgen and classloaders and so
on, but still, I’m sorry I missed some. There were 70 or so people
there, mostly way smarter than me. Herewith impressions and
pictures.
[Update: See also write-ups from
Ted
Leung,
Cliff
Click,
and
John Rose.]
The official part of the proceedings. Here we see Eugene Kuleshov talking about ASM. Programming-language-celebrity spotters might want to blow this one up and scan the faces. At the near corner is organizer Brian Goetz.
Big Picture · Lots of interesting languages these days are choosing to host themselves on the JVM. Most will go nowhere. But, after the summit, my best guess is that some will become commercially important. First, at least one of JRuby and Jython, based simply on improving the deployment options and library repertoire for existing code. Plus, I’d be astounded if at least one of Scala or Fan or Clojure or Groovy doesn’t hit the big time; they’re just too well-crafted and compelling not to find a niche.
The real action, over beers after dinner. Either Rich Hickey (left) is beating up Charles Nutter (barely visible, right) about atomic invalidation of call sites, or Ola Bini (in hat) is beating up Rich about S-expressions. At the center, Frank Wierzbicki.
JCP Anyone? · Item: a small breakout group of really senior people is chewing over issues of language interoperability, which is hard even when you’re all running on the JVM. A few good ideas and lines of attack emerge (I’ll let the real experts blog those). Then someone says “I know, let’s form a working group and do a JSR!” whereupon the room dissolves in raucous laughter.
Item: Mark Reinhold, who sits at the center of Sun’s Java engineering group, gets a loud chorus of approval when he says “We’ll get invokedynamic into Java 7”. Speaking of JSRs...
Interesting times.
Interoperability · Here’s the thing: all of these JVM-ized languages can call into existing Java APIs; not a surprise since that’s a big piece of the value proposition. Some are better than others; Groovy (and it seems Clojure) make the biggest deal about it.
But how about talking to each other? And how about Java calling Ruby or Clojure or Scala code? This is not an abstract issue, at least for me. I’ve been ripping the protocol-validation pieces of the Ape out from the generic-AtomPub-client pieces, and when I’m done I’ll have a bunch of Ruby code that would be super-useful for anyone building AtomPub client-ware.
Furthermore, it doesn’t do any Ruby metaprogramming voodoo or even have blocks in the API, just old-fashioned objects and methods. Plus it’s got code for handling all sorts of icky authentication corner-cases. Yeah, it’s in Ruby so it won’t be as fast as Java, but who cares, it’ll be stalled waiting for HTTP 99.5% of the time anyhow.
So, why should someone have to write this again in Java?
I’m not saying interop is easy. One hopeful sign is the work that Attila Szegedi has been doing on a Meta-Object Protocol. Mind you, Attila’s preso included the following Javalicious code fragment:
MetaobjectProtocolFactory mop =
standardMetaobjectProtocol.createStandardMetaobjectProtocolFactory();Clojure · I’ve mentioned Clojure a couple of times now, and while I previously knew it existed, I’d thought “Yeah, Lisp on the JVM, yawn, whatever”. Well, either Rich Hickey is one of the great tech salesman or Clojure is just overwhelmingly cool. They’ve added what feels to me just the right little bit of syntax (gasp) sugar. Plus some exceptionally-palatable functional-programming machinery.
Rich Hickey, the Clojure guy.
Do I really believe that a Lisp (any Lisp) will grab a big chunk of the ecosystem? Probably not. Sigh. But it still looks like a fine piece of work. It’s not just me; you should have seen the buzz roll around Twitter.
PHP · IBM’s Rob Nicholson, whose work I’ve on Project Zero I’ve discussed previously, was there. No surprises, but I think this little sound-bite bears repeating: “Conventional wisdom is that there are about 7 million Java, and about 3 million PHP, developers.”
I remain skeptical that PHP will benefit as much as other languages might from the Java platform, but good on ’em for trying.
Oh, and by the way, the summit wiki is a PHP app (snicker).
JVM and CLR/DLR · A couple of Microsofties were there pitching in and met with no hostility I could detect. They’re not building languages on the JVM, obviously, but they are facing damn similar problems. Mads Torgersen got a laugh by saying “The JVM is a millstone around your necks, just like the CLR is around ours”.
The technology point that most amused we was around generics. I yield to no-one in my passionate hatred of Java generics. In particular, I was never convinced of the virtues of Type Erasure. Well it turns out that the .NET’s “real” generics with no erasure cause all sorts of heartburn for DLR dynlang guys. Cloud, meet lining.
John Rose, Da Vinci Machine guy, and JRubyist Charles Nutter. Tons of other people are helping push the state of the art, but John and Charlie are kind of at the pointy end of the stick, trying to make Invokedynamic into a useful reality.
Soundbite · Per Bothner: “Scala is perhaps a little too complicated for normal people”. Ya think?
Thanks Brian · Most of the heavy lifting in pulling this together was by Brian Goetz, who has done the developer community and Sun a major service. Hey Brian, do it again next year, OK?
Comment feed for ongoing:
From: Hervé (Sep 27 2008, at 04:40)
It seems that the JVM language summit was really interesting !! I have a question about what your remark about about DLR and Generics. You write that "Well it turns out that the .NET’s “real” generics with no erasure cause all sorts of heartburn for DLR dynlang guys". What kind of problems do they have ?
[link]
From: Charles Oliver Nutter (Sep 28 2008, at 07:17)
I can answer the question about generics.
The problem that dynlangs on .NET run into with "real" generics is that they have to represent and handle them somehow. So if it's reasonably to say that one major mismatch between a dynamic language and the underlying platform is the difference in the typing systems, real generics aggravate this. IronRuby and IronPython have both had to invent new syntax for representing all those generics, and have also had to deal with calling generic APIs, presenting appropriate generic-typed objects, selecting generic-typed methods, and so on. Real generics permeates the type system and makes the mismatch between the dynlang and the platform even more pronounced.
Contrast that to the JVM, where a List is a List. We lose some of the compile-time checking that generics provides, but interacting with Java's type system from Ruby or Python is much easier, since we don't additionally have to consume and produce parameterized types. Erasure becomes a huge win here, since the "faux" generics on the JVM do nothing to hurt its fundamentally dynamic nature.
[link]
From: Curt Hagenlocher (Sep 30 2008, at 08:50)
I think that "all sorts of heartburn for DLR dynlang guys" is a bit of an overstatement. Sure, it's something where the semantics of (say) Ruby aren't entirely compatible with those of the platform but it's not really all that fundamentally different than dealing with overloaded method names.
[link]
From: Rob Nicholson (Oct 02 2008, at 08:37)
Hi Tim. Thanks for mentioning PHP. I wonder why you think that PHP wont gain so much from running on the JVM? We are already seeing lots of benefits combining the really rather good open source PHP applications together with Java libraries and Java programmers. For example, PHP does not have particularly good support for reading and writing Microsoft excel and word format files but Java has Apache POI. Similarly there is better PDF support available in Java than there is in PHP.
Cheers,
Rob.
[link]
From: Attila Szegedi (Oct 08 2008, at 07:03)
Well, that monster of the expression is actually meant to be
MetaobjectProtocol mop = StandardMetaobjectProtocolFactory.createStandardMetaobjectProtocol();
which is still quite a mouthful. It's just my distaste for using abbreviations in my identifier showing through, which admittedly ain't always a healthy habit to have.
Fortunately I didn't name any core java classes, otherwise we might have
java.net.UniformResourceLocator too :-)
[link]