[concurrency-interest] Language extensions for java.util.concurrent?

Doug Lea dl at cs.oswego.edu
Sat Nov 12 10:27:12 EST 2005

Brian Goetz wrote:
> [... transactions ...]
>> I just don't buy into this sort of system magic (yet!). Languages 
>> have been trying to sell the "tell us what you want and we'll 
>> figure out how to do it" story on concurrency for many many years.
>>  They don't succeed because basically noone believes they can both
>>  do it right and fast.
> I'm not sure that it needs to be right and fast for it to be damn 
> useful today.

Millions of J2EE/EJB application programmers apparently agree with you.

Recall that most J2EE application code does (in the most common usages)
behave in a basically transactional manner: Containers
may serialize objects for the sake of roll back on failure,
eliminate ability for application code to perform most IO or create  '
new threads, update most object state only via database operations, and
so on.  There's supposedly no need for these programmers to ever use
"synchronized" or anything in java.util.concurrent, and also no need to
deal with security or distribution. Although, inevitably, there are
some cases where reality leaks through, so it is hard to make
simple uniform semantic guarantees about effects.

All this middleware support has a huge effect on performance, but many
people seem to think it is worth the tradeoffs.

But even J2EE programmers sometimes find that they need or
want to introduce concurrency rather than just maintain safety in
the face of potential underlying concurrency. So, stay tuned for
the JSR236/237 "Managed" versions of the java.util.concurrent Executor
framework that will allow J2EE programmers to use async tasks and
Futures as their main (and practically only) form of concurrency
support. The in-progress JSR236/237 will be standardizing the kinds of
things now non-standardly supported in the Websphere and Weblogic
"commonj" work packages to instead use special forms of j.u.c Executors.

Anyway, my main point is just the usual one: There are lots of
useful styles of (concurrent) programming, none of which are always
best, but all of which might be subject to improvement via combinations
of better language, library, and tool support.


More information about the Concurrency-interest mailing list