commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: codec - thread safe
Date Tue, 09 Oct 2007 09:27:14 GMT
On 09/10/2007, Qingtian Wang <> wrote:
> On 10/8/07, sebb <> wrote:
> > Which methods do you actually need?
> >
> > If you only need BCodec, then that (and Base64 which it calls) look to
> > be thread-safe, so you only need to instantiate it once for each
> > different charset.
> Yes, I sort of figured that out for myself already when I first
> started the conversation with Henri. Now thanks for your help, I got
> another pair of eyes confirming this. So I am good in my case.
> But all the discussion has been more about the "in general" case. I
> just feel that,
> 1. Codec as a commons library, it should not be this hard to find out
> about information like this. It should be either this or that, "find
> out for yourself" is no good situation. As someone else pointed out
> earlier, we could use a better documentation.

Agreed. It should be stated clearly whether or not the code is thread-safe.

> 2. It'd be nice for the biz method implementations to be thread safe
> (Ideally in a high performance manner as a value add-on of using a
> commons brand library such that user doesn't have to be too creative
> as some of the suggestions given in this discussion to achieve
> performance). Most of them may already be thread safe. And as it seems
> agreed by all that it's not hard to make them that way if not.

For a library such as codec, I agree that it should be thread-safe by
design. Where this is not possible, the unsafe classes should be
clearly identified.

I don't think it makes sense to separate methods into "biz" and the rest.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message