From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> It seems to me that SynchronizedQueue might fit better into a package of
> classes specifically focused on communicating between threads in a
> multi-thread application. One such set of classes is my
> "threading" proposal in the sandbox. Another possible source was
> suggested on the list today (the "util.concurrent" thread).
>
> What would you think about focusing the "collections" package on things
> that are independent of multi-thread communication assumptions, and having
> a separate Commons package ("threading" or "multithread" or whatever) that
> is specifically focused on that need?
I think thats a good idea, yes.
The SynchronizedQueue would probably be better being either submitted to the
"threading" sandbox or quietly replaced by something else that's already in
there.
A quick peek in the threading sandbox and it looks like the existing
LIFOQueue / FIFOQueue would probably do just fine, though I'd better take a
look at the source code to be sure. Though I'd prefer a couple of minor
changes ;-)
* use size() method rather than getCount() to be more Java 2
collections-like
* add a new dequeueNoWait() method that doesn't block and returns null if
there is no object available.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
