Re: RFR [9]: 8050142: Optimize java.util.Formatter

09/23/2014 12:27 PM, Claes Redestad wrote: On 2014-09-23 21:14, Xueming Shen wrote: On 09/22/2014 12:43 PM, Claes Redestad wrote: Hi, Sherman pointed out that there was a path that could actually take a minor performance hit from this patch, which would be unacceptable. This version takes the mini

Re: RFR [9]: 8050142: Optimize java.util.Formatter

On 09/22/2014 12:43 PM, Claes Redestad wrote: Hi, Sherman pointed out that there was a path that could actually take a minor performance hit from this patch, which would be unacceptable. This version takes the minimal approach to addressing this by adding back a method operating on a char[], s

Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

On 09/22/2014 01:14 PM, Ivan Gerasimov wrote: Hello! The UTF-8 encoding allows characters that are 4 bytes long. However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which is not always enough. Would you please review the simple fix for this issue? BUGURL: https://bugs.openjdk.jav

Re: RFR: 8058887: (fmt) Improve java/util/Formatter test coverage of group separators and width

On 09/22/2014 02:00 PM, Xueming Shen wrote: It was on purpose to keep those blank lines when I wrote the Spp to replace the original script. it serves the purpose of preserving the line number the generated source code (identical to the ln# of the same code line in template file). This is

Re: RFR: 8058887: (fmt) Improve java/util/Formatter test coverage of group separators and width

It was on purpose to keep those blank lines when I wrote the Spp to replace the original script. it serves the purpose of preserving the line number the generated source code (identical to the ln# of the same code line in template file). This is convenient/import when debugging those generated

Re: RFR (XXS): 8058887: TEST_BUG: java/util/Formatter/genBasic.sh points to old location of Spp.java

On 09/22/2014 07:35 AM, Claes Redestad wrote: Hi, can I have a review and sponsor for this trivial fix to make the jtreg test generator script jdk/test/java/util/Formatter/genBasic.sh work in the new build system? bug: https://bugs.openjdk.java.net/browse/JDK-8058887 webrev: http://cr.openjdk

Re: RFR: 8058520: jar xf does not work on zip files with leading garbage.

On 09/17/2014 11:42 AM, Martin Buchholz wrote: On Tue, Sep 16, 2014 at 9:03 AM, Xueming Shen mailto:xueming.s...@oracle.com>> wrote: There is also some "regressions" reported later with the ZipFile path when dealing with some "wrong"/non-ZIP64-spec-complia

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

You're correct. I was confused by the hash_code() in javaClass that I'm recently working on:-) that is for those constants only. -Sherman On 9/17/14 9:43 AM, Aleksey Shipilev wrote: Hi Xueming, On 09/17/2014 08:13 PM, Xueming Shen wrote: String.hashCode() has intrinsics, No,

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

sn't special cased. Sent from my phone On Sep 17, 2014 12:14 PM, "Xueming Shen" <mailto:xueming.s...@oracle.com>> wrote: It definitely helps the "readability". String.hashCode() has intrinsics, so I don't think we are seeing the real perfor

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

It definitely helps the "readability". String.hashCode() has intrinsics, so I don't think we are seeing the real performance "difference" of the implementations. My guess is the original one probably is faster. On 9/17/14 8:25 AM, Aleksey Shipilev wrote: Thanks Martin! It used to be "Clean-

Re: RFR: 8058520: jar xf does not work on zip files with leading garbage.

On 9/15/14 6:40 PM, Martin Buchholz wrote: Hi Alan, Xueming, I'd like you to do a code review. https://bugs.openjdk.java.net/browse/JDK-8058520 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jar-leadingGarbage/

Re: RFR : 8044725 :Bug in zlib 1.2.5 prevents inflation of some gzipped files (zlib 1.2.8 port)

On 09/03/2014 03:05 AM, Seán Coffey wrote: I'd like to port the zlib v1.2.8 libraries to JDK 7u. Currently, 7u uses zlib v1.2.3 libraries. 8u20 was recently upgraded to 1.2.8. zlib fixes since 1.2.3 can be found at http://cr.openjdk.java.net/~coffeys/webrev.8044725.7u/webrev/raw_files/new/src/

Re: RFR: JDK-8056934: ZipInputStream does not correctly handle local header data descriptors with the optional signature missing

On 9/1/14 9:05 AM, Alan Bateman wrote: On 29/08/2014 20:12, Martin Buchholz wrote: Hi Xueming and Alan, I'd like you to do a code review. https://bugs.openjdk.java.net/browse/JDK-8056934 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/zip-DataDescriptorSignatureMissing/

Re: RFR: JDK-8056934: ZipInputStream does not correctly handle local header data descriptors with the optional signature missing

On 8/29/14 12:12 PM, Martin Buchholz wrote: Hi Xueming and Alan, I'd like you to do a code review. https://bugs.openjdk.java.net/browse/JDK-8056934 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/zip-DataDescriptorSignatureMissing/

Re: Exposing LZ77 sliding window size in the java.util.zip.[Inflator|Defaltor] API

Hi Mark, It sounds like a reasonable requirement. I have filed the rfe at https://bugs.openjdk.java.net/browse/JDK-8056093. Let's consider to add a pair of constructors in In/Deflator in jdk9. -Sherman On 08/26/2014 01:45 AM, Mark Thomas wrote: Hi, I'm currently working on the implementatio

Re: RFR 8055262: Update jdk/test/java/util/Base64 tests to use java.util.Base64 instead of sun.misc.BASE64Encoder/Decoder

On 08/18/2014 12:08 AM, Amy Lu wrote: There are two tests under jdk/test/java/util/Base64 that have dependency on internal API sun.misc.BASE64Encoder sun.misc.BASE64Decoder java/util/Base64/TestBase64Golden.java java/util/Base64/TestBase64.java This fix is to remove the internal API dependency

Re: RFR(S): 8055004: Reduce allocation overhead in java.time.Period/Duration parse methods

looks fine. though arguably it might be more correct to do if (dayStart != -1 || hourStart != -1 || minuteStart != -1 || secondStart != -1) { ... } as the regex spec says the start/end return -1 if no match for the group. -Sherman On 08/13/2014 05:50 AM, Claes Redestad wrote: Hi, can I ha

Re: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations

It appears input like "" now triggers different exception, the spec says it should throw IAE. -Sherman On 07/21/2014 04:41 AM, Claes Redestad wrote: On 07/19/2014 02:59 PM, Ivan Gerasimov wrote: This looks just beautiful! Thanks! But why do you need the digits() function at all? In my

Re: Review request for 8050968: Extension class loader initialization fails on Win7 x64 zh_TW

On 7/17/14 9:56 PM, Mandy Chung wrote: This is a regression caused by JDK-8038177 that changed sun.nio.cs.ext.ExtendedCharsets to use lambda. It turns out that ExtendedCharsets is loaded during the initialization of the extension class loader when opening jre/lib/ext/meta-index on windows with s

Re: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings

gister pressure (especially on older CPUs), this might be a performance advantage. Also I think we should not grow the result array for any character where "mapLen > srcCount", we could wait until the result array is actually full. -Ulf Am 17.07.2014 00:55, schrieb Xueming Shen:

Re: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings

Still need a reviewer. On 07/09/2014 01:04 PM, Xueming Shen wrote: Hi, Please help review the change for JDK-8042589. Issue:https://bugs.openjdk.java.net/browse/JDK-8042589 webrev: http://cr.openjdk.java.net/~sherman/8042589/webrev/ This is a regression caused by the following change for

RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings

Hi, Please help review the change for JDK-8042589. Issue:https://bugs.openjdk.java.net/browse/JDK-8042589 webrev: http://cr.openjdk.java.net/~sherman/8042589/webrev/ This is a regression caused by the following change for #JDK-8032012, issue:https://bugs.openjdk.java.net/browse/JDK-803

Re: RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException

On 07/07/2014 10:07 AM, Ivan Gerasimov wrote: Hello! The javadoc says that Pattern.compile(String regex, int flag) will throw IllegalArgumentException, if flag contains an invalid bit set. However, it fails to do so. Would you please help review the simple fix for that? Alternatively, we could

Re: RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb

hould be well used and maintained and be well supported. TzdbZoneRulesCompiler.java: +130 The error for srcFile == null still mentions "-srcdir". :+153; the commented out message should be removed Roger On 5/19/2014 2:12 PM, Xueming Shen wrote: Hi, I've not got any feedback

RFR: JDK-8044727: Problem reading the contents of some zip files

Hi, Please help review issue: https://bugs.openjdk.java.net/browse/JDK-8044727 webrev: http://cr.openjdk.java.net/~sherman/8044727/webrev/ cause: Regression caused by the following changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f [http://cr.openjdk.java.net/~sherman/6303183/

RFR: JDK-8044725: Bug in zlib 1.2.5 prevents inflation of some gzipped files

Hi, Please help review the change to upgrade the zlib bundled with jdk/jre from 1.2.5 to 1.2.8. This is mainly to address the bug fix mentioned in 1.2.8's release at zlib.net. "Version 1.2.8 fixes a very rare bug in decompression. All users are encouraged to upgrade immediately..." http://cr.o

Re: RFR: 8043592: The basic XML parser based on UKit fails to read XML files encoded in UTF-16BE or LE

looks good. -Sherman On 5/27/14 3:36 PM, huizhe wang wrote: Thanks Sherman! On 5/27/2014 1:46 PM, Xueming Shen wrote: One more nit, ln#2876-2879 Do we really need to create a new ReaderUTF8, if the encoding is indeed is utf8? which I would assume should be true for most use scenarios

Re: RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb

still mentions "-srcdir". :+153; the commented out message should be removed Roger On 5/19/2014 2:12 PM, Xueming Shen wrote: Hi, I've not got any feedback so far, so I assume it's good:-) Anyway, I'm going a little further to throw in a TarInputStream so now we just

