commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Pugh <>
Subject Re: codec - thread safe
Date Tue, 09 Oct 2007 17:04:11 GMT
sebb wrote:
> 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.
I attached a patch to this bug.

My solution here was to add static methods called

on all the classes that are thread safe.  For a few, this simply returns 
an instance of the object.  For others, it returns an instance of the 
object that overrides the dangerous set* methods.  That way, if anyone 
tried to use it in an unsafe manner, they will deterministically get an 

My patch also adds a blurb in package.html basically saying this.
>> 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.
I agree.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message