commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
Date Wed, 21 Mar 2012 01:06:39 GMT

    [ https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234003#comment-13234003
] 

Sebb commented on CODEC-96:
---------------------------

I've got a prototype which passes all the tests.
Basically I put all the mutable fields in a Context class which is created by the appropriate
stream classes and public methods. This allows the BaseN classes to be immutable i.e. threadsafe.

Clirr reports several incompatibilities because I moved all the protected mutable fields into
the context.

However, these are protected fields, and are not really intended for use by external code,
so it's very unlikely to cause problems. I did not need to change the test code (except where
it was overriding or testing package-protected methods), which is a good sign.

See attachment to follow.
                
> 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

        

Mime
View raw message