From naoto at openjdk.org  Fri Jan  2 19:03:04 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Jan 2026 19:03:04 GMT
Subject: <i18n dev> RFR: 8374433: java/util/Locale/PreserveTagCase.java does
 not run any tests
Message-ID: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>

Removing `static` from the JUnit test cases so that they are executed

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/29021/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29021&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374433
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29021/head:pull/29021

PR: https://git.openjdk.org/jdk/pull/29021

From iris at openjdk.org  Fri Jan  2 19:07:53 2026
From: iris at openjdk.org (Iris Clark)
Date: Fri, 2 Jan 2026 19:07:53 GMT
Subject: <i18n dev> RFR: 8374433: java/util/Locale/PreserveTagCase.java
 does not run any tests
In-Reply-To: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
References: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
Message-ID: <y-R8M1V88odiYaSdcvIM0guQsZYi7A1bA_2FJQpIYmg=.5da11cdf-cfb4-44be-95ad-61557e8d2772@github.com>

On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing `static` from the JUnit test cases so that they are executed

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29021#pullrequestreview-3623731349

From joehw at openjdk.org  Fri Jan  2 19:37:02 2026
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 2 Jan 2026 19:37:02 GMT
Subject: <i18n dev> RFR: 8374433: java/util/Locale/PreserveTagCase.java
 does not run any tests
In-Reply-To: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
References: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
Message-ID: <lMEKQuDBsOqVFQLgWEuvjSNbQUkYzXHNAlL2a6-EB2s=.d8db59d5-2aa9-4116-9d45-8db69bfb5fd3@github.com>

On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing `static` from the JUnit test cases so that they are executed

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29021#pullrequestreview-3623770093

From duke at openjdk.org  Sun Jan  4 06:09:09 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 4 Jan 2026 06:09:09 GMT
Subject: <i18n dev> RFR: 8364007: Add no-argument codePointCount method
 to CharSequence and String [v3]
In-Reply-To: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
Message-ID: <eYnD4Rlb0REvtKg1Up1l7VmJJImnl0yFgmkrYEJW1pw=.18bf3157-31e8-430d-85a2-d0e3cc94e5b9@github.com>

On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update `@bug` in correct file
>  - Add default implementation on codePointCount in CharSequence
>  - Update `@bug` entries in test class doc comments
>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

I had Copilot (GPT-4.1) create a draft:

