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 of some > reasonable size and submit a FutureTask > to run the encode or decode, and then do a future.get() when > the value is needed. You might > even get some concurrency if you can start the encode, then continue > doing other work until you need the result.
Because it runs on JDK 1.3? 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 :) - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
