[
https://issues.apache.org/jira/browse/CODEC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533466
]
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 matter.
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: https://issues.apache.org/jira/browse/CODEC-55
> 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.