Re: RFR: 8043592: The basic XML parser based on UKit fails to read XML files encoded in UTF-16BE or LE

Hi (1) Do we really need those shift at line ln#2989/90 and 2994/95? it appears to me those bytes have been decided to be ZERO already, we are talking about mChar[0] = '<' and mChar[1] = '?' here, right? (2) for test, maybe we should just do p.loadFromXML(in) ? that path should verif

Re: RFR: Faster ZipFile.getEntry()/entries()

On 05/21/2014 02:31 PM, Bernd Eckenfels wrote: Am Wed, 21 May 2014 14:19:13 -0700 schrieb Xueming Shen: And java implementation also brings in the benefits of better memory usage (all memory allocated in java heap), no more expensive jni invocations... Opinion/comments are appreciated. I had

Re: RFR: Faster ZipFile.getEntry()/entries()

n the benefits of better memory usage (all memory allocated in java heap), no more expensive jni invocations... Opinion/comments are appreciated. Thanks! -Sherman On 09/05/2013 04:16 PM, Xueming Shen wrote: Hi, The change proposed here is to bring the zip entry handing code from the native lev

Re: RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb

ps run with the new data in next 24 hrs...) in the future. http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev On 05/04/2014 11:16 PM, Xueming Shen wrote: Hi Please help review the change for #8042369 Issue: https://bugs.openjdk.java.net/browse/JDK-8042369 Webrev: http://cr.openjdk.java.ne

RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb

Hi Please help review the change for #8042369 Issue: https://bugs.openjdk.java.net/browse/JDK-8042369 Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev In jdk8 we had to duplicate dozen java.time classes in build.tools to build the timezone data for the new JSR310 timezone data compil

Re: Error: ~Documents/hg-workspaces/openjdk9/dev/jdk/test/TEST.groups: group jdk_other: file not found: demo/zipfs

Looks good. > On Apr 22, 2014, at 6:05 AM, Lance Andersen wrote: > > > Here is the diff for this via bug 8041485 > > hg diff test/Test.groups > diff -r 3aeb306d985c test/TEST.groups > --- a/test/TEST.groupsTue Apr 22 08:57:01 2014 -0400 > +++ b/test/TEST.groupsTue Apr 22 09:01

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

15/04/2014 1:48 PM, Xueming Shen wrote: Hi, webrev has been updated to use the name space jdk.nio.zipfs. http://cr.openjdk.java.net/~sherman/8038500/webrev/ -Sherman On 4/14/14 12:15 PM, Xueming Shen wrote: On 4/14/14 11:56 AM, Alan Bateman wrote: On 14/04/2014 18:52, Xueming Shen wrote: T

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

Hi, webrev has been updated to use the name space jdk.nio.zipfs. http://cr.openjdk.java.net/~sherman/8038500/webrev/ -Sherman On 4/14/14 12:15 PM, Xueming Shen wrote: On 4/14/14 11:56 AM, Alan Bateman wrote: On 14/04/2014 18:52, Xueming Shen wrote: Thanks Mandy and Alan for the review

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

