You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Matt Ryall (JIRA)" <ji...@apache.org> on 2010/02/26 06:22:27 UTC
[jira] Updated: (CODEC-96) Base64 encode() method is no longer
thread-safe, breaking clients using it as a shared BinaryEncoder
[ 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.