> 2) Currently each JVM language has its own incompatible reinvention of closures.
Yeah, but as long as they expect Callables in the right place interop can be pretty easy with just interfaces. For instance, you can pass JRuby lambdas to Clojure functions just fine. Sure there's a duplication of effort, but it's not too bad for interop purposes.
Have you looked at the source code for that project? It doesn't use callables at all. the orig_commute function, the original commute method on class Ref, gets passed a monkey-patched ruby Proc object that implements the invoke method which takes one argument, a list, containing all of the original ruby arguments. Clojure then most likely calls invoke inside orig_commute through reflection. The end result: a bunch of hackery specific to Ruby and Clojure, something JVM-level closures would help eliminate.
Again, you cannot pass a ruby function expecting arguments to Clojure! What your link shows is that you can, however, send monkey-patched versions of ruby functions that implement clojure-specific calling conventions to clojure. :)
I noticed in the test code linked to by the article that the closed over variables are all declared final. I'm not sure if that's just because of the early stage of implementation or if that's actually going to be a requirement. If so that seems unfortunate and maybe an impediment to interoperability.
Look, I'm an independent programmer and I can pretty much chose everything about what I program in. Still, when it comes to completely new, and not very mission critical projects, I go for Clojure (still a bit green and unsure on my lipspy feet). When it comes to existing projects and serious stuff, Java is and Java will stay. Way too much code invested in it. I can and I do try to evolve my style and tools, but the one single thing that's always been in my way was a complete lack of higher order functions (anonymous classes are a verbose joke). So yeah, I'm ecstatic :)
Even if you do your project in Scala it is tremendously likely that you will be doing so on the back of a ton of Java infrastructure and you will have to interact with it intimately at times. If Java itself gets closures then (in time) we will get support for them in all the base Java APIs and 3rd party libraries and that will make them significantly more pleasant to use for everyone that is building on the JVM.