But let me ask one question: Why has it taken so long for the Java community to realize that? It's just a few month until JDK7 is going to be released, but the closure debate has been around for quite a long time now (not to say years). There were several proposals, there has been the straw-man proposal and the spec draft and the announcement last Devoxx. But there hasn't been much of a discussion in the community.
What is the reason for that? I have some assumptions. Has project lambda been too quiet? There weren't many blog posts or examples. Or is there something broken with the community? Were have the community leaders been? Are they too busy learning Scala? Or is it just that closures in a statically typed language (without type inferencing) are intrinsically complex?
And by the way, what about Java modularity?
Posts
10 comments:
You bring up a good point, Nick. I've also heard a lot of complaining from the community about Project Jigsaw (Java Modularity).
Because there isn't much to discuss. They just shouldn't be implemented. If you want closures, take Scala.
to me, the chosen syntax for closures is the best among all that I have seen, especially if you compare to BGGA spec :)
Maybe it is isn't as nice as it is in Groovy or Ruby, but that's because of the type system probably..
I find the attitude surprising. The community has of course been commenting from the beginning about the syntax. But given the multiplicity of proposals around closures, which have often differed widely in syntax, and sometimes have very much been prompted by a cleaner syntax, it is difficult for the developer to figure out exactly which version to give feedback upon.
In any case, depending on the enthusiast developer to guide syntax and features that may end up affecting every developer may not be the best idea. The generics implementation was a sound one given the constraints it was designed under, but did not end up making the average developer happier.
So Closures shouldnt be in JDK7, because the syntax for them is always ugly?
I d rather say that Sun/Oracle dont have the cahonas to create nice looking closures. Why cant we do the following in Java that is perfect Groovy?
System.getProperties().each{ String prop -> println prop}
This way Closures would be awesome and nice to look at. But Sun/Oracle dont have what it takes to introduce the superb "{params -> code}" syntax.
@Anonymous: they simply cannot introduce that very syntax, because java has the worry not to ressemble c#
Brian Goetz personally responded to it - syntax will be improved later it sounds like.
Personally it looks fine - way better already than JS closures which I would argue are the most popular in the world.
At least I'm a little bit confused with the whole Java 7 process. There seems to be all kinds of proposals floating around and quite often it is challenging to figure out which ones have some kind of an offical status.
"Syntax will be improved later" ... yeah sure. This will be biggest disaster after the introduction of Generics.
Seeing how type erasure, varargs, arrays vs. parameterized types create bugs hard to fix at every corner I'm very happy to see that Java has finally reached a state which I always predicted. If people start putting features into a language without doing it right the first time, that's exactly what they deserve.
Instead of cramming weird syntax into Java 7, I would really like to see a serious proposal about a long-time deprecation of Java.
I'm against them since the beginning.
Main reason for 'no' is current null-s handling.
We have no way to deal with null-s / depending on logic kind, null check can make one line function grow to 5 lines.
Elvis and Other Null-Safe Operators for Java
I'm worry about exceptions as well. But as soon as I'll have some free time I'll check latest specifications.
Post a Comment