On 4/14/14 11:56 AM, Alan Bateman wrote: On 14/04/2014 18:52, Xueming Shen wrote: Thanks Mandy and Alan for the review. webrev has been updated accordingly to (1) Removed the basic.sh. The tests are now using test.jdk to access the zipfs.jar directly (2) Updated most of the class to package

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

/2014 3:42 PM, Xueming Shen wrote: webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev It's good to see the source of the zip provider moved to the jdk repo. You have made some public classes to package-private which is good. I wonder whether a few remaining public classes can b

RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

Hi, Please help review this changeset to upgrade the zip filesystem provider implementation from demo to a supported provider. Back in JDK7 we created a demo file system provider for zip/jar files. It is shipped in two forms, one as a binary under lib/ext that works "out of the box" to suppor

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

On 04/10/2014 12:03 PM, Chris Hegarty wrote: On 10 Apr 2014, at 19:50, Xueming Shen wrote: On 04/10/2014 11:38 AM, Mike Duigou wrote: On Apr 10 2014, at 11:08 , Chris Hegarty wrote: On 10 Apr 2014, at 18:40, Mike Duigou wrote: On Apr 10 2014, at 03:21 , Chris Hegarty wrote: On

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

On 04/10/2014 11:38 AM, Mike Duigou wrote: On Apr 10 2014, at 11:08 , Chris Hegarty wrote: On 10 Apr 2014, at 18:40, Mike Duigou wrote: On Apr 10 2014, at 03:21 , Chris Hegarty wrote: On 10 Apr 2014, at 11:03, Ulf Zibis wrote: Hi Chris, Am 10.04.2014 11:04, schrieb Chris Hegarty: Tr

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

On 04/10/2014 11:08 AM, Chris Hegarty wrote: On 10 Apr 2014, at 18:40, Mike Duigou wrote: On Apr 10 2014, at 03:21 , Chris Hegarty wrote: On 10 Apr 2014, at 11:03, Ulf Zibis wrote: Hi Chris, Am 10.04.2014 11:04, schrieb Chris Hegarty: Trivially, you could ( but of not have to ) use ja

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

This fix is to "un-do" a previous changeset (8036848), in which it replaces the use of deprecated String.getBytes(int,int,byte[],int) method with String.getBytes() (which uses the default platform default charset), therefor causes a behavioral change. This one is to undo that change to go back to

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

Looks fine. Personally I would prefer the "canonicalized/real" name "ISO-8859-1" though. -Sherman On 4/10/14 7:57 AM, Brian Burkhalter wrote: On Apr 10, 2014, at 3:27 AM, Ulf Zibis wrote: Correction ... Am 10.04.2014 12:03, schrieb Ulf Zibis: Hi Chris, Am 10.04.2014 11:04, schrieb Chris

RFR: JDK-8039751: UTF-8 decoder fails to handle some edge cases correctly

Hi, Please help review the fix for JDK-8039751. Issue: https://bugs.openjdk.java.net/browse/JDK-8039751 webrev: http://cr.openjdk.java.net/~sherman/8039751/webrev/ This is the corner case (in 4 bytes sequence) we missed when fixing 7096080 [1]. The UTF_8 decoder correctly returns the malf

Re: RFR : 8038491: Improve synchronization in ZipFile.read()

ecks that we make : e.g 722 if (rem == 0) { 723 close(); 724 } Am I reading this correctly ? regards, Sean. On 08/04/2014 16:59, Xueming Shen wrote: Hi Sean, It might be more explicit to check "if (zentry == 0)" here? -Sherman On 4/8/14 8:21 AM,

Re: RFR : 8038491: Improve synchronization in ZipFile.read()

;s code in certain circumstance... -Sherman regards, Sean. On 08/04/2014 16:59, Xueming Shen wrote: Hi Sean, It might be more explicit to check "if (zentry == 0)" here? -Sherman On 4/8/14 8:21 AM, Seán Coffey wrote: A recently reported bug shows a race condition is possible on the

Re: RFR : 8038491: Improve synchronization in ZipFile.read()

Hi Sean, It might be more explicit to check "if (zentry == 0)" here? -Sherman On 4/8/14 8:21 AM, Seán Coffey wrote: A recently reported bug shows a race condition is possible on the rem == 0 check in ZipFile.read(byte b[], int off, int len). A bad check can result in referencing a jzentry str

