Programming question

[Asher]

You, obviously.

Kuci, Java does not have closures. Period.

Sun announced Java 7 would finally support Closures but then they pulled it from the Java 7 roadmap and tentatively put it on the Java 8 roadmap.

You are simply wrong here. A simple google will tell you all you need to know.

[Asher]

This is the proposed syntax for Closures that was cut from Java 7:

http://java.dzone.com/news/closures-coming-java-7

// function expressions
#(int i, String s) {
  System.println.out(s);
  return i + s.length();
}

// function expressions
#(int i, String s) (i + s.length())

// function types
#int(int, String)

[Asher]

And if you really understood how Java works, you'd realize why anonymous inner classes do not constitute closures.

The reason is simple: they do not actually close on the surrounding scope. It copies the surrounding scope.

There's another hack to get around this: use the "final" keyword on any variable used in the inner class.

But this doesn't work in all cases either; specifically, it doesn't work with immutable reference types.

The reason why closures aren't in Java is it's far more than just syntactic sugar or something simple to add at the language level -- it requires some foundational changes to the JVM.

[Kuciwalker]

import java.math.*;
import java.util.*;

public class AsherIsWrong {

    public static Comparator getComparator(final int x) {
        return new Comparator {
            // who cares about being consistent with equals
            public int compare(String s1, String s2) {
                return (s1.hashCode() % x) - (s2.hashCode() % x);
            }
        }
    }
    
    public static void main(String[] args) {
        Arrays.sort(args, getComparator(42));
        for (String s : args) System.out.println(s);
        
        Arrays.sort(args, getComparator(13));
        for (String s : args) System.out.println(s);        
    }

}

[Asher]

I hope you're joking...

[Kuciwalker]

I'm perfectly aware of the Java 7 closures; I've been keeping an eye on the proposals. They are just a massive syntactic upgrade from current closures, and IIRC they also maintain the final requirement.

And if you really understood how Java works, you'd realize why anonymous inner classes do not constitute closures.

The reason is simple: they do not actually close on the surrounding scope. It copies the surrounding scope.

There's another hack to get around this: use the "final" keyword on any variable used in the inner class.

But this doesn't work in all cases either; specifically, it doesn't work with immutable reference types.

The reason why closures aren't in Java is it's far more than just syntactic sugar or something simple to add at the language level -- it requires some foundational changes to the JVM.

Holy ****, did you even read what I wrote? They are closed over final variables in scope. You can easily get the full expressive power of closures with a trivial wrapper, map, or one-element list, if you really need it.

[Kuciwalker]

http://en.wikipedia.org/wiki/Closure_(computer_science)

In computer science, a closure is a first-class function with free variables that are bound in the lexical environment. Such a function is said to be "closed over" its free variables. A closure is defined within the scope of its free variables, and the extent of those variables is at least as long as the lifetime of the closure itself.

QED.

http://en.wikipedia.org/wiki/Closure_(computer_science)

Java allows defining "anonymous classes" inside a method; an anonymous class may refer to names in lexically enclosing classes, or read-only variables (marked as final) in the lexically enclosing method.

...

Some features of full closures can be emulated by using a final reference to a mutable container, for example, a single-element array. The inner class will not be able to change the value of the container reference itself, but it will be able to change the contents of the container.

This is, of course, trivially isomorphic to "full closures".

[Asher]

THERE ARE NO CURRENT CLOSURES. There exists an approximation in current Java, but it is NOT a closure.

If you had ACTUALLY been following the proposal, which dates back over four years, you'd know exactly why.

http://gafter.blogspot.com/2006/08/closures-for-java.html

[Kuciwalker]

Sure, if you were writing closures into a language from the ground up, you probably wouldn't introduce the final constraint. But they are still closures, and when needed you can do anything with anonymously instantiated interfaces in Java that you would do with closures in Javascript or other functional languages.

[Asher]

http://en.wikipedia.org/wiki/Closure_(computer_science)

In computer science, a closure is a first-class function with free variables that are bound in the lexical environment. Such a function is said to be "closed over" its free variables. A closure is defined within the scope of its free variables, and the extent of those variables is at least as long as the lifetime of the closure itself.

QED.

http://en.wikipedia.org/wiki/Closure_(computer_science)

Java allows defining "anonymous classes" inside a method; an anonymous class may refer to names in lexically enclosing classes, or read-only variables (marked as final) in the lexically enclosing method.

...

Some features of full closures can be emulated by using a final reference to a mutable container, for example, a single-element array. The inner class will not be able to change the value of the container reference itself, but it will be able to change the contents of the container.

This is, of course, trivially isomorphic to "full closures".

No, it is not. It's quite clear to me you're out of your element here.

C# has supported anonymous classes from the beginning, but did not gain closures til C# 2.0.
Java has supported anonymous classes from the beginning, but it will not gain closures til Java 8 (at the earliest).

What you are describing are "APPROXIMATIONS" or "EMULATIONS", all of which have caveats and gotchas and messy syntax/design. It is NOT a first-class feature of Java, it is not a feature at all -- it is simply a concept that can be approximated in Java.

It is disingenuous to say Java supports closures when it can merely be approximated.

[Kuciwalker]

THERE ARE NO CURRENT CLOSURES. There exists an approximation in current Java, but it is NOT a closure.

If you had ACTUALLY been following the proposal, which dates back over four years, you'd know exactly why.

http://gafter.blogspot.com/2006/08/c...-for-java.html

Asher, 90% of the work on this issue is not "how should we do closures" but "how should we do lambdas". They are different things. The rest is "should we relax the final restriction and force the VM to do a significant internal overhaul?"

[Kuciwalker]

In computer science, a closure is a first-class function with free variables that are bound in the lexical environment. Such a function is said to be "closed over" its free variables. A closure is defined within the scope of its free variables, and the extent of those variables is at least as long as the lifetime of the closure itself.

The only way in which Java conceivably fails this definition is that anonymous classes are actually more expressive than first-class functions - first-class functions are a subset of anonymous classes (those with just one method).

[Asher]

Sure, if you were writing closures into a language from the ground up, you probably wouldn't introduce the final constraint. But they are still closures, and when needed you can do anything with anonymously instantiated interfaces in Java that you would do with closures in Javascript or other functional languages.

This is demonstrably false. First of all, the approximation of closures with using anonymous inner classes DOES NOT satisfy your definition quoted, because it does not close on the lexical environment. It is not bound to it. It COPIES this environment. This is not BINDING. When you BIND in computer science, it does not mean to COPY it.

Here's a task for you: implement a proper closure that computes the factorial of 1000, using ints.

BTW, here's the Principle Engineer at Oracle (nee Sun), heading up Java's development. Can you read what the slide says?
http://twitpic.com/pz3hn

PS: I haven't even gone into the other ugliness of the closure approximation hack in Java. Each additional anonymous class is an additional compilation unit in Java. Closures are also supposed to be tidy, neat shortcuts in the syntax and the approximation in Java is verbose.

[Kuciwalker]

This is demonstrably false. First of all, the approximation of closures with using anonymous inner classes DOES NOT satisfy your definition quoted, because it does not close on the lexical environment.

The definition doesn't require that the entire lexical environment be bound, but only that some of the function's free variables are bound.

It is not bound to it. It COPIES this environment. This is not BINDING. When you BIND in computer science, it does not mean to COPY it.

There is literally no difference whatsoever between two immutable references to the same object (which may itself be mutable) and one immutable reference shared between two closures.

Hell, the former is actually a plausible implementation of closures under the hood in a functional language.

[Kuciwalker]

http://rickyclarkson.blogspot.com/2007/10/why-java-needs-closures-it-already-has.html