From user-return-20029-apmail-commons-user-archive=commons.apache.org@commons.apache.org Tue Oct 09 09:27:52 2007 Return-Path: Delivered-To: apmail-commons-user-archive@www.apache.org Received: (qmail 99431 invoked from network); 9 Oct 2007 09:27:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Oct 2007 09:27:49 -0000 Received: (qmail 62184 invoked by uid 500); 9 Oct 2007 09:27:33 -0000 Delivered-To: apmail-commons-user-archive@commons.apache.org Received: (qmail 62117 invoked by uid 500); 9 Oct 2007 09:27:33 -0000 Mailing-List: contact user-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list user@commons.apache.org Received: (qmail 62108 invoked by uid 99); 9 Oct 2007 09:27:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Oct 2007 02:27:33 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates 209.85.198.186 as permitted sender) Received: from [209.85.198.186] (HELO rv-out-0910.google.com) (209.85.198.186) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Oct 2007 09:27:35 +0000 Received: by rv-out-0910.google.com with SMTP id k20so1128137rvb for ; Tue, 09 Oct 2007 02:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ePnTExxcUJBDwi2kKhZiRruQDDOZ/lUgUAjBvq7GH2k=; b=B1TCos6lO2iiTdcPiQb+Uv4upXNaRktt25Ajt1w11B1ne3F30E2TFYMf/MKbosl+iQ+RXbXZampluBWk/OhLw8G3UfIQkznJK0Z6de2zAAqecf3lXYIlAijSE9I4zLi3PeBgzNJZahMm7rJamOswye9t1lEFD/KtXzKeEzzkf4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JTLhtLQGUAT/hqjggaA+hwtb3K1RY8SfWIQ94EbhUcjOWvKr+Y49+yUZCA6rb9v6bzZUczKcmXFZ3DK60zkanH0sCBe2/e4VIIR9QMxkMc3XUk5rlKsz5rqkCnbKOjd9b3n5+ztBfAGF4D0x2zhSjLaOud9d5o0YBfb+fp2i7+0= Received: by 10.141.145.11 with SMTP id x11mr3376576rvn.1191922034278; Tue, 09 Oct 2007 02:27:14 -0700 (PDT) Received: by 10.141.193.7 with HTTP; Tue, 9 Oct 2007 02:27:14 -0700 (PDT) Message-ID: <25aac9fc0710090227o4d33829av7a291811e627f47b@mail.gmail.com> Date: Tue, 9 Oct 2007 10:27:14 +0100 From: sebb To: "Jakarta Commons Users List" Subject: Re: codec - thread safe In-Reply-To: <49645ccf0710081910i15566dc9l970bc6bbe2f1f5bc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49645ccf0709292130ud20383y756f33415e224e31@mail.gmail.com> <20071008151647.2B58E72486B@athena.apache.org> <470A5A32.1010402@sourcelabs.com> <25aac9fc0710080956k23d8cb06ye68c3a00bb9800ec@mail.gmail.com> <470A98F4.5070802@sourcelabs.com> <49645ccf0710081508ia79e768g2c3c0c73dc039387@mail.gmail.com> <25aac9fc0710081553t18cd49e8jd4f57210371f6398@mail.gmail.com> <49645ccf0710081910i15566dc9l970bc6bbe2f1f5bc@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org 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: user-unsubscribe@commons.apache.org For additional commands, e-mail: user-help@commons.apache.org