On Aug 29, 2006, at 4:13 PM, Dain Sundstrom wrote:
Wow! I never expected you to do the conversion... very cool.
Well... I can write code... I'm not just a build system foolio :-P
Here are the notes from my review (I think only the first item is
necessary and the rest are ideas or observations):
I don't think we need to import the Latch class from
concurrent. We should be able to use the CountDownLatch class with
the initial size set to 1. This will also let us avoid the long
discussion on the proper way to import the code :)
Ah, I missed that, did not see CountDownLatch... I prefer that to
importing the code.
It doesn't look like AbstractSinglePoolConnectionInterceptor
ever uses the writeLock in the ReentrantReadWriteLock so it may be
possible to replace that lock with a simpler ReentrantLock.
Aight.
I never noticed that Java5 atomics only have an incrementAndGet
method and no increment method
Ya... no such method... I think they wanted to be explicit when the
increment happened and what is returned. All of the usages I could
see don't care about the return value anyways, so we could have used
either incrementAndGet or getAndIncrement.
The changes in the configuration for the Executor in Java5 seem
much better.
I did run into one issue with ThreadPoolExecutor... this has no wait
policy, and some discussion online related indicate that it was not
added to java.util.concurrent stuff because it was not very safe or
friendly todo... or something like that.
I was not sure exactly how to get around that and use the standard
policies, so I wrote a wait policy that does basically the same thing
(i think) as the wait policy for PooledExecutor.
--jason
