RFR: 8026330: java.util.Base64 urlEncoder should omit padding

[Xueming Shen]

On 11/08/2013 06:00 AM, Alan Bateman wrote:
> On 06/11/2013 18:44, Xueming Shen wrote:
>> Hi,
>>
>> The latest spec and implementation of java.util.Base64.getXXXEncoder()
>> is to add appropriate padding character(s) at the end of the output
>> encoded data stream, to follow the note explicitly specified in the
>> RFC
>>
>>    Implementations MUST include appropriate pad characters at the end
>>    of encoded data unless the specification referring to this document
>>    explicitly states otherwise.
>>
>> However the RFE also mentions that
>>
>>    In some circumstances, the use of padding ("=") in base-encoded data
>>    is not required or used...
>>
>> Feedback so far also suggests that Base64.encoder without padding might
>> be desired in some real world use scenario.
>>
>> So here is the webrev to add a new method to the Encoder class to return
>> a non-padding version.
>>
>> http://cr.openjdk.java.net/~sherman/8026330/webrev
> The API looks okay although some developers might not initially recognize that an Encoder is immutable. In particularly, this statement might not be clear:
>
>   "This instance of encoder is unaffected by this invocation."
>
> What you would think about including an example in the javadoc so that it's clear how to get an Encoder that doesn't emit padding?

I have updated that statement to be more verbose and obvious

          *
          * <p> The encoding scheme of this encoder instance is unaffected by
          * this invocation. The returned encoder instance should be used for
          * non-padding encoding operation.
          *

Hope it is now clear enough. Personally I feel it might be clearer than an example
like
     Base64.Encoder nonPaddingEncoder = Base64.getEncoder().withoutPadding();

>
> Otherwise this looks good except that I wonder about needing to eagerly create all 6 Encoders.
>

Given the non-padding encoder is supposed to not be used "frequently" as
the standard one, and the encoder is really a "simple"/not-expensive object,
I removed the singleton approach for the non-padding encoders. We can add
any time later, if requested/ pointed out to be necessary.

http://cr.openjdk.java.net/~sherman/8026330/webrev/

> So are you trying to get this into 8 or are you thinking of holding this to 9?
>

I hope it can get in, as it is requested couple weeks ago. But if it has to be
cut off and leave for 9, then be it:-)

thanks!
-Sherman