I'd suggest something like the following strategy: * Add this backport to the thirdparty * Allow projects currently under development to use it, e.g. JMS, MC * When those projects confirm it is usable worry about porting old code using oswego
The idea being that people doing development are more likely to investigate any problems and don't have to worry about changes in semantics between supposedly similar classes. Additionally, there are already two abstractions: org.jboss.util.threadpool wraps pooled executor org.jboss.util.CollectionsFactory allows the concurrent set impls to be modified There are no current abstractions for things like synchronizedBoolean or the locks/semaphores. On Fri, 2006-01-20 at 17:32, Scott M Stark wrote: > So all of the retroweavers to date rely on the java.util.concurrent > backport to jdk1.4 > (http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) for > mapping the jdk5 concurrent util classes. I guess we need to validate > this library and deprecate the current Oswego concurrent package in > favor of this if its seen to be solid to promote reuse of a common > jdk1.4 compatible library. I have not found any stability comparison > between the dl.util.concurrent and backport-util-concurrent libraries. -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
