[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233234#comment-13233234
]
Matt Ryall commented on CODEC-96:
---------------------------------
I'm happy to have it resolved if there's Javadoc saying that the class isn't
thread-safe. That's the most important thing.
Arguably encoder classes like this _should_ be thread-safe, since I can't see
anything in base-64 encoding that should require state across method calls, but
that's up to the maintainers. In response to [[email protected]]'s comment,
the main problem is that this particular encoder was thread-safe before, and
was used this way in one of the multi-threaded applications that I maintain,
and upgrading commons-codec broke it in a non-obvious way.
Despite being the original reporter, I don't have the necessary JIRA power to
resolve the issue, so someone else will have to do it.
> Base64 encode() method is no longer thread-safe, breaking clients using it as
> a shared BinaryEncoder
> ----------------------------------------------------------------------------------------------------
>
> Key: CODEC-96
> URL: https://issues.apache.org/jira/browse/CODEC-96
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Matt Ryall
> Assignee: Julius Davies
> Fix For: 1.x
>
> Attachments: codec-96-3rd-attempt.patch
>
>
> Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
> This introduced instance variables to Base64 which means the class can no
> longer be used as a shared BinaryEncoder instance.
> For example, BinaryEncoder has an interface which could be (and was) used
> like this with Base64:
> {code:java}
> class Example {
> private BinaryEncoder encoder = new Base64();
> byte[] someMethod(byte[] data) {
> try {
> return encoder.encode(data);
> }
> catch (EncoderException e) {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
> which is accessed by multiple threads can throw NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
> at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
> at ... (application code)
> {noformat}
> Looking at the implementation of Base64, I think making it thread-safe for
> this kind of usage would be quite tricky. I haven't attempted to prepare a
> patch.
> I would be happy if it was indicated in the Javadoc that Base64 is not
> thread-safe and should not be shared. However, some other users of
> commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
