#418 No Closures for Java - Should We Care?

brian Thu 18 Dec 2008

Sounds like closures are out for Java 7. I have two minds about closures in Java. On one hand adding closures is a pretty big addition to the Java complexity tax. And of course the argument goes (which I am all for) is that alternative JVM languages like Fan, Clojure, Scala, Groovy, JRuby, etc already provide closures so we should just leave Java alone. But the problem is that all of those alternative languages do have some notion of first class functions and all of those languages require Java as their lingua franca. So until Java has some notion of first class function types, then all the alternate JVM languages are missing a standard Java representation for a key aspect of their type system. I think this is a bad thing for JVM language interop.

The latest versions of Fan now map types like Bool, Int, and Str directly to the expected Java types. So we are getting pretty close to where canonical Fan code could be exposed as a pretty normal Java API. The big missing piece is how do we expose function types? It doesn't make sense to generate an interface for every possible function type signature. But using a single generic Java class to represent all function types and arities seems pretty lame too.

So my personal opinion is that having a standard notion of a function type in Java would go a long way towards making Java the "assembly language" of future JVM languages like Fan.

djspiewak Fri 19 Dec 2008

Actually, I don't believe that any of the closures proposals included the notion of a first-class function at the JVM level. In fact, AFAIK the BGGA spec compiles down to code which is remarkably similar to what Scala or Groovy (and I'm assuming Fan) would generate for the same construct. Don't get me wrong, I want first-class functions in the JVM as much as the next guy, but the cancellation of this particular Java 7 enhancement isn't going to affect alternative languages like Fan even a little bit.

helium Fri 19 Dec 2008

Th problem is the design of the standard libraries.

brian Fri 19 Dec 2008

Actually, I don't believe that any of the closures proposals included the notion of a first-class function

Yeah I saw that some of them didn't really include first class function types - that is a shame (edit: although BGGA does have function types right?). I actually haven't really dug into any of the proposals deeply myself. I guess that was sort of my unspoken point - that what Java really needs are function types (closures being one implementation). But I think however closures are implemented, they definitely help with consuming the APIs of alternate languages. So I would clarify to say that function types help with general interop, but closures would specifically help with Java to alternate lang interop.

The problem is the design of the standard libraries.

I agree completely. Everyone likes to complain about Java the language and talk about how great it is to reuse Java libraries. But to me the Java libraries are the problem, not the language so much. In fact I would say Fan is more about library design than language design - I thought about how I wanted the libraries to work and designed a language around that. In the end though having closures is a key tool in the ability to design libraries.

JohnDG Fri 19 Dec 2008

I think every pod should have a giant static class called Functions with interfaces for every function type that appears in the signature of any method.

This way, Java interop will be trivial. At the top:

import static [podname].Functions.*;

where you need the function:

fanFunction(new XXX() { public Y doZ() { } });

brian Fri 19 Dec 2008

I think every pod should have a giant static class called Functions with interfaces for every function type that appears in the signature of any method.

That would certainly work - and I guess you could Javadoc it so that people could figure out what type to use. But I think your interface names would end up something like Func1, Func2, Func3 or else some weird name mangling.

JohnDG Sat 20 Dec 2008

I would name them the same as the called function. Maybe Class_Callee. This is guaranteed to be unique and known by the user at the time he needs to invoke the method.

Login or Signup to reply.