More on Closures

Last night I had the rare occasion to have a  face to face discussion about language, complexity, and a whole host of related topics that of course included generics and closures. It is no secret that I see little value with generics. In fact my stated position is that they do more harm than good. I campaigned against generics before the 1.5 was released. I had no illusions of stopping generics from being released. The people in charge of getting them into the language were obliged by the JCP specification to make it happen. More over they had surrounded themselves with like minded people and there was just no way that anyone short of James turning that ship around.

But that was then and this is now. Now I see that the JCP is a much more open process. I see that people are much more interested in what the language theorist are planning to do. More importantly, those theorist seem to be much more willing to engage in meaningful discussions with people, such as myself, who are not quite as clever as they are.

As was the case with generics, I think we need to ask the same types of questions about closures that we didn’t ask of generics. We need to do that now while we have a chance to influence because if we wait until it gets into a JCP specification, it will be too late. First question on the block, what is the problem that we are trying to solve and are closures the best solution or are their other solutions we need to be considering? Assuming the answer to that question is positive in favor of closures, the next question is; should we be adding closures to the language at all. Will adding closures take Java add enough complexity to the language that it will no longer be easily reachable to those that is has served so well?

My retrospective on generics is that they are mostly easy to use. However in the vast majority of those cases the usage is uninteresting. I see little value in providing type safe collections. Of course there are other uses but those cases are so esoteric that most developers either don’t understand them, or will have very few opportunities to apply them. More over, and maybe most importantly, generics contain a number of edge cases that even the experts can’t sort out. Even more importantly, developers run into these edge cases on a regular basis if they start to use generics in a more interesting way than just for compile time type safety of a collection. Why? Simple answer is; look to the implementation and decisions that were made by those involved or those controlling the process. In other words, those that did may not of had the luxury of delivering an implementation with fewer edge cases.

From my perspective, the lessons learned from the generics experiment were; openness in the process matters, implementation devoid of edge cases really matters, and that we, the Java developer community, need to pop up out of our cubes for a second and become involved in the process.

I think that there is a lot of evidence that work on closures is happening in an environment that is much more open than it was with generics. This is evidenced by the several different completing specifications with a number of emerging implementations. The authors of each specification now senses that they need to support of the community rather than support of a single large corporation if they are to win the battle. Translation, your voice counts. Some may view this as chaotic, I view it as a sign that Java is alive and well and is still kicking

WIthout getting into any long winded justifications, my opinion on implementations is that Neal’s proposal offers us far few edge cases. I feel that it is important that if closures are adopted that they do not introduce any more edge cases. As much as I like the puzzler books, it seems a bit odd that the authors of the features become authors of books that poke holes in their implementations. Why didn’t they do this before they released it. I could make the tongue in cheek observation that without the books they wouldn’t of had the opportunities to become famous authors but I won’t. But I will say this, don’t take my word for it, go and take a look for yourself.

All of this doesn’t answer any of my original questions. Nor does it answer the question of wether or not closures should make it into Java. While each proposal to add closures has at least one advocate, the “no closures crowd” is a highly fragmented voice in the wind. From all accounts that crowd is a crowd. On a java.net survey, the Gafter proposal may of won out but it enjoys only a marginally lead on the “no closures” crowd. Will the “no” crowd eventually lose because they have no proposal on the table? Should someone step up and advocate for the “no” position and put a “no closures” proposal on the table? It may sound silly but who hasn’t heard of “get out the no vote” campaigns.

In talking to Neal I was both able to express my fears of breaking the complexity budget for the language and yet be reassured that this time that those making the proposal were genuinely interested in our opinions. They were aware of the complexity budget. In other words, they are listening and although there seems to be more politics, at least there is a lot more transparency.

All I can say is that I like closures, I see the power in closures and I've used closures in other languages. However I’m not sure about closures in Java. Some days I’m wishing that I could use them and other days I’m wondering if the added complexity or the addition of edge cases is going drive people to use something else. I don’t know how to answer that question. All I do is keep looking at generics and wondering... One thing I do know for sure is that we can answer the question for ourselves by downloading Neals reference implementation and giving it a go.