Ulf,
The base64 implementation is in TL right now. It does address some of the
issue you suggested in this email. And I remember I did try use "byte[]"
alphabets, which I don't recall bring us any benefit, but I'm not sure in which
setup. The latest is at
http://cr.openjdk.java.net/~sherman/800
Hi Sherman,
is this ssue still open ?
-Ulf
Am 03.11.2012 21:33, schrieb Ulf Zibis:
Am 30.10.2012 23:40, schrieb Xueming Shen:
I'm "confused" about the order of xxcode() and Xxcoder.
In other places e.g. charsets, we have de... before en..., which is also true
alphabetical
should not be an
Am 30.10.2012 23:40, schrieb Xueming Shen:
I'm "confused" about the order of xxcode() and Xxcoder.
In other places e.g. charsets, we have de... before en..., which is also true
alphabetical
should not be an issue. javadoc output should be in alphabetic order. If it is
really
concerns you, I c
Hi Ulf, thanks for the comments.
Webrev has been updated to address most of your comments.
http://cr.openjdk.java.net/~sherman/4235519/webrev
(1) all @param and @return tags have been "normalized".
(2) private constructor BAse64() {} has been moved up.
(3) MIMELINEMAX and CRLF have been moved i
Hi Sherman,
thanks for your details.
Has this discussion been on the list, and I have missed it?
I see a problem with hiding the "singleton" choice:
Developers might tend to repetitively invoke
public static Encoder getEncoder(int lineLength, byte[] lineSeparator)
instead reusing the the sam
Oops:
lineLength << 2 >> 2
I meant::
lineLength >> 2 << 2
-Ulf
Am 24.10.2012 04:56, schrieb Xueming Shen:
Thanks for the review. I hope I addressed most of the comments in the
updated webrev at
http://cr.openjdk.java.net/~sherman/4235519/webrev
Hi Sherman,
my additional comments:
I'm "confused" about the order of xxcode() and Xxcoder.
In other places e.
Ulf, my apology. Some how I missed your email.
We tried various prototypes for this simple utility class. See
http://cr.openjdk.java.net/~sherman/base64/
The v4 might be close to the static constant approach you suggested.
While It's hard
to draw a clear line on which one is better, we conclude
Hi Sherman,
can you give me a short answer please?
-Ulf
Am 23.10.2012 16:57, schrieb Ulf Zibis:
Am 23.10.2012 15:04, schrieb Alan Bateman:
I'm not sure that getUrlEncoder is the most suitable name to get a base64url encoder. The reason
is that the method name makes it sound like it returns a
On 10/23/2012 8:50 PM, Mike Duigou wrote:
I'm eager to use this!
Some comments:
-code is used in some places rather than {@code }
fixed
- The initial would perhaps be better as a. I don't know if definition
lists are allowed in javadoc.
- public OutputStream wrap(OutputStream os) closi
I'm eager to use this!
Some comments:
- code is used in some places rather than {@code }
- The initial would perhaps be better as a . I don't know if
definition lists are allowed in javadoc.
- public OutputStream wrap(OutputStream os) closing the underlying output
stream precludes many pote
Hi Alan,
Thanks for the review. I hope I addressed most of the comments in the
updated webrev at
http://cr.openjdk.java.net/~sherman/4235519/webrev
mainly
(1) Pulled the base64 "terms" up to the class doc and then be referenced
from various methods
(2) Gave up the C style de/encode(byte[], nu
Am 23.10.2012 15:04, schrieb Alan Bateman:
I'm not sure that getUrlEncoder is the most suitable name to get a base64url encoder. The reason
is that the method name makes it sound like it returns a URLEncoder or or at least an encoder for
HTML forms. While more verbose, getBase64UrlEncoder is cle
On 18/10/2012 03:10, Xueming Shen wrote:
:
webrev:
http://cr.openjdk.java.net/~sherman/4235519/webrev
I took another pass over this, focusing on the API as that is what we
have to get right. Performance is important too but I think the priority
has to be the API first.
Overall I think it is
Understood. I do have the code:-) but I'm hesitated to go SharedSecrets
simply for
performance gain of a utility method. This definitely can be addressed
if it turns out
to be a real issue standing in critical path.
-Sherman
-
For me the greater concern, which is hard to measure, is the GC pressure added
by the discarded byte array.
Mike
On Oct 19 2012, at 17:03 , Xueming Shen wrote:
>
> I see a 20% performance gain on server vm if switch to pure char[] based
> encoding
> and then use the sharedSecrets to avoid the
I see a 20% performance gain on server vm if switch to pure char[] based
encoding
and then use the sharedSecrets to avoid the copy. The dis-advantage is
(1) have to
use the sharedSecrets and (2) can't share the same between the
encode(byte[])
and encode(String).
Anyway it appears to be an al
On 10/18/2012 07:43 AM, Alan Bateman wrote:
On 18/10/2012 03:10, Xueming Shen wrote:
Hi
Webrev has been updated with following changes
(1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
(2) some minor spec clarification regarding the "end of decoding"
(3) performance tuning.
I wonder if there would be advantage in using a SharedSecrets mechanism to
allow construction of a String directly from a char array. The intermediate
byte array seems wasteful especially for what is likely to be a heavily used
path.
Mike
On Oct 17 2012, at 19:10 , Xueming Shen wrote:
> Hi
>
Michael,
The current approach assumes that the base64 en/decoding of a file, stream
will be handled by the en/decoder.wrap(...). The en/decode(bb, bb) is
basically
for one time invocation input and output from/to existing buffers, with the
hope of avoiding the coding-life-circle management, so
Am 18.10.2012 04:10, schrieb Xueming Shen:
> Hi
>
> Webrev has been updated with following changes
>
> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
I think line 443 needs an additional check for atom == 0. Same for the
array case. At least if you do not want an endOfInpu
Am 18.10.2012 16:04, schrieb Xueming Shen:
On 10/18/2012 6:19 AM, Ulf Zibis wrote:
Oops, you are working at 6 in the morning?
Hi Sherman,
you could create the code table by help of a String constant, which would speed up the loading
and save a little footprint on the class file. (you have
On 10/18/12 7:43 AM, Alan Bateman wrote:
On 18/10/2012 03:10, Xueming Shen wrote:
Hi
Webrev has been updated with following changes
(1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
(2) some minor spec clarification regarding the "end of decoding"
(3) performance tuning.
w
On 18/10/2012 03:10, Xueming Shen wrote:
Hi
Webrev has been updated with following changes
(1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
(2) some minor spec clarification regarding the "end of decoding"
(3) performance tuning.
webrev:
http://cr.openjdk.java.net/~sherman
On 18/10/2012 14:19, Ulf Zibis wrote:
Hi Sherman,
you could create the code table by help of a String constant, which
would speed up the loading and save a little footprint on the class
file. (you have forgotten those tricks from sun.nio.cs coders? ;-) )
But my main question:
Why don't you e
On 10/18/2012 6:19 AM, Ulf Zibis wrote:
Hi Sherman,
you could create the code table by help of a String constant, which
would speed up the loading and save a little footprint on the class
file. (you have forgotten those tricks from sun.nio.cs coders? ;-) )
The implementation probably needs
Hi Sherman,
you could create the code table by help of a String constant, which would speed up the loading and
save a little footprint on the class file. (you have forgotten those tricks from sun.nio.cs coders?
;-) )
But my main question:
Why don't you enqueue those coders in the well known s
Hi
Webrev has been updated with following changes
(1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
(2) some minor spec clarification regarding the "end of decoding"
(3) performance tuning.
webrev:
http://cr.openjdk.java.net/~sherman/4235519/webrev
some performance scores:
On 10/13/12 10:21 AM, Xueming Shen wrote:
With moving some code piece around (moved those lookup table into
En/Decoder)
and some array access code tuning (with the hope of eliminating the
array boundary
access) in encode0(), it appears the hotspot now can better optimize
the decoder
loop for
With moving some code piece around (moved those lookup table into
En/Decoder)
and some array access code tuning (with the hope of eliminating the
array boundary
access) in encode0(), it appears the hotspot now can better optimize the
decoder
loop for the -server mode for encoding. decode0 also
On 10/13/2012 11:21 AM, Peter Levart wrote:
One way to do it without state in encoder is 1st as suggested to have
the 'endOfStream' flag and in addition when new-line breaks are
requested, to only encode "full lines" at each invocation. So If one
wants to use this line-breakage feature he/she m
One way to do it without state in encoder is 1st as suggested to have
the 'endOfStream' flag and in addition when new-line breaks are
requested, to only encode "full lines" at each invocation. So If one
wants to use this line-breakage feature he/she must make sure that there
is enough space (li
Yes, I'm trying to figure out where to have this position info stored...
On 10/12/2012 01:48 PM, Michael Schierl wrote:
Am 12.10.2012 22:12, schrieb Xueming Shen:
Hi,
It appears to be possible to do something like
boolean de/encode(ByteBuffer src, ByteBuffer dst);
returns true if all remai
Am 12.10.2012 22:12, schrieb Xueming Shen:
> Hi,
>
> It appears to be possible to do something like
>
> boolean de/encode(ByteBuffer src, ByteBuffer dst);
>
> returns true if all remaining bytes in src are en/decoded, false, the dst
> is not big enough for all output bytes, the src.position() wi
On 12/10/2012 21:12, Xueming Shen wrote:
Hi,
It appears to be possible to do something like
boolean de/encode(ByteBuffer src, ByteBuffer dst);
returns true if all remaining bytes in src are en/decoded, false, the dst
is not big enough for all output bytes, the src.position() will be
advanced
Hi,
It appears to be possible to do something like
boolean de/encode(ByteBuffer src, ByteBuffer dst);
returns true if all remaining bytes in src are en/decoded, false, the dst
is not big enough for all output bytes, the src.position() will be advanced
to the position of next un-en/decoded byte,
Hi,
Thanks for doing this BTW.
I think that including ByteBuffer API even if it isn't as efficient as
raw byte arrays is better then not having it in the API at all. If that
means allocating a byte array for the output and then doing a put on the
ByteBuffer that is fine.
Down the line if someone
Hi,
The exactly reason I was trying to skip en/decode(ByteBuffer in,
ByteByuffer out)
for now. I'm struggling with/can't make up my mind on whether or not the
en/decoder
should have internal state, like the charset en/decoder. It appears the
API is being
pushed going that direction though:-)
Hello,
(sorry if the threading is broken, but I was not subscribed to the list
and only found the discussion on Twitter and read it in the mailing list
archive)
Ariel Weisberg wrote on Thu Oct 11 11:30:56 PDT 2012:
> I know that ByteBuffers are pain, but I did notice that you can't
> specify a so
On 11/10/2012 19:30, Ariel Weisberg wrote:
:
I know that ByteBuffers are pain, but I did notice that you can't
specify a source/dest pair when using ByteBuffers and that ByteBuffers
without arrays have to be copied. I don't see a simple safe way to
normalize access to them the way you can if eve
On 10/11/2012 02:43 AM, Stephen Colebourne wrote:
There are lots of other public base 64 implementations to test/check
against.
http://commons.apache.org/net/api-3.1/org/apache/commons/net/util/Base64.html
http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/util/encoders/Base64.html
htt
Hi,
It looks like it tackles the issue of encoding binary data as text in an
isolated fashion and doesn't seem open to adding other ways of encoding
binary data as text such as hex or yEnc. Having a common interface in
java.util for different encodings would be great. I am not asking for
more impl
On 10/11/2012 02:43 AM, Stephen Colebourne wrote:
The class level javadoc is quite short. It also has hyperlinks in the
first sentence, which means that they are visible in package level
javadoc. Consider having no hyperlinks in the first sentence, and
expanding a little on what base 64 is.
Su
The class level javadoc is quite short. It also has hyperlinks in the
first sentence, which means that they are visible in package level
javadoc. Consider having no hyperlinks in the first sentence, and
expanding a little on what base 64 is.
There are lots of other public base 64 implementations t
On 11/10/2012 04:15, Xueming Shen wrote:
There is no plan yet. The sun.misc.BASE64En/Decoder should already
trigger a compiler
warning for it's a sun private API. @Deprecated annotation might be a
good fit.
-Sherman
Yes, I think we should deprecate them. The other thing suggested in the
JEP i
On 10/10/12 8:39 PM, Weijun Wang wrote:
On 10/11/2012 11:32 AM, Xueming Shen wrote:
On 10/10/12 8:16 PM, Weijun Wang wrote:
On 10/11/2012 11:09 AM, Xueming Shen wrote:
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 i
On 10/11/2012 11:32 AM, Xueming Shen wrote:
On 10/10/12 8:16 PM, Weijun Wang wrote:
On 10/11/2012 11:09 AM, Xueming Shen wrote:
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax && (atom != 0 || sp
On 10/10/12 8:16 PM, Weijun Wang wrote:
On 10/11/2012 11:09 AM, Xueming Shen wrote:
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax && (atom != 0 || sp <
sl)) {
Maybe atom != 0 is not necessary?
On 10/11/2012 11:09 AM, Xueming Shen wrote:
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax && (atom != 0 || sp < sl)) {
Maybe atom != 0 is not necessary?
The logic here is that if we reached the
There is no plan yet. The sun.misc.BASE64En/Decoder should already
trigger a compiler
warning for it's a sun private API. @Deprecated annotation might be a
good fit.
-Sherman
On 10/10/12 1:40 PM, Joe Darcy wrote:
Hello,
On 10/10/2012 1:03 PM, Iris Clark wrote:
Hi, Sherman.
I'm glad to see
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax && (atom != 0 || sp < sl)) {
Maybe atom != 0 is not necessary?
The logic here is that if we reached the last atom (atom == 0), but if there
is still by
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax && (atom != 0 || sp < sl)) {
Maybe atom != 0 is not necessary?
2. Is it necessary to explicitly mention in the spec that there is no
CrLf at the end of a MIME encoded string?
3. The test con
Hello,
On 10/10/2012 1:03 PM, Iris Clark wrote:
Hi, Sherman.
I'm glad to see this coming in. As you said, long overdue.
I'm curious. What are the plans are to encourage migration from the JDK
private and unsupported sun.misc.BASE64{En,DE}coder classes? Compile-time
warning? Documentation
Hi, Sherman.
I'm glad to see this coming in. As you said, long overdue.
I'm curious. What are the plans are to encourage migration from the JDK
private and unsupported sun.misc.BASE64{En,DE}coder classes? Compile-time
warning? Documentation? Something else?
Thanks,
iris
-Original Mes
54 matches
Mail list logo