> ## Summary
> 
> Add a no-argument `codePointCount()` method to `CharSequence` and `String` to count the number of Unicode code points in the entire sequence or string.
> 
> ## Problem
> 
> Currently, `String.codePointCount` and `CharSequence.codePointCount` only provide an overload that requires start and end indices. Developers often expect an overload with no arguments that returns the code point count of the entire string or sequence. Without this, developers resort to verbose or less efficient workarounds, such as using `codePoints().count()` (which yields every code point, adding unnecessary overhead) or calling `codePointCount(0, str.length())` (which is more verbose, requires a temporary variable, and performs an extra boundary check).
> 
> A common use case involves enforcing maximum character limits on user input, particularly for fields stored in databases such as MySQL or PostgreSQL. Both database systems can consider the declared length of `VARCHAR(n)` columns as the number of Unicode code points, not just the number of `char` units or bytes for character sets like UTF-8 or UTF8MB4. Correctly counting code points is essential for supporting internationalized input, emoji, and non-BMP characters. For example, the NIST SP 800-63B guideline specifies that passwords should be checked in terms of the number of Unicode code points.
> 
> ## Solution
> 
> Introduce default no-argument `codePointCount()` methods in both the `CharSequence` interface and the `String` class. The new method returns the number of Unicode code points in the entire character sequence, equivalent to invoking `codePointCount(0, length())`, but provides better readability and avoids unnecessary overhead. The implementation in `CharSequence` is a default method, while `String` provides an explicit override for potential performance optimization.
> 
> ## Specification
> 
> Add to `java.lang.CharSequence` interface:
> ```java
> /**
>  * Returns the number of Unicode code points in this character sequence.
>  * Equivalent to {@code codePointCount(0, length())}.
>  *
>  * @return the number of Unicode code points in this sequence
>  * @since N
>  */
> default int codePointCount() {
>     return codePointCount(0, length());
> }
> ```
> 
> Add to `java.lang.String` class:
> ```java
> /**
>  * Returns the number of Unicode code points in this string.
>  * Equivalent to {@code codePointCount(0, length())}.
>  *
>  * @return the number of Unicode code points in this string
>  * @since N
>  */
> @Override
> public int codePointCount() {
>     return codePointCount(0, length());
> }
> ```
> 
> Here, `N` refers to the next Java platform version in which this change will be available.
> 
> Informative Supplement:
> 
> - Implementation: [GitHub PR 26461](https://github.com/openjdk/jdk/pull/26461)
> - Example use cases:
>     ```java
>     // For user names stored in MySQL (or PostgreSQL) VARCHAR(20), which counts code points:
>     if (userName.codePointCount() > 20) {
>         IO.println("The user name is too long to store in VARCHAR(20) in utf8mb4 MySQL/PostgreSQL!");
>     }
>     // Password policy: require at least 8 Unicode characters (code points) as per NIST SP 800-63B:
>     if (password.codePointCount() < 8) {
>         IO.println("Password is too short!");
>     }
>     ```
> 
> References:
> - [MySQL VARCHAR documentation](https://dev.mysql.com/doc/refman/8.0/en/char.html)
> - [PostgreSQL Character Types](https://www.postgresql.org/docs/current/datatype-character.html)
> - [NIST SP 800-63B ?5.1.1.2](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver)

<details>
<summary>Markdown Source</summary>


## Summary

Add a no-argument `codePointCount()` method to `CharSequence` and `String` to count the number of Unicode code points in the entire sequence or string.

## Problem

Currently, `String.codePointCount` and `CharSequence.codePointCount` only provide an overload that requires start and end indices. Developers often expect an overload with no arguments that returns the code point count of the entire string or sequence. Without this, developers resort to verbose or less efficient workarounds, such as using `codePoints().count()` (which yields every code point, adding unnecessary overhead) or calling `codePointCount(0, str.length())` (which is more verbose, requires a temporary variable, and performs an extra boundary check).

A common use case involves enforcing maximum character limits on user input, particularly for fields stored in databases such as MySQL or PostgreSQL. Both database systems can consider the declared length of `VARCHAR(n)` columns as the number of Unicode code points, not just the number of `char` units or bytes for character sets like UTF-8 or UTF8MB4. Correctly counting code points is essential for supporting internationalized input, emoji, and non-BMP characters. For example, the NIST SP 800-63B guideline specifies that passwords should be checked in terms of the number of Unicode code points.

## Solution

Introduce default no-argument `codePointCount()` methods in both the `CharSequence` interface and the `String` class. The new method returns the number of Unicode code points in the entire character sequence, equivalent to invoking `codePointCount(0, length())`, but provides better readability and avoids unnecessary overhead. The implementation in `CharSequence` is a default method, while `String` provides an explicit override for potential performance optimization.

## Specification

Add to `java.lang.CharSequence` interface:

/**
 * Returns the number of Unicode code points in this character sequence.
 * Equivalent to {@code codePointCount(0, length())}.
 *
 * @return the number of Unicode code points in this sequence
 * @since N
 */
default int codePointCount() {
    return codePointCount(0, length());
}


Add to `java.lang.String` class:

/**
 * Returns the number of Unicode code points in this string.
 * Equivalent to {@code codePointCount(0, length())}.
 *
 * @return the number of Unicode code points in this string
 * @since N
 */
@Override
public int codePointCount() {
    return codePointCount(0, length());
}


Here, `N` refers to the next Java platform version in which this change will be available.

Informative Supplement:

- Implementation: [GitHub PR 26461](https://github.com/openjdk/jdk/pull/26461)
- Example use cases:
    ```java
    // For user names stored in MySQL (or PostgreSQL) VARCHAR(20), which counts code points:
    if (userName.codePointCount() > 20) {
        IO.println("The user name is too long to store in VARCHAR(20) in utf8mb4 MySQL/PostgreSQL!");
    }
    // Password policy: require at least 8 Unicode characters (code points) as per NIST SP 800-63B:
    if (password.codePointCount() < 8) {
        IO.println("Password is too short!");
    }
    ```

References:
- [MySQL VARCHAR documentation](https://dev.mysql.com/doc/refman/8.0/en/char.html)
- [PostgreSQL Character Types](https://www.postgresql.org/docs/current/datatype-character.html)
- [NIST SP 800-63B ?5.1.1.2](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver)


</details>

Needs to be fixed:

> for character sets like UTF-8 or UTF8MB4.

?

"for character sets like UTF-8 (utf8mb4 in MySQL)."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3707771006

From duke at openjdk.org  Sun Jan  4 07:25:06 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 4 Jan 2026 07:25:06 GMT
Subject: <i18n dev> RFR: 8364007: Add no-argument codePointCount method
 to CharSequence and String [v3]
In-Reply-To: <3JOprtfyEvBcaGwc36e-4qD7pXLFJ_bWYce2CHerALQ=.95148986-fa08-4ec7-93d9-0014d075abb0@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <fzQCP48AOnM_sAvhD0dMRiT4X8uRzW4-TlNcTamgCmk=.480bdc6b-687a-4bc9-8d13-ff392d98c9d1@github.com>
 <3JOprtfyEvBcaGwc36e-4qD7pXLFJ_bWYce2CHerALQ=.95148986-fa08-4ec7-93d9-0014d075abb0@github.com>
Message-ID: <IgyM6HBnfT1BcWqw0ChAzPrX7uOLgE18razO2nfIxws=.1f6078bd-5b91-4a57-99c7-c6a4910dc612@github.com>

On Sat, 8 Nov 2025 13:53:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The CSR text is not modified from the boilerplate, but I have no authority to modify it.
>
> Hi @tats-u, if you can provide the text for the CSR, I can help upload your text to the JBS. Unfortunately you need a JBS account in order to update the CSR.

@liach Fixed:

> ## Summary
> 
> Add a no-argument `codePointCount()` method to `CharSequence` and `String` to count the number of Unicode code points in the entire sequence or string.
> 
> ## Problem
> 
> Currently, `String.codePointCount` and `CharSequence.codePointCount` only provide an overload that requires start and end indices. Developers often expect an overload with no arguments that returns the code point count of the entire string or sequence. Without this, developers resort to verbose or less efficient workarounds, such as using `codePoints().count()` (which yields every code point, adding unnecessary overhead) or calling `codePointCount(0, str.length())` (which is more verbose, requires a temporary variable, and performs an extra boundary check).
> 
> A common use case involves enforcing maximum character limits on user input, particularly for fields stored in databases such as MySQL or PostgreSQL. Both database systems can consider the declared length of `VARCHAR(n)` columns as the number of Unicode code points, not just the number of `char` units or bytes for character sets like UTF-8 (utf8mb4 in MySQL). Correctly counting code points is essential for supporting internationalized input, emoji, and non-BMP characters. For example, the NIST SP 800-63B guideline specifies that passwords should be checked in terms of the number of Unicode code points.
> 
> ## Solution
> 
> Introduce default no-argument `codePointCount()` methods in both the `CharSequence` interface and the `String` class. The new method returns the number of Unicode code points in the entire character sequence, equivalent to invoking `codePointCount(0, length())`, but provides better readability and avoids unnecessary overhead. The implementation in `CharSequence` is a default method, while `String` provides an explicit override for potential performance optimization.
> 
> ## Specification
> 
> Add to `java.lang.CharSequence` interface:
> ```java
> /**
>  * Returns the number of Unicode code points in this character sequence.
>  * Equivalent to {@code codePointCount(0, length())}.
>  *
>  * @return the number of Unicode code points in this sequence
>  * @since N
>  */
> default int codePointCount() {
>     return codePointCount(0, length());
> }
> ```
> 
> Add to `java.lang.String` class:
> ```java
> /**
>  * Returns the number of Unicode code points in this string.
>  * Equivalent to {@code codePointCount(0, length())}.
>  *
>  * @return the number of Unicode code points in this string
>  * @since N
>  */
> @Override
> public int codePointCount() {
>     return codePointCount(0, length());
> }
> ```
> 
> Here, `N` refers to the next Java platform version in which this change will be available.
> 
> Informative Supplement:
> 
> - Implementation: [GitHub PR 26461](https://github.com/openjdk/jdk/pull/26461)
> - Example use cases:
>     ```java
>     // For user names stored in MySQL (or PostgreSQL) VARCHAR(20), which counts code points:
>     if (userName.codePointCount() > 20) {
>         IO.println("The user name is too long to store in VARCHAR(20) in utf8mb4 MySQL/PostgreSQL!");
>     }
>     // Password policy: require at least 8 Unicode characters (code points) as per NIST SP 800-63B:
>     if (password.codePointCount() < 8) {
>         IO.println("Password is too short!");
>     }
>     ```
> 
> References:
> - [MySQL VARCHAR documentation](https://dev.mysql.com/doc/refman/8.4/en/char.html)
> - [PostgreSQL Character Types](https://www.postgresql.org/docs/current/datatype-character.html)
> - [NIST SP 800-63B ?5.1.1.2](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver)

<details>
<summary>Markdown Source</summary>


## Summary

Add a no-argument `codePointCount()` method to `CharSequence` and `String` to count the number of Unicode code points in the entire sequence or string.

## Problem

Currently, `String.codePointCount` and `CharSequence.codePointCount` only provide an overload that requires start and end indices. Developers often expect an overload with no arguments that returns the code point count of the entire string or sequence. Without this, developers resort to verbose or less efficient workarounds, such as using `codePoints().count()` (which yields every code point, adding unnecessary overhead) or calling `codePointCount(0, str.length())` (which is more verbose, requires a temporary variable, and performs an extra boundary check).

A common use case involves enforcing maximum character limits on user input, particularly for fields stored in databases such as MySQL or PostgreSQL. Both database systems can consider the declared length of `VARCHAR(n)` columns as the number of Unicode code points, not just the number of `char` units or bytes for character sets like UTF-8 (utf8mb4 in MySQL). Correctly counting code points is essential for supporting internationalized input, emoji, and non-BMP characters. For example, the NIST SP 800-63B guideline specifies that passwords should be checked in terms of the number of Unicode code points.

## Solution

Introduce default no-argument `codePointCount()` methods in both the `CharSequence` interface and the `String` class. The new method returns the number of Unicode code points in the entire character sequence, equivalent to invoking `codePointCount(0, length())`, but provides better readability and avoids unnecessary overhead. The implementation in `CharSequence` is a default method, while `String` provides an explicit override for potential performance optimization.

## Specification

Add to `java.lang.CharSequence` interface:

/**
 * Returns the number of Unicode code points in this character sequence.
 * Equivalent to {@code codePointCount(0, length())}.
 *
 * @return the number of Unicode code points in this sequence
 * @since N
 */
default int codePointCount() {
    return codePointCount(0, length());
}


Add to `java.lang.String` class:

/**
 * Returns the number of Unicode code points in this string.
 * Equivalent to {@code codePointCount(0, length())}.
 *
 * @return the number of Unicode code points in this string
 * @since N
 */
@Override
public int codePointCount() {
    return codePointCount(0, length());
}


Here, `N` refers to the next Java platform version in which this change will be available.

Informative Supplement:

- Implementation: [GitHub PR 26461](https://github.com/openjdk/jdk/pull/26461)
- Example use cases:
    ```java
    // For user names stored in MySQL (or PostgreSQL) VARCHAR(20), which counts code points:
    if (userName.codePointCount() > 20) {
        IO.println("The user name is too long to store in VARCHAR(20) in utf8mb4 MySQL/PostgreSQL!");
    }
    // Password policy: require at least 8 Unicode characters (code points) as per NIST SP 800-63B:
    if (password.codePointCount() < 8) {
        IO.println("Password is too short!");
    }
    ```

References:
- [MySQL VARCHAR documentation](https://dev.mysql.com/doc/refman/8.4/en/char.html)
- [PostgreSQL Character Types](https://www.postgresql.org/docs/current/datatype-character.html)
- [NIST SP 800-63B ?5.1.1.2](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3707818947

From duke at openjdk.org  Mon Jan  5 08:41:50 2026
From: duke at openjdk.org (Johny Jose)
Date: Mon, 5 Jan 2026 08:41:50 GMT
Subject: <i18n dev> RFR: 8373476 : (tz) Update Timezone Data to 2025c
Message-ID: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>

tzdata changes for 2025c

-------------

Commit messages:
 - 8373476: (tz) Update Timezone Data to 2025c

Changes: https://git.openjdk.org/jdk/pull/29029/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29029&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373476
  Stats: 132 lines in 11 files changed: 67 ins; 8 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/29029.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29029/head:pull/29029

PR: https://git.openjdk.org/jdk/pull/29029

From coffeys at openjdk.org  Mon Jan  5 09:18:22 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 5 Jan 2026 09:18:22 GMT
Subject: <i18n dev> RFR: 8373476 : (tz) Update Timezone Data to 2025c
In-Reply-To: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>
References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>
Message-ID: <Za1lye4Nx9or_3GcO96hpeqSSUfEMoBHr-VCj0S4wac=.bfa5a686-f547-47d3-a20e-ad98e04fa0c2@github.com>

On Mon, 5 Jan 2026 08:33:32 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata changes for 2025c

LGTM

-------------

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29029#pullrequestreview-3626034314

From jlu at openjdk.org  Mon Jan  5 17:21:47 2026
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 5 Jan 2026 17:21:47 GMT
Subject: <i18n dev> RFR: 8374433: java/util/Locale/PreserveTagCase.java
 does not run any tests
In-Reply-To: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
References: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
Message-ID: <wfodc-0QXJlZSBPi5-MelaPhmlAXGL0FMag2pcN84XE=.c2da29f0-b7ca-4647-b176-e86025284e09@github.com>

On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing `static` from the JUnit test cases so that they are executed

Marked as reviewed by jlu (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29021#pullrequestreview-3627735928

From naoto at openjdk.org  Mon Jan  5 17:56:30 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Jan 2026 17:56:30 GMT
Subject: <i18n dev> RFR: 8373476 : (tz) Update Timezone Data to 2025c
In-Reply-To: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>
References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>
Message-ID: <jbWpBDiMCuRWNhdy6h9HvPwqnY-y2gtrWjUuFqxcgPg=.ba7d8496-3996-4d21-bbf5-bae1c989f22c@github.com>

On Mon, 5 Jan 2026 08:33:32 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata changes for 2025c

LGTM.

For the JIRA issue, please fix the last paragraph in the problem text:

Commentary now also uses characters from the set -''""?? as this
     can be useful and should work with current applications. This
     also affects data in iso3166.tab and zone1970.tab, which now
     contain strings like "C?te d'Ivoire" instead of "C?te d'Ivoire".

which seems to have converted the non-ASCII quotes to ASCII equivalents, which made the paragraph not making sense. FWIW, the original was:

Commentary now also uses characters from the set ??????? as this
     can be useful and should work with current applications.  This
     also affects data in iso3166.tab and zone1970.tab, which now
     contain strings like ?C?te d?Ivoire? instead of ?C?te d'Ivoire?

src/java.base/share/data/tzdata/iso3166.tab line 44:

> 42: #     ?Czech Republic? and ?Turkey? rather than ?Czechia? and ?T?rkiye?),
> 43: #     and sometimes to omit needless detail or churn (e.g., ?Netherlands?
> 44: #     rather than ?Netherlands (the)? or ?Netherlands (Kingdom of the)?).

It's interesting that they started using non-ASCII quotes in comments, which is different from our policy, but we need to live with it as it is the upstream change

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29029#pullrequestreview-3627828729
PR Review Comment: https://git.openjdk.org/jdk/pull/29029#discussion_r2662309506

From vyazici at openjdk.org  Tue Jan  6 08:23:16 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 08:23:16 GMT
Subject: <i18n dev> RFR: 8374523: [BACKOUT] Move input validation checks to
 Java for java.lang.StringCoding intrinsics
Message-ID: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>

Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210].

[JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

-------------

Commit messages:
 - Revert "8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics"

Changes: https://git.openjdk.org/jdk/pull/29055/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374523
  Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/29055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29055/head:pull/29055

PR: https://git.openjdk.org/jdk/pull/29055

From vyazici at openjdk.org  Tue Jan  6 08:23:16 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 08:23:16 GMT
Subject: <i18n dev> RFR: 8374523: [BACKOUT] Move input validation checks
 to Java for java.lang.StringCoding intrinsics
In-Reply-To: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
Message-ID: <zk3-XGiaG5jLISqVAtPgLgvcEOT9raXjQ_UefbivPCs=.b0496830-92a7-47b8-8696-60b22a7cb106@github.com>

On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210].
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Tier 1-3 are clear on c8acc80b8c6.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3713645184

From duke at openjdk.org  Tue Jan  6 10:09:58 2026
From: duke at openjdk.org (duke)
Date: Tue, 6 Jan 2026 10:09:58 GMT
Subject: <i18n dev> RFR: 8373476 : (tz) Update Timezone Data to 2025c
In-Reply-To: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>
References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>
Message-ID: <f23HvJWKsKhgj4kvthESW9EVddleazVR3JFuHLCbHyY=.3fc46238-d130-4613-9a41-6b9549f5f8c1@github.com>

On Mon, 5 Jan 2026 08:33:32 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata changes for 2025c

@johnyjose30 
Your change (at version 512f7a5dcb5340647720760b847a52f15bcfd98a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29029#issuecomment-3714052685

From duke at openjdk.org  Tue Jan  6 10:09:59 2026
From: duke at openjdk.org (Johny Jose)
Date: Tue, 6 Jan 2026 10:09:59 GMT
Subject: <i18n dev> RFR: 8373476 : (tz) Update Timezone Data to 2025c
In-Reply-To: <jbWpBDiMCuRWNhdy6h9HvPwqnY-y2gtrWjUuFqxcgPg=.ba7d8496-3996-4d21-bbf5-bae1c989f22c@github.com>
References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>
 <jbWpBDiMCuRWNhdy6h9HvPwqnY-y2gtrWjUuFqxcgPg=.ba7d8496-3996-4d21-bbf5-bae1c989f22c@github.com>
Message-ID: <FkSc2xZY248xsmVDfuKU5782VaQxgaDLEjUiDnChtnw=.a804a0f6-0793-4b13-9f47-34add119859f@github.com>

On Mon, 5 Jan 2026 17:42:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> tzdata changes for 2025c
>
> src/java.base/share/data/tzdata/iso3166.tab line 44:
> 
>> 42: #     ?Czech Republic? and ?Turkey? rather than ?Czechia? and ?T?rkiye?),
>> 43: #     and sometimes to omit needless detail or churn (e.g., ?Netherlands?
>> 44: #     rather than ?Netherlands (the)? or ?Netherlands (Kingdom of the)?).
> 
> It's interesting that they started using non-ASCII quotes in comments, which is different from our policy, but we need to live with it as it is the upstream change

Updated Jira

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29029#discussion_r2664372684

From duke at openjdk.org  Tue Jan  6 10:42:21 2026
From: duke at openjdk.org (Johny Jose)
Date: Tue, 6 Jan 2026 10:42:21 GMT
Subject: <i18n dev> Integrated: 8373476 : (tz) Update Timezone Data to 2025c
In-Reply-To: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>
References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com>
Message-ID: <LsNrWxnMOh0WmNrghjbx-LgJlPBlrN-LR-vne-_1qi4=.9b7c3771-2782-4f26-a7a1-95bff5abdcf5@github.com>

On Mon, 5 Jan 2026 08:33:32 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata changes for 2025c

This pull request has now been integrated.

Changeset: 5df183be
Author:    Johny Jose <johny.jose at oracle.com>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5df183be6c484d8f9635fac149caf5e2079c5561
Stats:     132 lines in 11 files changed: 67 ins; 8 del; 57 mod

8373476: (tz) Update Timezone Data to 2025c

Reviewed-by: coffeys, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/29029

From naoto at openjdk.org  Tue Jan  6 16:31:38 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Jan 2026 16:31:38 GMT
Subject: <i18n dev> RFR: 8374433: java/util/Locale/PreserveTagCase.java
 does not run any tests
In-Reply-To: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
References: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
Message-ID: <6ELTvLimbKKHD_x-JQPvPLAbPRXj2H93S_-3u6DZ_8Y=.ffcbe1d2-5dce-465b-8f3e-3f3f969d3d26@github.com>

On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing `static` from the JUnit test cases so that they are executed

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29021#issuecomment-3715362758

From naoto at openjdk.org  Tue Jan  6 16:31:39 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Jan 2026 16:31:39 GMT
Subject: <i18n dev> Integrated: 8374433:
 java/util/Locale/PreserveTagCase.java does not run any tests
In-Reply-To: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
References: <pSHnQ3nt7VHB6Ag46BoIu7hzfQIu-MdwhVFkA9-3YGk=.d095be2f-1a6f-4260-a53b-7a9397213b6f@github.com>
Message-ID: <esnzLqrj98ZsXBtqofDnyqNH_4AsJJ0KLpo-hTJMb5c=.2e667eba-2b25-4416-9c1c-ab9ba108d599@github.com>

On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing `static` from the JUnit test cases so that they are executed

This pull request has now been integrated.

Changeset: 136ac0d1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/136ac0d10b92df8875f36c717e85595740b50ed2
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8374433: java/util/Locale/PreserveTagCase.java does not run any tests

Reviewed-by: iris, joehw, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/29021

From jlu at openjdk.org  Tue Jan  6 18:22:45 2026
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 Jan 2026 18:22:45 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests
 to use JUnit over TestNG [v3]
In-Reply-To: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
Message-ID: <cGxDYAzwMOlozIZc5Z2gwqS9cosvZyPoqVLaf8v0bcw=.c5855d64-462d-4af8-9794-ca29308d43d1@github.com>

> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.
> 
> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
> The rest of the commits are aesthetic related.
> 
> Before conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit
> 
> 
> After conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit

Justin Lu 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 request contains 13 additional commits since the last revision:

 - Removing now outdated testNG comment
 - Merge branch 'master' into java.time-to-JUnit
 - Merge branch 'master' into java.time-to-JUnit
 - nontestng -> nonjunit
 - Fix comments
 - Fixing @timeout as well as unrelated stray spacing
 - Apply copyright years
 - Cleaning up some leftover whitespace from tool
 - Automated conversion created statement lambdas for exception tests. Modify to expression lambdas
 - Cleaning up unused JUnit imports
 - ... and 3 more: https://git.openjdk.org/jdk/compare/c6f3f85a...1cb313ea

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28911/files
  - new: https://git.openjdk.org/jdk/pull/28911/files/d90d23ed..1cb313ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=01-02

  Stats: 8409 lines in 2284 files changed: 2778 ins; 1646 del; 3985 mod
  Patch: https://git.openjdk.org/jdk/pull/28911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28911/head:pull/28911

PR: https://git.openjdk.org/jdk/pull/28911

From naoto at openjdk.org  Tue Jan  6 18:57:51 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Jan 2026 18:57:51 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests
 to use JUnit over TestNG [v3]
In-Reply-To: <cGxDYAzwMOlozIZc5Z2gwqS9cosvZyPoqVLaf8v0bcw=.c5855d64-462d-4af8-9794-ca29308d43d1@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
 <cGxDYAzwMOlozIZc5Z2gwqS9cosvZyPoqVLaf8v0bcw=.c5855d64-462d-4af8-9794-ca29308d43d1@github.com>
Message-ID: <hUycGm9XjARWE5AnWr1t7phlveJb1dfp1Z3MItQr0VM=.e38d54c8-c6c0-4d5d-8597-9e4575605ed0@github.com>

On Tue, 6 Jan 2026 18:22:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.
>> 
>> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
>> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
>> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
>> The rest of the commits are aesthetic related.
>> 
>> Before conversion stats
>> 
>> 
>> Test results: passed: 187
>> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit
>> 
>> 
>> After conversion stats
>> 
>> 
>> Test results: passed: 187
>> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit
>
> Justin Lu 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 request contains 13 additional commits since the last revision:
> 
>  - Removing now outdated testNG comment
>  - Merge branch 'master' into java.time-to-JUnit
>  - Merge branch 'master' into java.time-to-JUnit
>  - nontestng -> nonjunit
>  - Fix comments
>  - Fixing @timeout as well as unrelated stray spacing
>  - Apply copyright years
>  - Cleaning up some leftover whitespace from tool
>  - Automated conversion created statement lambdas for exception tests. Modify to expression lambdas
>  - Cleaning up unused JUnit imports
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/23530f6a...1cb313ea

Still looks good. I think the new commit warrants a copy right year increment

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28911#issuecomment-3715907068

From jlu at openjdk.org  Tue Jan  6 19:24:35 2026
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 Jan 2026 19:24:35 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests
 to use JUnit over TestNG [v4]
In-Reply-To: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
Message-ID: <ekjGAIfSmahMK4mQwXoxhDArq_y-8fnBzCyyuwaVxjM=.9e2e609f-e7d2-4f04-afa8-69e9f7dee065@github.com>

> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.
> 
> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
> The rest of the commits are aesthetic related.
> 
> Before conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit
> 
> 
> After conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Bumping copyright year for TCKDateTimeFormatter.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28911/files
  - new: https://git.openjdk.org/jdk/pull/28911/files/1cb313ea..7e1ae3c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28911/head:pull/28911

PR: https://git.openjdk.org/jdk/pull/28911

From naoto at openjdk.org  Tue Jan  6 19:24:36 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Jan 2026 19:24:36 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests
 to use JUnit over TestNG [v4]
In-Reply-To: <ekjGAIfSmahMK4mQwXoxhDArq_y-8fnBzCyyuwaVxjM=.9e2e609f-e7d2-4f04-afa8-69e9f7dee065@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
 <ekjGAIfSmahMK4mQwXoxhDArq_y-8fnBzCyyuwaVxjM=.9e2e609f-e7d2-4f04-afa8-69e9f7dee065@github.com>
Message-ID: <463l2VqYZdLGc3Aw2YJd5gXNMHGbPoklAroJjs951-Y=.65f94b1b-85c2-4741-8cb5-f850f196ad65@github.com>

On Tue, 6 Jan 2026 19:21:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.
>> 
>> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
>> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
>> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
>> The rest of the commits are aesthetic related.
>> 
>> Before conversion stats
>> 
>> 
>> Test results: passed: 187
>> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit
>> 
>> 
>> After conversion stats
>> 
>> 
>> Test results: passed: 187
>> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bumping copyright year for TCKDateTimeFormatter.java

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28911#pullrequestreview-3632176797

From jlu at openjdk.org  Tue Jan  6 19:27:10 2026
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 Jan 2026 19:27:10 GMT
Subject: <i18n dev> Integrated: 8373830: Refactor test/jdk/java/time/test
 tests to use JUnit over TestNG
In-Reply-To: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
Message-ID: <Vv3puZOfq21IAzAP_4CHMyHNlS1ajuV_JRQgbw__oFc=.b0c744e4-8d21-42d2-819e-a317e5808fb1@github.com>

On Thu, 18 Dec 2025 23:01:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.
> 
> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
> The rest of the commits are aesthetic related.
> 
> Before conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit
> 
> 
> After conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit

This pull request has now been integrated.

Changeset: 53300b4a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53300b4ac12240ea08227386412bfb90650c0aee
Stats:     13724 lines in 186 files changed: 2264 ins; 691 del; 10769 mod

8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG
8373829: Refactor test/jdk/java/time/tck tests to use JUnit over TestNG

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/28911

From lkorinth at openjdk.org  Wed Jan  7 12:35:42 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:35:42 GMT
Subject: <i18n dev> RFR: 8367993: G1: Speed up ConcurrentMark
 initialization [v2]
In-Reply-To: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
Message-ID: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>

On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
> 
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>    
>    Reviewed-by: aboldtch
>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>    
>    Reviewed-by: serb, aivanov, dnguyen
>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767

I will redo the merge, I have done something strange.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595

From lkorinth at openjdk.org  Wed Jan  7 12:58:43 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:58:43 GMT
Subject: <i18n dev> RFR: 8367993: G1: Speed up ConcurrentMark
 initialization [v3]
In-Reply-To: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>

> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
> 
> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
> 
> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
> 
> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:

 - Merge branch '8373253' into 8367993
 - Merge branch 'master' into _8373253
 - Merge branch 'master' into _8367993
 - 8366058: Outdated comment in WinCAPISeedGenerator
   
   Reviewed-by: mullan
 - 8357258: x86: Improve receiver type profiling reliability
   
   Reviewed-by: kvn, vlivanov
 - 8373704: Improve "SocketException: Protocol family unavailable" message
   
   Reviewed-by: lucy, jpai
 - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
   
   Reviewed-by: jiefu, jbhateja, erfang, qamai
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image
   
   Reviewed-by: alanb, dholmes
 - 8374465: Spurious dot in documentation for JVMTI ClassLoad
   
   Reviewed-by: kbarrett
 - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
   
   Reviewed-by: djelinski, mpowers, ascarpino
 - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

-------------

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02
  Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

PR: https://git.openjdk.org/jdk/pull/28723

From vyazici at openjdk.org  Thu Jan  8 09:51:51 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 Jan 2026 09:51:51 GMT
Subject: <i18n dev> [jdk26] RFR: 8374700: [BACKOUT] Move input validation
 checks to Java for java.lang.StringCoding intrinsics
Message-ID: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>

Backport of [JDK-8374210] integrated in 7e18de13 by #29055.

[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

-------------

Commit messages:
 - Backport 7e18de137c3b5f08a479af2b64eb22923261900b

Changes: https://git.openjdk.org/jdk/pull/29112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374700
  Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/29112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29112/head:pull/29112

PR: https://git.openjdk.org/jdk/pull/29112