> Date: Mon, 8 Oct 2007 16:23:59 +0200 > From: =?iso-8859-1?Q?J=F6rg_Schaible?= <[EMAIL PROTECTED]> > > David J. Biesack wrote on Monday, October 08, 2007 3:02 PM: > > >> Date: Sat, 6 Oct 2007 23:31:19 -0500 > >> From: "Qingtian Wang" <[EMAIL PROTECTED]> > >> > >> Well, it's pick-your-poison kind of a deal. Either block on one > >> instance and take a performance hit, or burn up the memory with lots > >> of instances..... > > > > Why not compromise? Create a ThreadPoolExecutor ... > > Because it runs on JDK 1.3?
The java.util.concurrent backport http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this kind of use. > However, that's the reason why I argumented not to promise thread-safety for > any codec and provide synchronization wrappers or a user might take the pool > approach ... which is quite easy with JDK 5 as you've provided here :) I think it makes a lot of sense to document the thread safety attributes of Commons libraries. > - Jörg -- David J. Biesack SAS Institute Inc. (919) 531-7771 SAS Campus Drive http://www.sas.com Cary, NC 27513 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
