JVM startup since JDK21, if
> the app is using `COMPAT`). A corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Addressing review comments
-
Changes:
- all: https://git.openjdk.org
JVM startup since JDK21, if
> the app is using `COMPAT`). A corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Update test/jdk/java/text/Format/DateFormat/Bug6683975.java
Co-authore
JVM startup since JDK21, if
> the app is using `COMPAT`). A corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Remove `GensrcLocaleData.gmk`
-
Changes:
- all: https://git.openj
JVM startup since JDK21, if
> the app is using `COMPAT`). A corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
Co-auth
On Mon, 26 Feb 2024 16:39:29 GMT, Magnus Ihse Bursie wrote:
>> Actually, as the file currently in the PR, it does not seem like it does
>> anything at all, since we no longer create `_the.locale_resources`. Or...
>> hm, without that file, `PREV_LOCALE_RESOURCES` will always be empty. I
>>
This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
`COMPAT` locale data was introduced for applications' migratory purposes
transitioning to `CLDR`. It is becoming a technical debt and now is the time to
remove it (we've been emitting a warning at JVM startup since
On Fri, 23 Feb 2024 17:29:18 GMT, Justin Lu wrote:
>> Please review this PR which handles an edge case pattern bug with
>> ChoiceFormat.
>>
>>
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
>> "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>>
On Thu, 22 Feb 2024 22:50:03 GMT, Justin Lu wrote:
>> Please review this PR which handles an edge case pattern bug with
>> ChoiceFormat.
>>
>>
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
>> "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>>
aleOfavgt 20 62564.079 ± 406.697 ns/op
>
> (w/ fix)
> Benchmark Mode Cnt Score Error Units
> LocaleCache.testForLanguageTag avgt 20 4801.175 ± 371.830 ns/op
> LocaleCache.testLocaleOf avgt 20 60394.652 ± 352.471 ns/op
Naoto
aleOfavgt 20 62564.079 ± 406.697 ns/op
>
> (w/ fix)
> Benchmark Mode Cnt Score Error Units
> LocaleCache.testForLanguageTag avgt 20 4801.175 ± 371.830 ns/op
> LocaleCache.testLocaleOf avgt 20 60394.652 ± 352.471 ns/op
Naoto
On Thu, 22 Feb 2024 00:14:23 GMT, Naoto Sato wrote:
>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211
>> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored
>> the in-house cache with WeakHashMap, and removed the Key class as i
On Thu, 22 Feb 2024 17:38:50 GMT, Justin Lu wrote:
>> src/java.base/share/classes/java/text/ChoiceFormat.java line 332:
>>
>>> 330:
>>> 331: // Used to explicitly define the segment mode while applying a
>>> pattern
>>> 332: private enum Segment {
>>
>> Do we need a new enum? Would
On Thu, 22 Feb 2024 17:55:18 GMT, Justin Lu wrote:
>> Please review this PR which handles an edge case pattern bug with
>> ChoiceFormat.
>>
>>
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
>> "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>>
aleOfavgt 20 62564.079 ± 406.697 ns/op
>
> (w/ fix)
> Benchmark Mode Cnt Score Error Units
> LocaleCache.testForLanguageTag avgt 20 4801.175 ± 371.830 ns/op
> LocaleCache.testLocaleOf avgt 20 60394.652 ± 352.471 ns/op
Naoto Sat
On Tue, 20 Feb 2024 18:34:59 GMT, Naoto Sato wrote:
> Fixing a typo in the said method.
This pull request has now been integrated.
Changeset: 64f7972a
Author: Naoto Sato
URL:
https://git.openjdk.org/jdk/commit/64f7972a3d0c82ad7047f73f0b57c3d88f62935f
Stats: 2 lines in 1 f
On Thu, 15 Feb 2024 19:44:42 GMT, Justin Lu wrote:
> Please review this PR which handles an edge case pattern bug with
> ChoiceFormat.
>
>
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
> "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
>
>
>
On Tue, 20 Feb 2024 19:56:53 GMT, Lance Andersen wrote:
> Please review the updates to open/src/java.base/share/legal/zlib.md to update
> the file from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR
> for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)
Marked as
Fixing a typo in the said method.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/17933/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17933=00
Issue: https://bugs.openjdk.org/browse/JDK-8326158
Stats: 2 lines in 1 file changed: 0 ins; 0 del;
Vote: yes
Naoto
On 2/19/24 3:40 PM, Stuart Marks wrote:
I hereby nominate Viktor Klang [6] to Membership in the Core Libraries
Group [4].
Viktor has been a member of the Java team in Oracle since 2022, and he
is currently a Committer on the JDK project. Viktor has led JEP 461 [1],
an
On Fri, 16 Feb 2024 23:35:10 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756)
>> which defines the behavior for creating ChoiceFormats with incorrect
>> patterns. The wording is added to both the ChoiceFormat constructor and
>>
On Fri, 16 Feb 2024 21:53:26 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756)
>> which defines the behavior for creating ChoiceFormats with incorrect
>> patterns. The wording is added to both the ChoiceFormat constructor and
>>
On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie wrote:
>> Since jcheck only checks file in a commit, there is a possibility of us
>> getting files in the repository that would not be accepted by jcheck. This
>> can happen when extending the set of files checked by jcheck, or if jcheck
>>
On Thu, 15 Feb 2024 18:54:46 GMT, Brian Burkhalter wrote:
> Revert `@replace` snippet annotation construct to value of `replacement`
> attribute.
I saw the internal discussion and agree with the changes.
-
Marked as reviewed by naoto (Reviewer).
PR Review:
On Thu, 15 Feb 2024 17:28:52 GMT, Andy Goryachev wrote:
>> Please do not replace those tabs with spaces as they are intentional for
>> testing the runtime to safely ignore them. I suggest replacing them with
>> Unicode escapes (`\u000b`)
>
> `\u000b` is VT (vertical tab)
> `\u0009` or `\t`
On Thu, 15 Feb 2024 15:48:38 GMT, Magnus Ihse Bursie wrote:
>> This looks weird indeed. Luckily it's just test code. Did you run the test
>> after this change?
>
> All the java/util/Currency tests pass. I also searched the code for "ZZ" but
> could not find any references in the test.
Please
On Wed, 14 Feb 2024 23:05:25 GMT, Justin Lu wrote:
> Please review this PR which fixes / finishes the rest of the IntlTest test
> framework removal in java.text and java.util.i18n tests.
>
> For context, the IntlTest class only ran methods prefixed by _test_ or _Test_
> with public visibility
Vote: yes
Naoto
On 2/13/24 12:25 PM, Brian Burkhalter wrote:
I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
Raffaello has been working in the Core Library team at Oracle since April,
2022. He has authored more than 50 contributions to OpenJDK in a number of
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
>
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
>
On Thu, 8 Feb 2024 21:29:19 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
>> which adds MessageFormat pattern support for the following subformats:
>> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
>> intended to
On Thu, 8 Feb 2024 20:37:18 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
>> which adds MessageFormat pattern support for the following subformats:
>> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
>> intended to
On Thu, 8 Feb 2024 17:31:15 GMT, Thiago Henrique Hüpner
wrote:
>> 8325505: Fix Javadoc ResourceBundle::getString
>
> Thiago Henrique Hüpner has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Apply changes from review
LGTM
-
On Wed, 7 Feb 2024 08:45:40 GMT, Johny Jose wrote:
> Timezone data 2024a changes
LGTM
-
Marked as reviewed by naoto (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17743#pullrequestreview-1868470439
On Tue, 6 Feb 2024 23:07:49 GMT, Roger Riggs wrote:
>> I agree, it was the existing design that caused for example,
>> CompactNumberFormat to not automatically be supported by MessageFormat. A
>> simple alternative would be storing the potential pre-defined NumberFormats
>> in some data
On Thu, 1 Feb 2024 23:12:46 GMT, Naoto Sato wrote:
> Implementing "loose matching" of space separators in both
> `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient
> parsing. This will effectively fix the NNBSP issues on parsing time with
> am
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
On Fri, 2 Feb 2024 22:43:28 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
>> which adds MessageFormat pattern support for the following subformats:
>> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
>> intended to
On Fri, 2 Feb 2024 22:46:34 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reworded spec
>
> src/java.base/share/classes/java/text/DateFormat.java line 751:
>
://inside.java/2023/03/28/quality-heads-up/). A draft CSR has also been
> drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Fixed wording
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17678/files
- new:
On Fri, 2 Feb 2024 22:16:30 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
>> which adds MessageFormat pattern support for the following subformats:
>> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
>> intended to
On Fri, 2 Feb 2024 22:11:17 GMT, Justin Lu wrote:
>> src/java.base/share/classes/java/text/MessageFormat.java line 676:
>>
>>> 674: * java.time.format.DateTimeFormatter}. In addition, {@code
>>> DateTimeFormatter}
>>> 675: * does not implement {@code equals()}, and thus cannot be
On Fri, 2 Feb 2024 22:13:39 GMT, Justin Lu wrote:
> > Slightly tangential question (since you're talking about adding new
> > subformats)...
> > Has it ever been considered to add `MessageFormat` itself as a subformat
> > option?
> > It's not as crazy an idea as it sounds :) Here's an example:
On Fri, 2 Feb 2024 19:31:55 GMT, Joe Wang wrote:
> Since the default parsing mode is strict in java.time.format, applications
> would still have to make code changes when moving existing code to the new
> JDK releases.
You are right, Joe. Apps using `java.time` formatters would still need to
://inside.java/2023/03/28/quality-heads-up/). A draft CSR has also been
> drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Reworded spec
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17678/files
- new:
On Fri, 2 Feb 2024 01:57:18 GMT, Archie Cobbs wrote:
>> Please consider this fix to ensure that going from `MessageFormat` to
>> pattern string via `toPattern()` and then back via `new MessageFormat()`
>> results in a format that is equivalent to the original.
>>
>> The quoting and escaping
On Tue, 30 Jan 2024 18:28:32 GMT, Archie Cobbs wrote:
>> Please consider this fix to ensure that going from `MessageFormat` to
>> pattern string via `toPattern()` and then back via `new MessageFormat()`
>> results in a format that is equivalent to the original.
>>
>> The quoting and escaping
Implementing "loose matching" of space separators in both
`java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient
parsing. This will effectively fix the NNBSP issues on parsing time with am/pm
markers introduced with CLDR version 42
On Wed, 30 Aug 2023 22:35:43 GMT, Naoto Sato wrote:
>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211
>> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored
>> the in-house cache with WeakHashMap, and removed the Key class as i
On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu wrote:
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
> which adds MessageFormat pattern support for the following subformats:
> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
> intended to
On Tue, 30 Jan 2024 23:09:17 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822)
>> which allows for the _Format_ segment of a ChoiceFormat pattern to use the
>> ChoiceFormat Relational symbols without the need to escape them using
>> quotes.
On Tue, 30 Jan 2024 19:57:01 GMT, Eirik Bjørsnøs wrote:
> Please review this test-only PR which improves test coverage of
> `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i"
> characters with their latin cousins.
>
> The test `CompactStrings/RegionMatches.java`
On Tue, 30 Jan 2024 21:19:27 GMT, Justin Lu wrote:
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822)
> which allows for the _Format_ segment of a ChoiceFormat pattern to use the
> ChoiceFormat Relational symbols without the need to escape them using quotes.
>
On Fri, 26 Jan 2024 17:36:52 GMT, Jim Laskey wrote:
>> Currently String::translateEscapes does not support unicode escapes,
>> reported as a IllegalArgumentException("Invalid escape sequence: ...").
>> String::translateEscapes should translate unicode escape sequences to
>> provide full
On Mon, 22 Jan 2024 20:52:32 GMT, Roger Riggs wrote:
> When an exception handler for an OutOfMemoryError uses string concatenation
> to compose an exception message, the invoke dynamic string format
> implementation may itself exhaust memory, preventing the exception from being
> handled.
>
On Tue, 23 Jan 2024 22:13:14 GMT, Justin Lu wrote:
>> Archie Cobbs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add @implNote to Javadoc for toPattern().
>
> src/java.base/share/classes/java/text/MessageFormat.java line 556:
>
>>
On Tue, 23 Jan 2024 18:40:42 GMT, Justin Lu wrote:
> Please review this PR which clarifies some confusion for the digit getter and
> setter methods of DecimalFormat.
>
> When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses
> 309/340 as hard limits for integer and
On Tue, 23 Jan 2024 18:53:39 GMT, Jim Laskey wrote:
>> Currently String::translateEscapes does not support unicode escapes,
>> reported as a IllegalArgumentException("Invalid escape sequence: ...").
>> String::translateEscapes should translate unicode escape sequences to
>> provide full
On Thu, 18 Jan 2024 19:37:33 GMT, Naoto Sato wrote:
> Fixing incorrect std/dst transitions for time zones that have rules beyond
> 2037. The year 2037 restriction seems to come from the old `zic` command
> implementation and thus can be expanded in the JDK. Arbitrary I chose 2100
On Thu, 18 Jan 2024 23:19:44 GMT, Justin Lu wrote:
> LGTM, _NegativeDSTTest.java_ can bump the copyright year to 2024 as well.
Forgot that! Fixed.
-
PR Comment: https://git.openjdk.org/jdk/pull/17492#issuecomment-1899410249
arthest rule at the moment.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
copyright year
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17492/files
- new: https://git.openjdk.org/jdk/pull/17492/files/9ce8f35b..cb652
arthest rule at the moment.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Added comment to clarify the possible need for the last year expansion
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17492/files
On Thu, 18 Jan 2024 20:48:03 GMT, Iris Clark wrote:
> Hopefully "2100" is unique enough that you'll be able to easily
> search/replace the next time you need to extend.
Thank you, Iris. Added a comment to clarify the need for possible expansion.
-
PR Comment:
Fixing incorrect std/dst transitions for time zones that have rules beyond
2037. The year 2037 restriction seems to come from the old `zic` command
implementation and thus can be expanded in the JDK. Arbitrary I chose 2100
which is greater than the year 2087 which is the farthest rule at the
On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote:
> Please review this trivial PR to reorder the `sealed` class or interface
> modifier. For context of this change see:
> https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.
Marked as reviewed by naoto (Reviewer).
On Tue, 16 Jan 2024 11:12:44 GMT, Andrey Turbanov wrote:
>> 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily
>
> src/java.base/share/classes/java/util/TimeZone.java line 629:
>
>> 627: */
>> 628: public static String[] getAvailableIDs(int rawOffset) {
>> 629:
On Fri, 12 Jan 2024 19:07:46 GMT, Justin Lu wrote:
>> Please review this PR which implements toString() for the `Format`
>> subclasses. Corresponding CSR:
>> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>>
>> The general specification follows a template that provides the locale
On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu wrote:
> Please review this PR which is a backport of commit
> [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The original commit was a
On Fri, 12 Jan 2024 18:27:55 GMT, Justin Lu wrote:
>> Please review this PR which implements toString() for the `Format`
>> subclasses. Corresponding CSR:
>> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>>
>> The general specification follows a template that provides the locale
On Thu, 11 Jan 2024 22:56:38 GMT, Joe Wang wrote:
> Backport to fix the regression introduced in JDK 22.
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/63#pullrequestreview-1817006707
On Thu, 11 Jan 2024 18:36:39 GMT, Joe Wang wrote:
> Fix a regression in the source resolution process where it failed to
> recognize a custom InputSource when both the public and system IDs are null.
> The particular issue is fixed at line 1233, the rest of the changes is
> formatting to make
On Thu, 11 Jan 2024 19:30:09 GMT, Justin Lu wrote:
>> Please review this PR which implements toString() for the `Format`
>> subclasses. Corresponding CSR:
>> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>>
>> The general specification follows a template that provides the locale
On Wed, 10 Jan 2024 20:56:14 GMT, Naoto Sato wrote:
> Backporting the document only fix to jdk22
This pull request has now been integrated.
Changeset: 6951987b
Author: Naoto Sato
URL:
https://git.openjdk.org/jdk22/commit/6951987b65e50143ee3f1f79f7731159a0310223
Stats: 5 li
On Wed, 10 Jan 2024 21:05:53 GMT, Justin Lu wrote:
>> Please review this PR which splits up the _LocaleProvidersRun_ test file for
>> performance and maintenance reasons.
>>
>> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR,
>> HOST, SPI, etc.) was getting rather
On Wed, 10 Jan 2024 20:43:19 GMT, Mandy Chung wrote:
> `jdk.test.lib.process.ProcessTools::executeTools` was modified to throw
> Exception by JDK-8322920 that has only been in the main line. It's a
> mistake to backport JDK-8322809 without catching this. Trivial fix - update
> the
Backporting the document only fix to jdk22
-
Commit messages:
- Backport 3bd9042054116365323912ed5867b70936fe85c4
Changes: https://git.openjdk.org/jdk22/pull/59/files
Webrev: https://webrevs.openjdk.org/?repo=jdk22=59=00
Issue: https://bugs.openjdk.org/browse/JDK-8320788
On Tue, 9 Jan 2024 00:51:28 GMT, Naoto Sato wrote:
> Adding an explanation of the locale-related system properties in the
> `System.getProperties()` method. Corresponding CSR has also been drafted.
This pull request has now been integrated.
Changeset: 3bd90420
Author: Naoto Sat
On Tue, 9 Jan 2024 23:40:35 GMT, Naoto Sato wrote:
>> Adding an explanation of the locale-related system properties in the
>> `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target b
On Tue, 9 Jan 2024 23:55:30 GMT, Naoto Sato wrote:
> Backporting the document clarification to JDK22
This pull request has now been integrated.
Changeset: 46b1b1ae
Author: Naoto Sato
URL:
https://git.openjdk.org/jdk22/commit/46b1b1ae8ddc9466bda5af5ba2e917ded3352f4d
Stats:
Backporting the document clarification to JDK22
-
Commit messages:
- Backport 376051a9be95e0e4acf3c59d0eba3e9ef8727d79
Changes: https://git.openjdk.org/jdk22/pull/47/files
Webrev: https://webrevs.openjdk.org/?repo=jdk22=47=00
Issue: https://bugs.openjdk.org/browse/JDK-8320919
> Adding an explanation of the locale-related system properties in the
> `System.getProperties()` method. 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 pull request now contains 18 commits:
-
On Tue, 9 Jan 2024 20:06:10 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/java/lang/System.java line 819:
>>
>>> 817: *
>>> 818: * Additional locale-related system properties defined by the
>>> 819: * {@link Locale##default_locale Default Locale} section in the
>>>
On Mon, 11 Dec 2023 18:54:25 GMT, Naoto Sato wrote:
> This is a doc change to clarify what the `Default Locale` is, and how it is
> established during the system startup using the system properties. Those
> locale-related system properties have existed since the early days of Java,
&
On Tue, 9 Jan 2024 19:27:12 GMT, Justin Lu wrote:
> Please review this PR which is the backport of the ISO 4217 Amendment 176
> Update. Commit
> [8b24851b](https://github.com/openjdk/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc)
> from the [openjdk/jdk](https://git.openjdk.org/jdk)
On Tue, 9 Jan 2024 19:02:39 GMT, Iris Clark wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflects review comments
>
> src/java.base/share/classes/java/lang/System.java line
> Adding an explanation of the locale-related system properties in the
> `System.getProperties()` method. Corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Reflects review co
Adding an explanation of the locale-related system properties in the
`System.getProperties()` method. Corresponding CSR has alos been drafted.
-
Depends on: https://git.openjdk.org/jdk/pull/17065
Commit messages:
- initial commit
Changes:
On Fri, 5 Jan 2024 17:05:04 GMT, Dan Lutker wrote:
> Clean backport tzdata 2023d.
> `make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test
> test/jdk/sun/util/resources test/jdk/sun/text/resources
> test/jdk/sun/util/calendar"` is all passing
LGTM. Thanks for the backport.
On Thu, 4 Jan 2024 19:30:00 GMT, Justin Lu wrote:
>> Please review this PR which splits up the _LocaleProvidersRun_ test file for
>> performance and maintenance reasons.
>>
>> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR,
>> HOST, SPI, etc.) was getting rather
On Thu, 4 Jan 2024 19:09:34 GMT, Joe Wang wrote:
> backport of PR: https://github.com/openjdk/jdk/pull/17252
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/32#pullrequestreview-1804842674
On Wed, 30 Aug 2023 22:35:43 GMT, Naoto Sato wrote:
>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211
>> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored
>> the in-house cache with WeakHashMap, and removed the Key class as i
On Wed, 3 Jan 2024 23:30:41 GMT, Justin Lu wrote:
> Please review this PR which splits up the _LocaleProvidersRun_ test file for
> performance and maintenance reasons.
>
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR,
> HOST, SPI, etc.) was getting rather long,
On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose wrote:
> tzdata2023d changes
LTGM too, assuming all the tests passed
-
Marked as reviewed by naoto (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17268#pullrequestreview-1804702013
On Thu, 4 Jan 2024 17:26:37 GMT, Naoto Sato wrote:
> 8322647: Short name for the `Europe/Lisbon` time zone is incorrect
This pull request has now been integrated.
Changeset: a72afb38
Author: Naoto Sato
URL:
https://git.openjdk.org/jdk22/com
8322647: Short name for the `Europe/Lisbon` time zone is incorrect
-
Commit messages:
- Backport ad31ec5c5f120082cedd7b9ece45b6b44147c0c5
Changes: https://git.openjdk.org/jdk22/pull/30/files
Webrev: https://webrevs.openjdk.org/?repo=jdk22=30=00
Issue:
On Fri, 22 Dec 2023 18:59:20 GMT, Naoto Sato wrote:
> This is a regression caused by the fix to
> [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing
> of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is
> generated during the bu
On Fri, 22 Dec 2023 18:59:20 GMT, Naoto Sato wrote:
> This is a regression caused by the fix to
> [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing
> of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is
> generated during the bu
On Fri, 22 Dec 2023 20:19:17 GMT, Joe Wang wrote:
>> This is a regression caused by the fix to
>> [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the
>> parsing of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java`
>> which is generated during the build time
This is a regression caused by the fix to
[JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing
of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is
generated during the build time has the following diffs from the previous
(incorrect) one:
---
On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung wrote:
> Backport of JDK-8322041
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/22#pullrequestreview-1791633961
On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier wrote:
> …g exception
>
> After leaving the method by throwing an exception the data can not be cleaned
> any more.
LGTM. Please remove the redundant package name before push.
src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
201 - 300 of 1223 matches
Mail list logo
