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
