Re: Request for review: Optimize common-case UTF8 path for native ZipFile.getEntry calls

Hi Neil, Thanks for looking into this performance problem. I had the assumption that (1) code conversion is really a small portion of the overall Zip read/write operation (2) I will have the time to do the same optimization for UTF_8 charset as I did for other singlebyte charsets [2] in

Re: proposal to optimise the performance of the Jar utility

reason for this data being collected. I am probably missing the obvious ... 4. After that there is just the parallelisation of the jar utility and the underlying stream What is the best way to proceed regards Mike ____ From: Xueming Shen To: core-libs-dev@openjdk.java.

Re: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties

On 04-26-2011 2:20 AM, Alan Bateman wrote: Xueming Shen wrote: Thanks Mark! Let's go with UNICODE_PROPERTY, if there is no objection. I went through the updates to the javadoc and the approach looks good and nicely done. A minor comment is that the compile(String,int) method repeat

Re: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties

Thanks Alan! webrev has been updated accordingly. -Sherman On 4/27/2011 8:51 AM, Alan Bateman wrote: Xueming Shen wrote: : UNICODE_CHARACTER_CLASS is clear and straightforward. I am OK with it. The webrev, ccc and api docs have been updated accordingly. Yes, I still need a reviewer for

Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

Hi This is motivated by Neil's request to optimize common-case UTF8 path for native ZipFile.getEntry calls [1]. As I said in my replying email [2] I believe a better approach might be to "patch" UTF8 charset directly to implement sun.nio.cs.ArrayDecoder/Encoder interface to speed up the codin

Re: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

/webrev.00) Thanks, -Sherman Am 28.04.2011 08:34, schrieb Xueming Shen: Hi This is motivated by Neil's request to optimize common-case UTF8 path for native ZipFile.getEntry calls [1]. As I said in my replying email [2] I believe a better approach might be to "patch"

Re: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

On 04/28/2011 01:55 PM, Ulf Zibis wrote: Am 28.04.2011 21:56, schrieb Xueming Shen: That said, you do have the point, we should do better even in malformed case, ... Yes, that's what I wanted to point on. But I thought, you could go 1 step further, declaring bb as member of UTF_8.De

Re: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

On 04-28-2011 3:46 PM, Ulf Zibis wrote: It's safe to say that java.nio.cs.StandardCharset is not for String.getBytes()/toCharArray() only, so the fact that "cs" variant of String.getBytes()/toCharArray() is "slower" than its "csn" variant arguably might not be a very strong/supportive material

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 775b77e74bec Author:sherman Date: 2011-04-28 20:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/775b77e74bec 7037261: j.l.Character.isLowerCase/isUpperCase need to match the Unicode Standard Summary: updated j.l.c.lsLowerCase/isUpperCase Reviewed-by: okutsu ! m

hg: jdk7/tl/jdk: 7036522: j.u.r.Pattern documentation errors

Changeset: 4ac05b50f09c Author:sherman Date: 2011-05-01 11:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4ac05b50f09c 7036522: j.u.r.Pattern documentation errors Summary: updated the Perl related information Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.

Re: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

On 5/2/2011 7:31 AM, Alan Bateman wrote: Xueming Shen wrote: Hi This is motivated by Neil's request to optimize common-case UTF8 path for native ZipFile.getEntry calls [1]. As I said in my replying email [2] I believe a better approach might be to "patch" UTF8 charset direct

hg: jdk7/tl/jdk: 7040220: java/char_encodin Optimize UTF-8 charset for String.getBytes()/new String(byte[])

Changeset: fa17f2b9a6d5 Author:sherman Date: 2011-05-02 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa17f2b9a6d5 7040220: java/char_encodin Optimize UTF-8 charset for String.getBytes()/new String(byte[]) Summary: implement sun.nio.cs.ArrayEn/Decoer in utf8 Reviewed-

Re: StandardCharset vs. StandardCharsets

On 05-07-2011 上午 9:00, Rémi Forax wrote: On 05/07/2011 02:17 PM, Ulf Zibis wrote: Hi all, please excuse, that I have still problems to accept this additional class, but +1 for the plural name. If those charset constants are there, people _will use_ them without respect on the existing _perf

