openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abe White <>
Subject java.util.concurrent
Date Thu, 01 Jun 2006 01:36:33 GMT
Hello all --

For those of you who don't know me, my name is Abe White, I'm a BEA  
employee (by way of SolarMetric), and I expect that I'll be spending  
most of my time working on OpenJPA once we separate out our  
proprietary bits and get it off the ground.

As you've been discussing, one of the goals of OpenJPA is that the  
core be JDK 1.3-compatible.  Another goal, however, is that OpenJPA  
scale very well.  To that end, I spent a little time recently  
investigating concurrency in the Kodo codebase.  I've only gone over  
the "lib" code (basically the stuff that's checked into OpenJPA), but  
it turns out that with a few of the java.util.concurrent classes, we  
could get rid of almost all synchronization.  Unfortunately, the  
java.util.concurrent package is 1.5-only, and even the available  
backport is 1.4 code ( 
concurrent/).  The backport is public domain, and it would be trivial  
to alter the few classes we need (ConcurrentHashMap,  
CopyOnWriteArrayList, CopyOnWriteArraySet) to be 1.4-compatible and  
check them in as OpenJPA utils (well actually Kodo utils, but OpenJPA  
utils when we synch the codebases).  Before I do that, however, I'm  
wondering if  anyone has other suggestions.  Perhaps there is already  
code out there I don't know about.

p.s. It turns out that a ConcurrentHashMap that could deal with soft/ 
weak references would also be very useful in a couple of places, so  
if anyone knows of such a beast, speak up.  I haven't investigated  
the feasibility of making one yet.

p.p.s. Not sure if Patrick has mentioned this, but the plan is to use  
a Sun-like coding style for OpenJPA.  The code currently checked in  
uses the old SolarMetric style (which has its roots in the style of  
an even older company).  So I just wanted to assure everyone that  
we'll switch over to a style more people are probably used to at some  
point in this migration from the Kodo codebase.  I personally am a  
nazi about formatting being consistent, so when we do switch, it will  
be completely. 
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

View raw message