[
https://issues.apache.org/jira/browse/CODEC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533087
]
Sebb commented on CODEC-55:
---------------------------
This would require creating two instances of the QCodec class, one for true and
the other for false. Not obvious. However there is still a problem.
The setEncodeBlanks() method updates an instance field. The field is not marked
volatile, and the method is not synchronized.
Therefore if thread A creates the class and then updates the field, thread B
will not necessarily see the same value.
This is a consequence of the Java Memory Model - the JMM allows threads to keep
local copies of shared variables.
Only by synchronising - or using volatile - does the JMM mandate that the
memory will be updated.
So I think QCodec is only thread-safe if setEncodeBlanks() is not used.
The only way to fix this for all conditions is to make the encodeBlanks setting
part of the constructor.
> 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
>
> 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.
