RFR 8025003: Base64 should be less strict with padding
Alan Bateman
Alan.Bateman at oracle.com
Thu Oct 24 15:40:47 UTC 2013
On 23/10/2013 23:42, Xueming Shen wrote:
> :
>
> Here is the webrev
>
> http://cr.openjdk.java.net/~sherman/8025003/webrev/
I've looked through the changes.
The method rename make sense as it is a MIME Encoder. Also I think
having the MIME Decoder be lenient is reasonable too. There will be
cases where someone might need it to be strict but that can be added at
another time (and there are API choices for that).
A minor comment on the Decoder spec is that a comma before "and if there
is padding character present in the final unit," would make the sentence
a bit easier to read.
The implementation changes look okay although this is an area where good
tests are important. I notice that you've commented out one of checkIAE
tests in TestBase64, I assume that should be removed. Do you think that
testLenientPadding is sufficient? I recall the initial bug tail when the
implementation was original lenient.
-Alan.
More information about the core-libs-dev
mailing list