commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Qingtian Wang (JIRA)" <>
Subject [jira] Commented: (CODEC-55) make all "business" method implementations of public API thread safe
Date Tue, 09 Oct 2007 19:42:50 GMT


Qingtian Wang commented on CODEC-55:

First let me mention again, in the user case where

. The thread-unsafe dependencies/setups are invoked once during the object instantiation,
and subsequently, only the biz methods (such as encode/decode) are invoked during the entire
life span of the instantiated object.

It's good enough to have only the biz methods thread safe while others are not, as long as
the such fact is well documented. That way, there is no need to deprecate setter style dependency
injection since some might like it that way over constructor injection, which is just a style

IMO, just to make matters simple, thread-unsafe biz methods like "encode(String in, String
charset)" should not even be supported (I don't even know whether such methods exist currently).
If the user needs a different charset, create a different instance just for that charset.
Usually the number of charsets an application needs is always pre-defineable and a finite
amount. Therefore, the number is instances needed by the application is also finite as opposed
to runtime decided, which is good enough in terms of memory concerns. 

And secondly, if we agree that the above mentioned use case is the most common use case, and
it's well documented as to which methods are thread safe and which are not, there is no need
for extra work such as having factory methods or static wrappers to create an "absolutely
thread safe" version of the objects.

> make all "business" method implementations of public API thread safe 
> ---------------------------------------------------------------------
>                 Key: CODEC-55
>                 URL:
>             Project: Commons Codec
>          Issue Type: Wish
>            Reporter: Qingtian Wang
>         Attachments: concurrentCodecs.diff, concurrentQDiff.diff, urlcodec.patch
> Maybe most of the implementations are already thread safe. Just such that codec can say
so in general...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message