Re: RFR: 8247781: Day periods support [v7]

On Fri, 6 Nov 2020 09:12:38 GMT, Stephen Colebourne wrote: >> Did you mean in STRICT mode, HOUR_OF_AMPM should default to 0, and to 6 in >> SMART/LENIENT modes? > > No. I mean that when resolving AMPM/dayPeriod in strict mode, and there is no > HOUR_OF_DAY or HOUR_OF_AMPM, then do not resolve

Re: RFR: 8247781: Day periods support [v7]

On Thu, 5 Nov 2020 23:25:38 GMT, Stephen Colebourne wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed typo/grammatical error. > > test/jdk/java/time/tck/java/time/format/TCKD

Re: RFR: 8255969: Improve java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags [v2]

On Thu, 5 Nov 2020 22:10:07 GMT, Brian Burkhalter wrote: >> Please review this change which would replace the use of a system property >> and a child process with updated jtreg tags. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last

Re: RFR: 8255969: Improve java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags

On Thu, 5 Nov 2020 19:50:14 GMT, Brian Burkhalter wrote: > Please review this change which would replace the use of a system property > and a child process with updated jtreg tags. test/jdk/java/io/BufferedInputStream/LargeCopyWithMark.java line 29: > 27: * @summary BufferedInputStream

Re: RFR: 8247781: Day periods support [v7]

and its spec are in this CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254629 > > Naoto Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed typo/grammatical error. - Changes: - all: https://git.ope

Re: RFR: 8247781: Day periods support [v7]

On Thu, 5 Nov 2020 16:07:30 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed typo/grammatical error. > > src/java.base/share/classes/java/time/format/DateTimeForm

Re: RFR: 8247781: Day periods support [v3]

On Mon, 2 Nov 2020 19:20:10 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed exception messages. > > src/java.base/share/classes/java/time/format/P

Re: RFR: 8247781: Day periods support [v6]

and its spec are in this CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254629 > > Naoto Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull reque

Re: RFR: 8247781: Day periods support [v5]

On Wed, 4 Nov 2020 18:44:33 GMT, Joe Wang wrote: >> Changes requested by scolebourne (Author). > > Since 24:00 is not represented in for example LocalTime and H (hour-of-day) > 0-23, it seems obvious midnight in the JDK would be 00:00, and the new > DayPeriod tests proves that. The CLDR rule

Re: RFR: 8247781: Day periods support [v5]

and its spec are in this CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254629 > > Naoto Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed TCK test failures, added the new pattern char description in DateTimeFormatter

Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d [v3]

On Tue, 3 Nov 2020 15:49:09 GMT, Kiran Sidhartha Ravikumar wrote: >> Hi Guys, >> >> Please review the integration of tzdata2020d to JDK. >> >> Details regarding the change can be viewed at - >> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html >> Bug:

Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

On Tue, 3 Nov 2020 00:00:26 GMT, Kiran Sidhartha Ravikumar wrote: >> My question is why it is failing. Have you figured it? The existing >> exceptions are either negative DST or last rule beyond 2037, which javazic >> cannot handle. The changes introduced with 2020d does not meet either of

Re: RFR: 8247781: Day periods support [v4]

On Mon, 2 Nov 2020 17:08:10 GMT, Stephen Colebourne wrote: >> src/java.base/share/classes/java/time/format/Parsed.java line 497: >> >>> 495: AMPM_OF_DAY.checkValidValue(ap); >>> 496: } >>> 497:

Re: RFR: 8247781: Day periods support [v4]

On Mon, 2 Nov 2020 17:05:40 GMT, Stephen Colebourne wrote: >> MINUTE_OF_HOUR without HOUR_OF_DAY/HOUR_OF_AMPM may not make any sense, so >> it is only validated in updateCheckDayPeriodConflict. > > But can you get a CLDR rule that says "at night" before 05:30 and "In the > morning" from 05:30

Re: RFR: 8247781: Day periods support [v4]

and its spec are in this CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254629 > > Naoto Naoto Sato has updated the pull request incrementally with three additional commits since the last revision: - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516147298 - A

