Closures in Java (as opposed to Clojure, which… nevermind)

Last time I worked with Java was before my Lisp days (or at least various attempts to get into Lisp), so I’m looking at it again now with a different context. So when I came across this use of an anonymous class in Effective Java (comments removed for brevity – bad practice shut up shut up):

static List<Integer> intArrayAsList(final int[] a) {
    if (a == null)
        throw new NullPointerException();

    return new AbstractList<Integer>() {
        public Integer get(int i) {
            return a[i];

        @Override public Integer set(int i, Integer val) {
            int oldVal = a[i];
            a[i] = val;
            return oldVal;

        public int size() {
            return a.length;

…my first thought was “waaaitaminute… Java has closures?

Now, it took a while for my memory of these things to come back, and a bit of searching to fill in the gaps… it turns out Java doesn’t quite do closures (it doesn’t work with non-final variables because it actually copies them behind the scenes), and at any rate there’s still the whole anonymous class mess instead of first-class functions (which I’ve always found annoying).

Then, it turns out that there’s a proposal to get first-class functions and lambda expressions in Java. And not from some random functional programming fanboy, but taken seriously by Sun and at one point planned for inclusion in Java 7 (it’s now deferred to Java 8).

All of this makes me wonder though… How does Clojure implement closures? Does it have some roundabout way of doing it that could mess up performance in opaque ways? Or is the JVM really that much more flexible than the Java language lets on? Or is Clojure a completely degenerate Lisp dialect?

Apparently I’ve got more reading to do.

Leave a Comment