Re: StringBuilder version of java.util.regex.Matcher.append*

On 04/04/2014 10:08 AM, Xueming Shen wrote: On 4/3/14 4:43 PM, Jeremy Manson wrote: Good catch, thanks. I think we should probably just go with the (equivalent to the) StringBuffer variant. I'm pretty loathe to modify the StringBuilder directly if we are going to back that change out

Re: StringBuilder version of java.util.regex.Matcher.append*

I can/will send out an updated webrev before push. -Sherman Jeremy On Thu, Apr 3, 2014 at 2:27 PM, Xueming Shen <mailto:xueming.s...@oracle.com>> wrote: On 03/25/2014 02:07 PM, Jeremy Manson wrote: Okay. Thanks, Sherman. Here's an updated version. I've div

Re: StringBuilder version of java.util.regex.Matcher.append*

t;); } We may have to either catch the IAE and reset the sb, or create a new sb, as the StringBuffer does. -Sherman I also noticed a redundant cast to (int), which I removed. Jeremy On Fri, Mar 21, 2014 at 7:34 PM, Xueming Shen mailto:xueming.s...@oracle.com>> wrote: le

Re: RFR: 8038306: (tz) Support tzdata2014b

looks fine. On 4/2/14 3:55 AM, Aleksej Efimov wrote: Hello, Can I have a review for the latest (2014b) TZ data integration to JDK9. The webrev can be located here [1]. The following set of tests were executed without failures: test/sun/util/calendar test/java/util/Calendar test/sun/util/res

Re: JDK-8038451: Incorrect initialization order of static fields in sun.nio.cs.ext.JISAutoDetect$Decoder

On 03/27/2014 01:49 PM, Mandy Chung wrote: This fixes the regression introduced by JDK-8038177 in which the osName field should be initialized before it's accessed in the class static initializer. https://bugs.openjdk.java.net/browse/JDK-8038451 Webrev at: http://cr.openjdk.java.net/~mchung/jd

Re: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null

Stephen, public DateTimeFormatter withResolverFields(TemporalField... resolverFields) { - Objects.requireNonNull(resolverFields, "resolverFields"); - Set fields = new HashSet<>(Arrays.asList(resolverFields)); + Set fields = null; + if (resolverFields != null) { + fields = Collections.unmodifiable

Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

ectiveZone and effectiveChrono (which I thought you were trying to remove). thanks Stephen On 24 March 2014 15:00, Xueming Shen mailto:xueming.s...@oracle.com>> wrote: Stephen, I commented on this one last week. I did not see the response, is it something worth considering? or

Re: StringBuilder version of java.util.regex.Matcher.append*

g with the Appendable differently is the right approach, FWIW. Jeremy On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen mailto:xueming.s...@oracle.com>> wrote: 2009? I do have something similar back to 2009 :-) http://cr.openjdk.java.net/~sherman/regex_re

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

as the IBM ebcdic. -Sherman On 3/20/14 3:48 PM, Mandy Chung wrote: On 3/19/14 12:28 PM, Xueming Shen wrote: On 03/19/2014 11:37 AM, Mandy Chung wrote: https://bugs.openjdk.java.net/browse/JDK-8035807 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ This patch

Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

Hi Stephen, Given the fact that the parser context is no longer public, the parsed from the formatter is either unresolved or resolved, just wonder if we really need those "effective" chrono and zone fields in Parsed. It appears perfect for me to simply keep these info inside the parser context

Re: StringBuilder version of java.util.regex.Matcher.append*

2009? I do have something similar back to 2009 :-) http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ Then the ball was dropped around the discussion of whether or not the IOE should be thrown. But if we are going to/have to have explicit StringBuilder/Buffer pair anyway, then we can kee

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

On 03/19/2014 11:37 AM, Mandy Chung wrote: https://bugs.openjdk.java.net/browse/JDK-8035807 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64. We sh

Re: StringBuilder version of java.util.regex.Matcher.append*

Similar suggestion has been on the to-do list for a while. There were discussion back then that it might be interesting to add the more general interface Appendable... The issue was how to deal with the IOE declared by the Appendable methods then. If the appendable is not going to happen, then

Re: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java

nitpicking, (1) shouldn't the variable at #468 to be updated to "lch" instead of "uch" as well? (2) StringBuilder can be used to replace the StringBuffer in toString(). -Sherman On 03/05/2014 12:18 PM, David Li wrote: Hi, This is an update from Xerces for file impl/xpath/regex/TokenRange.jav

