[CODEC-96] Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.4
• Fix Version/s: 1.7
• Assignee: Unassigned
• Reporter: Matt Ryall
• Created: 26/Feb/10 04:59
• Updated: 14/Sep/12 20:27
• Resolved: 03/Apr/12 17:25

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.

Issue Links

• relates to: CODEC-97 Base64 default constructor behaviour changed to enable chunking in 1.4
• relates to: CODEC-69 Streaming Base64