Re: RFR: 8247781: Day periods support [v3]

On Mon, 2 Nov 2020 17:27:35 GMT, Stephen Colebourne wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed exception messages. > > test/jdk/java/time/test/java/time/format/TestDateTim

Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

On Mon, 2 Nov 2020 18:06:28 GMT, Kiran Sidhartha Ravikumar wrote: >> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201: >> >>> 199: zid.equals("Iran") || // last rule mismatch >>> 200: zid.equals("Asia/Gaza") || // last rule mismatch >>> 201:

Re: RFR: 8255529: Remove unused methods from java.util.zip.ZipFile

On Mon, 2 Nov 2020 17:33:57 GMT, Lance Andersen wrote: > Please review this fix for JDK-8255529 which removes methods that were unused > and were added back merge in July > > Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean. Looks good to me. - Marked as reviewed by naoto

Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

On Mon, 2 Nov 2020 16:29:07 GMT, Kiran Sidhartha Ravikumar wrote: > Hi Guys, > > Please review the integration of tzdata2020d to JDK. > > Details regarding the change can be viewed at - > https://mm.icann.org/pipermail/tz-announce/2020-October/62.html > Bug:

Integrated: 8255671: Bidi.reorderVisually has misleading exception messages

On Fri, 30 Oct 2020 22:23:30 GMT, Naoto Sato wrote: > Hi, > > Please review this simple message fix that follows JDK-8255242. > > Naoto This pull request has now been integrated. Changeset: 6dac8d27 Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit

RFR: 8255671: Bidi.reorderVisually has misleading exception messages

Hi, Please review this simple message fix that follows JDK-8255242. Naoto - Commit messages: - 8255671: Bidi.reorderVisually has misleading exception messages Changes: https://git.openjdk.java.net/jdk/pull/973/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=973=00

Re: RFR: 8247781: Day periods support [v3]

and its spec are in this CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254629 > > Naoto Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed exception messages. - Changes: - all: https://git.openjdk.ja

Re: RFR: 8247781: Day periods support [v2]

On Fri, 30 Oct 2020 10:33:28 GMT, Stephen Colebourne wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressed the following comments: >> - https://github.com/openjdk/jdk/

Re: RFR: 8247781: Day periods support [v2]

and its spec are in this CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254629 > > Naoto Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressed the following comments: - https://github.com/openjdk/jdk/pull/938#disc

RFR: 8247781: Day periods support

Hi, Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:

Integrated: 8255533: Incorrect javadoc in DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'

On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix in > DateTimeFormatterBuilder.appendPattern(). It is missing the value for > `maxWidth` argument. > > Naoto This pull request has now been integrated. Changeset: 790d6e2d

RFR: 8255533: Incorrect javadoc in DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'

Hi, Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern(). It is missing the value for `maxWidth` argument. Naoto - Commit messages: - 8255533: Incorrect javadoc in DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy' Changes:

Integrated: 8255242: Bidi.requiresBidi has misleading exception message

On Fri, 23 Oct 2020 16:48:03 GMT, Naoto Sato wrote: > Hi, > > Please review this small exception message fix. > > Naoto This pull request has now been integrated. Changeset: 57d903bd Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/57d903bd Stats:

RFR: 8255242: Bidi.requiresBidi has misleading exception message

Hi, Please review this small exception message fix. Naoto - Commit messages: - 8255242: Bidi.requiresBidi has misleading exception message Changes: https://git.openjdk.java.net/jdk/pull/841/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=841=00 Issue:

Integrated: 8255086: Update the root locale display names

On Wed, 21 Oct 2020 20:39:18 GMT, Naoto Sato wrote: > Hi, > > Please review the changes to the subject issue. The fix replaces the > obsolete/incorrect English language/region/script display names in the COMPAT > root locale bundle. The data are derived from CLDR's English na

Re: RFR: 8255086: Update the root locale display names [v2]

