Skip to main content

When the World is Running Down

Posted by editor on June 28, 2007 at 4:14 AM PDT

Finding and fixing bugs in heavily concurrent code

A strong understanding of concurrency and threading is one of the traits that distinguishes the best Java developers, in every permutation of the platform. Servers by their very nature are heavily multi-threaded, good desktop developers know to thread off expensive work and unblock AWT-Event-Dispatch, and ME developers often have to carefully manage threads and other resources in order to coexist with other apps in the same small VM.

The concurrency utilities introduced in Java 5.0 offer various ways to achieve high efficiency with threads. For example, the ReadWriteLock interface and ReentrantReadWriteLock class give you a convenient means of providing concurrent read-many, write-once access to some resource.

It also provides some means of thoroughly messing up your application. What if you forget to unlock? Or what if you have a read lock and you try to perform a write operation? These mistakes can create subtle, hard-to-fix bugs.

Fortunately, there's help in today's Feature Article, Ran Kornfeld's Extending the ReentrantReadWriteLock

This article was not written just to tell you about these pitfalls and send you on your way, but also to introduce a solution, which comes as an extension to the ReentrantReadWriteLock class. This extension (actually a composition) will wrap the lock and add more capabilities to help you overcome the specified problems.

In Java Today,
the Filthy Rich Clients project hosts sample code for the upcoming book of the same name by Chet Haase and Romain Guy. On his blog, Romain recently announced the availability of demos for chapters 5 (Performance) and 6 (Composites). Ultimately, the project will host the complete collection of demos and examples found in the book

The blog has published an interview with Mobile & Embedded Community Leader Roger Brinkley. "Roger and I had a chance to visit recently and talk more about his involvement in leading the community. Read on to learn a little more about what goes on behind the scenes in this thriving community..."

In an opinion piece on JavaLobby, Clemens Eisserer asks Why Doesn't Google Bet On Java? "Google is well-known for doing almost everything possible using Javascript and to have a lot of knowledge in this area. Sometimes this works very well (like for GMail) and sometimes not (like for docs & spreadsheets). [...] But why? Its like building a school-bus with a motorcycle engine just because these engines are there. "

Today's Weblogs section starts with some
Quick feedback from Jazoon by Fabrizio Giudici.
"I still need some time to get to a comprehensive evaluation about Jazoon, so I will talk about the conference in general after the event is over. Nevertheless today I can say what has been the most interesting talk I've attended."

SCA & JBI: Made for each other. (SOA Gone Wild), Brian O'Neill writes,
"after some exploration, it appears as though JBI is ideally positioned to serve as a run-time for SCA contributions. Here are three ways that SCA and JBI complement each other."

Finally, a warning from James Stauffer:
Don't return in a finally clause:
"Some things that look ok at first can cause major problems. One of them is returning in a finally clause."

In today's Forums,
javadesigner2 kicks off what's sure to be a contentious thread with a call to
Remove generics in JDK SE.
"Generics as proven to be unreadable garbage for me and many other java programmers. It's a fundamental design problem. Even Ken Arnold, author of the language specification thinks so. It needs to be removed either officially. Is the openJDK Governing Board doesn't want to do this, the openJDK tree needs to be formally branched into a new jdk tree."

sjd00d could use help with
Two schemas referencing one common schema. Compilation problem!!!
"Basically I have two schemas (different targetnamespace) that reference elements from another common schema. I have to include this common schema in both the schemas as otherwise compiler won't like it. When i do that, compiler complains that a class with given name was already generated coz it would try to create duplicate class while compiling the second schema. The question is, how could I structure my schemas so that I don't run into this issue. One potentially options is to compile them separately in different packages which works for me on most cases but on some cases i have to compile them in the same package (which is good coz there won't be duplicate classes)."

Finally, Joshua Marinacci has a tip for achieving a Mac OS X effect in
Re: how to make a hidden java application in Mac.
"This is a Mac specific thing. If you bundle your application as a Mac only application (using an .app bundle) then you can set a special flag in the Info.plist. See this tip. This will work with any Mac application, not just Java ones."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Finding and fixing bugs in heavily concurrent code