[
https://issues.apache.org/jira/browse/CODEC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533944
]
Qingtian Wang commented on CODEC-55:
------------------------------------
First, as the opener of this issue, let me say for sure that
"QCodec is definitely not thread-safe; the method setEncodeBlanks() updates an
instance variable."
is definitely NOT the reason the issue is opened, although that was the first
comment to the issue.
Secondly, again as the opener is this issue, I think as long as all the
interface methods (I used to refer them as business methods, which sort of
caused confusion) are thread-safe, it's good enough for me.
The documentation should clearly say which method is thread safe (in this case
interface methods), which is not (setters for instance).
The concern of calling setters after the object is instantiated is just a
matter of style: constructor injection of dependency vs. setter injection. The
implications of those two styles are pretty well known. So it's no big deal to
me, and is not what this issue is about - This issue is about thread safety of
the interface/business methods.
If it is strongly that non-interface/business methods thread safety is an
important issue (to me it isn't), please open a separate issue for discussion.
> 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.