Sun had publicly announced that there would be no closures in Java 7, however a surprise U-Turn was made yesterday when Mark Reinhold announced that Java 7 will now include ‘Light’ Closures. After years of debate it looks like they have chosen the FCM syntax style.
more info below
http://java.dzone.com/news/closures-coming-java-7
http://www.jroller.com/scolebourne/entry/closures_in_jdk_7
Gee that syntax looks really messy. I don’t think it’s necessary, the current way of doing it is fine using inner classes. I just wish they’d make it so that inner classes could change variables outside their class without them having to be final
Oh no 
More complexity. More opaque syntax. More ASCII being used in strange new ways. No longer readable. How crap.
Cas 
Also Milestone 5 came out a few days ago (download here).
Includes some of the (Project Coin) language changes (binary literals, generic inference, strings in switches). As well as escape-analysis and pointer compression. Other stuff includes newer concurrency stuff from Doug Lea, elliptic curve crypto and a new swing component (JLayer).
I’ve mentioned Zero a few times in the past…it has been added to version control.
Yea, I agree. I still haven’t figured out how to properly use generics, annotations, although I wouldn’t want to be without it.
I like using anonymous classes for defining a single function to pass around, so for me clojures offer a better and more readable alternative to what I’m already doing.
But I don’t like the use of #. Couldn’t they have just used ‘fun’ like everyone else?
I agree with you. If Sun goes on complicating Java, it will look as crappy as C++. I would like to freeze its syntax, concentrate on maintaining existing APIs and creating new ones.
I don’t see the point. What’s the problem with just declaring a private class? At least then you know what’s going on.
The problem is that a bunch of smartypants types who have been programming for years think it’d be great to add this fancy new feature to Java to make it look even more complicated than it really needs to be, and so the original goal of Java (“C++ without the knives, guns, and clubs”) is going to be completely lost.
I had to debug some C++ code yesterday. If it ends up looking like that … well, I’ll get me coat.
Cas
where would you go though? don’t think there really is an alternative good enough atm to jump ship too.
Pssst, Cas loves Blitz!
I agree too :(, stop chnging the language every days… Java is fine as it
I don’t understand the hostility… surely no-one thinks
button.addActionListener(
new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.out.println("Hi!"); } } );
is nicer than
button.addActionListener(#(ActionEvent e) System.out.println("Hi!));
Java could be a lot worse, but having done quite a bit with C# recently I must say I do prefer it as a language. This isn’t “knives, guns and clubs” - we still have the managed environment of the JVM - and it’s certainly not going to turn Java into C++, it’s just implementing a little bit more of the functional side that’s been sorely lacking.
Oh, and did I mention… anyone who dislikes operator overloading is a foul heathen.
[quote]Oh, and did I mention… anyone who dislikes operator overloading is a foul heathen.
[/quote]
As a day job professional c++ developer who has to maintain other peoples “creative” c++ code I can categorically say that the ONLY instance in which operator overloading has not caused more pain than it is worth is ‘+’ for string concatenation. Even that is suspect because it breaks the commutativity property of numeric addition.
Operator overloading should ONLY be defined by the language and ONLY for immutable types and ONLY where it makes logical sense. If you think operator overloading is only abused by bad programmers consider the fact that one of worst cases I have seen is the “bit-shift is totally logically similar to stream concatenation” in the c++ STL.
On closures:
Have investigated a few times and still don’t really understand the concept fully. Anonymous inner classes have served me fine for the rare cases when I have needed them. I have always wondered how likely closures are to introduce obscure bugs and how they impact debugging.
The day I switch to Python will be the day operator overloading is added to Java.
Good news, but reading from the spec i can’t understand if non-local returns are in or not.
Also with closures ParallelArray can be included into std java.
(Also good news in that this means that java 7 is delayed and so the various JSR - date and time, concurrency, coin. Will have some more time. I want composed exception types catch).
Also say hello to Collections 2.0 (almost a need with closures now).
As long as they don’t do this:
http://blogs.msdn.com/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx
I’m fine.
Just noticed as part of coin:
String s = ...
switch(s) {
case "x":
doX();
break;
case "y":
doY();
break;
}
Awesome!
OK, I admit… I almost added to my post that I’d managed to stay out of the OS thread and felt like I was missing out on holy wars. I don’t usually troll like that, honest.
I’m also not the worlds experienced programmer, and I have no doubt that operator overloading can be bad… but I do hate doing vector maths with Java style syntax. Then again, even XNA’s vector stuff doesn’t use operator overloading for some reason. I suppose to avoid excessive new objects being created.