Re: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v10]

On Thu, 10 Mar 2022 18:34:27 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance >> by caching the current Locale zero. Such fixes, however, ignore the real >> issue, which is the slowness of fetching DecimalFormatSymbols. By directly >> caching

Re: RFR: 8282819: Deprecate Locale class constructors

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create `i

Re: RFR: 8282819: Deprecate Locale class constructors

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create `i

Re: RFR: 8283781: Avoid allocating unused lastRulesCaches

On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad wrote: > This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` > (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily. LGTM - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java

Re: RFR: 8282819: Deprecate Locale class constructors [v3]

On Mon, 28 Mar 2022 16:00:14 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/util/Locale.java line 819: >> >>> 817: * @since 19 >>> 818: */ >>> 819: public static Locale of(String... fields) { >> >> Arguably, there should be `Locale.of` overloads taking 0 to 4 arguments

Re: RFR: 8282819: Deprecate Locale class constructors [v6]

On Mon, 28 Mar 2022 22:16:43 GMT, Naoto Sato wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. >> There is already a factory method and a builder to return singletons, so >> there is no need to have constructors anymore unless one purposefully wants >> to creat

Re: RFR: 8283842: TestZoneTextPrinterParser.test_roundTripAtOverlap fails: DateTimeParseException

On Wed, 30 Mar 2022 16:46:40 GMT, Naoto Sato wrote: > Fixes test failures caused by depending on the default locale. Specifying > explicit `Locale.US` will do. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8045

Re: RFR: 8283996: Reduce cost of year and month calculations

On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad wrote: > A few integer divisions and multiplications can be replaced with test + > addition, leading to a decent speed-up on java.time microbenchmarks such as > `GetYearBench`. Numbers from my local x86 workstation, seeing similar > speed-up on

Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v7]

On Fri, 15 Apr 2022 18:47:53 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to >> ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incr

Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v4]

On Mon, 7 Mar 2022 18:47:17 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/time/chrono/IsoChronology.java line 689: >> >>> 687: */ >>> 688: @Override >>> 689: public boolean isIsoBased() { >> >> Is this meant to be 'default'? The CSR indicated adding default methods. >

Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v9]

On Tue, 19 Apr 2022 17:43:21 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to >> ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last rev

Re: RFR: 8282227: Locale information for nb is not working properly

On Tue, 26 Apr 2022 00:32:48 GMT, Naoto Sato wrote: > This was caused by incorporating CLDR v39, which switched the Norwegian > locale inheritance from `no` -> `nb` to `nb` ->`no` and moved the resources > from `nb` to `no`, which now contradicts Java's locale fallback. Explicitly > inheriting

RFR: 8286378: Address possibly lossy conversions in java.base

PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >From the CSR: "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v2]

nd suggestions will inform similar updates to other OpenJDK modules). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: remove stray file - Changes: - all: https://git.openjdk.java.net/jdk/pull/8642/files - new: https://g

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

nd suggestions will inform similar updates to other OpenJDK modules). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Updated copyrights Fixed cast style to add a space after cast, (where consistent with file style) Improved code per

Integrated: 8286378: Address possibly lossy conversions in java.base

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy > conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not > assignment compatible with the type

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

On Fri, 13 May 2022 05:54:15 GMT, Alan Bateman wrote: >> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: >> >>> 126: // timed poll interrupted so need to adjust timeout >>> 127: long adjust = System.nanoTime() - startTime; >>> 128:

Re: RFR: 8267038: Update IANA Language Subtag Registry to Version 2022-03-02

On Wed, 18 May 2022 16:28:02 GMT, Naoto Sato wrote: > This is to incorporate the latest language subtag registry definition > (version 2022-03-02) into JDK19. Looks fine. - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8776

Re: RFR: 8287053: Avoid redundant HashMap.containsKey calls in ZoneInfoFile.getZoneInfo0

On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov wrote: > Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use > single call `HashMap.getOrDefault`. > It's faster and clearer. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/

Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]

On Tue, 17 May 2022 23:40:04 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to >> ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incr

Re: RFR: 8287181: Avoid redundant HashMap.containsKey calls in InternalLocaleBuilder.setExtension

On Sat, 30 Apr 2022 17:10:55 GMT, Andrey Turbanov wrote: > No need to separately perform `HashMap.containsKey` before `HashMap.remove` > call. If key is present - it will be removed anyway. If it's not present, > nothing will be deleted. Marked as reviewed by rriggs (Reviewer). -

Re: Fix for small leak in TimeZone_md.c

Ok, looks fine to me. Thanks, Roger On 9/3/2015 9:39 AM, Langer, Christoph wrote: Here is the updated webrev: http://cr.openjdk.java.net/~simonis/webrevs/2015/8134505/ -Original Message- From: Langer, Christoph Sent: Donnerstag, 3. September 2015 12:25 To: 'Roger Riggs&#x

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

Hi, Stephen, can you confirm that the added text and test in DateTimeFormatter is not a specification change? Our processes have a bit more to do if it is a spec change and it would limit the backport to JDK 8. This bug fix will cause an existing TCK/JCK test to fail but that is considered

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

6. Few Positive and negative invalid offsets for each time Regards, Ramanand. -Original Message- From: Roger Riggs Sent: Saturday, December 12, 2015 1:37 AM To:_core-libs-...@openjdk.java.net_<mailto:core-libs-...@openjdk.java.net> Cc:_i18n-...@openjdk.java.ne

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

DateTimeFormatter.java is because of the javadocs entry - {@link ChronoLocalDateTime#atZone(ZoneId)} Regards, Ramanand. *From:*Roger Riggs *Sent:* Monday, December 14, 2015 8:36 PM *To:* Ramanand Patil; core-libs-...@openjdk.java.net *Cc:* i18n-dev@openjdk.java.net *Subject:* Re: Review request

Re: RFR: regex changes

Hi Sherman, A few more comments, Pattern.java: - 1782: typo: "deterministci" - 2176: commented out code? - 2667: indentation - 5660,5655: lambda syntax use of simply "ch" is preferred over "(ch)" for single parameter lambdas and for consistency within the file. PrintPattern.java ne

Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

+1 On 9/14/2016 2:34 AM, Thomas Stüfe wrote: Hi all, thanks for the reviews. Here is version two: http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/

Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

Hi Thomas, It looks like NAME_MAX is not defined on Solaris and breaks the build on Solaris. [1] An alternative would be to conditionally use PATH_MAX. But I think it would be reasonable to just remove the use of NAME_MAX, since the following code increases the value to at least 1024, whic

RFR 9: 8166148 Fix for JDK-8165936 broke Solaris builds

, Roger On 9/15/2016 1:39 PM, Roger Riggs wrote: Hi Thomas, It looks like NAME_MAX is not defined on Solaris and breaks the build on Solaris. [1] An alternative would be to conditionally use PATH_MAX. But I think it would be reasonable to just remove the use of NAME_MAX, since the

Re: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map in LocaleEquivalentMap.java

Hi Nishit, Can the hardcoded copyright be made more automatic? I see the make/src/classes/build/tools/cldrconverter has functions to create/convert copyrights. Can that be leveraged to generate the needed copyright and reduce some potential maintenance of the copyright date and or contents?

Re: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map in LocaleEquivalentMap.java

lsr data is updated in jdk. Regards, Nishit Jain On 25-07-2017 21:28, Roger Riggs wrote: Hi Nishit, Can the hardcoded copyright be made more automatic? I see the make/src/classes/build/tools/cldrconverter has functions to create/convert copyrights. Can that be leveraged to generate the nee

Re: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map in LocaleEquivalentMap.java

good enough. Roger On 7/26/2017 2:34 AM, Nishit Jain wrote: Thanks Roger, Made the suggested changes related to hardcoded copyright year. Please check the updated webrev http://cr.openjdk.java.net/~nishjain/8177472/webrev.06/ Regards, Nishit Jain On 25-07-2017 22:55, Roger Riggs wrote

Re: [10] RFR 6354947: [Fmt-*] DecimalFormat ignores FieldPosition settings on input, contrary to Javadocs

Hi Nishit, The webrev and updates to the javadoc look fine. However, the summary of the issue does not reflect the issue and implies the implementation is wrong; but it is the javadoc that need clarification. Please change the issue summary (on both the CSR and the issue) to reflect the true

Re: [10] RFR 8187551: MessageFormat.setFormat(int, Format) AIOOBE not thrown when documented

Hi Nishit, Looks good, Thanks, Roger On 12/4/2017 1:36 AM, Nishit Jain wrote: Thanks Roger, Updated the webrevto add the new test case in MessageRegression.java http://cr.openjdk.java.net/~nishjain/8187551/webrev.03/ Regards, Nishit Jain On 01-12-2017 20:40, Roger Riggs wrote: Hi Nishit

Re: [11] RFR: 8202088: Japanese new era implementation

Hi Naoto, Is there a reference to the official description or anticipation of the new Era? JapaneseImperialCalendar: 134 NEWERA = 5;   (The real name can also be defined later; but still might be more unique as ERA_MAY_1_2019.) Syntax style:  - TCKJapaneseChronology:692: align the  columns

Re: [13] RFR: 8221432: Upgrade CLDR to Version 35.1

Hi Naoto, The changes look fine. Thanks, Roger On 05/07/2019 04:12 PM, naoto.s...@oracle.com wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8221432 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8221432/webrev.0

Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string

Hi, Looks ok, but... .../java/time/format/DateTimeFormatterBuilder.java 3924: needs a space in "if(" -> "if (" java/time/format/TestLocalizedOffsetPrinterParser.java I would cut the number of test cases to a minimum; only need to ensure the code is correct. We don't need to be testing the CL

Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string

AM To: Roger Riggs ; core-libs-...@openjdk.java.net; i18n-dev@openjdk.java.net Subject: RE: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string Hi Roger, Thank you for the review. I am in transit this weekend, but I will fix this and republi

Re: [13] RFR: 8228450: unicode.md and icu.md text should be pre-formatted

Looks fine On 7/22/19 10:54 AM, naoto.s...@oracle.com wrote: Hi, Please review this doc only fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8228450 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8228450/webrev.00/ This is simply to supply tripl

Re: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system.

Hi Naoto, Bundle.java:  - 28: Explicit import are preferred,  (if the IDE make the change, fix the settings in the IDE).  - 763, the indentation of the nested getOrDefault calls doesn't look conventional.   (It might be interesting to have an API that allows one or more defaults to be tried

Re: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system.

ted until the value was needed.] Thanks, Roger On 9/9/19 2:23 PM, naoto.s...@oracle.com wrote: Hi Roger, Thanks for the review. On 9/9/19 8:12 AM, Roger Riggs wrote: Hi Naoto, Bundle.java:   - 28: Explicit import are preferred,  (if the IDE make the change, fix the settings in the IDE).

Re: [14] RFR 8212749: DecimalFormat.setGroupingSize(int) allows setting negative grouping size, 8231984: Clarify semantics of DecimalFormat.getGroupingSize(0)

n}.    * I will file a follow-on CSR and merge changesets. Naoto On 10/8/19 6:59 AM, Roger Riggs wrote: Hi Naoto, DecimalFormat.java: 2776:  "Invalid value, i.e.," -> "Values that are". Otherwise looks fine. No need for another webrev. Thanks, Roger On 10/4/19 6

Re: [14] RFR 8212749: DecimalFormat.setGroupingSize(int) allows setting negative grouping size, 8231984: Clarify semantics of DecimalFormat.getGroupingSize(0)

Looks good. Thanks,  Roger On 10/11/19 4:15 PM, naoto.s...@oracle.com wrote: Thanks, Roger. Modified readObject() accordingly: https://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.01/ Naoto On 10/11/19 10:41 AM, Roger Riggs wrote: Hi Naoto, The javadoc/spec comments look fine. Code

Re: [14] RFR: 8231273: Upgrade CLDR to v36

HI Naoto, cldrconverter/Bundle.java: 233-246:  If there is a parent list, it seems to ignore/drop patterns greater than plist.size(). This would be clearer if it always processed all the patterns and used the parent if the pattern[i] was empty and i < plist.size().  Switching around the range

Re: [14] RFR: 8231273: Upgrade CLDR to v36

Hi Naoto, Looks good Thanks for the clarification, Roger On 10/25/19 7:31 PM, naoto.s...@oracle.com wrote: Hi Roger, Thanks for the review. On 10/25/2019 AD 11:57 午前, Roger Riggs wrote: HI Naoto, cldrconverter/Bundle.java: 233-246:  If there is a parent list, it seems to ignore/drop

Re: [14] RFR: 8222756: Plural support in CompactNumberFormat

Hi Naoto, Thanks for the updates. Looks fine. Roger On 12/5/19 1:49 PM, naoto.s...@oracle.com wrote: Thanks, Joe and Roger, for the reviews. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8222756/webrev.02/ These are the changes since v.01: CompactNumberFormat.java: - Refl

Re: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider

/webrev.01/ Naoto On 12/12/19 1:37 PM, Roger Riggs wrote: +1 There's quite a bit of work being done to get the eligible stings as part of each parse but it doesn't look easy to re-use it acrosses parses. Roger On 12/12/19 3:42 PM, Joe Wang wrote: On 12/12/19 12:31 P

Re: [15] RFR: 8187987: Add a mechanism to configure custom variants in HijrahChronology

Hi, On 1/15/20 3:06 PM, naoto.s...@oracle.com wrote: Hi Roger, Thank you for the review. Please find my comments below: On 1/15/20 10:30 AM, Roger Riggs wrote: Hi Naoto, Is it correct to say that there is no impact on startup until there is an explicit reference to HijrahChronology? It

Re: [15] RFR: 8187987: Add a mechanism to configure custom variants in HijrahChronology

.com wrote: Updated: https://cr.openjdk.java.net/~naoto/8187987/webrev.02/ The change includes the new naming convention, reduction of properties files reading to once, and utilization of logging. Naoto On 1/15/20 12:37 PM, Roger Riggs wrote: Hi, On 1/15/20 3:06 PM, naoto.s...@oracle.com wrote:

Re: [15] RFR: 8187987: Add a mechanism to configure custom variants in HijrahChronology

Hi Naoto, Looks good.  Thanks for the updates. Roger On 1/16/20 4:08 PM, naoto.s...@oracle.com wrote: Hi Roger, Thanks. My comments are embedded below. On 1/16/20 12:06 PM, Roger Riggs wrote: Hi Naoto, A couple of comments in the tests. HijrahConfigTest: 72:  Since onExit() starts a

Re: [15]: RFR: 8244245: localizedBy() should override localized values with default values

Hi Naoto, Looks fine with a small source edit below. TestUnicodeExtension.java: Please wrap the excessively long lines; string concatination will put them together for the test. Thanks, Roger On 5/6/20 4:44 PM, naoto.s...@oracle.com wrote: Hello, Please review the fix to the following iss

Re: [15]: RFR: 8244245: localizedBy() should override localized values with default values

Looks good, thanks On 5/7/20 12:06 PM, naoto.s...@oracle.com wrote: Hi Roger, Thank you for the review. Wrapped the long lines as suggested, along with some typo fixes in the comments: https://cr.openjdk.java.net/~naoto/8244245/webrev.01/ Naoto On 5/7/20 7:43 AM, Roger Riggs wrote: Hi

Re: RFR: 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. Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 1153:

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

On Wed, 16 Sep 2020 17:51:18 GMT, Lance Andersen wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressing Roger's comments. > > Looks in line with the discussion on core-libs. Removing hashcode from the serialized

Re: RFR: 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. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/234

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

On Sat, 19 Sep 2020 01:36:38 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 fixed a paramet

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

On Wed, 16 Sep 2020 18:02:42 GMT, Naoto Sato wrote: >> 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: >

RFR: 8251989: Hex formatting and parsing utility

java.util.HexFormat utility: - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase - Static factories and builder methods to create HexFormat copies with modified parameters. - Consistent naming of methods for conversion of byte arrays to fo

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly

On Mon, 5 Oct 2020 22:23:56 GMT, Ian Graves wrote: > The `java.util.Formatter` format specifies support for field widths, argument > indexes, or precision lengths of a field > that relate to the variadic arguments supplied to the formatter. These > numbers are specified by integers, sometimes >

Re: RFR: 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 Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.ne

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

On Fri, 30 Oct 2020 22:03:08 GMT, Naoto Sato wrote: >> 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

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

On Wed, 4 Nov 2020 22:13:25 GMT, Naoto Sato wrote: >> 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

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

On Tue, 10 Nov 2020 00:07:16 GMT, Naoto Sato wrote: >> 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

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

On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato wrote: >> 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

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

On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato wrote: >> 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

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v9]

On Tue, 17 Nov 2020 19:58:29 GMT, Ian Graves wrote: >> The `java.util.Formatter` format specifies support for field widths, >> argument indexes, or precision lengths of a field that relate to the >> variadic arguments supplied to the formatter. These numbers are specified by >> integers, somet

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v11]

On Wed, 18 Nov 2020 22:09:21 GMT, Ian Graves wrote: >> The `java.util.Formatter` format specifies support for field widths, >> argument indexes, or precision lengths of a field that relate to the >> variadic arguments supplied to the formatter. These numbers are specified by >> integers, somet

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v12]

On Wed, 18 Nov 2020 22:57:19 GMT, Ian Graves wrote: >> The `java.util.Formatter` format specifies support for field widths, >> argument indexes, or precision lengths of a field that relate to the >> variadic arguments supplied to the formatter. These numbers are specified by >> integers, somet

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class"

Re: RFR: 8253497: Core Libs Terminology Refresh

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words > with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were > changed as follows: > 1

Re: RFR: 8253497: Core Libs Terminology Refresh [v3]

On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words >> with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were >> changed as follows

RFR: 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys

Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal strings to use java.util.HexFormat methods. Also in tests test/jdk/java/util/Locale/SoftKeys. - Commit messages: - 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale

Integrated: 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys

On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs wrote: > Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format > hexadecimal strings to use java.util.HexFormat methods. > Also in tests test/jdk/java/util/Locale/SoftKeys. This pull request has now been integrated.

Re: RFR: 8246788: ZoneRules invariants can be broken

On Fri, 22 Jan 2021 05:39:55 GMT, Stuart Marks wrote: > Tighten up argument checking in constructor. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2191

Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]

On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato wrote: >> Please review this doc fix to j.l.Character, which now includes the table of >> the history of supported Unicode versions. A corresponding CSR will be filed >> accordingly. > > Naoto Sato has updated the pull request incrementally with one

Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v3]

On Tue, 16 Feb 2021 17:59:51 GMT, Naoto Sato wrote: >> Please review this doc fix to j.l.Character, which now includes the table of >> the history of supported Unicode versions. A corresponding CSR will be filed >> accordingly. > > Naoto Sato has updated the pull request with a new target base

Re: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter

On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato wrote: > Please review this simple doc fix. A CSR will be filed accordingly. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2616

Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]

On Thu, 18 Feb 2021 03:56:49 GMT, David Holmes wrote: >> The table is informative and should not be construed as specification. >> The wording "has supported" should be sufficient. > >> >> >> The table is informative and should not be construed as specification. >> The wording "has supported" s

Re: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter [v2]

On Wed, 17 Feb 2021 20:21:57 GMT, Naoto Sato wrote: >> Please review this simple doc fix. A CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Made the additional text an @apiNote Marked as review

Re: RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category)

On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad wrote: > This patch refactors Locale.getDefault(Category) so that the volatile field > holding the Locale is typically only read once. This has a small performance > advantage, and might be more robust if initialization is racy. Marked as reviewe

Re: RFR: 8263091: Remove CharacterData.isOtherUppercase/-Lowercase

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad wrote: > This patch removes the CharacterData.isOtherUppercase and isOtherLowercase > methods. It also exploits the fact that isOtherUppercase is always false for > all codepoints in the CharacterDataLatin1 range for a small speed-up. > > I have

Re: RFR: JDK-8262471: Fix coding style in src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java

On Fri, 26 Feb 2021 17:50:19 GMT, Christoph Göttschkes wrote: > Please review this small patch which fixes the coding style of > CharacterDataPrivateUse.java For (most) core-libs changes, only 1 reviewer is required. However, given the broad interest, please allow time (a day or weekend) for o

Re: RFR: 8263677: Improve Character.isLowerCase/isUpperCase lookups

On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad wrote: > This patch changes the otherLowercase / otherUppercase bits to be set if > either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the > Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies > the

Re: RFR: 8263658: Use the blessed modifier order in java.base

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt wrote: > Sonar displays a warning message that modifiers should be declared in the > order listed in the JLS; specifically, that isntead of using `final static` > the `static final` should be preferred. > > This fixes the issues in the `java.base

