[ 
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.

Reply via email to