Search |
|||
Cay Horstmann's blogClosures? In Java 7???Posted by cayhorstmann on November 18, 2009 at 8:22 PM PST
Today, a tantalizing announcement by Mark Reinhold about closures in Java 7 has made its way through the twittersphere.
On the same day, Neal Gafter updated his closure proposal (known as the BGGA proposal, named after the initials of Bracha, Gafter, Gosling, and von der Ahé, and not at all related to the B. G. G. A. organization).
Presumably the timing is not a coincidence. The proposal is a bit technical, so I thought I'd translate my understanding of it into some use cases. Here goes.
Overall, I like it. The simple things are simple, and there don't seem any hidden pitfalls. Of course, someone out there will say "Oh my, oh my, that
To which I'll say “I rest my case”. More interestingly, someone on the Project Coin mailing list tried to muddy the waters by asking how this feature interacts with other new features of Java 7, like
try (Closeable c = #() { System.out.println("YOUR HEAD A SPLODE"); }) {
// ...
}
Ok, that means that the If this is indeed to come to pass in Java 7 (and I have absolutely no inside knowledge whether it will), I am willing to wait a bit longer. What do you think? »
Comments
Comments are listed in date ascending order (oldest first)
Latest Spec??
Submitted by gafter on Fri, 2009-11-20 16:31.
FYI: the 0.6a specification http://www.javac.info/closures-v06a.html is NOT BGGA, nor is it intended to document Mark Reinhold's plans for JDK7. Although it resulted from a discussion with the other authors of the BGGA spec culminating in this document a couple of weeks ago, I do not have permission to list any of them as authors (I asked). The spec was completed before Devoxx but not linked on javac.info until Wednesday. In fact, I was attending PDC09 when I read a tweet about closures and put up the link. I think the timing and similarity to Mark Reinhold's announcement are either coincidental or Gosling has passed it on to him. I've had no contact with Mark Reinhold, so I have no idea which. Note that this spec allows access to non-final local variables from the enclosing scope, which rumors suggest Reinhold has ruled out.
Clean up Generics first
Submitted by cowwoc on Fri, 2009-11-20 09:58.
Closures is going to turn into another Generics mess.
How about you clean up Generics first (making them more readable through Reification) before you stuff Closures in there?
I would love to see an entire release dedicated to *improving* the language cohesiveness, not reducing it. And for god's sake, feel free to drop backwards compatibility with software that is over 10 years old. No one cares. Really!
Yes they do!
Submitted by pjmlp on Fri, 2009-11-20 16:49.
We still have customers holding on to Java 1.4 environments with no desire to upgrade.
oh yark. It's not hard to
Submitted by survivant on Fri, 2009-11-20 09:27.
oh yark. It's not hard to understand, but I only see more problems for junior developers or when we will use IDE. Imagine that you want to find all Runnable into your classes, you will miss all the line using #. For what I have seen, it's not worth it.. not yet.
bye bye Java
Submitted by jwenting on Fri, 2009-11-20 03:12.
Hello Obfuscated Java Programming Contest.
So we get function pointers, and destroy any semblance of writing maintainable, readable, code in the process. Seems Sun bowed once again to the Me2! crowd of people who think that anything and everything that's in any other language would be a great addition to Java and that "Jav iz ded" without it. Calm down, the sky isn't falling
Submitted by cayhorstmann on Fri, 2009-11-20 07:57.
Today, people write obfuscated Java code every day. Code such as
button.addActionListener(
new ActionListener() {
public void actionPerformed(ActionEvent e) {
// button action
} } );
When people read this code, do they say "Oh, here we design a new inner class that implements the ActionListener interface so that its actionPerformed method carries out this action"? Or do they say "When the button gets clicked, this action happens, and I have to read past this !@#$ noise because Java makes me"? The closures version
button.addActionListener(#(ActionEvent e) { /* button action */ });
is less obfuscated.
yes, but...
Submitted by atripp on Fri, 2009-11-20 10:07.
Yes, the closures version is arguably slightly less obfuscated.
But I think the argument is not "which is cleaner in the common, best-case scenario", but rather "which gives more ability to write really nasty code?" Take generics, for example. Yes, used reasonably (which is most cases), they eliminate ugly type casting. But the bad cases - wildcards and such - also introduces a potentially huge ability to write some *really* obfuscated code. Not just "It looks a bit funny but I see what it's doing" but "I'm an expert programmer and can't make heads or tails of it". Or take a look at many of the often-misused C++ constructs: function pointers, operator overloading, templates, even pointers or gotos. In all those cases, the simple, straightforward usage really is cleaner than the alternative. But the sheer horror of dealing with the misuses is tough to get over. nice summary
Submitted by atripp on Thu, 2009-11-19 14:57.
Very nice summary - thank you.
As someone who's head easily explodes when looking at closure proposals, I can say that this seems like a nice, big step in the right direction.
One thing I wonder is what's the benefit to allowing us to drop the curly braces when we just have an expression? Wouldn't it be cleaner to just force people to write include a return statement? I'd rather see "{return a+b;}" rather than just "a+b". I suppose I've never gotten over the complaint that you don't have to use curly braces on if/then/else clauses if there's only one statement, and this is similar.
You raise a good point with
Submitted by cayhorstmann on Thu, 2009-11-19 19:26.
You raise a good point with the syntax of "expr" vs. { return expr; }. Some programming languages want to guide the user with strict rules, eliminating as much gratuitous choice as possible. For example Python with using indentation for blocks. No brace style wars in Python! Other languages try to give you every option and shortcut imaginable, for example Scala. Java is somewhere in the middle, and I think leaving this choice is within the spirit of Java.
@Shared versus multiple threads
Submitted by abies on Thu, 2009-11-19 09:42.
Assuming that I have @Shared variable and pass closure modifying it to another thread for execution, what will be the visibility of updates? Could you define local volatile @Shared variable? How it would be implemented ? (maybe instead of using array[1], there would be class of mutable wrappers for each primitive type, with second set of volatile counterparts, sharing same interface)
My guess is that you will be
Submitted by cayhorstmann on Thu, 2009-11-19 13:42.
My guess is that you will be able to define a @Shared volatile int. They will just have to do the right thing under the hood--such as transforming it into a new int[1] and using some helper method in sun.misc.Unsafe for reading/updating the entry. Another reason why you want closures in the language rather than as an inner-class coding convention :-)
Very Good News
Submitted by scotty69 on Thu, 2009-11-19 05:39.
Whatever they finally pick, it's good that the closure wars are over and we can move on. The next decade is coming soon :-)
Nothing hard about it
Submitted by markmahieu on Thu, 2009-11-19 01:07.
Cay,
The original 'muddying the waters' snippet was also preceded by a comment declaring that it's a tongue-in-cheek example, with its 'Closeable closure' (in the original example) and deliberate mix of ARM and the simplified BGGA syntax.
I agree that there's nothing hard about it, although I have no idea at this point whether it would actually be considered valid.
Investigating how the features interact is important though, and isn't muddying anything in the context of the Coin list.
Mark
You are right--it is
Submitted by cayhorstmann on Thu, 2009-11-19 07:08.
You are right--it is important to understand how the features mix. The "muddying the waters" comment was meant to be tongue-in-cheek as well :-)
Fair enough then :) I
Submitted by markmahieu on Thu, 2009-11-19 07:55.
Fair enough then :) I certainly agree that it's something worth waiting a little longer for. Let's see what unfolds...
I'm confused. Some people are
Submitted by i30817 on Wed, 2009-11-18 22:47.
I'm confused. Some people are saying that its more like BGGA others like FCM.
Non local returns yea or not?
Also please don't do this
http://blogs.msdn.com/ericlippert/archive/2009/11/12/closing-over-the-lo...
We don't really know what
Submitted by cayhorstmann on Thu, 2009-11-19 07:06.
We don't really know what exactly Sun intends to do. I simply analyzed the BGGA 0.6a proposal, which is presumably what BGGA is today. There is no denying that it looks a lot like FCM. No non-local returns. # for lambda.
Since you need to annotate a mutated variable with @Shared when you capture it, perhaps people would think twice before writing
foreach(@Shared String v : values) funcs.add( #() => v); |
CategoriesArchivesNovember 2009
October 2009 September 2009 August 2009 July 2009 June 2009 May 2009 April 2009 February 2009 January 2009 December 2008 November 2008 October 2008 September 2008 July 2008 June 2008 May 2008 April 2008 March 2008 January 2008 December 2007 August 2007 July 2007 June 2007 May 2007 April 2007 January 2007 October 2006 September 2006 August 2006 July 2006 June 2006 Recent Entries |
||
|
|
"... it's something that only library writers worry about."