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.)
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".
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.
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.
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);
}
});
be nicer? (or whatever else syntax) Redundancy is already pretty common in Java and the current syntax just seems to try to win the price for most redundancy. You're implementing one interface, which you can infer in most cases with one function which you already know, which returns one result you already know the type of. So why would I want to repeat that?
Sure - you can use the verbose syntax when you have many methods, but this example could be cut down to one line. Less line noise -> less errors.
Yes, actually, while I was editing, I was going to mention C# delegates and new lambdas (I've been using C# 2.0, haven't upgraded yet). In my opinion, C# has been the better Java for a while; I think they should just copy C# stuff since it's already been proven to work and has some nice properties/syntax. It's not like C# didn't copy from Java in the earlier days...
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.
> 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.
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:
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.
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.
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.)
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.
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.
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 :-)
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:
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).
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.
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.