Re: RFR: 8263677: Improve Character.isLowerCase/isUpperCase lookups [v2]

On Tue, 16 Mar 2021 21:02:28 GMT, Claes Redestad wrote: >> This patch changes the otherLowercase / otherUppercase bits to be set if >> either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or >> the Unicode Other_Lowercase / Other_Uppercase property is set. This >> simplifies

Re: RFR: 8263668: Update java.time to use instanceof pattern variable

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.time` > package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick In addition to the other suggestions, java.time could use

Re: RFR: 8262110: DST starts from incorrect time in 2038

On Tue, 23 Mar 2021 23:38:28 GMT, Naoto Sato wrote: > Please review the fix to the DST transition bug after the year 2037. The > logic had the side effect that it adjusted the dst offset every time the > method `getOffsets()` is issued. Only adjust the offset when issued with wall > time. Mar

Re: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > 8264148: Update spec for exceptions retrofitted for exception chaining I agree that the public field in WriteAbortedException could be remediated. But it is also mostly harmless. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMO

Re: RFR: 8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits [v2]

On Wed, 7 Apr 2021 02:48:00 GMT, Ian Graves wrote: >> This fixes a bug where the formatting code for `%g` flags incorrectly tries >> to round `BigDecimal` after determining whether it should be a decimal >> numeric format or a scientific numeric format. The solution rounds before >> determinin

Re: RFR: 8263668: Update java.time to use instanceof pattern variable [v4]

On Mon, 19 Apr 2021 10:38:17 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.time` >> package to make use of the `instanceof` pattern variable? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request w

