Java 7: Oracle pushes a first version of closures | Hacker News Reader

Java 7: Oracle pushes a first version of closures

baptiste-wicht.com

85 pointsbudu57 comments

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);
  });

dude, you made it look so much prettier than those examples

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

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.)

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);

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".

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.

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.

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

We've been calling them "anonymous classes" for years.

And we've been needing a usable syntax for anonymous classes for years.

I am fully onboard with closures as semantically equivalent to an anonymous class with a single method. The current syntax for creating them, though, is ridiculous.

I can see that, but I'd be a lot happier if the new syntax they came up with was more consistent with the rest of the language.

I don't think the current syntax for anonymous classes is 'ridiculous', it's just inconveniently verbose when you only want a single method. If you're implementing a more complex interface, the current method is actually pretty good.

It is ridiculous.

Java often completely ignores the design guideline of making the easy things easy and the hard things possible, preferring just to make the hard things possible. Anonymous inner classes with many methods are far less commonly needed than anonymous functions, and it's rare that the program is better served having them inline rather than defined elsewhere anyways.

Five lines and dozens of characters of boilerplate for every anonymous function does come at a cost and is ridiculous.

Java often completely ignores the design guideline of making the easy things easy and the hard things possible, preferring just to make the hard things possible.

That's it exactly. My "favorite" example is file I/O. Yes, it's great that I can chain a bunch of InputStream instances together to read encrypted gzipped serialized objects over the network, but it shouldn't be more than one line for the far more common case of reading a file's contents into a string or a byte array.

Apologies: was editing, deleted, but people already replied; I always forget the markdown syntax...

Just to play devil's advocate, what is unusable about the syntax for anonymous classes in Java? An example close to bnoordhuis's post below, in today's syntax:

  Collections.sort(list, new Comparator<Integer>() {
    public int compare(Integer i1, Integer i2) {
      return i1.compareTo(i2);
    }
  });

How are closures going to help?

yea, that looks about right.

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

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.

Clojure is adding cool stuff of its own:

http://freegeek.in/blog/2010/05/clojure-protocols-datatypes-...

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

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.

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

I beg to differ: http://github.com/technomancy/clojure-gem/blob/master/test/t...

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.

Closing only over final variables is deliberately a requirement because closing over non-final variables can lead to confusing situations. I discussed this in more detail in a previous thread:

http://news.ycombinator.com/item?id=1257599

Good point regarding the effect on interoperability. I don't have an answer for that.

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.

Maybe they are trying to make Scala the default language on the JVM with that? :-)

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.

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)

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.

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.

> 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.)

> tail-calls and coroutines

Wanna bet those are never going to make it in Java7?

Oh wait ... probably some half-baked form of those will ... after all, they are calling anonymous method blocks that DON'T capture the whole current context "closures".

Not to mention that they could've inferred the type of the requested function ... an instance where those half-baked generics could've actually been somewhat useful, instead of just a way to avoid explicit type-casts.

The whole language is fucked-up. They should've just froze it at version 1.4 and be done with it.

I don't know why you say that. Oracle is brand new on this turf. There has been no chance of kicking any footballs under their watch yet. They deserve a chance to prove whether they're good or evil without prejudice here.

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

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.

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

That's new for lambdas.

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.

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

It's borrowed from the javadoc syntax, unfortunately.

This syntax is similiar to Stephen Colebourne's FCM proposal: http://docs.google.com/Doc?id=ddhp95vd_6hg3qhc

That proposal also used the "#" symbol, with the following rationale: "The symbol is already used within Javadoc to separate the class name from the method name in exactly this manner. The method literal syntax merely brings the Javadoc convention into Java source code."

It's a reasonable choice for full first-class methods; it doesn't fit quite as nicely if Oracle only introduces closures as a syntax sugar for anonymous classes.

But I think it's OK anyway -- it's concise and even looks a bit like clojure :-)

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

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).

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

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

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

And for that matter, are they receptive to Clojure?

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

You could but the talent pool is much smaller for both of those and the customer might not like that.

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.

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.

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.

I'd say our customers would think we're slow to support new Java versions. But I'm also pretty confident that they've never heard of Clojure and probably not even Scala. I added support for Groovy a few years ago and it's received very little attention despite the fact that it often makes it possible to apply code changes immediately and avoid the long (2-3 minute) application restart time.

Our customers are mostly fortune 1000 companies, the people we deal with are not very technical and almost always outsource all of their development work overseas. They're also very good at finding outsourced developers with minimal skill sets. So a language with a smaller pool of developers would probably be seen as a negative.

yeah, I suppose I do :)

Reply on news.ycombinator.com