[ 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 [~joc...@apache.org]'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