commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <>
Subject [jira] Commented: (CODEC-95) Base64: optionally allow strict parsing of base64 strings
Date Wed, 26 Jan 2011 15:39:43 GMT


Sebb commented on CODEC-95:

No, in this case I'm not advocating this for MT safety.

The codecs are not thread-safe currently, and AFAICT cannot easily be made so, because the
buffers etc are not synch - nor should they be.

The codecs should be used per-thread only.

But the point about final variables and additional mutable state still applies within a single

If there is a setter - e.g. to change validation - should that be allowed to be used arbitrarily
during  processing?
Or only between usages of the instance?
In either case, additonal testing is needed to esnure that the new settings are handled correctly.

If the setter is only allowed before intial processing, how is that enforced? 
Or is it purely a documentation issue?

> Base64: optionally allow strict parsing of base64 strings
> ---------------------------------------------------------
>                 Key: CODEC-95
>                 URL:
>             Project: Commons Codec
>          Issue Type: Improvement
>    Affects Versions: 1.4
>            Reporter: Adam Rabung
>            Priority: Minor
>         Attachments:
> Currently, Codec skips base64 characters that are outside of the encode table.  I realize
this is perfectly to spec, but I wonder if other users might appreciate a "strict" mode that
throws an exception when one of these illegal characters are encountered.  For example, I
would love an exception to be thrown here:
> new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message