commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject RE: codec - thread safe
Date Mon, 08 Oct 2007 14:23:59 GMT
David J. Biesack wrote on Monday, October 08, 2007 3:02 PM:

>> Date: Sat, 6 Oct 2007 23:31:19 -0500
>> From: "Qingtian Wang" <>
>> 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:
For additional commands, e-mail:

View raw message