Skip to main content

Conspiracy theory about closures in Dolphin

Posted by kirillcool on September 4, 2006 at 4:17 PM PDT

I was watching the (not so impressive for now) Flying Irish on Saturday and my mind wandered off. Neal Gafter's original proposal for introducing closures into Dolphin along with code samples and what not has been published only two weeks ago and already the blogosphere is abuzz (more on that later). And i started to think - it's like a crime movie and all those cheap police thrillers. When you try to solve a murder, think about who's the first to profit from that death and you have your killer. Now, who's going to profit from having closures in Java and all those corner cases? Of course, the writers of "Java puzzlers"!!! Hey, isn't Neal one of those? Of course!!! Isn't Neal behind the closure proposal? Of course!!!

And now on a more serious note. We have tens of discussions (notably this Javalobby thread initiated by Mikael Grev, this SwingLabs thread and Remi blog right here on We have scores of proposed syntax changes and hundreds of opinions. Somebody on one of those threads (don't have a link at hand) said "People either understand closures, or don't like it". Well, i understand closures but i can't say that i like them. I feel that it's too disruptive for a such widespread language (and i completely back up Mikael's original post on Javalobby). Does it make programs easier to read? In some cases - yes. Does it bring more clarity to programs? In some cases - yes. Is it easily abused by inexperienced programmers, novices and showoffs? Almost certainly. Does it add yet another way to do what can be done already with existing language constructs (this is what makes Swing so hard for the beginners)? Certainly. Can it make harder to join an existing project and fix somebody else's code? Almost certainly.

Now, language changes in Tiger were both a blessing and a curse. Generics offload some of the error screening to the compiler stage, while making code look more complicated. Autoboxing / unboxing make working with primitive types easier, while introducing hard-to-track bugs, especially in collections of primitive values (see "Java puzzlers" session from JavaOne 2006). Enhanced for-loop is less handy than i originally thought since it doesn't provide a way to remove / index entries. And the list goes on. But, and this is a major but. All these changes were minor compared to what is planned for Dolphin. In Dolphin, we are talking about inferred types, function pointers, omitting entire language constructs and so on. It's not eighties - most of this code is generated in IDE when you press Ctrl+Space, guys. And it's not a problem to read it as well.

Be that as it may, the widespread coverage of the proposed syntax is excellent for both the proposal and for the community. The only thing that makes me wonder is the seemingly selective choice of the community for this particular feature.

More than a year ago, Mark Reinhold outlined the proposed changes to Dolphin at JavaOne 2005. One of the major changes (no closures being mentioned at that time) was native XML support in the language. The community response was anemic at best. This entry on my own blog wasn't very popular (well, it may as well be my fault :), and the only other worthy entry was on Val's blog (which is kind of dormant lately). Sun's own XML engineers were politely shooshed during the Q&A section, and their opinion is nowhere to be seen on the web (and remember, that was more than a year ago). This year's JavaOne featured 158-slide presentation (downloadable here, session number 3441), and Mark followed up on his blog with only 3 (!!!) total comments. The server people seem to not care (well, most of the commercial applications still run on 1.4.2, so we're talking at least 7-8 more years until this gets to the application servers). In the meanwhile, the proposed features seem well-matured, and i'm sure that somebody at Sun already has working prototypes ready to go into Dolphin monthly builds.

Why everybody is such an expert at closures but not at XML? The potential for hard-to-read code is even greater with native XML support, yet nobody seems to care. If this is true (that nobody cares), perhaps we don't need it in the language at all... And i wonder yet again - why we don't hear about this from Sun's XML engineers (JAXWS / JAXB / FI / ... groups).


Related Topics >>