

Java 7: Oracle pushes a first version of closures - budu
http://www.baptiste-wicht.com/2010/05/oracle-pushes-a-first-version-of-closures/

======
bnoordhuis
The syntax won't win beauty pageants but I like how they retrofitted lambdas
onto interfaces so you can do something like:

    
    
      Collections.sort(list, (Comparator) #(String a, String b) {
        return a.compareToIgnoreCase(b);
      });

~~~
jpr
(sort list #'string-lessp) still wins in my book :)

~~~
jimbokun
You can always static import Collections.sort. The main thing missing, then,
is a way to simply refer to an existing method to perform the comparison. Is
there syntax for this in the current release? (I believe there was in some of
the earlier proposals.)

~~~
tlrobinson
I haven't tried this but according to the comments on the post you can do
something like this:

    
    
        Comparator string_lessp = (Comparator) #(String a, String b) {
            return a.compareToIgnoreCase(b);
        }
    
        sort(list, string_lessp);

~~~
jpr
Yeah, but that just seems _wrong_. It's like "I have this function, but I
can't actually refer to it, so I'll have to wrap it in this thingamajig just
so that I can pass it around".

~~~
tlrobinson
Huh? You can, but the sort method already takes a Comparator class. If it took
a function you could pass around the function instead.

Anyway, the point was only that "(sort list #'string-lessp)" is nothing
special.

~~~
jpr
The definition of Comparator-interface includes only two methods, .compare and
.equals. The documentations says that it is always safe to not override
.equals, so we're left with just .compare. This effectively means that each
comparator is effectively a function of two arguments that returns a boolean.
Had functions been in Java in the first place, the whole Comparator interface
would have been superfluous.

------
strebler
Look at what the cat dragged in - a syntax for closures in Java.

~~~
whakojacko
yea, that looks about right.

Everyone looking for these kind of features should probably just be using
Scala...

~~~
ericlavigne
While I would prefer Scala over [Java + closures], and would prefer Clojure
over either of those, I am still pleased to see closures in Java for several
reasons.

1) For now, I still have a job as a Java programmer. Closures in Java will
save me some lines of code until I can fix that.

2) Currently each JVM language has its own incompatible reinvention of
closures. I think that closures in Java are a step towards better
interoperability between JVM languages.

3) A lot of programmers will be introduced to a higher level of abstraction
than they otherwise would have.

~~~
technomancy
> 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.

~~~
sreque
How in the world do callables replace closures? Closures can have arguments,
callables can't. You cannot pass a ruby lambda expecting arguments to Clojure.

~~~
technomancy
> You cannot pass a ruby lambda expecting arguments to Clojure.

I beg to differ: [http://github.com/technomancy/clojure-
gem/blob/master/test/t...](http://github.com/technomancy/clojure-
gem/blob/master/test/test_ref.rb#L46)

~~~
sreque
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. :)

------
radu_floricica
I _really_ didn't expect to say I love Oracle. But in hindsight, better
productivity for the Java platform is a huge thing for them.

~~~
rbanffy
It's like watching your hero being swallowed by a monster and then discovering
the monster started to exhibit some personality traits of your hero ;-)

Oracle is ceasing to be the Ultimate Uncool Company in tech. (no, really, that
place is Microsoft's - Oracle never stood a chance)

------
WilliamLP
I think waiting for Oracle to do something with Java 7 at this point is like
believing Lucy will let you kick the football this time.

~~~
avar
Is there anything to suggest that they'll let the current development hell
continue? They have a lot invested in Java now, they might actually get their
act together and push Java forward. Both to make it attractive to the
programmers that like C# better, and to add features to the JVM to allow
alternate languages to thrive, e.g. tail-calls and coroutines.

~~~
WilliamLP
> Is there anything to suggest that they'll let the current development hell
> continue?

History, inertia, lack of any demonstrated interest or unified direction, key
Java players running away, a change in planned features every month, no clear
incentive, almost no interest from Java programmers? (What interest there is
seems to be mainly from the fringe community involved in Scala and Clojure,
who want invokeDynamic.)

------
jared314
Good or bad, I am just happy they are actually doing something. (Wow, that is
depressing.)

------
BonoboBoner
Good to know that they at least work on it and dont delay it till jdk8. This
will be a great addition to the jdk for alternative-language-developers just
like MethodHandles allowing them to compete with Java performance-wise.

------
euroclydon
What's with the "#" sign? Is that new for lambdas, or an existing Java symbol?

~~~
ebiester
That's new for lambdas.

~~~
tlack
Java isn't very "symboly" in practice. Any idea why they made such an unusual
choice? I'm not against it (I prefer symbols to long words generally, even if
they have a slightly longer learning curve), but it seems unlike the rest of
the Java spec.

~~~
RodgerTheGreat
Well, the alternative is adding a new keyword, and it's difficult to do that
without risking breaking any existing code that uses whatever identifier they
choose. Breaking old code is even less "Java" than introducing new symbols.

edit: Actually, now that I think about it, this wouldn't be the first time
they introduced a new keyword with a language update. So much for that
argument:

[http://java.sun.com/docs/books/tutorial/java/nutsandbolts/_k...](http://java.sun.com/docs/books/tutorial/java/nutsandbolts/_keywords.html)

------
jrockway
None of these closures actually close over any state. Is that feature going to
exist, or are these really just C-style function pointers?

~~~
strlen
If this is equivalent to anonymous classes, then it can close over final
references.

E.g.,

    
    
      public class Ref<T> {
         private T t;
         public Ref(T initial) { t = initial; }
         public T get() { return t; }
         public void set (T t) { this.t = t; }
      }
    
      public Callable<Integer> makeIncrementer(int initial) {
          final Ref<Integer> ref = new Ref<Integer>(initial);
          
          return new Callable<Integer> () {
             public Integer call() {
                 int rv = ref.get();
                 rv += 1;
                 ref.set(rv);
             }
         }
      }
    

Nonetheless if the reference closed over still has to be final (e.g., I can't
just give it an Integer) this is merely syntactic sugar over what Java already
has. Perl had this for ages:

    
    
      sub make_incrementer {
          my $i = shift;
    
          return sub { return $i++; }
      }
     
    

Too little, too late. I am almost certainly using Scala (or Clojure) for any
future JVM projects (unless there's a good reason not to).

------
morphir
now the blob-programmer can create compound blobs out of smaller atomic blobs.

~~~
pivo
You mean "blub", right? Anyway, as someone stuck programming in Java because
our customers require it I would welcome this language addition.

~~~
wglb
Out of curiosity, how flexible are your customers to updating java versions?

And for that matter, are they receptive to Clojure?

~~~
morphir
usually its the jvm that is the dependency. So I don't see why you could not
program in clojure or scala.

~~~
pivo
We could but it would be difficult. Our product requires that our customers
subclass our Java classes to implement their custom business logic, and
sometimes it's necessary to provide the source to our base classes for
reference. Sending a customer some Clojure code and expecting a Java developer
to know how to handle that doesn't seem reasonable.

~~~
morphir
one can also ask the question whether its you that want to continue coding in
java, because you think in java, or because you want to avoid learning
something new. But yeah, if the customer don't grasp Lisp, you are pretty much
settled with java.

~~~
pivo
If one were to ask me that question I would respond by saying that I have been
programming in Common Lisp for many years and would gladly switch to any lisp,
especially Clojure, if it made sense for our business.