On Thu, 22 Oct 2020 22:29:16 GMT, Joe Wang wrote: >> Marked as reviewed by bchristi (Reviewer). > > Hi Naoto, > > Do we need a test similar to ISO3166 where display names of Locale.ROOT and > Locale.US are compared? I see LocaleEnhanceTest.java has references to > Locale.ROOT and a few

Re: RFR: 8255086: Update the root locale display names [v2]

> Hi, > > Please review the changes to the subject issue. The fix replaces the > obsolete/incorrect English language/region/script display names in the COMPAT > root locale bundle. The data are derived from CLDR's English names. Naoto Sato has updated the pull request increme

Re: RFR: 8255086: Update the root locale display names

On Wed, 21 Oct 2020 23:01:59 GMT, Brent Christian wrote: >> Hi, >> >> Please review the changes to the subject issue. The fix replaces the >> obsolete/incorrect English language/region/script display names in the >> COMPAT root locale bundle. The data are derived from CLDR's English names. >

RFR: 8255086: JRE country and region name may be the latest

Hi, Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names. - Commit messages: - 8255086: JRE country and region name may

Re: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c [v2]

On Tue, 20 Oct 2020 11:39:36 GMT, Kiran Sidhartha Ravikumar wrote: >> Hi Guys, >> >> Please review the integration of tzdata2020c to JDK. >> >> Details regarding the change can be viewed at - >> https://mm.icann.org/pipermail/tz-announce/2020-October/60.html >> Bug:

Re: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c

On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar wrote: > Hi Guys, > > Please review the integration of tzdata2020c to JDK. > > Details regarding the change can be viewed at - > https://mm.icann.org/pipermail/tz-announce/2020-October/60.html > Bug:

Integrated: 8253240: No javadoc for DecimalFormatSymbols.hashCode()

On Wed, 16 Sep 2020 17:29:52 GMT, Naoto Sato wrote: > Hi, > > Please review the fix to the issue wrt missing hashCode() javadoc, which was > recently discussed in core-libs ml. This pull request has now been integrated. Changeset: bddb8225 Author: Naoto Sato URL:

Integrated: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode

On Fri, 18 Sep 2020 23:26:39 GMT, Naoto Sato wrote: > Hi, > > Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) > hash code was incorrectly referenced in > equals() method. Removing it will correct the problem. Also, unrelated to the > issue, I

Re: RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode [v2]

On Sat, 19 Sep 2020 01:19:04 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressing Joe's comments > > Marked as reviewed by joehw (Reviewer). > Also, copyright ye

Re: RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode [v2]

> Hi, > > Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) > hash code was incorrectly referenced in > equals() method. Removing it will correct the problem. Also, unrelated to the > issue, I fixed a parameter description in > a private metho

RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode

Hi, Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) hash code was incorrectly referenced in equals() method. Removing it will correct the problem. Also, unrelated to the issue, I fixed a parameter description in a private method. Naoto - Commit

Integrated: 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc

On Fri, 18 Sep 2020 01:49:09 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. This pull request has now been integrated. Changeset: 89044200 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/89044200 Stats: 2 lines in 1 file changed: 0 i

RFR: 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc

Hi, Please review this simple doc fix. - Commit messages: - 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc Changes: https://git.openjdk.java.net/jdk/pull/234/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=234=00 Issue:

Re: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() [v2]

On Wed, 16 Sep 2020 19:53:26 GMT, Roger Riggs wrote: >> Looks in line with the discussion on core-libs. > > Removing hashcode from the serialized form needs a CSR because it was > non-transient in JDK 15. > The intent is to not use the serialized value, so the readObject method > should zero

Re: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() [v2]

> Hi, > > Please review the fix to the issue wrt missing hashCode() javadoc, which was > recently discussed in core-libs ml. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressing Roger's comments. --

Re: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() [v2]

On Wed, 16 Sep 2020 17:47:17 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressing Roger's comments. > > src/java.base/share/classes/java/text/DecimalFormatSymb

RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode()

Hi, Please review the fix to the issue wrt missing hashCode() javadoc, which was recently discussed in core-libs ml. - Commit messages: - 8253240: No javadoc for DecimalFormatSymbols.hashCode() Changes: https://git.openjdk.java.net/jdk/pull/208/files Webrev:

