Closures

There has been a lot of chatter about the closures proposal penned by Neal Gafter. And, in particular, whether or not I support it. I absolutely do. My "Feel of Java" talk of many years ago got rather infamously twisted at JavaPolis a couple of months ago. Java feels alive, not stuck in some chisel marks on stone tablets. Closures were left out of Java initially more because of time pressures than anything else. Closures, as a concept, are tried and true - well past the days of being PhD topics. The arguments are in the details, not the broad concepts. In the early days of Java the lack of closures was pretty painful, and so inner classes were born: an uncomfortable compromise that attempted to avoid a number of hard issues. But as is normal in so many design issues, the simplifications didn't really solve any problems, they just moved them. We should have gone all the way back then. Some have criticized the current proposal as being too complex. If you read through all of what Neal has written, you'll see that there are two sources of this perception: the spec is really detailed and explores all kinds of corner cases that never get touched on in most programming manuals; and the proposal is a collection of features that at first blush seem separate, but in fact are deeply inter-related and push each other into existence.
January 31, 2008