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