Re: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode

I created a JIRA issue for this: https://bugs.openjdk.java.net/browse/JDK-8253240 Naoto On 9/16/20 2:11 AM, Pavel Rappo wrote: On 15 Sep 2020, at 21:50, Rob Spoor wrote: On 15/09/2020 22:02, Pavel Rappo wrote: On 15 Sep 2020, at 20:50, Brian Burkhalter wrote: On Sep 15, 2020, at

Integrated: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

On Mon, 14 Sep 2020 22:18:34 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. This pull request has now been integrated. Changeset: 57f92d23 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/57f92d23 Stats: 2 lines in 1 file changed: 0 i

Re: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

On Mon, 14 Sep 2020 22:52:50 GMT, Joe Wang wrote: >> Hi Naoto, >> >> The change looks fine. I might have created a CSR just to track the doc >> change. > > The change looks fine. However, are other methods in the same situation, e.g. > void setTimeZone​(TimeZone value), > getInstance​(Locale

Re: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

On Mon, 14 Sep 2020 23:13:25 GMT, Naoto Sato wrote: >> The change looks fine. However, are other methods in the same situation, >> e.g. void setTimeZone​(TimeZone value), >> getInstance​(Locale aLocale), etc.? Or, would it better to add a general >> statement abou

RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

Hi, Please review this simple doc fix. - Commit messages: - 8220483: Calendar.setTime(Date date) throws NPE with Date date = null Changes: https://git.openjdk.java.net/jdk/pull/159/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=159=00 Issue:

Re: RFR: 8223187: Investigate setLocale() call in jpackage native launcher

On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev wrote: > setlocale() affects several C functions. We do not use most of these > functions. We only using isspace() and toLower(). > Based on how we use it I do not see any needs for setlocale(). After removing > it I retested jpackage by

Re: Case insensitive regexes and collators

Hi David, Glad to hear that you are delighted with the recent fix (JDK-8248655). The scope of the fix is limited to the String class, so it may or may not affect the said RegEx and/or Collator case insensitive operations. I created the following two issues to track your observations:

Re: RFR: 8251495: Clarify DOM documentation

On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote: > Revert changes made by JDK-8249643, removing the implNote. Looks good. - Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/100

Re: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types [v2]

On Tue, 8 Sep 2020 23:03:25 GMT, Stuart Marks wrote: >> Add some generics and wrap in `{@code}` to protect angle brackets. > > Stuart Marks has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright years. All good. -

Re: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types

On Tue, 8 Sep 2020 22:32:47 GMT, Stuart Marks wrote: > Add some generics and wrap in `{@code}` to protect angle brackets. Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/87

Re: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types

On Tue, 8 Sep 2020 22:47:40 GMT, Joe Darcy wrote: >> Add some generics and wrap in `{@code}` to protect angle brackets. > > Marked as reviewed by darcy (Reviewer). Looks good with the copyright year update. - PR: https://git.openjdk.java.net/jdk/pull/87

Re: RFR [16/java.xml] 8252354 : Properties :: storeToXML method does not throw ClassCastException when supplied non strings.

Hi Joe, Looks good to me. The test can declare @Test(expected = CCE.class) to eliminate storeToXML(), but I am ok with either way. Naoto On 9/1/20 2:12 PM, Joe Wang wrote: Please review a fix to report CCE when keys or values are not Strings as specified. JBS:

Re: RFR: 8252552: DecimalFormat javadoc contains HTML tags in example code

, 2020, at 12:22 PM, Naoto Sato wrote: Hello, Please review this simple javadoc fix to: https://bugs.openjdk.java.net/browse/JDK-8252552 The proposed diff is inserted here: --- --- old/src/java.base/share/classes/java/text/DecimalFormat.java 2020-08-31 09:07:22.0 -0700 +++ new/src

RFR: 8252552: DecimalFormat javadoc contains HTML tags in example code

Hello, Please review this simple javadoc fix to: https://bugs.openjdk.java.net/browse/JDK-8252552 The proposed diff is inserted here: --- --- old/src/java.base/share/classes/java/text/DecimalFormat.java 2020-08-31 09:07:22.0 -0700 +++

Re: [NEW BUG] NumberFormat.parse fails in some scenarios

Hi Christoph, The behavior you are observing is what is expected with the CLDR provider, as the currency format is exactly the one that CLDR has for the de locale: https://unicode-org.github.io/cldr-staging/charts/37/by_type/numbers.number_formatting_patterns.html#53687a25c19b6481 I'd

Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package

+1 Naoto On 8/25/20 11:47 AM, Joe Wang wrote: Cc-ing build-...@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating

Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package

Still looks good. Naoto On 8/24/20 2:44 PM, Joe Wang wrote: Hi all,  adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote:

Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package

+1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS:

Re: RFR 8251203: Fix "no comment" warnings in java.base/java.lang and java/io

Hi Roger, Changes look good to me. One question, do we need to update the copyright year for this change? Naoto On 8/21/20 8:09 AM, Roger Riggs wrote: Please review the addition of comments to classes and fields to resolve javadoc "no comment" warnings in the java.lang and java.io packages.

Re: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException

Hi Roger, Thank you for your comments. I've addressed your suggestions and created a new webrev below: https://cr.openjdk.java.net/~naoto/8251499/webrev.03/ Naoto On 8/19/20 8:33 AM, Roger Riggs wrote: Hi Naoto, CompactNumberFormat.java: 269: The field "placeHolders" should be named

Re: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException

Hi Joe, Thank you for your comment. I consolidated those duplicated pieces into one piece. Did not make it a private method, though, as it would need to return two results from the method (cnfMultiplier and whether to return immediately for no-placeholder cases).

Re: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException

Hi Roger, Thank you for your comment. I added a brief comment in the issue on how the implementation behaves in the problem case. Naoto On 8/18/20 8:19 AM, Roger Riggs wrote: Hi Naoto, I think the issue would benefit from a comment describing the solution. Its not clear how the code

Re: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException

Hi Joe, It turned out that the previous fix did not address plural format cases. That means that just making the divisor negative to indicate non-placeholder cannot distinguish multiple plural cases with the same divisor. Instead, I created a list of placeholders (minimum digits) for each

RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException

Hello, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8251499 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8251499/webrev.00/ The current implementation of CompactNumberFormat assumes that there is always the number

Re: [Ping] Re: 8181919: Refactor test/java/io/File/GetXSpace.sh to java test

Looks good, Brian. I'd add the bug id in GetXSpace.java's @bug tag. Naoto On 8/13/20 8:40 AM, Brian Burkhalter wrote: Thanks! On Aug 11, 2020, at 11:32 AM, Brian Burkhalter wrote: A revised version [A] is available pursuant to the changes made in the course of the review [B] of the fix

Re: RFR [16/java.xml] 8246816: XMLGregorianCalendar.hashCode() produces far too many identical hashes

Looks good. Thank you for the change. Naoto On 8/7/20 12:13 PM, Joe Wang wrote: Hi Naoto, Why not :-). I kept it to go with equals(). Removing both now. Added a reference comparison as did in the Impl class. http://cr.openjdk.java.net/~joehw/jdk16/8246816/webrev_04/ Joe On 8/7/20 10:50

