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.....
But in the case of BCodec, I think encode/decode is thread safe. Unfortunately per Henri, that's not generally true for others. Well, let me make it clear that I am a total layman on codec. But it seems to me it's not that difficult to implement all the codec methods in a thread safe manner, without sync blocks. Can the dev team make that happen? - a humble request from a user. Thanks, -Q On 10/6/07, ben short <[EMAIL PROTECTED]> wrote: > How about... > > MyStringCodec { > BCodec delegate = new BCodec(); > > String encode(String in) { > > String result = null; > > synchronized(delegate) > { > result = delegate.encode(in); > } > > return result; > > } > } > > > On 10/6/07, Qingtian Wang <[EMAIL PROTECTED]> wrote: > > Henri, > > > > That was an unpleasant surprise. > > > > So what would be the general suggested program pattern to use the API > > if one wants to be thread safe? > > > > Is it 1: > > > > MyStringCodec { > > String encode(String in) { > > return new BCodec().encode(in); > > } > > } > > > > or 2: > > > > MyStringCodec { > > BCodec delegate = new BCodec(); > > > > String encode(String in) { > > return delegate.encode(in); > > } > > } > > > > Option 2 apparently won't work in a multi-thread scenario if BCodec is > > thread unsafe. But option 1 really creates A LOT of BCodec objects in > > memory.... > > > > -Q > > > > > > > > > > On 10/5/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On 9/29/07, Qingtian Wang <[EMAIL PROTECTED]> wrote: > > > > I apologize for this question as it must have been asked a million > > > > times: I was unable to search the mailing list archive for this. > > > > > > > > Are all the "encode/decode" methods in commons-codec intended to be > > > > thread safe? > > > > > > > > I peeked into the source code for a couple of those methods. They both > > > > seem to be thread safe. But I'd rather ask here to make sure that's > > > > the general intention when the code is written. > > > > > > I think you'll find it varies. The various algorithms come from > > > different sources, and though a common interface was put on them all, > > > I doubt that time was spent to make sure they were all threadsafe. > > > > > > Looking at the objects, I see a few with private attributes that are > > > set at more than just construction time - so very likely that one or > > > another is thread unsafe. > > > > > > Hen > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > 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]