Re: StandardCharset vs. StandardCharsets

On 5/7/2011 10:55 AM, Ulf Zibis wrote: Rémi, thanks for your feedback. Am 07.05.2011 18:00, schrieb Rémi Forax: On 05/07/2011 02:17 PM, Ulf Zibis wrote: Hi all, please excuse, that I have still problems to accept this additional class, but +1 for the plural name. If those charset constant

hg: jdk7/tl/jdk: 7043234: (fmt) java.util.Formatter links in javadoc to BigDecimal need to be fixed

Changeset: 501ca93ea3ef Author:sherman Date: 2011-05-11 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/501ca93ea3ef 7043234: (fmt) java.util.Formatter links in javadoc to BigDecimal need to be fixed Summary: fixed the doc miss Reviewed-by: alanb, emcmanus ! src/share/

hg: jdk7/tl/jdk: 7044849: Constructs for Unicode binary properties should be \p{IsXXX} not p{isXXX}

Changeset: d830ec851cee Author:sherman Date: 2011-05-14 11:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d830ec851cee 7044849: Constructs for Unicode binary properties should be \p{IsXXX} not p{isXXX} Summary: fixed the doc typo Reviewed-by: alanb ! src/share/classes/ja

j.u.regex: Negated Character Classes

I'm sure everybody understands what "negated character classes" [^...] in j.u.regex means. You would never have doubt about [^c] does NOT match "c" [^0-9] does NOT match "8" [^a-z] does NOT match "b" [^a-bc-d] does NOT match 'c" But how about does [^[c]] match "c"? does [^[0-9]] match "8"? doe

Re: j.u.regex: Negated Character Classes

#x27;ll admit to reading through to the end of your note and finding it interesting ;-) Some comments in-lined. On 03/Jun/2011 22:55, Xueming Shen wrote: I'm sure everybody understands what "negated character classes" [^...] in j.u.regex means. You would never have doubt about [^c

Re: Trivial: 1 char fix : java launcher help message fix.

OK, it's a nit-pick and it has nothing to do with this fix, and it probably has been there from day one. But just wonder if those "%n" should be replaced by "/n" in those properties file, otherwise my guess is that the result of java -help will not have the correct line-end on Windows platform.

Re: Trivial: 1 char fix : java launcher help message fix.

On 06/21/2011 12:32 PM, Xueming Shen wrote: OK, it's a nit-pick and it has nothing to do with this fix, and it probably has been there from day one. But just wonder if those "%n" should be replaced by "/n" in those properties file, otherwise I meant to say "t

Re: Review request: Test bugs to add cygwin support

Looks good. Thanks for fixing them. On 08/08/2011 02:37 PM, Mandy Chung wrote: > Simple fix on these tests to run on cygwin. > > 7036518: TEST_BUG: add cygwin support to > test/java/nio/charset/coders/CheckSJISMappingProp.sh > 7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh > > W

Request for review 6237353: Remove sun.io package from j2se binary

Hi, This is something long over due. Some background info. (1)The java.nio.charset package (to replace the private sun.io package) is added into JDK 1.4 as the result of the nio JSR. Part of the sun.io converters were migrated to the java.nio.charset implementation in JDK8. (2) All

Re: Request for review 6237353: Remove sun.io package from j2se binary

Ulf, I tried to be conservative to not touch the source code, just in case I might be forced to put them back again:-) But since I have already removed the whole sun.io source branch, it's reasonable to do the complete cleanup up as well. The webrev has been updated accordingly (to remove tho

Re: Request for review 6237353: Remove sun.io package from j2se binary

ers, Sasha On 8/17/2011 2:07 AM, Alan Bateman wrote: Xueming Shen wrote: Hi, This is something long over due. Some background info. (1)The java.nio.charset package (to replace the private sun.io package) is added into JDK 1.4 as the result of the nio JSR. Part of the sun.io converters