Re: [Ping] Re: 8249703: test/jdk/java/io/File/GetXSpace.java fails on macos

Looks good. Thank you for the change. Naoto On 8/7/20 10:57 AM, Brian Burkhalter wrote: Hi Naoto, Good point. Here’s an updated version: http://cr.openjdk.java.net/~bpb/8249703/webrev.01/. The number of blocks is not available via a dedicated API call and so has to be calculated. Thanks,

Re: RFR [16/java.xml] 8246816: XMLGregorianCalendar.hashCode() produces far too many identical hashes

Hi Joe, If the new XMLGregorianCalendarImpl.hashCode() just calls super.hashCode(), could it be removed entirely? Also XMLGregorianCalendarImpl.equals() seems to do the same thing as its parent. Could it also be removed? Naoto On 8/7/20 10:16 AM, Joe Wang wrote: Naoto, Roger, Sorry have

Re: [Ping] Re: 8249703: test/jdk/java/io/File/GetXSpace.java fails on macos

Looks fine, Brian. I might add the condition if the block number is odd. Naoto On 8/7/20 8:33 AM, Brian Burkhalter wrote: On Jul 31, 2020, at 10:42 AM, Brian Burkhalter wrote: On macOS, the number of 1024 byte blocks appears to be incorrectly calculated by 'df' using integer division by

