sebb wrote:
On 09/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote:
On 10/8/07, sebb <[EMAIL PROTECTED]> 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
createThreadSafeCodec
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
error.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
