You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Abe White <aw...@bea.com> on 2006/06/01 03:36:33 UTC
java.util.concurrent
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 (http://dcl.mathcs.emory.edu/util/backport-util-
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.
Re: java.util.concurrent
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Abe White wrote:
> 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.
Keep in mind that it's now an Apache community project, so you'll want
to reach consensus on style and rigidity, rather than declaring it by
fiat. :)
> _______________________________________________________________________
> 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.
Can you fix your mailer to get rid of this?
geir
Re: java.util.concurrent
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jun 2, 2006, at 1:22 PM, Abe White wrote:
>> But not everyone favors it. For a project like this, where there are
>> multiple people working on things, having the imports called out
>> really
>> helps.
>>
>> What's the downside?
>
> Just that it's verbose and makes writing imports by hand take
> longer. But I don't feel strongly about it. I'm find with
> explicit imports if that's the consensus.
>
I've already given my rationale why I like explicit imports.
>
>> I'm a "before dot" man myself so it's clear from just looking at the
>> beginning of the line it's a method/field.
>
> I'm an after dot person, but again I'm fine with whatever,
> including not enforcing any particular policy on this.
I don't feel strongly enough to require a standard.
>
>> How about just configuring IDEA/Eclipse to do it right, and fixing
>> things as we go along?
>
> I like the idea of using an IDE to fix everything. I don't use an
> IDE myself, so I don't know whether it can make the necessary
> fixes. Here's a list of changes necessary to get SolarMetric code
> looking more like the standards we've outlined:
> - Change to explicit imports.
yes
> - Move opening brace to same line.
yes
> - Move up "else" and "catch" to same line as previous closing brace.
yes
> - Move up "extends" and "implements" to same line as class
> declaration.
yes
> - Move up "throws" to same line as method declaration.
yes
> - Remove spaces before opening parens on method calls.
don't really care
> - Change tabs to spaces.
yes
> - Remove extraneous spaces from field declarations (we tend to
> align declarations with tabs, so converting the tabs to spaces make
> sit look horrible... plus I'd like to just stop aligning
> declarations altogether anyway).
don't care about extraneous spaces or aligning declarations, but
would like to remove tabs
> - Remove extraneous spaces from Javadoc (again, we use tabs to
> align things a lot).
don't care
> - Collapse double-blank lines into a single blank line (we use 2
> blank lines for block separators a lot).
don't care
> - Make above changes without creating lines over 80 chars.
yes
>
> My formatter does all the above except the explicit imports, and it
> sometimes create lines over 80 chars when moving up extends/
> implements/throws lines. Not mentioned on the list: it's also able
> to take a previously-continued line and turn it back into a single
> line if the above changes cause the single line to now be <= 80 chars.
>
> If IDE's can't do that, then perhaps a hybrid approach where we use
> my formatter to get everything most of the way there, then use an
> IDE to get the explicit imports as we go along. This also has the
> advantage of getting everything into an almost-there style in one
> fell swoop, rather than having two totally different styles until
> someone with an IDE opens all the files eventually.
>
> Note that until we can get everything necessary from Kodo into
> OpenJPA, we probably don't want to mess with formatting, because we
> have to be able to merge changes back and forth between the
> codebases easily.
I like the idea of a massive change early in the cycle (before the
initial checkin is fine, or sometime shortly thereafter). For the
first week or so, I'm mostly going to be reading the code anyway.
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: java.util.concurrent
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I'm using IntelliJ (Eclipse does the same thing) so that you set the coding standards in a template
and it will auto indent, line break, handle imports, etc. It would be a plus if we followed general
development patterns from the existing projects as it will reduce the effort when people work on
projects and go back and forth.
Also, Abe, you mentioned a tool. Are you donating that to the project (it might already be in the
tree :)
Matt
Abe White wrote:
>> But not everyone favors it. For a project like this, where there are
>> multiple people working on things, having the imports called out really
>> helps.
>>
>> What's the downside?
>
> Just that it's verbose and makes writing imports by hand take longer.
> But I don't feel strongly about it. I'm find with explicit imports if
> that's the consensus.
>
>
>> I'm a "before dot" man myself so it's clear from just looking at the
>> beginning of the line it's a method/field.
>
> I'm an after dot person, but again I'm fine with whatever, including not
> enforcing any particular policy on this.
>
>> How about just configuring IDEA/Eclipse to do it right, and fixing
>> things as we go along?
>
> I like the idea of using an IDE to fix everything. I don't use an IDE
> myself, so I don't know whether it can make the necessary fixes. Here's
> a list of changes necessary to get SolarMetric code looking more like
> the standards we've outlined:
> - Change to explicit imports.
> - Move opening brace to same line.
> - Move up "else" and "catch" to same line as previous closing brace.
> - Move up "extends" and "implements" to same line as class declaration.
> - Move up "throws" to same line as method declaration.
> - Remove spaces before opening parens on method calls.
> - Change tabs to spaces.
> - Remove extraneous spaces from field declarations (we tend to align
> declarations with tabs, so converting the tabs to spaces make sit look
> horrible... plus I'd like to just stop aligning declarations altogether
> anyway).
> - Remove extraneous spaces from Javadoc (again, we use tabs to align
> things a lot).
> - Collapse double-blank lines into a single blank line (we use 2 blank
> lines for block separators a lot).
> - Make above changes without creating lines over 80 chars.
>
> My formatter does all the above except the explicit imports, and it
> sometimes create lines over 80 chars when moving up
> extends/implements/throws lines. Not mentioned on the list: it's also
> able to take a previously-continued line and turn it back into a single
> line if the above changes cause the single line to now be <= 80 chars.
>
> If IDE's can't do that, then perhaps a hybrid approach where we use my
> formatter to get everything most of the way there, then use an IDE to
> get the explicit imports as we go along. This also has the advantage of
> getting everything into an almost-there style in one fell swoop, rather
> than having two totally different styles until someone with an IDE opens
> all the files eventually.
>
> Note that until we can get everything necessary from Kodo into OpenJPA,
> we probably don't want to mess with formatting, because we have to be
> able to merge changes back and forth between the codebases easily.
> _______________________________________________________________________
> 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.
>
>
>
Re: java.util.concurrent
Posted by Abe White <aw...@bea.com>.
> But not everyone favors it. For a project like this, where there are
> multiple people working on things, having the imports called out
> really
> helps.
>
> What's the downside?
Just that it's verbose and makes writing imports by hand take
longer. But I don't feel strongly about it. I'm find with explicit
imports if that's the consensus.
> I'm a "before dot" man myself so it's clear from just looking at the
> beginning of the line it's a method/field.
I'm an after dot person, but again I'm fine with whatever, including
not enforcing any particular policy on this.
> How about just configuring IDEA/Eclipse to do it right, and fixing
> things as we go along?
I like the idea of using an IDE to fix everything. I don't use an
IDE myself, so I don't know whether it can make the necessary fixes.
Here's a list of changes necessary to get SolarMetric code looking
more like the standards we've outlined:
- Change to explicit imports.
- Move opening brace to same line.
- Move up "else" and "catch" to same line as previous closing brace.
- Move up "extends" and "implements" to same line as class declaration.
- Move up "throws" to same line as method declaration.
- Remove spaces before opening parens on method calls.
- Change tabs to spaces.
- Remove extraneous spaces from field declarations (we tend to align
declarations with tabs, so converting the tabs to spaces make sit
look horrible... plus I'd like to just stop aligning declarations
altogether anyway).
- Remove extraneous spaces from Javadoc (again, we use tabs to align
things a lot).
- Collapse double-blank lines into a single blank line (we use 2
blank lines for block separators a lot).
- Make above changes without creating lines over 80 chars.
My formatter does all the above except the explicit imports, and it
sometimes create lines over 80 chars when moving up extends/
implements/throws lines. Not mentioned on the list: it's also able
to take a previously-continued line and turn it back into a single
line if the above changes cause the single line to now be <= 80 chars.
If IDE's can't do that, then perhaps a hybrid approach where we use
my formatter to get everything most of the way there, then use an IDE
to get the explicit imports as we go along. This also has the
advantage of getting everything into an almost-there style in one
fell swoop, rather than having two totally different styles until
someone with an IDE opens all the files eventually.
Note that until we can get everything necessary from Kodo into
OpenJPA, we probably don't want to mess with formatting, because we
have to be able to merge changes back and forth between the codebases
easily.
_______________________________________________________________________
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.
Re: java.util.concurrent
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jun 2, 2006, at 12:57 PM, Geir Magnusson Jr wrote:
>
> Abe White wrote:
>> Craig Russell wrote:
>>> Consistency is good. I look forward to helping out. By the way, it
>>> might be good to take a look at the OpenJPA coding guidelines at
>>> http://incubator.apache.org/openjpa/ which I made up (based on the
>>> Geronimo standards. The guidelines can be changed to suit our
>>> project,
>>> but please take a look.
>>
>> Actually, the coding standards link from the above page goes
>> directly to
>> the Geronimo project standards. You seem to imply that maybe you
>> meant
>> to copy their standards into our own document?.
Sorry for the confusion. I didn't change the Geronimo document at
all, and the web site does directly link to the Geronimo standards.
>>
>> Anyway, currently we have a formatter that produces code with the
>> following significant differences from the linked guidelines:
>> - Uses package.* imports, rather than importing every class. I
>> personally favor this approach because dependencies tend to be
>> package-level anyway, and it's what we've historically used with
>> Kodo.
>
> But not everyone favors it. For a project like this, where there are
> multiple people working on things, having the imports called out
> really
> helps.
I also like explicit imports, because it's easy to see what you are
doing. It really helps if you see a class in the middle of the source
that you're not familiar with to be able to go to the imports list
and actually tell whence it cometh. Of course, a good IDE can also
tell you that, but I don't think we should rely on IDE tricks.
>
> What's the downside?
>
>> - Indents line continuations one logical tab (4 spaces), rather than
>> indenting 2 tabs or attempting to align the continued line with the
>> previous (for example, aligning method parameter declarations).
>
> seems reasonable.
I'm not really too concerned about this one. Readability is the most
important thing. If I have a tool that automatically does this for
me, fine. But I wouldn't refuse a patch because of a missing (or
extra) indentation on a continuation line.
>
>> - The formatter retains inconsistencies in our existing source. I
>> believe the only noticeable one is that the SolarMetric developers
>> all
>> like to break continued lines at different points (before opening
>> paren,
>> after opening paren, before dot in call chain, after dot, etc).
>
> I'm a "before dot" man myself so it's clear from just looking at the
> beginning of the line it's a method/field.
I also prefer before dot but have no preferences wrt before/after paren.
>
>>
>> We tried the free version of Jalopy and it didn't work well for
>> us, so
>> the formatter I'm referring to is an in-house formatter I wrote that
>> doesn't create a syntax tree -- it just looks for certain SolarMetric
>> formatting constructs with regexps and changes them to be more Sun-
>> like
>> in style. So if we want a different style, we'll probably have
>> to see
>> about purchasing a commercial formatter, since my regexp approach is
>> very limited.
>
> How about just configuring IDEA/Eclipse to do it right, and fixing
> things as we go along?
I use Netbeans and it does auto-import and auto-space-indent but
doesn't have other formatting enforcement rules as far as I know. I
guess if there is a tool that you can run against patch files I'd be
willing to use it before a checkin...
Craig
>
> geir
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: java.util.concurrent
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Abe White wrote:
>> Consistency is good. I look forward to helping out. By the way, it
>> might be good to take a look at the OpenJPA coding guidelines at
>> http://incubator.apache.org/openjpa/ which I made up (based on the
>> Geronimo standards. The guidelines can be changed to suit our project,
>> but please take a look.
>
> Actually, the coding standards link from the above page goes directly to
> the Geronimo project standards. You seem to imply that maybe you meant
> to copy their standards into our own document?.
>
> Anyway, currently we have a formatter that produces code with the
> following significant differences from the linked guidelines:
> - Uses package.* imports, rather than importing every class. I
> personally favor this approach because dependencies tend to be
> package-level anyway, and it's what we've historically used with Kodo.
But not everyone favors it. For a project like this, where there are
multiple people working on things, having the imports called out really
helps.
What's the downside?
> - Indents line continuations one logical tab (4 spaces), rather than
> indenting 2 tabs or attempting to align the continued line with the
> previous (for example, aligning method parameter declarations).
seems reasonable.
> - The formatter retains inconsistencies in our existing source. I
> believe the only noticeable one is that the SolarMetric developers all
> like to break continued lines at different points (before opening paren,
> after opening paren, before dot in call chain, after dot, etc).
I'm a "before dot" man myself so it's clear from just looking at the
beginning of the line it's a method/field.
>
> We tried the free version of Jalopy and it didn't work well for us, so
> the formatter I'm referring to is an in-house formatter I wrote that
> doesn't create a syntax tree -- it just looks for certain SolarMetric
> formatting constructs with regexps and changes them to be more Sun-like
> in style. So if we want a different style, we'll probably have to see
> about purchasing a commercial formatter, since my regexp approach is
> very limited.
How about just configuring IDEA/Eclipse to do it right, and fixing
things as we go along?
geir
Re: java.util.concurrent
Posted by Abe White <ab...@mac.com>.
> Consistency is good. I look forward to helping out. By the way, it
> might be good to take a look at the OpenJPA coding guidelines at
> http://incubator.apache.org/openjpa/ which I made up (based on the
> Geronimo standards. The guidelines can be changed to suit our
> project, but please take a look.
Actually, the coding standards link from the above page goes directly
to the Geronimo project standards. You seem to imply that maybe you
meant to copy their standards into our own document?.
Anyway, currently we have a formatter that produces code with the
following significant differences from the linked guidelines:
- Uses package.* imports, rather than importing every class. I
personally favor this approach because dependencies tend to be
package-level anyway, and it's what we've historically used with Kodo.
- Indents line continuations one logical tab (4 spaces), rather than
indenting 2 tabs or attempting to align the continued line with the
previous (for example, aligning method parameter declarations).
- The formatter retains inconsistencies in our existing source. I
believe the only noticeable one is that the SolarMetric developers
all like to break continued lines at different points (before opening
paren, after opening paren, before dot in call chain, after dot, etc).
We tried the free version of Jalopy and it didn't work well for us,
so the formatter I'm referring to is an in-house formatter I wrote
that doesn't create a syntax tree -- it just looks for certain
SolarMetric formatting constructs with regexps and changes them to be
more Sun-like in style. So if we want a different style, we'll
probably have to see about purchasing a commercial formatter, since
my regexp approach is very limited.
Re: java.util.concurrent
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Abe,
First, welcome to the OpenJPA mailing list.
On May 31, 2006, at 6:36 PM, Abe White wrote:
> 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 (http://
> dcl.mathcs.emory.edu/util/backport-util-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.
The JDO project has a couple of classes that are not highly
concurrent but use weak references. WeakHashSet and WeakValueHashMap
are useful for persistent object caches. They are copyright Apache so
just take them if they are useful.
>
> 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.
Consistency is good. I look forward to helping out. By the way, it
might be good to take a look at the OpenJPA coding guidelines at
http://incubator.apache.org/openjpa/ which I made up (based on the
Geronimo standards. The guidelines can be changed to suit our
project, but please take a look.
Craig
> ______________________________________________________________________
> _
> 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.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: java.util.concurrent
Posted by Eddie O'Neil <ek...@gmail.com>.
Yeah, I agree with Brian -- the original concurrency utils are great
and are basically the code that ended up in the JDK in 1.5. Beehive
took a look at those about a year ago and deemed that the license ASF
compatible and repackaged / committed them to our code base. Seems
like that might be really useful here.
One suggestion for enforcing a code style is to use the Checkstyle
tool to actively enforce a style than to hope for the best. It's
over here:
http://checkstyle.sourceforge.net/
Various projects use it, and it's pretty configurable.
Abe, thanks for introducing yourself!
Eddie
On 5/31/06, Brian McCallister <br...@apache.org> wrote:
>
> On May 31, 2006, at 6:36 PM, Abe White wrote:
>
> > 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 (http://dcl.mathcs.emory.edu/util/backport-
> > util-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.
>
> Doug Lea's original concurrency utils ( http://g.oswego.edu/dl/
> classes/EDU/oswego/cs/dl/util/concurrent/intro.html ) are very good
> in jdk 1.4/1.3.
>
> -Brian
>
Re: java.util.concurrent
Posted by Abe White <ab...@mac.com>.
> Doug Lea's original concurrency utils ( http://g.oswego.edu/dl/
> classes/EDU/oswego/cs/dl/util/concurrent/intro.html ) are very good
> in jdk 1.4/1.3.
Doug seems to recommend using the backport instead of his libs on the
linked page, though.
Re: java.util.concurrent
Posted by Brian McCallister <br...@apache.org>.
On May 31, 2006, at 6:36 PM, Abe White wrote:
> 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 (http://dcl.mathcs.emory.edu/util/backport-
> util-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.
Doug Lea's original concurrency utils ( http://g.oswego.edu/dl/
classes/EDU/oswego/cs/dl/util/concurrent/intro.html ) are very good
in jdk 1.4/1.3.
-Brian