Re: RFR 8251202: Add missing javadoc comments

Looks good, Lance. nit: a couple of comments (line 128,133) don't end with periods. Naoto On 8/6/20 3:32 PM, Lance Andersen wrote: Hi all, Please review the webrev for: https://bugs.openjdk.java.net/browse/JDK-8251202 , which adds missing

Re: 8251272: Typo in java.util.Formatter: "Numberic" should be "Numeric"

+1 Good catch! Naoto On 8/6/20 4:12 PM, Brent Christian wrote: Looks good! -Brent On 8/6/20 3:54 PM, Brian Burkhalter wrote: For [1], please review this trivial fix [2]. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8251272 [2] diff ---

Re: RFR [16/java.xml] 8246816: XMLGregorianCalendar.hashCode() produces far too many identical hashes

Hi Joe, thank you for looking it into further. Yes, I agree the chances of collision is very rare, as sub-millisecond difference in two objects. So fine with the version 01. Naoto On 8/6/20 12:18 PM, Joe Wang wrote: Thanks Naoto, Roger for the review! For Naoto's concern about the equals

Re: RFR [16]: 8250665 : Wrong translation for the month of May in ar_JO, ar_LB and ar_SY

Looks good to me. Naoto On 8/6/20 9:47 AM, li.ji...@oracle.com wrote: Hi, Pls review the fix for month names in COMPAT provider data for ar_JO/LB/SY. Customer reported some month names are incorrect in JDK8 code according to latest CLDR definition. Bug:

Re: RFR [16/java.xml] 8246816: XMLGregorianCalendar.hashCode() produces far too many identical hashes

Hi Joe, For the consistency with equals(), just wondering if the sub-second element should be obtained with getFractionalSecond() instead of getMillisecond(), as the equals() subsequently calls it in internalCompare() method. Also should it call getEonAndYear() appropriately for the year?

Re: [16] 8251017: java/io/File/GetXSpace.java fails on UNIX