RFR JDK-8035814: Broken link in java.nio.StandardCharsets

Hi, please help review the trivial doc typo fix. https://bugs.openjdk.java.net/browse/JDK-8035814 http://cr.openjdk.java.net/~sherman/8035814/webrev Thanks! -Sherman

Re: RFR: JDK-6609854: Regex does not match correctly for negative nested character classes

Couple rounds of emails had been exchanged internally regarding this issue years ago and a proposal had been briefly discussed at this list back to 2011 [1]. The only reason that hold us to just fix it is the "compatibility" concern, since the described behavior has been there for decade. It

Re: JDK 9 RFR of JDK-8035076: Pattern$BnMS never used due to bug in Pattern$BnM.optimize

ed, Feb 19, 2014 at 2:31 PM, Xueming Shen mailto:xueming.s...@oracle.com>> wrote: Hi, Please help codereview the change for JDK-8035076. Issue: https://bugs.openjdk.java.net/browse/JDK-8035076 Webrev: http://cr.openjdk.java.net/~sherman/8035067/webrev <http://cr.openjdk.ja

JDK 9 RFR of JDK-8035076: Pattern$BnMS never used due to bug in Pattern$BnM.optimize

Hi, Please help codereview the change for JDK-8035076. Issue:https://bugs.openjdk.java.net/browse/JDK-8035076 Webrev: http://cr.openjdk.java.net/~sherman/8035067/webrev This is regression caused by the change we made back to jdk7 to support case insensitive match, in which a base class Slic

Re: JDK 8: Second Release Candidate

Created an issue for this one. https://bugs.openjdk.java.net/browse/JDK-8035042 Need go dig out some history. requireEnd is primarily designed for j.u.Scanner. -Sherman On 2/15/14 8:02 AM, Martin Buchholz wrote: Java has had for a while now a bug in its regex system which I'd like to see fi

Re: ObjectIn/OutputStream improvements

Modified UTF8 has to be used, as specified by the spec. http://download.java.net/jdk8/docs/api/java/io/DataInput.html#modified-utf-8 -Sherman On 02/06/2014 02:50 PM, Robert Stupp wrote: >>> -Chris. >>

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

On 02/06/2014 11:41 AM, Ulf Zibis wrote: Me again ;-) On 02/06/2014 10:30 AM, Ulf Zibis wrote: But why not just coding: 2558 char ch = value[first]; 2559 if (Character.isSurrogate(ch) { 2560 hasSurr = true; 2561 break; 2562 }

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

On 02/06/2014 10:30 AM, Ulf Zibis wrote: Am 06.02.2014 18:40, schrieb Xueming Shen: Ulf, webrev has been updated to use isBmpCodePoint() as suggested. Another benefit of using isBmpCodePoint() is that some Character.ERROR checks are no longer necessary Great, I didn't see that. But wh

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

it took much longer than I would have expected, but I'm happy with the latest result. http://cr.openjdk.java.net/~sherman/8032012/webrev/ -Sherman On 02/06/2014 01:44 AM, Paul Sandoz wrote: On Feb 6, 2014, at 5:37 AM, Xueming Shen wrote: Fair enough. I don't think it's goin

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

d not cost anything; it'll just make jit use low 16 bits of the registers for (unsigned) comparisons. I haven't checked this though, but that's what I'd expect. Sent from my phone On Feb 5, 2014 7:27 PM, "Xueming Shen" <mailto:xueming.s...@oracle.com>> wro

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

n -Ulf Am 05.02.2014 22:30, schrieb Xueming Shen: Hi Remi, Good suggestion. Now the "common case" path is much simple and faster :-) I'm seeing a 5%-10% boost for the normal-non-surrogates case. And it appears the bmp+surr mixed is getting faster as well. Though I would assume the it w

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

Hi Remi, Good suggestion. Now the "common case" path is much simple and faster :-) I'm seeing a 5%-10% boost for the normal-non-surrogates case. And it appears the bmp+surr mixed is getting faster as well. Though I would assume the it would get slower in case of "no-case-folding" + surrogates. Bu

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

