Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.4
-
None
Description
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:
class Example { private BinaryEncoder encoder = new Base64(); byte[] someMethod(byte[] data) { try { return encoder.encode(data); } catch (EncoderException e) { throw new RuntimeException(e); } } }
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:
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)
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.