Looks good, Brian. Naoto On 8/4/20 9:01 AM, Brian Burkhalter wrote: Add @requires tag for [1]. This patch is layered on top of that proposed in [2]. --- a/test/jdk/java/io/File/GetXSpace.java +++ b/test/jdk/java/io/File/GetXSpace.java @@ -24,6 +24,7 @@ /** * @test * @bug 4057701

Re: Language locales have different calendars than country locales in 9+

On 7/31/20 3:08 PM, Bernd Eckenfels wrote: Hello, Is there a good description what calendar is actually used for a language-only locale? Is there a typical association of calendars with locales or is it a global default? If the unicode data does not have such a value, would it be better to

Re: Language locales have different calendars than country locales in 9+

Hi Bernd, As you pointed out, the change you see here is the result of this change in JDK9: https://bugs.openjdk.java.net/browse/JDK-8008577 where the default locale provider was switched to CLDR. Although we don't describe those behavior changes in the spec (as it is regarded as l10n

RFR 8233048: WeekFields.ISO is not a singleton

Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8233048 The proposed chageset is located at: https://cr.openjdk.java.net/~naoto/8233048/webrev.00/ java.time.temporal.WeekFields.ISO is instantiated using the constructor, which is a different object

Re: RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

Hi Joe, Thank you for the review! On 7/27/20 6:04 PM, Joe Wang wrote: Hi Naoto, Looks good to me, using the correct supplementary-aware implementation is an improvement for the impl to handle the situation. A note (probably a workaround) for the user's case, to replace invalid surrogate

Re: RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

On 7/27/20 11:51 AM, naoto.s...@oracle.com wrote: Apart from the original issue, there was a bug in Range() method (Pattern.java:5795), so it is fixed along. Created a test case for this: --- a/test/jdk/java/util/regex/SupplementaryTestCases.txt +++

RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8247546 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8247546/webrev.00/ On compiling the regex pattern, the start node is chosen based on the pattern, i.e, whether it

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Thanks Roger, Ah, I just saw your email just after I sent mine! On 7/22/20 1:38 PM, Roger Riggs wrote: Hi Naoto, Looks fine. (with Joe's suggestion) On 7/22/20 4:20 PM, Joe Wang wrote: Hi Naoto, The change looks good to me. "supLower" is indeed super slow :-) The only minor comment I have

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Joe, Thank you for the consecutive reviews! On 7/22/20 1:20 PM, Joe Wang wrote: Hi Naoto, The change looks good to me. "supLower" is indeed super slow :-) The only minor comment I have is that the compareCodePointCI method performs toUpperCase unconditionally. That's not a problem for

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi, I revised the fix again, based on further suggestions: https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/ Changes from v.04 are (all in StringUTF16.java): - The short cut now does case insensitive comparison that makes the fix closer to the previous implementation (for BMP

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Brent, On 7/21/20 2:56 PM, Brent Christian wrote: Hi, Naoto I have a few comments: src/java.base/share/classes/java/lang/StringUTF16.java 379 private static int getSupplementaryCodePoint(byte[] ba, int cp, int index, int start, int end) I think it would be worth a small addition to

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Thank you, Joe. I got it now. Will try out and benchmark. Naoto On 7/21/20 10:05 AM, Joe Wang wrote: On 7/20/2020 8:58 PM, naoto.s...@oracle.com wrote: The short-cut worked well. There's maybe a further optimization we could do to rid us of the performance concern (or the need to run

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Thank you, Roger. On 7/21/20 7:50 AM, Roger Riggs wrote: Hi Naoto, StringUTF16.java: 343, 348: The masking and comparisons seem awkward. I'd suggest just negating the value and testing for < 0 to flag the less usual case. If you continue with the flag bit, define your own static final

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Joe, On 7/20/20 7:14 PM, Joe Wang wrote: Hi Naoto, "Unless it showed 100% slower", wow, your tolerance is quite high :-). On the other hand, I do agree it's unlikely to show in specJVM (that's a speculation though). I am not saying 100% slowing is permissible :-) That's an example of

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Small correction in the updated part: http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.04/ Naoto On 7/20/20 2:39 PM, naoto.s...@oracle.com wrote: Hi Joe, Thank you for your comments. On 7/20/20 11:20 AM, Joe Wang wrote: Hi Naoto, StringUTF16: line 384 - 388 seem unnecessary since

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Joe, Thank you for your comments. On 7/20/20 11:20 AM, Joe Wang wrote: Hi Naoto, StringUTF16: line 384 - 388 seem unnecessary since you'd only get there if 389:isHighSurrogate is not true. Good point. But more importantly, StringUTF16 has existing method "codePointAt" you may want to

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Mark, Thank you for your comments. On 7/17/20 8:03 PM, Mark Davis ☕ wrote: One option is to have a fast path that uses char functions, up to the point where you hit a high surrogate, then drop into the slower codepoint path. That saves time for the high-runner cases. On the other hand,

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi, Based on the suggestions, I modified the fix as follows: https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/ Changes from the initial revision are: - Shared the implementation between compareToCI() and regionMatchesCI() - Enabled immediate short cut if two code points match. -

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Joe, Thank you for your review. On 7/15/20 10:57 AM, Joe Wang wrote: Hi Naoto, In StringUTF16.java, if one is isHighSurrogate and the other not, you may quickly return without going through the rest of the process, probably not significant as cp1 and cp2 and/or u1 and u2 won't be equal

<    4   5   6   7   8   9   10   11   12   13   >