Re: Request for review 6237353: Remove sun.io package from j2se binary

], so that line will not do anything. Thanks, Sasha [1] Actually, it gets set to "-Xlint:all -Xlint:-path", but that's temporary. This happens in jdk/make/common/shared/Defs-java.gmk. On 8/17/2011 11:41 AM, Xueming Shen wrote: Thanks Sasha, The flag has been set to true, as s

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 2961329a6774 Author:sherman Date: 2011-08-17 14:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2961329a6774 6237353: Remove sun.io package from j2se binary Summary: Removed sun.io package and related test cases Reviewed-by: alanb ! make/java/sun_nio/FILES_java.

Request for review for 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String)

The @since 1.7 tag was missed when regex groupname suport was added in JDK7. Here is the webrev for adding it back in. http://cr.openjdk.java.net/~sherman/7066490/webrev Thanks! -Sherman

hg: jdk8/tl/jdk: 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String)

Changeset: 11cc9c2e0431 Author:sherman Date: 2011-08-17 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11cc9c2e0431 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) Summary: Added the @since 1.7 tag Reviewed-by: mduigou, forax ! s

Re: Request for review 6237353: Remove sun.io package from j2se binary

obody from outside should access them directly. Am 17.08.2011 20:41, schrieb Xueming Shen: Ulf, I tried to be conservative to not touch the source code, just in case I might be forced to put them back again:-) Then we could provide my small sun.io-wrapper, maybe as additional resource lik

Code review request 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field

The fix tires to address two issues in ZipFileSystem class (1) The OutputStream used to write out the bits in sync() is not wrapped by a BufferedOutputStream. Without the BufferedOutputStream wrapper, we basically write all ZIP header tables (loc and cen) byte by byte. How big is the impact to th

Re: Code review request 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field

rman On 08/24/2011 12:06 AM, Alan Bateman wrote: Xueming Shen wrote: : Fix has been verified/test manually with existing test cases. Given the nature of the > 4G zip data file. I'm not including an auto regression test. Webrev is at http://cr.openjdk.java.net/~sherman/7077769/webre

Re: Code review request 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field

On 08/26/2011 01:17 PM, Alan Bateman wrote: Xueming Shen wrote: Alan Webrev has been updated to (1) use the new try(resource){} (2) update the existing test case LargetZip to a) be able to add one more entry at the end of the > 4g zip via ZipFileSystem b) read through all entr

Re: Request-Review: Remove two simple warnings in HttpsURLConnection.java

On 08/26/2011 02:45 PM, Alan Bateman wrote: Sebastian Sickelmann wrote: Hi, is there someone who wants to review / support this simple warning removal? The webrev is: http://oss-patches.24.eu/openjdk8/Simple_Warning/ -- Sebastian* * This is JSSE so probably best if someone from the security

Re: Request-Review: Remove two simple warnings in HttpsURLConnection.java

Please ignored this email. My apology. Wrong click. On 08/26/2011 03:16 PM, Xueming Shen wrote: On 08/26/2011 02:45 PM, Alan Bateman wrote: Sebastian Sickelmann wrote: Hi, is there someone who wants to review / support this simple warning removal? The webrev is: http://oss-patches.24.eu

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 973d923af88c Author:sherman Date: 2011-08-26 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/973d923af88c 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field Summary: fixed the wrong size when writing

Re: Request for review: 7084245: Update usages of InternalError to use exception chaining

Hi Sebastian, I will help to push the patch, if people all agreed the changes proposed. I pulled your patch and generated the webrev at http://cr.openjdk.java.net/~sherman/7084245/webrev with couple changes from your original patch. (1) Undo the changes in DecimalFormat.java and Format.java.

Re: Request for review: 7084245: Update usages of InternalError to use exception chaining

Hi Sebastian, On 08/30/2011 01:23 AM, Sebastian Sickelmann wrote: Sorry i have forgotten the webrev url. http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_1/ with couple changes from your original patch. (1) Undo the changes in DecimalFormat.java and Format.java. whil

Re: Request for review: 7084245: Update usages of InternalError to use exception chaining