Hi Paul, http://cr.openjdk.java.net/~sherman/8032012/webrev webrev has been updated accordingly. Thanks! -Sherman On 02/05/2014 10:43 AM, Xueming Shen wrote: On 02/05/2014 11:09 AM, Paul Sandoz wrote: On Feb 5, 2014, at 6:58 PM, Xueming Shen wrote: Hi, Let's try to wrap it up, othe

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

On 02/05/2014 11:09 AM, Paul Sandoz wrote: On Feb 5, 2014, at 6:58 PM, Xueming Shen wrote: Hi, Let's try to wrap it up, otherwise I may drop the ball somewhere :-) On 01/22/2014 07:20 AM, Paul Sandoz wrote: if (lang == "tr" || lang == "az" || lang == &quo

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

Hi, Let's try to wrap it up, otherwise I may drop the ball somewhere :-) On 01/22/2014 07:20 AM, Paul Sandoz wrote: if (lang == "tr" || lang == "az" || lang == "lt") { // local dependent return toLowerCaseEx(result, firstUpper, locale, true); } // otherwise false is passed to subsequ

Re: RFR : 8029020 : Check src/share/native/java/util/zip code for JNI pending exceptions

On 2/4/14 5:31 AM, Seán Coffey wrote: Looking to correct some JNI handling code in java/util/zip for jdk9-dev. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8029020/webrev/ regards, Sean. looks fine.

Re: RFR java.time cleanup of javadoc and messages

The changeset looks fine. But, do we need a CCC for 8032558 and 8032494 "for the record"? -Sherman On 02/03/2014 02:43 PM, roger riggs wrote: Please review this group of java.time updates: 8032749 : Typo in java.time.Clock 8032888

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

Hi Paul, thanks for reviewing the changeset, comment inlined below. On 01/20/2014 09:24 AM, Paul Sandoz wrote: Some quick comments. In String.toLowerCase: - it would be nice to get rid of the pseudo goto using the "scan" labelled block. webrev has been updated to remove the pseudo goto by

RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

Hi, The proposed changeset is to improve the performance (both speed and memory usage) of String.toLowerCase/toUpperCase, by (1) to separate the "most likely" use scenario (non supplementary character, no special case mapping handling) into simple/quick iteration loop code path (2) to use the p

Re: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.

On 1/15/14 7:01 AM, Alexander Zuev wrote: Hello, the new webrev with all the typos and comments fixed can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ /Alex (1) jarmagic can be just a static constant somewhere or a stack variable. not big deal though. (2) the test

Re: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.

Hi Alex, (1) what's the bits are you setting into the general flags fields as below? header[4] = ( store ) ? SWAP_BYTES(0x0800) : 0x0808; (2) why do you want to use extra data descriptor to set crc/size/csize? while I understand that Jar/ZipOutputStream does that, but that is because they

Re: RFR java.time serialization

On 12/16/2013 09:02 AM, roger riggs wrote: Please review these changes to java.time serialization. The format of the serialized data is unchanged; deserialization uses readObject instead of readResolve to flag invalid values. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-serializatio

Re: RFR: Add value-type notice to java.time classes

On 12/04/2013 12:00 PM, roger riggs wrote: Following the lead of the notices added to Optional, the java.time value based classes should include the same notice. Please review: http://cr.openjdk.java.net/~rriggs/webrev-time-valuetype-8029551/ Thanks, Roger http://cr.openjdk.java.net/~rri

hg: jdk8/tl/jdk: 8028397: Undo the lenient MIME BASE64 decoder support change (JDK-8025003) and remove methods de/encode(buf, buf)

Changeset: 301d76b8cb55 Author:sherman Date: 2013-12-03 17:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/301d76b8cb55 8028397: Undo the lenient MIME BASE64 decoder support change (JDK-8025003) and remove methods de/encode(buf, buf) Summary: updated the spec and implement

Re: There needs to be support for java.time in java.text.MessageFormat

On 12/02/2013 12:46 PM, Stephen Colebourne wrote: On 2 December 2013 19:47, Xueming Shen wrote: That said, it might be desired to add the support of the JSR310 date/time for the DateFormat, but it will not make jdk8. FWIW, I think this should have been fixed in jdk 8. https

Re: There needs to be support for java.time in java.text.MessageFormat

On 12/01/2013 01:13 PM, Nick Williams wrote: On Dec 1, 2013, at 12:52 PM, Xueming Shen wrote: On 12/1/13 10:29 AM, Nick Williams wrote: I filed these bugs back in June. I noticed today that they were migrated to the JIRA instance: https://bugs.openjdk.java.net/browse/JDK-8016742 https

