Right. Such a component would contain evertything that is NOT in j.u.c., but still useful. This means it, it would be an addtion, not a replacement for j.u.c.
What could be useful, but is not in j.u.c is subject to discussion. This might be stuff that is NOT YET in j.u.c because exisiting solution do not have the quality to go there, yet. Or the scope of the code is more than general than what is inside j.u.c Examples for category I (not mature enough) might be the lock manager I was talking about. Category II (broader scope) might be the lock implementation that is geared towards resource locking. Or maybe more concurrent collections. Or pther special lock implementations. Or locks with deadlock detections (like in commons transaction). Does that make sense? Oliver 2007/10/3, Ben Speakmon <[EMAIL PROTECTED]>: > My ears prick up at any mention of concurrency! > > What's the scope of this, though? With Doug Lea's library, the > util.concurrent backport, and the JDK 5+ built-ins, what else is needed? > > On 10/3/07, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > > > > Folks! > > > > I was wondering if anyone would be interested in a component for > > classes that help you with concurrent programming. An initial > > contribution could be the locking manager including Lock > > implementations. > > > > Anyone? > > > > Cheers > > > > Oliver > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