Sebastian, src/share/classes/sun/misc/Launcher.java in new patch appears to miss a ending } at ln#487 -Sherman On 08/30/2011 10:20 AM, Xueming Shen wrote: Hi Sebastian, On 08/30/2011 01:23 AM, Sebastian Sickelmann wrote: Sorry i have forgotten the webrev url. http://oss-patches.24.eu

hg: jdk8/tl/jdk: 7084245: Update usages of InternalError to use exception chaining

Changeset: 8a51f0e24380 Author:sherman Date: 2011-08-30 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a51f0e24380 7084245: Update usages of InternalError to use exception chaining Summary: to use new InternalError constructor with cause chainning Reviewed-by: alanb, k

Codereview request for 6898310: (cs) Charset cache lookups should be synchronized

Hi, This is a forward porting. Same fix has been in jdk5/6, and will be in jdk 7u2 later. http://cr.openjdk.java.net/~sherman/6898310/webrev The change itself is relative simple. And given its race-condition nature, no reliable regression test case is provided. Thanks! -Sherman

Re: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized

On 09/02/2011 06:00 AM, Rémi Forax wrote: On 09/02/2011 01:34 PM, Alan Bateman wrote: Rémi Forax wrote: Arghhh, next() can return null ! CharsetProvider provider = ... Iterator it = provider.charsets(); Iterator it2 = provider.charsets(); Charset charset = it.next(); provider.deleteCharset(ch

hg: jdk8/tl/jdk: 6898310: (cs) Charset cache lookups should be synchronized

Changeset: 812c6d4d6a58 Author:sherman Date: 2011-09-02 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/812c6d4d6a58 6898310: (cs) Charset cache lookups should be synchronized Summary: synchronize the lookup in iterator Reviewed-by: alanb ! src/share/classes/sun/nio/cs/

Re: Code review for 6915797 & 7090178

Looks fine. On 9/13/2011 1:54 PM, Mandy Chung wrote: 6915797: Remove sun.tools.jar.JarImageSource that is not used 7090178: Move java.util.XMLUtils to another package to avoid split package Webrev at: http://cr.openjdk.java.net/~mchung/6915797/webrev.00/ The synopsis says it all. Thank

Codereview request for 7082884: Incorrect UTF8 conversion for sequence ED 31

Hi, Unicode Standard added "Addition Constraints on conversion of ill-formed UTF-8" in version 5.1 [1] and updated in 6.0 again with further "clarification" [2] regarding how a "conformance" implementation should handle ill-formed UTF-8 byte sequence. Basically it says (1) the conversion pro

Codereview request for 7096080: UTF8 update and new CESU-8 charset

Hi, [I combined the proposed charge for #7082884, in which no one appears to be interested:-) into this one] Unicode Standard added "Addition Constraints on conversion of ill-formed UTF-8" in version 5.1 [1] and updated in 6.0 again with further "clarification" [2] regarding how a "conformanc

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Hi, On 9/28/2011 3:44 PM, Ulf Zibis wrote: Hi Sherman, 1. bug 7096080 is not visible at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7096080 It might take couple days for it to show up on bugs.sun.com. But it has exactly the same content as my previous email. In fact I simply copy/pa

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

quot;desired"/recommended behavior in this case, from Standard point view? Am 29.09.2011 05:27, schrieb Xueming Shen: Hi, On 9/28/2011 3:44 PM, Ulf Zibis wrote: 5. IMHO charset CESU-8 should be hosted in extended-charsets, otherwise it should be added to java.nio.StandardCharsets W

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

On 09/30/2011 07:09 AM, Ulf Zibis wrote: (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---> CoderResult.malformedForLength(1) It appears the Unicode Standard now explicitly recommends to return the malformed length 2, what UTF-8 is doing now, for this scenario My idea behind is, that i

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf Go to 3.9 Unicode Encoding Forms. Or simply search D93 On 10/1/2011 2:21 PM, Ulf Zibis wrote: Am 30.09.2011 22:46, schrieb Xueming Shen: On 09/30/2011 07:09 AM, Ulf Zibis wrote: (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

On 10/11/2011 04:36 AM, Ulf Zibis wrote: Am 30.09.2011 22:46, schrieb Xueming Shen: I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to 2009(?) because the benchmark shows the "shift" version is slightly faster. Do you have any number shows any difference now

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

On 10/13/2011 09:55 AM, Ulf Zibis wrote: Am 11.10.2011 19:49, schrieb Xueming Shen: I don't know which one is better, I did a run on private static boolean op1(int b) { return (b >> 6) != -2; } private static boolean op2(int b) { return (b &

Re: performance updates to jar and zip

Hi Mike, It appears the patch failed to patch the ZipCoder for my JDK8 workspace (I did not look into details, guess the patch is against and "old" version, if you can just send me the updated ZipCoder file, I can add it into the workspace directly) I pull the rest change into a webrev at h

Re: performance updates to jar and zip

Hi Mark It appears the patch you provided throws unexpected exception (attached at the end of my email) when I tried it out on the latest JDK8 repository. Since I only did a quick scan of your patch, I'm not sure what went wrong here. This patch includes lots of stuff that obviously you ar

Re: performance updates to jar and zip

On 10/27/2011 06:07 AM, Alan Bateman wrote: On 27/10/2011 00:19, Xueming Shen wrote: : Here are the "surprising" results. "nio" is the walkFileTree, "io" is the File.list() "io2" is the File.listFiles(). The nio's File.walkFileTree is 15 t

Re: performance updates to jar and zip

ink that any of the API would return ../ Is it only on Z3 that this error occurs? I will install a Java8 with the patch, but it will be at the start of next week regards Mike *From:* Xueming Shen *To:* core-libs-dev@openjdk.java.net *Sent:* Thursday, 27 October 2011, 0:19

Re: performance updates to jar and zip

On 10/31/2011 5:11 PM, Mike Skells wrote: Hi Sherman, (1) Are the number here with writing the LOC in the background thread, in not I don't understand the comment The writeLOC in the base code version is very slow. each int written is written as 4 seperate bytes, each of which takes out lock

Re: performance updates to jar and zip

On 10/31/2011 5:11 PM, Mike Skells wrote: (2) Iti is true that this is not a performance gain by code improvement, but it is a performnce gain by specification. The same arguement applies to allowing a Zip Compression of 1 rather than the default. As for the spec, all I have seen is that it

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

Thanks Alan, The webrev has been updated accordingly to address your comments (the commented out isMalformed2 has been removed, copyright updated, bugid added...) And thanks for Ulf for the detailed review. -Sherman On 10/28/2011 09:14 AM, Alan Bateman wrote: On 28/09/2011 20:18, Xueming

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

CharsetEncoder - If final, protected doesn't make sense, as it can't be subclassed. (ideally this should be a compiler error) - Where is it used? Otherwise it could be private. -Ulf Am 07.11.2011 21:30, schrieb Xueming Shen: Thanks Alan, The webrev has been updated accordingly to ad

hg: jdk8/tl/jdk: 7096080: UTF8 update and new CESU-8 charset; ...

Changeset: 417d91754849 Author:sherman Date: 2011-11-07 13:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/417d91754849 7096080: UTF8 update and new CESU-8 charset 7082884: Incorrect UTF8 conversion for sequence ED 31 7082883: Incorrect UTF8 conversion for sequence fc 80 80

Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer

Hi, java.util.zip.Adler32/CRC32 do not have update method that accepts ByteBuffer. As of JDK7, you have to copy the content of the ByteBuffer into a byte[], then invoke Adler32/CRC32.update() method, which might have significant performance impact for some applications. Here I'm proposing to a

Re: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer

Thanks Alan. The webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/7109837/webrev/ -Sherman On 11/23/2011 02:58 AM, Alan Bateman wrote: On 22/11/2011 23:26, Xueming Shen wrote: Hi, java.util.zip.Adler32/CRC32 do not have update method that accepts ByteBuffer. As of

Re: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer

an wrote: On 23/11/2011 19:39, Xueming Shen wrote: Thanks Alan. The webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/7109837/webrev/ Minor nit but we should probably use {@code null} instead of null. I think the opening sentence "Updates the Adler32 checksum with

Re: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer

way, so I guess it probably not worth the testing circle to iterate more than 1. But not a big deal for me, if you strongly believe a 1 iteration result might help some time, I can check in the iteration as 1. -Sherman On 11/25/2011 2:51 AM, Alan Bateman wrote: On 24/11/2011 22:47, Xue

zlib 1.2.3 -> 1.2.5

Hi, Here is the webrev for upgrading the bundled zlib from 1.2.3 to 1.2.5 for JDK8 http://cr.openjdk.java.net/~sherman/7110149/webrev The changes to the original zlib source code (other than the copyright attachment) is at http://cr.openjdk.java.net/~sherman/7110149/webrev/src/share/native

Re: zlib 1.2.3 -> 1.2.5

The zlib-1.2.3 folder will be deleted. I did not list them in the webrev. I should have mentioned in the request. -Sherman On 11/28/2011 2:47 PM, Ulf Zibis wrote: Would zlib 1.2.3 remain in JDK8 repo alongside 1.2.5 ? -Ulf Am 28.11.2011 23:06, schrieb Xueming Shen: Hi, Here is the webrev

Re: zlib 1.2.3 -> 1.2.5

That would be a separate RFE for that. As Mark suggested (as the feedback for the EFP) we now divide the zlib related work into small/separate rfes. To use the platform zlib is still on my list. -Sherman On 11/29/2011 06:05 AM, Ulf Zibis wrote: Am 29.11.2011 11:23, schrieb Alan Bateman: When

Re: zlib 1.2.3 -> 1.2.5

/2011 22:06, Xueming Shen wrote: Hi, Here is the webrev for upgrading the bundled zlib from 1.2.3 to 1.2.5 for JDK8 http://cr.openjdk.java.net/~sherman/7110149/webrev The changes to the original zlib source code (other than the copyright attachment) is at http://cr.openjdk.java.net/~sherman

hg: jdk8/tl/jdk: 7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5

Changeset: a47de985fec9 Author:sherman Date: 2011-11-29 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a47de985fec9 7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5 Summary: updated to zlib-1.2.5 Reviewed-by: alanb ! make/common/Defs.gmk ! make

hg: jdk8/tl/jdk: 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer

Changeset: 07e359b01d8a Author:sherman Date: 2011-11-29 13:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07e359b01d8a 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Summary: added methods Adler32/CRC32.update(ByteBuffer) R

Re: zlib 1.2.3 -> 1.2.5

There is a > 2/4G support issue we will need to address when using the platform bundled zlib. The total_in/total_out variables of z_stream_s is "long", which is not "big" enough (32 bit) for ZIP64 support on a 32-bit platform. The zlib code bundled with JDK has been updated to use "long long", as

Re: Code Review Request for Bug #7069190

(1) you might need to consider the use scenario of an unset HOME env (2) it appears to be an in-compatible change if the values from getpwuid and from HOME are different (understood this is what you want to address), in which I think might need a CCC review (for the possible in-compatible chan

Code review request: 6907367 extcheck should skip non-jar files

Please help review the change at http://cr.openjdk.java.net/~sherman/6907367/webrev The proposed change does not include the test case I was originally planed as showed at http://cr.openjdk.java.net/~sherman/6907367/webrev.00/test/com/sun/tools/extcheck/TestExtcheckArgs.java.sdiff.html The test

hg: jdk8/tl/jdk: 5035850: (str) String.CASE_INSENSITIVE_ORDER should override readResolve()

Changeset: 1d7037df65ed Author:sherman Date: 2011-12-02 16:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d7037df65ed 5035850: (str) String.CASE_INSENSITIVE_ORDER should override readResolve() Summary: Fix to ensure singleton property of String.CaseInsensitiveComparator

hg: jdk8/tl/jdk: 5063455: (fmt) MissingFormatArgumentException.getFormatSpecifier() incorrect return value

Changeset: 194faa6fdb3c Author:sherman Date: 2011-12-05 10:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/194faa6fdb3c 5063455: (fmt) MissingFormatArgumentException.getFormatSpecifier() incorrect return value Summary: updated the incorrect StringBuilder constructor usage

Re: 6990617: Regular expression doesn't match if unicode character next to a digit.

Hi Steve, The \x3[0-9] approach is interesting, it appears to solve the problem without paying a higher cost I originally thought (looking back, for example). The logic of initializing/setting/unsetting of "beginQuote" to true/false appears to be incorrect when there are multiple \Qn...\E in

Re: 6990617: Regular expression doesn't match if unicode character next to a digit.

tinue" statement after line 1622 to get the case to pass. I have updated the webrev. Steve. On 12/12/2011 02:22 PM, Xueming Shen wrote: Hi Steve, The \x3[0-9] approach is interesting, it appears to solve the problem without paying a higher cost I originally thought (looking back, for example).

hg: jdk8/tl/jdk: 6990617: Regular expression doesn't match if unicode character next to a digit.

Changeset: 5b27b978ed42 Author:sherman Date: 2011-12-19 14:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b27b978ed42 6990617: Regular expression doesn't match if unicode character next to a digit. Summary: updated RemoveQEQuotation() to deal with this case correctly Revi

Re: Review request for #6783209

On 01/04/2012 09:54 AM, Alan Bateman wrote: On 04/01/2012 17:39, Iris Clark wrote: Hi, Brandon. Webrev: http://cr.openjdk.java.net/~bpassani/6783209/1/webrev/ You're revised webrev looks good to me. Looks good to me too. Sherman - you sponsored Brandon's previous update to Formatter, are

Re: CFV: New core-libs Group Member: Brian Goetz

Vote: yes On 01/05/2012 04:39 AM, Alan Bateman wrote: I hereby nominate Brian Goetz to membership of the core-libs group. Brian doesn't need too much introduction. He's lead for OpenJDK's Project Lambda, and while this project is sponsored by the compiler group, is all about the libraries an

Re: CFV: New core-libs Group Member: David Holmes

Vote: yes On 01/05/2012 05:08 AM, Alan Bateman wrote: I hereby nominate David Holmes to membership of the core-libs group. David doesn't need too much introduction. He is a reviewer on several OpenJDK projects, including the HotSpot Express project, JDK 7 and JDK 8. He is a prolific reviewer,

Re: Using unsigned library work in the JDK

ormance impact, if any, of this change. -Joe PS All the jar/zip regression tests pass with this change. On 01/26/2012 09:52 AM, Xueming Shen wrote: Joe, The changes look fine. However I have the same performance concern in cases that the vm fails to inline the toUnsignedInt(), especially fo

Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

Hi This is a long standing "regression" from 1.3.1 on how OutputStreamWriter.flush()/flushBuffer() handles escape or shift sequence in some of the charset/encoding, for example the ISO-2022-JP. ISO-2022-JP is encoding that starts with ASCII mode and then switches between ASCII andJapanese ch

Re: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

really a Java SE bug? The usage of OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo method in the bug report doesn't seem to be able to deal with any stateful encodings. Masayoshi On 2/9/2012 3:26 PM, Xueming Shen wrote: Hi This is a long standing "regression&qu

Re: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

CCed Bill Shannon. On 02/09/2012 11:10 AM, Xueming Shen wrote: CharsetEncoder has the "flush()" method as the last step (of a series of "encoding" steps) to flush out any internal state to the output buffer. The issue here is the the upper level wrapper class, OutputStre

Re: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

Jason, I might be misunderstanding your suggestion, but the current implementation of OutputStreamWriter.flushBuffer()/StreamWriter.implFlushBuffer() does not flush the encoder, so even the caller can choose when to invoke flushBuffer(), it does not solve the problem (flush() invokes flushBuff

Re: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

reate a filter stream to deal with stateful encodings with the java.io API. If it's OK to support only 1.4 and later, the java.nio.charset API should be used. Thanks, Masayoshi On 2/10/2012 4:12 AM, Xueming Shen wrote: CCed Bill Shannon. On 02/09/2012 11:10 AM, Xueming Shen wrote: Ch

Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

Hi This is a long standing Windows codepage support issue on Java platform (we probably have 20 bug/rfes filed for this particular issue and closed as the dup of 4153167). Windows supports two sets of codepages, ANSI (Windows) codepage and OEM (IBM) codepage. Windows uses ANSI/Windows codepa

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

underlying console can understand. -Sherman -Sherman -Ulf Am 13.02.2012 18:36, schrieb Xueming Shen: Hi This is a long standing Windows codepage support issue on Java platform (we probably have 20 bug/rfes filed for this particular issue and closed as the dup of 4153167). Windows

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

To have separate sun.stdout.encoding and sun.stderr.encoding is mainly because of implementation convenience. I need three things from the native (1) is std.out tty (2) is std.err tty (3) the console encoding if (1) or (2) are true, and I tried to avoid to go down to native multiple times it a

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

On 2/13/2012 11:07 AM, Bill Shannon wrote: Thanks for fixing this! The webrev is at http://cr.openjdk.java.net/~sherman/4153167/webrev You probably don't need to malloc 64 bytes for a string that's going to be less than 16 bytes. And shouldn't you use snprintf in any event? Unlike Unix,

Re: Review: JDK 8 CR for Support Integer overflow updated

I can do the commit. On 2/16/2012 8:09 AM, Roger Riggs wrote: I don't anticipate making any more changes though a few of the comments deserve followup as a separate CR. Is there an OpenJDK committer who would commit? Thanks, Roger Updated the webrev for CR6708398: http://cr.openjdk.

hg: jdk8/tl/jdk: 6708398: Support integer overflow

Changeset: b971b51bec01 Author:sherman Date: 2012-02-16 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b971b51bec01 6708398: Support integer overflow Summary: Added add/sub/multiply/toIntExact methods to j.l.Math and StrictMath classes Reviewed-by: emcmanus Contributed

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

Thanks Alan, webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/4153167/webrev <http://cr.openjdk.java.net/%7Esherman/4153167/webrev/> -Sherman On 02/15/2012 07:00 AM, Alan Bateman wrote: On 13/02/2012 17:36, Xueming Shen wrote: : The webrev is at

hg: jdk8/tl/jdk: 4153167: separate between ANSI and OEM code pages on Windows

Changeset: d38fed7d2ea7 Author:sherman Date: 2012-02-16 22:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d38fed7d2ea7 4153167: separate between ANSI and OEM code pages on Windows Summary: To use OEM code page for System.out&err when not redirected Reviewed-by: alanb ! sr

Re: RFR : 7148584 Jar tools fails to generate manifest correctly when boundary condition hit

Looks fine. On 3/9/2012 7:52 AM, Seán Coffey wrote: Issue seen when the inner Manifest.FastInputStream.peek() method is called just as we hit EOF of main buffer being parsed (the manifest input file) Simple fix involves getting peek() to return -1 if a fill() request fails to read anything.

CR 7148271 REGESSION with PNG Image loading

Hi zlib 1.2.0.[4|5] and later have more "rigorous" distance-too-far boundary checks than previous versions. The PNG image file used in this case appears to be one of those "corrupted" files that have incorrect "distance" value in its compressed image data. This "invalid distance value" is expose

Re: CR 7148271 REGESSION with PNG Image loading

On 3/13/2012 1:09 PM, Alan Bateman wrote: On 13/03/2012 19:03, Xueming Shen wrote: While this indeed is a "regression", the question is do we really want this behavior (allow those corrupt zip/png files without throwing exception) to be the default behavior? A possible approac

Re: CR 7148271 REGESSION with PNG Image loading

INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR + inflateUndermine() is the answer from zlib author. -Sherman On 3/13/2012 5:06 PM, Ulf Zibis wrote: Am 13.03.2012 20:03, schrieb Xueming Shen: While this indeed is a "regression", the question is do we really want this behavior (allow tho

Codereview request for 7152690: Initialization error with charset SJIS_0213 when security manager is enabled

Hi Please help codereview the change for #7152690 http://cr.openjdk.java.net/~sherman/7152690/webrev This is an overlook when we changed SJIS_0213 implementation in 7. The "resource reading" obviously needs to be wrapped in doPrivileged block. Thanks! -Sherman

  1   2   3   4   5   6   7   8   9   10   >