[ 
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Ryall updated CODEC-96:
----------------------------

    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:

{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.


  was:
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() {
        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.



> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.

Reply via email to