Re: RFR: 8263668: Update java.time to use instanceof pattern variable [v6]

On Tue, 20 Apr 2021 17:46:38 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.time` >> package to make use of the `instanceof` pattern variable? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request i

Re: RFR: 8263668: Update java.time to use instanceof pattern variable [v7]

On Wed, 21 Apr 2021 11:06:16 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.time` >> package to make use of the `instanceof` pattern variable? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request w

Re: RFR: 8265746: Update java.time to use instanceof pattern variable (part II)

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review the second half of my update for the `java.time` > package to make use of the `instanceof` pattern variable? > > This PR was split into two parts due to the large number of files affected. > > Ki

Re: RFR: 8265746: Update java.time to use instanceof pattern variable (part II) [v2]

On Fri, 23 Apr 2021 15:38:53 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review the second half of my update for the `java.time` >> package to make use of the `instanceof` pattern variable? >> >> This PR was split into two parts due to the large number of files affected. >

Re: RFR: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar

On Tue, 25 May 2021 16:40:53 GMT, Naoto Sato wrote: > Please review the fix. The issue was informed yesterday by @amaembo that it > offends some code analysis tools. > Although the fix is to change the condition error, it turned out that > `JapaneseImperialCalendar.roll()` did not work for `WEE

Re: RFR: 8272626: Avoid C-style array declarations in java.*

On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch > cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) 34 Minutes from proposed to integrated! Its hard

Re: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong

On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone > co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.

Re: RFR: 8273616: Fix trivial doc typos in the java.base module [v3]

On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional > commit since the last revision: > > Use "ensure" instead of "insure" Marked as reviewed by rriggs (R

Re: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato wrote: > Fixing an AIOOBE on normalizing the month value. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5611

Re: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem

On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue > reported in https://bugs.openjdk.java.net/browse/JDK-8273790? > > As noted in that issue, trying to class load > `sun.util.calendar.CalendarSystem` and `sun.util.

  1   2   >