Re: RFR JDK-8028397: Undo the lenient MIME BASE64 decoder support change (JDK-8025003) and remove methods de/encode(buf, buf)

4/2013 12:59 PM, Xueming Shen wrote: Hi, The consensus/conclusion from the discussion [1] regarding the changes we made earlier for JDK-8025003 [2] is to back out the existing "half-lenient" change to leave the door open for a clean "lenient" support for future releases. He

Re: There needs to be support for java.time in java.text.MessageFormat

On 12/1/13 10:29 AM, Nick Williams wrote: I filed these bugs back in June. I noticed today that they were migrated to the JIRA instance: https://bugs.openjdk.java.net/browse/JDK-8016742 https://bugs.openjdk.java.net/browse/JDK-8016743 I filed the bugs, though they say someone else did. It's fr

Re: Different error decoding Shift-JIS sequence in JDK8

Hi Charles, My apology for the late response. I was on vacation the past week and did not have full email access. As Sean pointed out, this is triggered by the change we just put in recently for 8008386, in which tried to address a strong request that asked for case like 'fe' '40' to be tre

Re: "".split(":").length?

Yes, I have to pull it back due to the compatibility concern. It appears the jdk source code itself has couple places depending on this "incorrect" behavior. The typical usage is "".split(...)[0], in which the code tries to access the 0th element without even checking the return length. I may re

Re: RFR JDK-8028397: Undo the lenient mimi decoder suport change (JDK-8025003) in jdk8

On 11/15/13 1:01 PM, Alan Bateman wrote: On 15/11/2013 17:12, Xueming Shen wrote: I'm happy to put the "IAE with advanced positions" change back, the webrev has been updated according. http://cr.openjdk.java.net/~sherman/8028397/webrev/ That looks much better. One case that

Re: RFR JDK-8028397: Undo the lenient mimi decoder suport change (JDK-8025003) in jdk8

On 11/15/13 6:36 AM, Alan Bateman wrote: On 14/11/2013 20:59, Xueming Shen wrote: : Here is the webrev for the undo (keep the mime encoder(...) rename change) http://cr.openjdk.java.net/~sherman/8028397/webrev I think is okay except for the restoring of the buffer position when an error

RFR JDK-8028397: Undo the lenient mimi decoder suport change (JDK-8025003) in jdk8

Hi, The consensus/conclusion from the discussion [1] regarding the changes we made earlier for JDK-8025003 [2] is to back out the existing "half-lenient" change to leave the door open for a clean "lenient" support for future releases. Here is the webrev for the undo (keep the mime encoder(...)

Re: RFR 8025003: Base64 should be less strict with padding

On 11/14/2013 11:12 AM, Bill Shannon wrote: Alan Bateman wrote on 11/14/2013 06:18 AM: On 13/11/2013 20:28, Xueming Shen wrote: Yes, the plan is to see what other implementations do. I think we've run out road on this for JDK 8. Even if we had agreement on dealing with corrupt input

hg: jdk8/tl/jdk: 8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression

Changeset: 1d790a56de4e Author:sherman Date: 2013-11-13 22:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d790a56de4e 8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression Summary: to undo the change for 6559590 Reviewed-by: darcy ! src/sh

RFR JDK-8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression.

Hi, The change set for JDK-6559590 [1] triggers couple regression test failures in various areas. It appears jdk8 source code itself has dependency on the "old" behavior of split() method when the input sequence is an empty string (split-ing a zero-length input sequence always returns the resu

Re: RFR 8025003: Base64 should be less strict with padding

On 11/13/2013 11:37 AM, Bill Shannon wrote: Xueming Shen wrote on 11/13/13 11:11: On 11/13/2013 10:41 AM, Bill Shannon wrote: The other thought is the charset API where a charset decoder can be configured to ignore, replace or report then malformed or unmappable input. Having support for all

hg: jdk8/tl/jdk: 8027645: Pattern.split() with positive lookahead; ...

Changeset: 9e37caf07ce0 Author:sherman Date: 2013-11-13 11:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e37caf07ce0 8027645: Pattern.split() with positive lookahead 6559590: Pattern.compile(".*").split("") returns incorrect result Summary: updated spec/impl for these tw

<    2   3   4   5   6   7   8   9   10   11   >