RFR: 8026330: java.util.Base64 urlEncoder should omit padding
xueming.shen at oracle.com
Fri Nov 8 22:28:13 UTC 2013
On 11/08/2013 06:00 AM, Alan Bateman wrote:
> On 06/11/2013 18:44, Xueming Shen wrote:
>> 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
>> 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.
> 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
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.
> 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:-)
More information about the core-libs-dev