Torbjörn Gannholm

Bio
Website

I have been writing code since 1980. In 1999, I learned Java and after discovering IntelliJ the love was complete. XML and XSLT was a revelation in 2000, too bad the standards committees have done so much damage since. Contributed to the Flying Saucer open source XML and CSS rendered and published an open source XSLT generator, weffo. Currently employed by Google. Torbjörn is a DZone MVB and is not an employee of DZone and has posted 9 posts at DZone. You can read more from them at their website. View Full User Profile

Java closures and threading

02.22.2008

| 1326 views |

My main concern with proposals for closures in Java has always been that it has the potential of making multi-threading so transparent that you forget to think about issues you need to think about, much like happens again and again with mechanisms that make it so transparent to make remote procedure calls that you forget to handle the issues you really need to think about in that scenario.

Rather than write a long story here, I wrote my first blog post ever: http://tobega.blogspot.com/2008/02/java-closures-and-threads.html

Published at DZone with permission of Torbjörn Gannholm, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Osvaldo Doederlein replied on Mon, 2008/03/03 - 3:54pm

Yep, the old "easier-is-worse, programmers are stupid" argument. And considering that you mention concurrency as example, did you check the proposed ForkJoin Framework? The 'standard' API draft sucks ass compared to the closures-enabled proposal. You refer to a very old blog from Neal - 1,5 year ago, before the ForkJoin work started. You may have a point that closures are a better match... for APIs that were designed (ar at least refactored) with closures in mind. Now that's not the greatest news ever, this can be said of most new language features.

Torbjörn Gannholm replied on Tue, 2008/03/04 - 3:00am

Osvaldo, programmers are no more stupid than anybody else as stated by Dilberts rule: "Everybody is an idiot sometimes".

It is even more likely that programmers are forgetful sometimes even if they know what they're doing.

You seem to read my post as "no closures" but that is not what I said, I merely stated that there is a weakness in BGGA where threading is concerned. But the CICE proposal has a nice solution for that, shared mutable variables have to be labelled public. The only enhancement I can think of over that would be to by default require that referenced shared objects are immutable.