Skip to main content

How do you think the closures debate will eventually be resolved?

BGGA added in Java 8
30% (160 votes)
CICE added in Java 8
21% (114 votes)
FCM added in Java 8
2% (9 votes)
Something else added in Java 8
8% (41 votes)
Closures added in Java 9
8% (40 votes)
No closures by Java 9
28% (148 votes)
Something else (please comment)
4% (21 votes)
Total votes: 533

Comments

Closures will be never added to Java

I would really like to see BGGA closures in Java. But I am very sure that this will never happen.

Closures will be never added to Java

I hope closures will never be added, but I fear some comittee will decide that because Ruby (for example) has them, Java MUST have them as well to survive and a half-baked effort will be made to introduce them. The utterly unintuitive way the BGGA proposal shows is probably what they'd use, but of course only partially implemented because doing everything would break the language (which IMO is a good indication for why it should not be implemented in the first place).

If you want closures so badly, use a language designed around them from the ground up, rather than trying to retrofit them in a language that works very well without them.

CICE is a very good solution for all of us

Java has already made the decision about closures. They are called inner classes. Yes, they are far from elegant to use, when the programmer want to use a pointer to a single method (closure) Therefore CICE just proposes a little tweak in the syntax. As a result you can do almost all that can be done with closures, but with far less complexity and side effects than with the over-complex BGGA. People are right when they say that future languages will have closures just as they have recursion. But, just as recursion, closures are very seldom of good use in day to day business when the language is not build around them. There are some algorithms that can be more concisely formulated with closures (as with recursions), but you seldom really need them. And CICE would be enough for almost all those cases. Closures are in more than 90% of the real cases just another idiom how to formulate an iteration. And also for this CICE would fill the bill. Closures are very good to reduce the number of interfaces needed. CICE is good for this too. BGGA tries, just as wildcards, to solve problems that are not there. And the coronation of all is yet another idiom for iterations via the possibility to define your own control structures. No mainstream language needs this feature and it makes the closures story enormous complex. Look at the side effects, the return without return, the ==> operator and so on. Wildcards on steroids so to say: Really needed for nothing, but overly complex. The exact opposite to what Java initially was. The proponents of BGGA try to force the large quiet rest of the community to transform Java to a different language, using even a different programming paradigm. What is the reason to try to transfom Java into Scala if this language is already available on the JVM? Most substantiations I have read say that their management demand the use of Java. This means that they want to force many, many people how to solve problems they do not have, because they cannot persuade their own management. Thats really a poor reason and mainly egomaniacal. Closures and functional programming are no new ideas. Languages using them existed before Java was adopted as the mainly used language. Not Ruby and not Python was chosen, but Java! To call people luddites because they do not want to use closures and functional programming is goofy. There is JRuby or Groovy or Scala or Jython on the JVM. If you think closures and functional programming are more than a temporary fashion, use these languages and promote them. If they are really a progress and solve problems far more elegant than Java does, they will be used by more people. But if you discover in the next season that closures with their side effects generate many problems and that the next season talks about other things anyway, Java had not been rendered unusable and you can return to it. No need to force someone into something. Therefore simplify Java syntax according to CICE, support the other languages, especially Scala and put the closure debate to an end.

Java9? what a joke...

Ha, I don't even want to bet when we'll see Java7... The way things are going, JVM and library enhancements that serve other languages may side-effect Java, but Java itself is not going to evolve, whether we like it or not.

From time to time a bigger step must be made

I think JavaFX is a far better solution than repeating the generics debacle with the over-complicated BGGA proposal and making the Java language completely unmanageable. BGGA is something for rule fetishists (just as wildcards) and the allegory how not to design a mainstream language.

Closures won't be added at all

JavaFX Script is Java++. Yes it's being marketed as a UI DSL, but if you actually walk through a tutorial or two, you'll see that it is as general purpose as Java itself. JavaFX was an opportunity to break syntax compatibility and "fix" all of the warts with the Java language (just like Java was created to "fix" C++ language warts). JavaFX has: * type inference * everything is an object (no more primitives) * named parameter lists * closures * functional programming * arrays are actually lists and never null (empty by default) * string are never null (empty by default) * less verbose syntax * etc, etc The primary language on the JVM in the future will be JavaFX Script. New language features will go there. Java will not accept new features. That's my prediction. -Bryan