From evergizova at openjdk.org  Thu Jun  1 14:58:14 2023
From: evergizova at openjdk.org (Ekaterina Vergizova)
Date: Thu, 1 Jun 2023 14:58:14 GMT
Subject: [jdk8u-dev] RFR: 8139348: Deprecate 3DES and RC4 in Kerberos
In-Reply-To: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
References: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
Message-ID: <NJ2PqikeHysgXt6tUiFIhR0IVSlmD6JboACbpW9etu0=.7a873c13-01c4-4704-b6be-5cc866e8a5f2@github.com>

On Thu, 4 May 2023 17:51:40 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8139348 to 8u for parity with Oracle 8u351. 
> CSR JDK-8262273 is approved for 8-pool.
> 
> 11u patch doesn't apply cleanly, some tests need to be adjusted:
> - jdk/test/sun/security/krb5/auto/NewSalt.java
>   - copyright years adjusted
>   - "default_tgs_enctypes=aes128-sha1" changed to "default_tgs_enctypes=aes128-cts" since aes128-sha1 alias is not supported in 8u (JDK-8014628 is not backported to 8u)
> - jdk/test/sun/security/krb5/auto/W83.java
>   - copyright years adjusted
>   - compile tag hunk applied manually due to context difference
> - jdk/test/sun/security/krb5/etype/WeakCrypto.java
>   - bug tag hunk applied manually due to context difference
>   - List.of replaced with Arrays.asList 
> - test/jdk/sun/security/krb5/tools/KtabCheck.java changes applied to jdk/test/sun/security/krb5/tools/ktcheck.sh (JDK-8180569 is not backported to 8u)
>   - additionally, aes128-sha2 (19) values are removed since it is not supported in 8u (JDK-8014628 is not in 8u)
> - jdk/test/sun/security/krb5/tools/onlythree.conf
>   - aes128-sha2 removed from default_tkt_enctypes since it is not supported in 8u (JDK-8014628 is not in 8u)
> 
> Tested with jdk_security and tier1, no regressions.

Could anyone review this backport please?

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/312#issuecomment-1572211556

From andrew at openjdk.org  Thu Jun  1 15:35:14 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 1 Jun 2023 15:35:14 GMT
Subject: [jdk8u-dev] RFR: 8139348: Deprecate 3DES and RC4 in Kerberos
In-Reply-To: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
References: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
Message-ID: <MdzVeeSBqlCklyodxcqXZpnpGqP3WIBHpA6rtfe_CWE=.949b1de5-fe4d-4c2f-a60b-a07b38e8d21c@github.com>

On Thu, 4 May 2023 17:51:40 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8139348 to 8u for parity with Oracle 8u351. 
> CSR JDK-8262273 is approved for 8-pool.
> 
> 11u patch doesn't apply cleanly, some tests need to be adjusted:
> - jdk/test/sun/security/krb5/auto/NewSalt.java
>   - copyright years adjusted
>   - "default_tgs_enctypes=aes128-sha1" changed to "default_tgs_enctypes=aes128-cts" since aes128-sha1 alias is not supported in 8u (JDK-8014628 is not backported to 8u)
> - jdk/test/sun/security/krb5/auto/W83.java
>   - copyright years adjusted
>   - compile tag hunk applied manually due to context difference
> - jdk/test/sun/security/krb5/etype/WeakCrypto.java
>   - bug tag hunk applied manually due to context difference
>   - List.of replaced with Arrays.asList 
> - test/jdk/sun/security/krb5/tools/KtabCheck.java changes applied to jdk/test/sun/security/krb5/tools/ktcheck.sh (JDK-8180569 is not backported to 8u)
>   - additionally, aes128-sha2 (19) values are removed since it is not supported in 8u (JDK-8014628 is not in 8u)
> - jdk/test/sun/security/krb5/tools/onlythree.conf
>   - aes128-sha2 removed from default_tkt_enctypes since it is not supported in 8u (JDK-8014628 is not in 8u)
> 
> Tested with jdk_security and tier1, no regressions.

Yes, I'll take a look. As Severin says, I was planning to do this one too, so thanks for taking it on.

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/312#issuecomment-1572280518

From gnu.andrew at redhat.com  Thu Jun  1 15:38:32 2023
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 1 Jun 2023 16:38:32 +0100
Subject: [jdk8u-dev] RFR: 8193017: Import freetype sources into OpenJDK
 source tree [v4]
In-Reply-To: <b465bda9-19dc-5671-f3f6-9833ec6d8c15@tarent.de>
References: <XOBcBVye8WM8WNyj_6fQEk3oMPt7kgxyggcIf6MMk6E=.dcd2441e-2fb5-4b18-ab98-8e274b11c562@github.com>
 <0GHr4S0HzJRGkbPyQdB79OnrgmqwLE-1XM5oscR8r_Y=.b0329029-5602-4d09-beae-66d273496f29@github.com>
 <3ii9h1EBSHStkQ6X5l0A4kFnVumho_wNDG8LwdSzSk8=.fd4fc87b-7c00-4a7d-8645-df4145e02c0e@github.com>
 <b465bda9-19dc-5671-f3f6-9833ec6d8c15@tarent.de>
Message-ID: <ZHi7eFUwHlHBIJxC@hex.discworld.ac.uk>

On 20:03 Wed 31 May     , Thorsten Glaser wrote:
> On Wed, 31 May 2023, Andrew John Hughes wrote:
> 
> >Good to see this being proposed. I was wondering what had happened to it.
> 
> As long as there is a flag to still use the system library,
> and I can figure out how and where to add it in the build
> process?
> 
> bye,
> //mirabilos
> -- 
> Infrastrukturexperte ? tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
> Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
> HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
> Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
> 
>                         ****************************************************
> /?\ The UTF-8 Ribbon
> ??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
> ??? HTML eMail! Also,     https://www.tarent.de/newsletter
> ??? header encryption!
>                         ****************************************************
> 

Given 8u is a stable release, I don't intend for any defaults to
change, so you shouldn't have to add any new options.

This is primarily aimed at Windows, where FreeType is not readily
available on the system and FreeType sources have to be supplied
manually to the JDK build.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Principal Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Please contact via e-mail, not proprietary chat networks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20230601/18c9724d/signature-0001.asc>

From duke at openjdk.org  Thu Jun  1 15:45:22 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Thu, 1 Jun 2023 15:45:22 GMT
Subject: [jdk8u-dev] RFR: 8309274: backporting tests for GET and POST OCSP
 calls
Message-ID: <e3_WAyoLDEzlQw2W9xtXeVrXZeKnCeK74Tbe0Yr39XA=.e83ddb32-90eb-4f02-aa8e-82e44e6b17d7@github.com>

Hi!

Here is backport of forgotten tests for **[JDK-8179503: Java should support GET OCSP calls](https://bugs.openjdk.org/browse/JDK-8179503)**.

Original `GetAndPostTests.java` backported from `11u` with the following changes
- unsupported `List.of()`, `Set.of()`, `Map.of()` replaced with equivalents
- `algorithm` parameter dropped from instantiation `PKCS8EncodedKeySpec`
- required `public static enumSSLSocketTemplate.Cert` copied from `11u`

Verification (amd64/20.04LTS): newly added `jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java`
Regression (amd64/20.04LTS): `jdk_security`

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

Commit messages:
 - 8309274: backporting tests for GET and POST OCSP calls

Changes: https://git.openjdk.org/jdk8u-dev/pull/328/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=328&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309274
  Stats: 804 lines in 2 files changed: 804 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/328.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/328/head:pull/328

PR: https://git.openjdk.org/jdk8u-dev/pull/328

From andrew at openjdk.org  Thu Jun  1 17:08:09 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 1 Jun 2023 17:08:09 GMT
Subject: [jdk8u-dev] RFR: 8139348: Deprecate 3DES and RC4 in Kerberos
In-Reply-To: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
References: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
Message-ID: <4EZdNc_IqfLAQ0_pVHtiZRpYkT2QcEXvgmVPpKN5_z0=.de5567fa-7da0-480b-8749-4c1667f175f6@github.com>

On Thu, 4 May 2023 17:51:40 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8139348 to 8u for parity with Oracle 8u351. 
> CSR JDK-8262273 is approved for 8-pool.
> 
> 11u patch doesn't apply cleanly, some tests need to be adjusted:
> - jdk/test/sun/security/krb5/auto/NewSalt.java
>   - copyright years adjusted
>   - "default_tgs_enctypes=aes128-sha1" changed to "default_tgs_enctypes=aes128-cts" since aes128-sha1 alias is not supported in 8u (JDK-8014628 is not backported to 8u)
> - jdk/test/sun/security/krb5/auto/W83.java
>   - copyright years adjusted
>   - compile tag hunk applied manually due to context difference
> - jdk/test/sun/security/krb5/etype/WeakCrypto.java
>   - bug tag hunk applied manually due to context difference
>   - List.of replaced with Arrays.asList 
> - test/jdk/sun/security/krb5/tools/KtabCheck.java changes applied to jdk/test/sun/security/krb5/tools/ktcheck.sh (JDK-8180569 is not backported to 8u)
>   - additionally, aes128-sha2 (19) values are removed since it is not supported in 8u (JDK-8014628 is not in 8u)
> - jdk/test/sun/security/krb5/tools/onlythree.conf
>   - aes128-sha2 removed from default_tkt_enctypes since it is not supported in 8u (JDK-8014628 is not in 8u)
> 
> Tested with jdk_security and tier1, no regressions.

Changes look good to me. I'll add my usual proviso that `Arrays.asList` is modifiable while the original `List.of` method isn't, but this doesn't matter for a test that only calls three read only methods on the result.

JDK-8180569 might be worth looking at for backport, but isn't a pre-requisite for this.

Please flag with `jdk8u-fix-request` for approval.

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

Marked as reviewed by andrew (Reviewer).

PR Review: https://git.openjdk.org/jdk8u-dev/pull/312#pullrequestreview-1455937996

From evergizova at openjdk.org  Thu Jun  1 17:22:07 2023
From: evergizova at openjdk.org (Ekaterina Vergizova)
Date: Thu, 1 Jun 2023 17:22:07 GMT
Subject: [jdk8u-dev] RFR: 8139348: Deprecate 3DES and RC4 in Kerberos
In-Reply-To: <MdzVeeSBqlCklyodxcqXZpnpGqP3WIBHpA6rtfe_CWE=.949b1de5-fe4d-4c2f-a60b-a07b38e8d21c@github.com>
References: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
 <MdzVeeSBqlCklyodxcqXZpnpGqP3WIBHpA6rtfe_CWE=.949b1de5-fe4d-4c2f-a60b-a07b38e8d21c@github.com>
Message-ID: <VcvC1cvGMc0mgG6NciWGTm0CU_M0gHxLKjDDHFHOnro=.401d053f-f523-4d9d-a314-484497dbc9fb@github.com>

On Thu, 1 Jun 2023 15:32:43 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> I'd like to backport JDK-8139348 to 8u for parity with Oracle 8u351. 
>> CSR JDK-8262273 is approved for 8-pool.
>> 
>> 11u patch doesn't apply cleanly, some tests need to be adjusted:
>> - jdk/test/sun/security/krb5/auto/NewSalt.java
>>   - copyright years adjusted
>>   - "default_tgs_enctypes=aes128-sha1" changed to "default_tgs_enctypes=aes128-cts" since aes128-sha1 alias is not supported in 8u (JDK-8014628 is not backported to 8u)
>> - jdk/test/sun/security/krb5/auto/W83.java
>>   - copyright years adjusted
>>   - compile tag hunk applied manually due to context difference
>> - jdk/test/sun/security/krb5/etype/WeakCrypto.java
>>   - bug tag hunk applied manually due to context difference
>>   - List.of replaced with Arrays.asList 
>> - test/jdk/sun/security/krb5/tools/KtabCheck.java changes applied to jdk/test/sun/security/krb5/tools/ktcheck.sh (JDK-8180569 is not backported to 8u)
>>   - additionally, aes128-sha2 (19) values are removed since it is not supported in 8u (JDK-8014628 is not in 8u)
>> - jdk/test/sun/security/krb5/tools/onlythree.conf
>>   - aes128-sha2 removed from default_tkt_enctypes since it is not supported in 8u (JDK-8014628 is not in 8u)
>> 
>> Tested with jdk_security and tier1, no regressions.
>
> Yes, I'll take a look. As Severin says, I was planning to do this one too, so thanks for taking it on.

Thanks for the review, @gnu-andrew!

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/312#issuecomment-1572476834

From andrew at openjdk.org  Thu Jun  1 17:38:06 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 1 Jun 2023 17:38:06 GMT
Subject: [jdk8u-dev] RFR: 8139348: Deprecate 3DES and RC4 in Kerberos
In-Reply-To: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
References: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
Message-ID: <DrZEkjy9ObYugCyhmLj2B3EJ6HlOF92RRhdsjBGaUb8=.a2e276e3-81bd-44f7-ba7a-b28b36240d9d@github.com>

On Thu, 4 May 2023 17:51:40 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8139348 to 8u for parity with Oracle 8u351. 
> CSR JDK-8262273 is approved for 8-pool.
> 
> 11u patch doesn't apply cleanly, some tests need to be adjusted:
> - jdk/test/sun/security/krb5/auto/NewSalt.java
>   - copyright years adjusted
>   - "default_tgs_enctypes=aes128-sha1" changed to "default_tgs_enctypes=aes128-cts" since aes128-sha1 alias is not supported in 8u (JDK-8014628 is not backported to 8u)
> - jdk/test/sun/security/krb5/auto/W83.java
>   - copyright years adjusted
>   - compile tag hunk applied manually due to context difference
> - jdk/test/sun/security/krb5/etype/WeakCrypto.java
>   - bug tag hunk applied manually due to context difference
>   - List.of replaced with Arrays.asList 
> - test/jdk/sun/security/krb5/tools/KtabCheck.java changes applied to jdk/test/sun/security/krb5/tools/ktcheck.sh (JDK-8180569 is not backported to 8u)
>   - additionally, aes128-sha2 (19) values are removed since it is not supported in 8u (JDK-8014628 is not in 8u)
> - jdk/test/sun/security/krb5/tools/onlythree.conf
>   - aes128-sha2 removed from default_tkt_enctypes since it is not supported in 8u (JDK-8014628 is not in 8u)
> 
> Tested with jdk_security and tier1, no regressions.

No problem, sorry for the delay. I only just saw this today.

I've approved the bug. If you integrate, I can sponsor the commit and we can get this one in. Thanks for the backport :)

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/312#issuecomment-1572509123

From evergizova at openjdk.org  Fri Jun  2 02:28:20 2023
From: evergizova at openjdk.org (Ekaterina Vergizova)
Date: Fri, 2 Jun 2023 02:28:20 GMT
Subject: [jdk8u-dev] Integrated: 8139348: Deprecate 3DES and RC4 in Kerberos
In-Reply-To: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
References: <qdxNYxqLCnHEFyxRBzItX7BPc4JB8r6T0AIsdwUfWxE=.8163a4a2-598a-4f33-9b25-e88eeec6eff4@github.com>
Message-ID: <cS7YGu58wM4pifjN7jhVpkSljdod1YmoT2pkN9PslPc=.af895a16-155b-4b8b-9d05-69230d35a811@github.com>

On Thu, 4 May 2023 17:51:40 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8139348 to 8u for parity with Oracle 8u351. 
> CSR JDK-8262273 is approved for 8-pool.
> 
> 11u patch doesn't apply cleanly, some tests need to be adjusted:
> - jdk/test/sun/security/krb5/auto/NewSalt.java
>   - copyright years adjusted
>   - "default_tgs_enctypes=aes128-sha1" changed to "default_tgs_enctypes=aes128-cts" since aes128-sha1 alias is not supported in 8u (JDK-8014628 is not backported to 8u)
> - jdk/test/sun/security/krb5/auto/W83.java
>   - copyright years adjusted
>   - compile tag hunk applied manually due to context difference
> - jdk/test/sun/security/krb5/etype/WeakCrypto.java
>   - bug tag hunk applied manually due to context difference
>   - List.of replaced with Arrays.asList 
> - test/jdk/sun/security/krb5/tools/KtabCheck.java changes applied to jdk/test/sun/security/krb5/tools/ktcheck.sh (JDK-8180569 is not backported to 8u)
>   - additionally, aes128-sha2 (19) values are removed since it is not supported in 8u (JDK-8014628 is not in 8u)
> - jdk/test/sun/security/krb5/tools/onlythree.conf
>   - aes128-sha2 removed from default_tkt_enctypes since it is not supported in 8u (JDK-8014628 is not in 8u)
> 
> Tested with jdk_security and tier1, no regressions.

This pull request has now been integrated.

Changeset: 6244292d
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/6244292d28e1cddcc70bc4dbf98adad13fe1e3d7
Stats:     70 lines in 7 files changed: 27 ins; 8 del; 35 mod

8139348: Deprecate 3DES and RC4 in Kerberos

Reviewed-by: andrew
Backport-of: ded96ddcde1e9e8556a6ce8948acef27b6e192cc

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

PR: https://git.openjdk.org/jdk8u-dev/pull/312

From duke at openjdk.org  Fri Jun  2 06:47:10 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Fri, 2 Jun 2023 06:47:10 GMT
Subject: [jdk8u-dev] Withdrawn: JDK-8309274: [TEST] the tests for JDK-8179503
 (GET OCSP calls support) were not backported
In-Reply-To: <e3_WAyoLDEzlQw2W9xtXeVrXZeKnCeK74Tbe0Yr39XA=.e83ddb32-90eb-4f02-aa8e-82e44e6b17d7@github.com>
References: <e3_WAyoLDEzlQw2W9xtXeVrXZeKnCeK74Tbe0Yr39XA=.e83ddb32-90eb-4f02-aa8e-82e44e6b17d7@github.com>
Message-ID: <h0ftXqc_8FGvIJG-h746uFSK4NApqqyYwkS2buDNR4k=.4be12513-0854-4827-8c8b-4ecb893e994e@github.com>

On Thu, 1 Jun 2023 15:39:24 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> Hi!
> 
> Here is backport of forgotten tests for **[JDK-8179503: Java should support GET OCSP calls](https://bugs.openjdk.org/browse/JDK-8179503)**.
> 
> Original `GetAndPostTests.java` backported from `11u` with the following changes
> - unsupported `List.of()`, `Set.of()`, `Map.of()` replaced with equivalents
> - `algorithm` parameter dropped from instantiation `PKCS8EncodedKeySpec`
> - required `public static enum SSLSocketTemplate.Cert` copied from `11u`
> 
> Verification (amd64/20.04LTS): newly added `jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java`
> Regression (amd64/20.04LTS): `jdk_security`

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/328

From dl at openjdk.org  Mon Jun  5 10:36:10 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 5 Jun 2023 10:36:10 GMT
Subject: [jdk8u-dev] RFR: 8205399: Set node color on pinned
 HashMap.TreeNode deletion
In-Reply-To: <gAvuPhJpdk-tefQoLUfiqdoiqIsLFi9A7vayJVTK_QU=.c210b9c8-8a5b-4e61-8831-72ebc473e04a@github.com>
References: <gAvuPhJpdk-tefQoLUfiqdoiqIsLFi9A7vayJVTK_QU=.c210b9c8-8a5b-4e61-8831-72ebc473e04a@github.com>
Message-ID: <wswy3vrBJJbAWFfRtwC31ee-kd1YK_97zNJ6Gm1i18M=.4e69e06c-5b7b-4361-b4e8-dad3a9e48a1a@github.com>

On Tue, 30 May 2023 08:42:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the issue for details. It reproduces in 8u, which breaks applications that run with `-ea -esa` for extra safety. We have seen at least two in-production bug reports due to this.
> 
> The backport is not clean, because the test should reside in the different folder.
> 
> The verification barfs on discovering the red root, when it also discovers left/right child node is also red. This technically violates one of the basic properties of RB trees: a red node should not have red children. We can always change (sub-)root node color from red to black without violating RB properties, as the path to any descendant node would still have the same number of black nodes. AFAIU, leaving the (sub-)root red and the child red could potentially break something else. This is why I believe this backport is required and safe for 8u.
> 
> Additional testing:
>  - [x] Linux x86_64, new regression test fails without the patch, passes with it
>  - [x] Linux x86_64 `jdk_util`
>  - [x] Linux x86_64 fastdebug `tier1` (some intermittent failures, which look unrelated and present in current master)

Yes, this was a  rare bug that hadn't got checked for years in HashMap tests. There's no reason not to backport.

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/325#issuecomment-1576542637

From shade at openjdk.org  Mon Jun  5 11:00:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Jun 2023 11:00:11 GMT
Subject: [jdk8u-dev] RFR: 8205399: Set node color on pinned
 HashMap.TreeNode deletion
In-Reply-To: <wswy3vrBJJbAWFfRtwC31ee-kd1YK_97zNJ6Gm1i18M=.4e69e06c-5b7b-4361-b4e8-dad3a9e48a1a@github.com>
References: <gAvuPhJpdk-tefQoLUfiqdoiqIsLFi9A7vayJVTK_QU=.c210b9c8-8a5b-4e61-8831-72ebc473e04a@github.com>
 <wswy3vrBJJbAWFfRtwC31ee-kd1YK_97zNJ6Gm1i18M=.4e69e06c-5b7b-4361-b4e8-dad3a9e48a1a@github.com>
Message-ID: <VRSfaM72YOfPajiYPMXAbiuzFvlJcU1y9bw07sPWylw=.8324bbe0-9f4f-4799-8f37-23253ae6e632@github.com>

On Mon, 5 Jun 2023 10:33:27 GMT, Doug Lea <dl at openjdk.org> wrote:

> Yes, this was a rare bug that hadn't got checked for years in HashMap tests. There's no reason not to backport.

Thank you!

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/325#issuecomment-1576571325

From duke at openjdk.org  Mon Jun  5 13:36:21 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Mon, 5 Jun 2023 13:36:21 GMT
Subject: [jdk8u-dev] RFR: 8179503: Java should support GET OCSP calls
Message-ID: <r_iAZi9QoV2UGdBs34dr_dhDqxCc98ahBMCrz4ZUBqc=.23f526ed-33bd-4b07-b9fd-6383750a694a@github.com>

Hi!

I would like to backport **[JDK-8179503: Java should support GET OCSP calls](https://bugs.openjdk.org/browse/JDK-8179503)** for parity with Oracle JDK.

Except the path suffling the following changes were done to original patch:

**`jdk/src/share/classes/sun/security/provider/certpath/OCSP.java`**
- still reads the response piece by piece using `InputStream.read()` method because `IOUtils.readExactlyNBytes()` is not available

**`jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java`**
- unsupported `List.of()`, `Set.of()`, `Map.of()` replaced with equivalents
- `algorithm` parameter dropped from instantiation `PKCS8EncodedKeySpec`

**`jdk/test/javax/net/ssl/templates/SSLSocketTemplate.java`**
- required `public static enum SSLSocketTemplate.Cert` copied from `11u`

Verification (amd64/20.04LTS): newly added `jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java`
Regression (amd64/20.04LTS): `jdk_security`

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

Commit messages:
 - Backport f5ee356540d7aa4a7663c0d5d74f5fdb0726b426

Changes: https://git.openjdk.org/jdk8u-dev/pull/330/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=330&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8179503
  Stats: 902 lines in 4 files changed: 858 ins; 27 del; 17 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/330.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/330/head:pull/330

PR: https://git.openjdk.org/jdk8u-dev/pull/330

From phh at openjdk.org  Mon Jun  5 19:11:07 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 5 Jun 2023 19:11:07 GMT
Subject: [jdk8u-dev] RFR: 8179503: Java should support GET OCSP calls
In-Reply-To: <r_iAZi9QoV2UGdBs34dr_dhDqxCc98ahBMCrz4ZUBqc=.23f526ed-33bd-4b07-b9fd-6383750a694a@github.com>
References: <r_iAZi9QoV2UGdBs34dr_dhDqxCc98ahBMCrz4ZUBqc=.23f526ed-33bd-4b07-b9fd-6383750a694a@github.com>
Message-ID: <22Xx8_9IJ5Sns2pCflqAYHqcqGivVMbskg4JumPhRy8=.507bc0f8-90cb-4a12-b832-4924bd1ee532@github.com>

On Mon, 5 Jun 2023 13:25:49 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> Hi!
> 
> I would like to backport **[JDK-8179503: Java should support GET OCSP calls](https://bugs.openjdk.org/browse/JDK-8179503)** for parity with Oracle JDK.
> 
> Except the path suffling the following changes were done to original patch:
> 
> **`jdk/src/share/classes/sun/security/provider/certpath/OCSP.java`**
> - still reads the response piece by piece using `InputStream.read()` method because `IOUtils.readExactlyNBytes()` is not available
> 
> **`jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java`**
> - unsupported `List.of()`, `Set.of()`, `Map.of()` replaced with equivalents
> - `algorithm` parameter dropped from instantiation `PKCS8EncodedKeySpec`
> 
> **`jdk/test/javax/net/ssl/templates/SSLSocketTemplate.java`**
> - required `public static enum SSLSocketTemplate.Cert` copied from `11u`
> 
> Verification (amd64/20.04LTS): newly added `jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java`
> Regression (amd64/20.04LTS): `jdk_security`

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk8u-dev/pull/330#pullrequestreview-1463215651

From duke at openjdk.org  Tue Jun  6 06:24:08 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Tue, 6 Jun 2023 06:24:08 GMT
Subject: [jdk8u-dev] RFR: 8179503: Java should support GET OCSP calls [v2]
In-Reply-To: <r_iAZi9QoV2UGdBs34dr_dhDqxCc98ahBMCrz4ZUBqc=.23f526ed-33bd-4b07-b9fd-6383750a694a@github.com>
References: <r_iAZi9QoV2UGdBs34dr_dhDqxCc98ahBMCrz4ZUBqc=.23f526ed-33bd-4b07-b9fd-6383750a694a@github.com>
Message-ID: <Yel_2OjQfqsgQW-vgVGZfSdlOGSbS1z-7UDGk7JCD9g=.5a9a5cb4-27bc-45d7-951e-fc743a1362bd@github.com>

> Hi!
> 
> I would like to backport **[JDK-8179503: Java should support GET OCSP calls](https://bugs.openjdk.org/browse/JDK-8179503)** for parity with Oracle JDK.
> 
> Except the path suffling the following changes were done to original patch:
> 
> **`jdk/src/share/classes/sun/security/provider/certpath/OCSP.java`**
> - still reads the response piece by piece using `InputStream.read()` method because `IOUtils.readExactlyNBytes()` is not available
> 
> **`jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java`**
> - unsupported `List.of()`, `Set.of()`, `Map.of()` replaced with equivalents
> - `algorithm` parameter dropped from instantiation `PKCS8EncodedKeySpec`
> 
> **`jdk/test/javax/net/ssl/templates/SSLSocketTemplate.java`**
> - required `public static enum SSLSocketTemplate.Cert` copied from `11u`
> 
> Verification (amd64/20.04LTS): newly added `jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java`
> Regression (amd64/20.04LTS): `jdk_security`

Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:

  restore lost newlines at the end of files

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/330/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/330/files/ed2d1b76..63ba22db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=330&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=330&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/330.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/330/head:pull/330

PR: https://git.openjdk.org/jdk8u-dev/pull/330

From duke at openjdk.org  Tue Jun  6 09:40:04 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Tue, 6 Jun 2023 09:40:04 GMT
Subject: [jdk8u-dev] RFR: 8274471: Add support for RSASSA-PSS in OCSP Response
Message-ID: <eCMuP9ka_XygWEP0wyWplqAtMnk6Wh0nAChdrYkhO8Q=.70ead652-7421-4e9a-945f-a2059eb47f82@github.com>

Hi!

I'd like to backport **[JDK-8274471: Add support for RSASSA-PSS in OCSP Response](https://bugs.openjdk.org/browse/JDK-8274471)** for parity with Oracle JDK.

The patch from `11u` applied with the following changes (except the path shuffling):

**`jdk/src/share/classes/sun/security/provider/certpath/OCSP.java`**
- `URLEncoder.encode()` accepts desired charset as a string, charset constants are not supported in `8`, so import of `java.nio.charset.StandardCharsets` also skipped
- resolved little baseline conflict

**`jdk/src/share/classes/sun/security/x509/AlgorithmId.java`**
- required `public static String getDefaultSigAlgForKey(PrivateKey k)` and `private static String ecStrength (int bitLength)` copied from `11`

Verification (amd64/20.04): `jdk/test/javax/net/ssl/Stapling/HttpsUrlConnClient.java` with new `RSASSA-PSS` case
Regression (amd64/20.04): `jdk_security`

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

Depends on: https://git.openjdk.org/jdk8u-dev/pull/330

Commit messages:
 - removing unwanted delta
 - Backport f63c4a832a1aea451f47aaf86d5361e970c6a28f

Changes: https://git.openjdk.org/jdk8u-dev/pull/331/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=331&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8274471
  Stats: 213 lines in 9 files changed: 142 ins; 40 del; 31 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/331.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/331/head:pull/331

PR: https://git.openjdk.org/jdk8u-dev/pull/331

From gdams at openjdk.org  Tue Jun  6 14:30:58 2023
From: gdams at openjdk.org (George Adams)
Date: Tue, 6 Jun 2023 14:30:58 GMT
Subject: [jdk8u-dev] RFR: 8193017: Import freetype sources into OpenJDK
 source tree [v4]
In-Reply-To: <3ii9h1EBSHStkQ6X5l0A4kFnVumho_wNDG8LwdSzSk8=.fd4fc87b-7c00-4a7d-8645-df4145e02c0e@github.com>
References: <XOBcBVye8WM8WNyj_6fQEk3oMPt7kgxyggcIf6MMk6E=.dcd2441e-2fb5-4b18-ab98-8e274b11c562@github.com>
 <0GHr4S0HzJRGkbPyQdB79OnrgmqwLE-1XM5oscR8r_Y=.b0329029-5602-4d09-beae-66d273496f29@github.com>
 <3ii9h1EBSHStkQ6X5l0A4kFnVumho_wNDG8LwdSzSk8=.fd4fc87b-7c00-4a7d-8645-df4145e02c0e@github.com>
Message-ID: <_VtitkeEhj6RJ7QWkH7-3qt1v6XcTQB6co3kmbLR3pY=.12724955-908e-4427-9a1c-6d9d6b78ae9b@github.com>

On Wed, 31 May 2023 17:23:41 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Good to see this being proposed. I was wondering what had happened to it.
> 
> How close is this to JDK-8193017? Were other changes necessary on top?
> 
> I'll do a comparison of the two patches when I get a chance.

it's reasonably close, the main difference is that the freetype source is located in `jdk/src/share/native/sun/awt/libfreetype/` rather than `jdk/src/share/native/libfreetype` to be consistent with other JDK8u sources. I also removed [freetype task](https://github.com/openjdk/jdk8u-dev/pull/318/commits/7eea8f2c331fe7555446e2d08ac54f10fb6ac31c) from the GitHub actions workflow.

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/318#issuecomment-1578873858

From phh at openjdk.org  Tue Jun  6 16:36:17 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 6 Jun 2023 16:36:17 GMT
Subject: [jdk8u-dev] RFR: 8205399: Set node color on pinned
 HashMap.TreeNode deletion
In-Reply-To: <gAvuPhJpdk-tefQoLUfiqdoiqIsLFi9A7vayJVTK_QU=.c210b9c8-8a5b-4e61-8831-72ebc473e04a@github.com>
References: <gAvuPhJpdk-tefQoLUfiqdoiqIsLFi9A7vayJVTK_QU=.c210b9c8-8a5b-4e61-8831-72ebc473e04a@github.com>
Message-ID: <atRaiQJeMOQ9MlAmiIjCVEKsnasRuMkg_E2OxwyOw8o=.37bd09e2-9e8b-4a22-b2c4-1ea178809ece@github.com>

On Tue, 30 May 2023 08:42:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the issue for details. It reproduces in 8u, which breaks applications that run with `-ea -esa` for extra safety. We have seen at least two in-production bug reports due to this.
> 
> The backport is not clean, because the test should reside in the different folder.
> 
> The verification barfs on discovering the red root, when it also discovers left/right child node is also red. This technically violates one of the basic properties of RB trees: a red node should not have red children. We can always change (sub-)root node color from red to black without violating RB properties, as the path to any descendant node would still have the same number of black nodes. AFAIU, leaving the (sub-)root red and the child red could potentially break something else. This is why I believe this backport is required and safe for 8u.
> 
> Additional testing:
>  - [x] Linux x86_64, new regression test fails without the patch, passes with it
>  - [x] Linux x86_64 `jdk_util`
>  - [x] Linux x86_64 fastdebug `tier1` (some intermittent failures, which look unrelated and present in current master)

File location change only.

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/325#issuecomment-1568440291

From duke at openjdk.org  Tue Jun  6 16:36:24 2023
From: duke at openjdk.org (yaqsun)
Date: Tue, 6 Jun 2023 16:36:24 GMT
Subject: [jdk8u-dev] RFR: 8159690: [TESTBUG] Mark headful tests with @key
 headful.
In-Reply-To: <38KGfdgNjyk4aAa_04Fcg3PUJmgKxrlErG_ybmEqRtE=.740ad6d8-c65c-422e-bd5f-71e51199f06b@github.com>
References: <38KGfdgNjyk4aAa_04Fcg3PUJmgKxrlErG_ybmEqRtE=.740ad6d8-c65c-422e-bd5f-71e51199f06b@github.com>
Message-ID: <8r16CJ8GvhvBrc5aRqbHq7KtIJ5CdX9n4aqOy5cI5Sk=.ec58657c-dfc2-46cf-85b2-cff93b68f216@github.com>

On Thu, 20 Apr 2023 03:04:25 GMT, yaqsun <duke at openjdk.org> wrote:

> The patch is not clean because the 31 tests are omitted, and because of various context differences. The only substantive change is the addition of @headful, which doesn?t affect running any of the tests.
> 
> There are 30 tests that were in the original patch that are not present in 8u. And there is 1 test that does not need to handle headful.

I am a Loongson employee

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/306#issuecomment-1515777140

From duke at openjdk.org  Wed Jun  7 10:27:15 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 7 Jun 2023 10:27:15 GMT
Subject: [jdk8u-dev] RFR: 8296343: CPVE thrown on missing content-length in
 OCSP response
Message-ID: <uaB82QwS7dzonrEJ6hW3GIGvCvvFXPKiK2J0W7ZQhgI=.95b0af6c-a775-4602-a93d-01011599e73b@github.com>

Hi!

Here is backport of **[JDK-8296343: CPVE thrown on missing content-length in OCSP response](https://bugs.openjdk.org/browse/JDK-8296343)**. The patch from `11u` applied with the following changes (except the path shuflling):

**`jdk/src/java.base/share/classes/sun/security/provider/certpath/OCSP.java`**
- reading response content from the input stream reworked due to `InputStream.readAllBytes()` and `IOUtils.readExactlyNBytes()` are not available in `8`

**`jdk/test/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java`**
- unsupported `List.of()` and `Set.of()` replaced with equivalent code
- added a newline at the end of the file

Verification (amd64/20.04): newly added `test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java` **FAILS**, will be fixed by backporting of [JDK-8300939](https://bugs.openjdk.org/browse/JDK-8300939)
Regression (amd64/20.04): `jdk_security`

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

Depends on: https://git.openjdk.org/jdk8u-dev/pull/331

Commit messages:
 - removing trailing whitespaces
 - cleaning up
 - properly fix
 - Backport 1a3cb8c5018bc016c2ad6b078e4abe13b39d151c

Changes: https://git.openjdk.org/jdk8u-dev/pull/332/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=332&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296343
  Stats: 432 lines in 9 files changed: 310 ins; 32 del; 90 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/332.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/332/head:pull/332

PR: https://git.openjdk.org/jdk8u-dev/pull/332

From duke at openjdk.org  Wed Jun  7 18:39:03 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 7 Jun 2023 18:39:03 GMT
Subject: [jdk8u-dev] RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors
Message-ID: <8UMMFqO6YtZ4zrh7iCzjdWVpD7xjNUk_oUWmb8D32UQ=.924222f9-249c-4a40-a15d-bf680a2c9925@github.com>

Hi!

Here is backport of [JDK-8300939](https://bugs.openjdk.org/browse/JDK-8300939) fixing `sun/security/provider/certpath/OCSP/OCSPNoContentLength.java` test. The patch from `11u` applied cleanly except the path shuffling

Verification/regression (amd64/LTS20.04): `jdk_security`

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

Depends on: https://git.openjdk.org/jdk8u-dev/pull/332

Commit messages:
 - remove trailing whitespaces
 - Backport 57d0a7f1b69214bd2de951c9907fe1321a66f3b8

Changes: https://git.openjdk.org/jdk8u-dev/pull/333/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=333&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300939
  Stats: 48 lines in 2 files changed: 34 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/333.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/333/head:pull/333

PR: https://git.openjdk.org/jdk8u-dev/pull/333

From duke at openjdk.org  Thu Jun  8 01:35:52 2023
From: duke at openjdk.org (yaqsun)
Date: Thu, 8 Jun 2023 01:35:52 GMT
Subject: [jdk8u-dev] RFR: 8159690: [TESTBUG] Mark headful tests with @key
 headful.
In-Reply-To: <38KGfdgNjyk4aAa_04Fcg3PUJmgKxrlErG_ybmEqRtE=.740ad6d8-c65c-422e-bd5f-71e51199f06b@github.com>
References: <38KGfdgNjyk4aAa_04Fcg3PUJmgKxrlErG_ybmEqRtE=.740ad6d8-c65c-422e-bd5f-71e51199f06b@github.com>
Message-ID: <HEOHjqy4JEhgAuvydzDZ3lFRuY2OxKnOenms6iC8wgw=.9f4c7b56-e043-4b8c-90cd-5e67df9efa8c@github.com>

On Thu, 20 Apr 2023 03:04:25 GMT, yaqsun <duke at openjdk.org> wrote:

> The patch is not clean because the 31 tests are omitted, and because of various context differences. The only substantive change is the addition of @headful, which doesn?t affect running any of the tests.
> 
> There are 30 tests that were in the original patch that are not present in 8u. And there is 1 test that does not need to handle headful.

I need help with progressing this pull request towards integration. 
Does patch need to break up? I look forward to the reply to the proposal of this patch. 
Thanks very much!

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/306#issuecomment-1581756224

From abakhtin at openjdk.org  Mon Jun 12 06:28:10 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 12 Jun 2023 06:28:10 GMT
Subject: [jdk8u-dev] RFR: 8200468: Port the native GSS-API bridge to Windows
Message-ID: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>

Hello,
I'd like to backport JDK-8200568: port the native GSS-API bridge to Windows to JDK8u
This is a prerequisite of the JDK-6722928 and JDK-8225687

The backport is not clean. I have to to make the following changes:
jdk/make/lib/SecurityLibraries.gmk
- Patched manually, just removed platform dependency
jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.c
- Clean merge except for copyright year
jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.h
- Visual Studio 2010-2012 doesn't provide inttypes.h so provide appropriate definitions the header file
- Manually updated copyright year
jdk/src/share/classes/sun/security/jgss/GSSManagerImpl.java
- Manually removed platform OS dependency

jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.c
- All changes applied manually because of JDK-8238388 already applied 
jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.h
- All changes applied clean 

jdk/test/sun/security/krb5/auto/BasicProc.java
- Manually added Windows platform dependency code
jdk/test/java/security/testlibrary/Proc.java
- Manually extended debug output

All related jtreg tests passed successfully on Windows

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

Commit messages:
 - Backport 0b6fbf50d24438117c33fa1a7d3633b792c99983

Changes: https://git.openjdk.org/jdk8u-dev/pull/335/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=335&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8200468
  Stats: 757 lines in 11 files changed: 342 ins; 309 del; 106 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/335.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/335/head:pull/335

PR: https://git.openjdk.org/jdk8u-dev/pull/335

From duke at openjdk.org  Tue Jun 13 02:54:58 2023
From: duke at openjdk.org (ktakakuri)
Date: Tue, 13 Jun 2023 02:54:58 GMT
Subject: [jdk8u-dev] RFR: 8154043: Fields not reachable anymore by tab-key,
 because of new tabbing behaviour of radio button groups.
Message-ID: <uS3pR-oynm7HF88V25wPugtA6mhPhDMLeLaQ-V2aWVA=.5a3ec1fe-7f63-4ce2-80c9-cd145022d928@github.com>

This is a backport of JDK-8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups.

Applying the JDK-8154043 fix as is will result in a regression of JDK-8182577.
The fix of JDK-8182577 adds an interface for JDK10, therefore this fix cannot be backported simply for JDK8u.
So, I propose to judge the buttonModel is an instance of DefaultButtonModel.

Testing:
java/awt
javax/swing
ButtonGroupLayoutTraversalTest.java
bug8033699.java
DefaultButtonModelCrashTest.java
on Windows x86_64

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

Commit messages:
 - Chmod ButtonGroupLayoutTraversalTest
 - Chmod DefaultButtonModelCrashTest
 - Fix the copyright year
 - Backport f3abf05b31893b9a066a436e2c4a587f8899ab10
 - Backport 8d81ec63b2bafc431cbb8572a3e45e76580ab46f

Changes: https://git.openjdk.org/jdk8u-dev/pull/285/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=285&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8154043
  Stats: 305 lines in 5 files changed: 270 ins; 15 del; 20 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/285.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/285/head:pull/285

PR: https://git.openjdk.org/jdk8u-dev/pull/285

From duke at openjdk.org  Tue Jun 13 02:54:59 2023
From: duke at openjdk.org (ktakakuri)
Date: Tue, 13 Jun 2023 02:54:59 GMT
Subject: [jdk8u-dev] RFR: 8154043: Fields not reachable anymore by tab-key, 
 because of new tabbing behaviour of radio button groups.
In-Reply-To: <uS3pR-oynm7HF88V25wPugtA6mhPhDMLeLaQ-V2aWVA=.5a3ec1fe-7f63-4ce2-80c9-cd145022d928@github.com>
References: <uS3pR-oynm7HF88V25wPugtA6mhPhDMLeLaQ-V2aWVA=.5a3ec1fe-7f63-4ce2-80c9-cd145022d928@github.com>
Message-ID: <DoPboqU9tIrmvDWl043RBA9ppD3wzmheHuy6eldGZAU=.da740e6d-2eef-4733-ad1b-c5707ddc532b@github.com>

On Wed, 15 Mar 2023 05:47:54 GMT, ktakakuri <duke at openjdk.org> wrote:

> This is a backport of JDK-8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups.
> 
> Applying the JDK-8154043 fix as is will result in a regression of JDK-8182577.
> The fix of JDK-8182577 adds an interface for JDK10, therefore this fix cannot be backported simply for JDK8u.
> So, I propose to judge the buttonModel is an instance of DefaultButtonModel.
> 
> Testing:
> java/awt
> javax/swing
> ButtonGroupLayoutTraversalTest.java
> bug8033699.java
> DefaultButtonModelCrashTest.java
> on Windows x86_64

Could someone please review this backport?

@mrserb 
I issued this PR in relation to https://github.com/openjdk/jdk8u-dev/pull/212.
Could you please review this backport?

Could someone please review this backport?

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/285#issuecomment-1491344724
PR Comment: https://git.openjdk.org/jdk8u-dev/pull/285#issuecomment-1504713120
PR Comment: https://git.openjdk.org/jdk8u-dev/pull/285#issuecomment-1571155449

From duke at openjdk.org  Tue Jun 13 06:58:31 2023
From: duke at openjdk.org (ktakakuri)
Date: Tue, 13 Jun 2023 06:58:31 GMT
Subject: [jdk8u-dev] RFR: 8154043: Fields not reachable anymore by tab-key, 
 because of new tabbing behaviour of radio button groups. [v2]
In-Reply-To: <uS3pR-oynm7HF88V25wPugtA6mhPhDMLeLaQ-V2aWVA=.5a3ec1fe-7f63-4ce2-80c9-cd145022d928@github.com>
References: <uS3pR-oynm7HF88V25wPugtA6mhPhDMLeLaQ-V2aWVA=.5a3ec1fe-7f63-4ce2-80c9-cd145022d928@github.com>
Message-ID: <oO-X7iCP0ZCjDQaiKMypFcV2_CZrM18iuLNALksOoV4=.16e3a06e-423c-4c95-9343-d469d7869467@github.com>

> This is a backport of JDK-8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups.
> 
> Applying the JDK-8154043 fix as is will result in a regression of JDK-8182577.
> The fix of JDK-8182577 adds an interface for JDK10, therefore this fix cannot be backported simply for JDK8u.
> So, I propose to judge the buttonModel is an instance of DefaultButtonModel.
> 
> Testing:
> java/awt
> javax/swing
> ButtonGroupLayoutTraversalTest.java
> bug8033699.java
> DefaultButtonModelCrashTest.java
> on Windows x86_64

ktakakuri 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 six additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8154043
 - Chmod ButtonGroupLayoutTraversalTest
 - Chmod DefaultButtonModelCrashTest
 - Fix the copyright year
 - Backport f3abf05b31893b9a066a436e2c4a587f8899ab10
 - Backport 8d81ec63b2bafc431cbb8572a3e45e76580ab46f

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/285/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/285/files/6a8e5fe6..cc8ef7ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=285&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=285&range=00-01

  Stats: 16730 lines in 168 files changed: 13866 ins; 778 del; 2086 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/285.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/285/head:pull/285

PR: https://git.openjdk.org/jdk8u-dev/pull/285

From zzambers at openjdk.org  Wed Jun 14 13:11:13 2023
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Wed, 14 Jun 2023 13:11:13 GMT
Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code
 consistent across platforms
Message-ID: <fvJPyW8RLXVysSDMSm7nYgpQ49-MMlaJqLOYb4j1TIc=.b9833199-848b-4800-97a4-0939325e45b5@github.com>

`java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`.  This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64.

Details:
This was discovered by examining one failing test (from tier1) present on aarch64 builds:
`test/serviceability/sa/jmap-hashcode/Test8028623.java`
Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings).

Fix:
Fixed by backporting very small portion of JDK-8141132.

Testing:
tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM)

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

Commit messages:
 - make hash_code consistent across platforms

Changes: https://git.openjdk.org/jdk8u-dev/pull/336/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=336&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310026
  Stats: 13 lines in 3 files changed: 10 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/336.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/336/head:pull/336

PR: https://git.openjdk.org/jdk8u-dev/pull/336

From phh at openjdk.org  Wed Jun 14 15:34:02 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 14 Jun 2023 15:34:02 GMT
Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code
 consistent across platforms
In-Reply-To: <fvJPyW8RLXVysSDMSm7nYgpQ49-MMlaJqLOYb4j1TIc=.b9833199-848b-4800-97a4-0939325e45b5@github.com>
References: <fvJPyW8RLXVysSDMSm7nYgpQ49-MMlaJqLOYb4j1TIc=.b9833199-848b-4800-97a4-0939325e45b5@github.com>
Message-ID: <VySU1Ei6opnzj8P6SqQvm2UsIqij9QUEfqrYDaMzSJo=.6f53b07a-6951-4387-8970-4cdcfaa340b3@github.com>

On Wed, 14 Jun 2023 13:02:53 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> `java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`.  This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64.
> 
> Details:
> This was discovered by examining one failing test (from tier1) present on aarch64 builds:
> `test/serviceability/sa/jmap-hashcode/Test8028623.java`
> Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings).
> 
> Fix:
> Fixed by backporting very small portion of JDK-8141132.
> 
> Testing:
> tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM)

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk8u-dev/pull/336#pullrequestreview-1479765847

From andrew at openjdk.org  Fri Jun 16 16:05:31 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 16 Jun 2023 16:05:31 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
Message-ID: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>

This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.

A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.

Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.

The detailed changes from the OpenJDK 10 patch are as follows:

1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change

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

Commit messages:
 - Backport cfe34ed89c4f6ef9a49dceef30da1e43b418b152

Changes: https://git.openjdk.org/jdk8u/pull/43/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u&pr=43&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8186801
  Stats: 144279 lines in 14 files changed: 130668 ins; 12678 del; 933 mod
  Patch: https://git.openjdk.org/jdk8u/pull/43.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u.git pull/43/head:pull/43

PR: https://git.openjdk.org/jdk8u/pull/43

From andrew at openjdk.org  Wed Jun 21 01:29:26 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 21 Jun 2023 01:29:26 GMT
Subject: [jdk8u] RFR: 8241311: Move some charset mapping tests from closed to
 open
Message-ID: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>

This is a second pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It adds more tests for character mappings, including GB18030.

The patch only introduces new tests, shuffled to the correct location. The one change to an existing file (`TestCharsetMapping.java`) is dropped, as it only adds an unneeded `@modules` line. Similarly, `@modules` is dropped from `CoderTest.java`, `ConverterTest.java` and `TestConv.java`.

The remaining change is to `MS950.c2b-irreversible`. 8u does not have [JDK-8232161](https://bugs.openjdk.org/browse/JDK-8232161), a change with an associated CSR that changed some of the mappings in the MS950 character set. We removed the four mappings from the test set, so as to match 8u's behaviour and avoid the `CoderTest.java` test from failing.

All `sun.nio.cs` tests pass with this patch applied.

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

Depends on: https://git.openjdk.org/jdk8u/pull/43

Commit messages:
 - Backport c809c9944400f7ee9bc296e40d6068273bde5912

Changes: https://git.openjdk.org/jdk8u/pull/44/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u&pr=44&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8241311
  Stats: 732192 lines in 166 files changed: 732192 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u/pull/44.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u.git pull/44/head:pull/44

PR: https://git.openjdk.org/jdk8u/pull/44

From stuefe at openjdk.org  Thu Jun 22 08:54:10 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Jun 2023 08:54:10 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
Message-ID: <OoHoTmgoYQ0QnW7Fa17FL6hKflyugegtutdqjpgoe6E=.121874c4-f9c0-432b-8260-80a40f73fbd1@github.com>

On Fri, 16 Jun 2023 15:55:38 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
> 
> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
> 
> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
> 
> The detailed changes from the OpenJDK 10 patch are as follows:
> 
> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change

Hi,

First review round. (Please note that formally, I am not jdk8u reviewer).

looked at the delta between two patches (yours and the JDK 10 one) and the delta on the file system between the frozen jdk10 repo and jdk8u-dev with your patch applied.

GB18030.map
 idendical after patch

Okay.

EUC_TW.map:
 - identical after patch
 - renamed uppercase in 8
 - I looked for remnants of lower case "euc_tw" but all I found was the historical alias.
 
Okay.
 
Looked at standard charset definitions. So, 8 (dbcs sbcs extsbcs) => 10 (charsets), and they changed the file format too.

Looked at the EBCDIC linefeed test. Arguably, you would not have to do this, or could do this in a separate patch. It has no bearing on the upcoming GB18030. But it's good to have. JDK-8186803 was a brainteaser, though, and it's annoying they did not do an individual patch.

Left to review is the Testcase itself. Will do after lunch.

Cheers, Thomas

jdk/test/sun/nio/cs/TestEBCDICLineFeed.java line 56:

> 54:                                   cs,  bb[0] & 0xff);
> 55:                 errs++;
> 56:             }

Took some thinking, but I think this is okay.

Are we sure the old (pre-8186803) translations are always "U+000A" -> 25? I am not sure, it looked to me like it could be either mapped to E15 or E25.

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

PR Review: https://git.openjdk.org/jdk8u/pull/43#pullrequestreview-1492697234
PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1238206969

From stuefe at openjdk.org  Thu Jun 22 11:31:09 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Jun 2023 11:31:09 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
Message-ID: <mMOmTLhMIHPcvzH-9szszxSiWo7m1rsQ_V-yxAg6H3E=.a077f9a3-308b-48a4-aa52-9eec50789fe4@github.com>

On Thu, 22 Jun 2023 11:15:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
>> 
>> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
>> 
>> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
>> 
>> The detailed changes from the OpenJDK 10 patch are as follows:
>> 
>> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
>> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
>> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
>> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
>> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
>> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
>> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
>> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
>> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
>> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change
>
> jdk/test/sun/nio/cs/TestCharsetMapping.java line 549:
> 
>> 547:             } else {
>> 548:                 cs.type = tokens[3];
>> 549:             }
> 
> Mentally parsing:
> 
> Format 1, dbcs:
> clzName  csName     hisName  dbtype    pkg               ascii   b1min  b1max  b2min b2max
> 
> hisname = 2
> pkgName = 4
> type = sbcs
> 
> Format 2, sbcs and extsbcs:
> clzName	csName		hisName		containASCII	pkg
> 
> hisname = 2
> pkgName = 4
> type = sbcs
> 
> Okay, checks out.

Could you add a small comment here, listing these two formats for easier code reading:


// dbcs format
// clzName csName hisName dbtype pkg ascii b1min b1max b2min b2max
// sbcs format
//  clzName csName hisName containASCII pkg


?

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

PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1238389620

From stuefe at openjdk.org  Thu Jun 22 11:31:11 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Jun 2023 11:31:11 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <mMOmTLhMIHPcvzH-9szszxSiWo7m1rsQ_V-yxAg6H3E=.a077f9a3-308b-48a4-aa52-9eec50789fe4@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
 <mMOmTLhMIHPcvzH-9szszxSiWo7m1rsQ_V-yxAg6H3E=.a077f9a3-308b-48a4-aa52-9eec50789fe4@github.com>
Message-ID: <6cQS6zZ8sH8NPK9QOX_wWdfEK9exggEEgttlQwvU0yg=.bb74b929-b353-499a-b3b9-3e47956749cc@github.com>

On Thu, 22 Jun 2023 11:22:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> jdk/test/sun/nio/cs/TestCharsetMapping.java line 549:
>> 
>>> 547:             } else {
>>> 548:                 cs.type = tokens[3];
>>> 549:             }
>> 
>> Mentally parsing:
>> 
>> Format 1, dbcs:
>> clzName  csName     hisName  dbtype    pkg               ascii   b1min  b1max  b2min b2max
>> 
>> hisname = 2
>> pkgName = 4
>> type = sbcs
>> 
>> Format 2, sbcs and extsbcs:
>> clzName	csName		hisName		containASCII	pkg
>> 
>> hisname = 2
>> pkgName = 4
>> type = sbcs
>> 
>> Okay, checks out.
>
> Could you add a small comment here, listing these two formats for easier code reading:
> 
> 
> // dbcs format
> // clzName csName hisName dbtype pkg ascii b1min b1max b2min b2max
> // sbcs format
> //  clzName csName hisName containASCII pkg
> 
> 
> ?

Maybe also some sanity tests:
- pkgname to start with "sun.nio"
- type one of "basic ebcdic euc_sim dbcsonly sbcs"

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

PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1238392147

From stuefe at openjdk.org  Thu Jun 22 11:31:08 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Jun 2023 11:31:08 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
Message-ID: <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>

On Fri, 16 Jun 2023 15:55:38 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
> 
> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
> 
> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
> 
> The detailed changes from the OpenJDK 10 patch are as follows:
> 
> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change

Second review round. Looked at TestCharSetMappings exclusively.

Most of my remarks are centered on code readability. 

My suggestion would be to test this test:

- build JDK and let it generate its charset
- then modify various *.map files and the charset definitions and check if the jtreg test picks up the changes as errors.

Unfortunately, I have no idea how to automate such tests, but as a sanity test that should be fine.

jdk/test/sun/nio/cs/TestCharsetMapping.java line 125:

> 123:     // 8u does not have JDK-8186803 so leHackIBM is true for
> 124:     // IBM1140-1149 charsets that map U+000A to 0x25.
> 125:     private boolean leHackIBM = false;

Can we give this a slightly better name? (I first thought le was leetspeak  pronoun :)

proposal: ebcdicLFHack or IBM114xLFHack or similar

jdk/test/sun/nio/cs/TestCharsetMapping.java line 477:

> 475:             if (csName.endsWith("_Solaris") ||
> 476:                 csName.endsWith("_MS5022X") ||
> 477:                 csName.endsWith("_MS932")) {

I would probably move this to the `charsets()` parsing function. To have all the code that deals with different data formats between 8 and later versions in one place.

Also, why the suffix solution? Easier to understand would be just listing the affected 5 charsets by full name, that way one can directly compare with later versions of the charsets file.

jdk/test/sun/nio/cs/TestCharsetMapping.java line 542:

> 540:                 continue;
> 541:             }
> 542:             CharsetInfo cs = new CharsetInfo(tokens[1], tokens[0]);

Small nit, could you add comments to the constructor args like this:

new CharsetInfo(/*csName*/ tokens[1], /*clzName*/ tokens[0]);


(We are different from the JDK 10 version anyway in this hunk)

jdk/test/sun/nio/cs/TestCharsetMapping.java line 549:

> 547:             } else {
> 548:                 cs.type = tokens[3];
> 549:             }

Mentally parsing:

Format 1, dbcs:
clzName  csName     hisName  dbtype    pkg               ascii   b1min  b1max  b2min b2max

hisname = 2
pkgName = 4
type = sbcs

Format 2, sbcs and extsbcs:
clzName	csName		hisName		containASCII	pkg

hisname = 2
pkgName = 4
type = sbcs

Okay, checks out.

jdk/test/sun/nio/cs/TestCharsetMapping.java line 576:

> 574:         Set<CharsetInfo> charsets = charsets(dir.resolve("sbcs"), true);
> 575:         charsets.addAll(charsets(dir.resolve("extsbcs"), true));
> 576:         charsets.addAll(charsets(dir.resolve("dbcs"), false));

small nit, can you reorder and parse dbcs first, then comment, then the other two? So its clear that dbcs is excluded from comment

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

Changes requested by stuefe (Committer).

PR Review: https://git.openjdk.org/jdk8u/pull/43#pullrequestreview-1492894268
PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1238335801
PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1238368942
PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1238384200
PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1238382586
PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1238381122

From sgehwolf at openjdk.org  Thu Jun 22 13:55:14 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 22 Jun 2023 13:55:14 GMT
Subject: [jdk8u] RFR: 8241311: Move some charset mapping tests from closed
 to open
In-Reply-To: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>
References: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>
Message-ID: <mHSJDAoORcYONHJgbVCzNMnwQWYvDJsf8wRJQBHTALQ=.2a27da07-85a6-4df1-abef-1e75c082ff37@github.com>

On Wed, 21 Jun 2023 01:18:23 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This is a second pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It adds more tests for character mappings, including GB18030.
> 
> The patch only introduces new tests, shuffled to the correct location. The one change to an existing file (`TestCharsetMapping.java`) is dropped, as it only adds an unneeded `@modules` line. Similarly, `@modules` is dropped from `CoderTest.java`, `ConverterTest.java` and `TestConv.java`.
> 
> The remaining change is to `MS950.c2b-irreversible`. 8u does not have [JDK-8232161](https://bugs.openjdk.org/browse/JDK-8232161), a change with an associated CSR that changed some of the mappings in the MS950 character set. We removed the four mappings from the test set, so as to match 8u's behaviour and avoid the `CoderTest.java` test from failing.
> 
> All `sun.nio.cs` tests pass with this patch applied.

OK.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk8u/pull/44#pullrequestreview-1493251550

From sgehwolf at openjdk.org  Thu Jun 22 16:39:09 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 22 Jun 2023 16:39:09 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
Message-ID: <J5IXMU2eiqwDlinsQ9c-fFG-NBy0Vuhao4yncrAmKJQ=.383802be-ffd1-4b57-b71a-7ae3203033de@github.com>

On Fri, 16 Jun 2023 15:55:38 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
> 
> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
> 
> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
> 
> The detailed changes from the OpenJDK 10 patch are as follows:
> 
> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change

My understanding is that this patch has no bearing on the product code (test only) since none of the added mappings are referenced in either of those `dbcs`, `sdcs` or `extsbcs` files. The main purpose of it would be to have the `GB18030.map` file available to move it to the cs test files used in `JDK-8301119` by `CoderTest.java`.

On that ground and by virtue of not introducing too much divergence from 11 code, this seems OK to me.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk8u/pull/43#pullrequestreview-1493616719

From phh at openjdk.org  Thu Jun 22 22:23:09 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 22 Jun 2023 22:23:09 GMT
Subject: [jdk8u-dev] RFR: 8309143: [8u] fix archiving inconsistencies in
 GHA
In-Reply-To: <shwrsX56Hp1y9BW50YbPEoxSCjvPDAzFvoHPq63JgiU=.2df8d5fa-3c50-4816-99f8-c57b958e904b@github.com>
References: <shwrsX56Hp1y9BW50YbPEoxSCjvPDAzFvoHPq63JgiU=.2df8d5fa-3c50-4816-99f8-c57b958e904b@github.com>
Message-ID: <b7cMpd17r4_IBQ94m_UCPXdAguqmiXX3KzHztZdw-hc=.92324dd0-b0d2-4b8e-bea5-c27089f1b2a7@github.com>

On Tue, 30 May 2023 22:10:44 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> There are few inconsistencies when it comes to packing/unpacking of JDK in GHA. Tar archives are not gzipped despite use `.tar.gz` extension. Zip JDK archives on windows are being extracted by tar. These inconsistencies do not cause failures, but better to fix them. Affects JDK 8 only.

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk8u-dev/pull/327#pullrequestreview-1494071151

From andrew at openjdk.org  Fri Jun 23 01:46:23 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 01:46:23 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
Message-ID: <iTP8fNZDLRo1eoSjCYmk6rSvoL2lO8XWbzVCWHmEkpU=.1015b3bb-509a-42f0-bbd3-51e0eb1a579c@github.com>

This is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`.

With the preceding test changes in place (#43 and #44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the `SPI.java` generator tool moves into `ExtendedCharsets.java` in the class library, as the file is not auto-generated in 8u. The change to `StandardCharsets.java.template` lands in `AbstractCharsetProvider.java`.

In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allows `IS_2000` to be package-private to `sun.nio.cs`, whereas we need to make it public in `sun.nio.cs.ext` so it can be accessed from `sun.nio.cs`.

To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to awk.

The only adjustment to `GB18030.java`, other than copyright headers, is to replace the use of `jdk.internal.misc.VM.initLevel` with that of `sun.misc.VM.isBooted`. 8u does not provide as fine-grained access to the initialisation status as 11u, and so may force the use of the 2022 standard until a later stage in the bootup (`BOOTED` is `initLevel() = 4` in 11u).

With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are frequent issues in backports, so I used this as an opportunity to introduce a full set of equivalents into the test library. It should now be possible to just rewrite `Set.of` to `Utils.setOf` and `List.of` to `Utils.listOf`. The returned collections are expected to be unmodifiable, not contain `null` and (in the case of sets) not contain duplicates. Simple replacement with a newly constructed `ArrayList` or `HashSet` would not ensure this. While this test does not rely on this, others may, so it seemed worth providing a closer replacement for use in future backports.

All `sun.nio.cs` tests pass with this patch applied.

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

Depends on: https://git.openjdk.org/jdk8u/pull/44

Commit messages:
 - Backport 5c4e744dabcf7785c35168db5d0458ccebfd41e6

Changes: https://git.openjdk.org/jdk8u/pull/45/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u&pr=45&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8186801
  Stats: 1019 lines in 9 files changed: 909 ins; 10 del; 100 mod
  Patch: https://git.openjdk.org/jdk8u/pull/45.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u.git pull/45/head:pull/45

PR: https://git.openjdk.org/jdk8u/pull/45

From andrew at openjdk.org  Fri Jun 23 01:51:08 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 01:51:08 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <OoHoTmgoYQ0QnW7Fa17FL6hKflyugegtutdqjpgoe6E=.121874c4-f9c0-432b-8260-80a40f73fbd1@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <OoHoTmgoYQ0QnW7Fa17FL6hKflyugegtutdqjpgoe6E=.121874c4-f9c0-432b-8260-80a40f73fbd1@github.com>
Message-ID: <PtddzLvPC3p8pVwNfvxReg_VrmGZ1stz54hHfSua-k0=.12016e16-f063-44ac-82d6-f808f824f10c@github.com>

On Thu, 22 Jun 2023 08:45:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
>> 
>> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
>> 
>> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
>> 
>> The detailed changes from the OpenJDK 10 patch are as follows:
>> 
>> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
>> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
>> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
>> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
>> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
>> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
>> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
>> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
>> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
>> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change
>
> jdk/test/sun/nio/cs/TestEBCDICLineFeed.java line 56:
> 
>> 54:                                   cs,  bb[0] & 0xff);
>> 55:                 errs++;
>> 56:             }
> 
> Took some thinking, but I think this is okay.
> 
> Are we sure the old (pre-8186803) translations are always "U+000A" -> 25? I am not sure, it looked to me like it could be either mapped to E15 or E25.

The changes I've made to detect IBM0114x were necessary to get the test to pass. Prior to that, it was failing because those character sets were producing 0x25.

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

PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1239203978

From t.glaser at tarent.de  Fri Jun 23 02:00:28 2023
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Fri, 23 Jun 2023 04:00:28 +0200 (CEST)
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <PtddzLvPC3p8pVwNfvxReg_VrmGZ1stz54hHfSua-k0=.12016e16-f063-44ac-82d6-f808f824f10c@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <OoHoTmgoYQ0QnW7Fa17FL6hKflyugegtutdqjpgoe6E=.121874c4-f9c0-432b-8260-80a40f73fbd1@github.com>
 <PtddzLvPC3p8pVwNfvxReg_VrmGZ1stz54hHfSua-k0=.12016e16-f063-44ac-82d6-f808f824f10c@github.com>
Message-ID: <8ab34972-ca3-4874-7dbc-6dbc457e2f75@tarent.de>

On Fri, 23 Jun 2023, Andrew John Hughes wrote:

>> Are we sure the old (pre-8186803) translations are always "U+000A" ->
>> 25? I am not sure, it looked to me like it could be either mapped to
>> E15 or E25.

In case this data point helps: for the porting of mksh to EBCDIC
systems, we have X'15' for U+000A whereas X'25' maps to U+0085,
so this is sort of expected for unix-y things.

bye,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From andrew at openjdk.org  Fri Jun 23 02:04:08 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 02:04:08 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
Message-ID: <wdRNyU9MiJR65qeVMTSjfKQS3QYNszitZv7bMNImSEk=.fe7fbec0-d324-43e0-ab9a-688db19d03e7@github.com>

On Thu, 22 Jun 2023 10:34:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
>> 
>> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
>> 
>> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
>> 
>> The detailed changes from the OpenJDK 10 patch are as follows:
>> 
>> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
>> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
>> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
>> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
>> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
>> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
>> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
>> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
>> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
>> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change
>
> jdk/test/sun/nio/cs/TestCharsetMapping.java line 125:
> 
>> 123:     // 8u does not have JDK-8186803 so leHackIBM is true for
>> 124:     // IBM1140-1149 charsets that map U+000A to 0x25.
>> 125:     private boolean leHackIBM = false;
> 
> Can we give this a slightly better name? (I first thought le was leetspeak  pronoun :)
> 
> proposal: ebcdicLFHack or IBM114xLFHack or similar

Yeah, not the best name in retrospect. It was starting to read to me as if it was some form of broken French :)

I've switched to `ebcdicLFHack`.

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

PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1239246598

From andrew at openjdk.org  Fri Jun 23 02:04:10 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 02:04:10 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <PtddzLvPC3p8pVwNfvxReg_VrmGZ1stz54hHfSua-k0=.12016e16-f063-44ac-82d6-f808f824f10c@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <OoHoTmgoYQ0QnW7Fa17FL6hKflyugegtutdqjpgoe6E=.121874c4-f9c0-432b-8260-80a40f73fbd1@github.com>
 <PtddzLvPC3p8pVwNfvxReg_VrmGZ1stz54hHfSua-k0=.12016e16-f063-44ac-82d6-f808f824f10c@github.com>
Message-ID: <wS5B3WC-yw-cL5IWKyq8nMHaB3tRZqM408oBjo3fW4E=.0a6efeeb-6736-4299-aa30-b7f2819c0522@github.com>

On Fri, 23 Jun 2023 01:48:06 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> jdk/test/sun/nio/cs/TestEBCDICLineFeed.java line 56:
>> 
>>> 54:                                   cs,  bb[0] & 0xff);
>>> 55:                 errs++;
>>> 56:             }
>> 
>> Took some thinking, but I think this is okay.
>> 
>> Are we sure the old (pre-8186803) translations are always "U+000A" -> 25? I am not sure, it looked to me like it could be either mapped to E15 or E25.
>
> The changes I've made to detect IBM0114x were necessary to get the test to pass. Prior to that, it was failing because those character sets were producing 0x25.

As to including this test, it seemed appropriate. The intention is for this backport to add tests to ensure the status quo, rather than change any behaviour (as Severin notes). So this version of `TestEBCDICLineFeed.java` is ensuring that the 8186803 bug is present in 8u.

I agree about it being a bit of a brainteaser. It was a pain to extract the 8186803 changes from the rest and I was surprised that even removing the `.nr` file additions still led to a mismatch in `TestCharsetMappings`, fixed by the hack. As you've seen, the IBM114x maps map both 0x15 and 0x25 to U+000a, so going the other way can produce either. In `TestCharsetMappings`, both are produced but 0x15 succeeds without the hack (i.e. `eq` is already true). As far as I can work out. the `.nr` files (no round trip) stop the 0x25 conversion happening, so only 0x15 occurs.

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

PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1239245738

From andrew at openjdk.org  Fri Jun 23 02:14:06 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 02:14:06 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
Message-ID: <WW4ixMUix_NlgTQjKPyVVrvGTD3VQzmfBKBbwool5WU=.452f4a5b-0882-4b39-85d0-432a414a091a@github.com>

On Thu, 22 Jun 2023 11:01:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
>> 
>> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
>> 
>> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
>> 
>> The detailed changes from the OpenJDK 10 patch are as follows:
>> 
>> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
>> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
>> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
>> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
>> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
>> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
>> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
>> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
>> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
>> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change
>
> jdk/test/sun/nio/cs/TestCharsetMapping.java line 477:
> 
>> 475:             if (csName.endsWith("_Solaris") ||
>> 476:                 csName.endsWith("_MS5022X") ||
>> 477:                 csName.endsWith("_MS932")) {
> 
> I would probably move this to the `charsets()` parsing function. To have all the code that deals with different data formats between 8 and later versions in one place.
> 
> Also, why the suffix solution? Easier to understand would be just listing the affected 5 charsets by full name, that way one can directly compare with later versions of the charsets file.

I think just laziness :) I noticed there were two common suffixes in use so could cut it down to three checks

I agree that making it explicit is clearer though and also avoids accidentally picking up any later additions with the same suffixes (though I think that's very unlikely to happen)

> jdk/test/sun/nio/cs/TestCharsetMapping.java line 576:
> 
>> 574:         Set<CharsetInfo> charsets = charsets(dir.resolve("sbcs"), true);
>> 575:         charsets.addAll(charsets(dir.resolve("extsbcs"), true));
>> 576:         charsets.addAll(charsets(dir.resolve("dbcs"), false));
> 
> small nit, can you reorder and parse dbcs first, then comment, then the other two? So its clear that dbcs is excluded from comment

Sure. I originally expected they'd need a separate method altogether and I guess I didn't clean it up completely when I realised I could simplify it to just a boolean.

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

PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1239250082
PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1239250942

From andrew at openjdk.org  Fri Jun 23 02:27:10 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 02:27:10 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
Message-ID: <tb7MaQAfVOQLdtNV5PjS13iUw7EFmKKHWItI2p5XQS4=.e49cdf58-69e7-4cbd-ae7b-1b16195186a6@github.com>

On Thu, 22 Jun 2023 11:16:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
>> 
>> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
>> 
>> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
>> 
>> The detailed changes from the OpenJDK 10 patch are as follows:
>> 
>> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
>> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
>> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
>> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
>> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
>> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
>> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
>> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
>> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
>> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change
>
> jdk/test/sun/nio/cs/TestCharsetMapping.java line 542:
> 
>> 540:                 continue;
>> 541:             }
>> 542:             CharsetInfo cs = new CharsetInfo(tokens[1], tokens[0]);
> 
> Small nit, could you add comments to the constructor args like this:
> 
> new CharsetInfo(/*csName*/ tokens[1], /*clzName*/ tokens[0]);
> 
> 
> (We are different from the JDK 10 version anyway in this hunk)

Done, though it should also now be clearer from having the format in there.

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

PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1239255845

From andrew at openjdk.org  Fri Jun 23 02:27:12 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 02:27:12 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <6cQS6zZ8sH8NPK9QOX_wWdfEK9exggEEgttlQwvU0yg=.bb74b929-b353-499a-b3b9-3e47956749cc@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
 <mMOmTLhMIHPcvzH-9szszxSiWo7m1rsQ_V-yxAg6H3E=.a077f9a3-308b-48a4-aa52-9eec50789fe4@github.com>
 <6cQS6zZ8sH8NPK9QOX_wWdfEK9exggEEgttlQwvU0yg=.bb74b929-b353-499a-b3b9-3e47956749cc@github.com>
Message-ID: <tctFj3QdfUOU6napXyBniIVLRVj5iqymvwKT7lVkNHI=.de5723e4-6538-411f-9e0d-0a37d0ab9117@github.com>

On Thu, 22 Jun 2023 11:25:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Could you add a small comment here, listing these two formats for easier code reading:
>> 
>> 
>> // dbcs format
>> // clzName csName hisName dbtype pkg ascii b1min b1max b2min b2max
>> // sbcs format
>> //  clzName csName hisName containASCII pkg
>> 
>> 
>> ?
>
> Maybe also some sanity tests:
> - pkgname to start with "sun.nio"
> - type one of "basic ebcdic euc_sim dbcsonly sbcs"

The comment is a good idea. I was looking at that line in the mapping file as I was writing the code, and it would be good to have it in there directly.

I think the sanity tests are something we should add in mainline first and backport, as both would apply there too (though mainline has a few more types).

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

PR Review Comment: https://git.openjdk.org/jdk8u/pull/43#discussion_r1239255377

From andrew at openjdk.org  Fri Jun 23 02:46:50 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 02:46:50 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time) [v2]
In-Reply-To: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
Message-ID: <VdW8MJUH4PVugxkG1MfEQmqo4YtpPjKHH5YaZEYBv6k=.bab627f0-79a4-4a21-aeaa-214336ab7d4f@github.com>

> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
> 
> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
> 
> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
> 
> The detailed changes from the OpenJDK 10 patch are as follows:
> 
> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change

Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:

  Review changes:
  
  * Rename leHackIBM => ebcdicLFHack
  * Move internal handling to charsets method
  * Use full class name for internal check
  * Add field headers in comments to ease code readability
  * Parse dbcs first to aid code readability
  * Drop redundant @modules from  TestEBCDLineFeed

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

Changes:
  - all: https://git.openjdk.org/jdk8u/pull/43/files
  - new: https://git.openjdk.org/jdk8u/pull/43/files/fff9059e..9c9319fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u&pr=43&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u&pr=43&range=00-01

  Stats: 26 lines in 2 files changed: 13 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk8u/pull/43.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u.git pull/43/head:pull/43

PR: https://git.openjdk.org/jdk8u/pull/43

From andrew at openjdk.org  Fri Jun 23 02:55:09 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 02:55:09 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time) [v2]
In-Reply-To: <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <xOvbOC0CYMSEkctjPKtk0mWq1PbzDhwNZk-AtUbPYKo=.31e2c2c9-4fcb-49e1-b6fa-2155da3d0fde@github.com>
Message-ID: <iLXDYPApZhVYLHppCY-mu2AQr8lqr_TkCF_F1HxKKEs=.9e7a7219-5dc9-4ecd-8b18-e06d4535e5d3@github.com>

On Thu, 22 Jun 2023 11:28:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> My suggestion would be to test this test:
> 
>     * build JDK and let it generate its charset
> 
>     * then modify various *.map files and the charset definitions and check if the jtreg test picks up the changes as errors.
> 
> 
> Unfortunately, I have no idea how to automate such tests, but as a sanity test that should be fine.

Confirmed by altering the IBM01140 map:

~~~
$ git diff
diff --git a/jdk/make/data/charsetmapping/IBM1140.map b/jdk/make/data/charsetmapping/IBM1140.map
index 6a79f6cba5a..0b2f6658bcd 100644
--- a/jdk/make/data/charsetmapping/IBM1140.map
+++ b/jdk/make/data/charsetmapping/IBM1140.map
@@ -240,7 +240,7 @@
 0xee   U+00d3
 0xef   U+00d5
 0xf0   U+0030
-0xf1   U+0031
+0xf1   U+0131
 0xf2   U+0032
 0xf3   U+0033
 0xf4   U+0034

testing: IBM01140
  string de/encoding
    new String()
      Error: new String() failed
    String.getBytes()
  1 byte/char
    decode
      Error: f1 --> U+0031, expected U+0131
    decode (direct)
      Error: f1 --> U+0031, expected U+0131
  1 byte/char
    encode
U+000a --> 25 allowed for IBM0114x
      Error: U+0131 --> 3f, expected f1
    encode (direct)
U+000a --> 25 allowed for IBM0114x
      Error: U+0131 --> 3f, expected f1

...

JavaTest Message: Test threw exception: java.lang.Exception: Errors detected in 1 charset
~~~

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

PR Comment: https://git.openjdk.org/jdk8u/pull/43#issuecomment-1603615664

From andrew at openjdk.org  Fri Jun 23 02:59:04 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 02:59:04 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time) [v2]
In-Reply-To: <VdW8MJUH4PVugxkG1MfEQmqo4YtpPjKHH5YaZEYBv6k=.bab627f0-79a4-4a21-aeaa-214336ab7d4f@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <VdW8MJUH4PVugxkG1MfEQmqo4YtpPjKHH5YaZEYBv6k=.bab627f0-79a4-4a21-aeaa-214336ab7d4f@github.com>
Message-ID: <OwxA_ssnqHZA5cE0QikVJtLtyZri6K_P7hCgr24eyKM=.7f77e07b-122e-450c-ae49-ca6d868afb3e@github.com>

On Fri, 23 Jun 2023 02:46:50 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
>> 
>> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
>> 
>> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
>> 
>> The detailed changes from the OpenJDK 10 patch are as follows:
>> 
>> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
>> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
>> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
>> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
>> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
>> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
>> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
>> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
>> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
>> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change
>
> Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review changes:
>   
>   * Rename leHackIBM => ebcdicLFHack
>   * Move internal handling to charsets method
>   * Use full class name for internal check
>   * Add field headers in comments to ease code readability
>   * Parse dbcs first to aid code readability
>   * Drop redundant @modules from  TestEBCDLineFeed

I've added `jdk8u-critical-request` to the bug for this and the follow-on JDK-8241311 now they're reviewed.
#45 is open for the final change which implements GB18030-2022.

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

PR Comment: https://git.openjdk.org/jdk8u/pull/43#issuecomment-1603617681

From stuefe at openjdk.org  Fri Jun 23 03:58:07 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 23 Jun 2023 03:58:07 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time) [v2]
In-Reply-To: <VdW8MJUH4PVugxkG1MfEQmqo4YtpPjKHH5YaZEYBv6k=.bab627f0-79a4-4a21-aeaa-214336ab7d4f@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <VdW8MJUH4PVugxkG1MfEQmqo4YtpPjKHH5YaZEYBv6k=.bab627f0-79a4-4a21-aeaa-214336ab7d4f@github.com>
Message-ID: <mLDSI3oUtYOj1NUTyykJcQiGtHia41BbJ2DyXVZ_yQE=.f0e9c455-037d-4f7e-8c78-41ef117ebc4c@github.com>

On Fri, 23 Jun 2023 02:46:50 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
>> 
>> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
>> 
>> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
>> 
>> The detailed changes from the OpenJDK 10 patch are as follows:
>> 
>> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
>> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
>> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
>> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
>> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
>> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
>> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
>> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
>> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
>> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change
>
> Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review changes:
>   
>   * Rename leHackIBM => ebcdicLFHack
>   * Move internal handling to charsets method
>   * Use full class name for internal check
>   * Add field headers in comments to ease code readability
>   * Parse dbcs first to aid code readability
>   * Drop redundant @modules from  TestEBCDLineFeed

Looks good to me!

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

Marked as reviewed by stuefe (Committer).

PR Review: https://git.openjdk.org/jdk8u/pull/43#pullrequestreview-1494353597

From sgehwolf at openjdk.org  Fri Jun 23 08:54:09 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 23 Jun 2023 08:54:09 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time) [v2]
In-Reply-To: <mLDSI3oUtYOj1NUTyykJcQiGtHia41BbJ2DyXVZ_yQE=.f0e9c455-037d-4f7e-8c78-41ef117ebc4c@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <VdW8MJUH4PVugxkG1MfEQmqo4YtpPjKHH5YaZEYBv6k=.bab627f0-79a4-4a21-aeaa-214336ab7d4f@github.com>
 <mLDSI3oUtYOj1NUTyykJcQiGtHia41BbJ2DyXVZ_yQE=.f0e9c455-037d-4f7e-8c78-41ef117ebc4c@github.com>
Message-ID: <9_A-1s1AjumXSvUTWisXTeUBCcudEQ8aZEACe0TToDc=.de00ea6c-43d1-4471-b855-a4ae46ed373a@github.com>

On Fri, 23 Jun 2023 03:55:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Looks good to me!

Thanks for helping out on the review!

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

PR Comment: https://git.openjdk.org/jdk8u/pull/43#issuecomment-1603950794

From andrew at openjdk.org  Fri Jun 23 09:51:09 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 09:51:09 GMT
Subject: [jdk8u] RFR: 8186801: Add regression test to test mapping based
 charsets (generated at build time) [v2]
In-Reply-To: <VdW8MJUH4PVugxkG1MfEQmqo4YtpPjKHH5YaZEYBv6k=.bab627f0-79a4-4a21-aeaa-214336ab7d4f@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
 <VdW8MJUH4PVugxkG1MfEQmqo4YtpPjKHH5YaZEYBv6k=.bab627f0-79a4-4a21-aeaa-214336ab7d4f@github.com>
Message-ID: <yEKTB4Pgj94eiWJAfXhnyoGE08n8ZkCSD2quqK6PMng=.6a410371-8e1f-4d27-8623-10b19a78b0c2@github.com>

On Fri, 23 Jun 2023 02:46:50 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
>> 
>> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
>> 
>> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
>> 
>> The detailed changes from the OpenJDK 10 patch are as follows:
>> 
>> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
>> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
>> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
>> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
>> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
>> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
>> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
>> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
>> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
>> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change
>
> Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review changes:
>   
>   * Rename leHackIBM => ebcdicLFHack
>   * Move internal handling to charsets method
>   * Use full class name for internal check
>   * Add field headers in comments to ease code readability
>   * Parse dbcs first to aid code readability
>   * Drop redundant @modules from  TestEBCDLineFeed

Thanks both. I see `jdk8u-critical-yes` for this one, so integrating now.

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

PR Comment: https://git.openjdk.org/jdk8u/pull/43#issuecomment-1604025833

From andrew at openjdk.org  Fri Jun 23 09:54:15 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 09:54:15 GMT
Subject: [jdk8u] Integrated: 8186801: Add regression test to test mapping based
 charsets (generated at build time)
In-Reply-To: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
References: <QHxGBOOOMRmREoNbxb_J2uC7yQ6gPoJDVEuxC8860ts=.a1fbe53c-cdd3-4572-9b48-be2e1201f7bb@github.com>
Message-ID: <qvBr_9rpUr3vR_KfrCTJDxRNQVCJZnleWo_EUUXsWdA=.30e1f5f8-cfdd-4794-8cc0-8fe593deabf1@github.com>

On Fri, 16 Jun 2023 15:55:38 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This is a pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It introduces `GB18030.map`, containing the character mappings for GB18030, and tests to verify the correct mappings happen at run-time.
> 
> A number of changes were necessary for 8u. One main reason was the inclusion of [JDK-8186803](https://bugs.openjdk.org/browse/JDK-8186803) "Update Cp1140-Cp1149 EBEDIC euro charset to map \u000A to EBCDIC 0x15" as part of this fix in OpenJDK 10+. I have removed these changes in the 8u version so as to avoid making potentially incompatible library changes and focus on testing the current character mappings in 8u.
> 
> Another is that the character set data is spread across three files - `dbcs`, `sbcs` and `extsbcs` - in 8u, whereas it was amalgamated into a single file, `charsets`, during the introduction of modules. The coding test (`TestCharsetMapping.java`) has been adapted to use the 8u data format.
> 
> The detailed changes from the OpenJDK 10 patch are as follows:
> 
> 1. Drop the introduction of the `IBM114x.nr` files which implement JDK-8186803.
> 2. Drop the change to `charsets` which doesn't exist in 8u and any equivalent change may lead to compatibility issues
> 3. `EUC_TW.java` has slightly different context in 8u (no `pkg` argument) but the filename change is the same
> 4. Drop the alias changes in `MS932_0213.java` & `x-MS932_0213` to avoid a compatibility risk.
> 5. Changes to `EuroConverter.java` are dropped as they relate to JDK-8186803.
> 6. Detect the IBM0114x character sets in `TestCharsetMapping.java` and expect an additional 0xA -> 25 mapping rather than counting this as an error
> 7. Remove the parsing and checking of aliases in `TestCharsetMapping.java` as the 8u data files don't store them
> 8. Handle the internal character sets in `TestCharsetMapping.java` as they are not marked as such in the 8u data files
> 9. Change the data file parsing in `TestCharsetMapping.java` to handle the three 8u data files. `dbcs` has additional fields to the other two, but the first five fields that we actually use are mostly the same (`dbcs` has a type field, the other two assume a type of `sbcs`).
> 10. `TestEBCDICLineFeed.java` is modified to handle IBM0114x as is, without the JDK-8186803 change

This pull request has now been integrated.

Changeset: 1818eaf7
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u/commit/1818eaf77e9ca6478627ef9471cae4163d16329a
Stats:     144285 lines in 14 files changed: 130674 ins; 12678 del; 933 mod

8186801: Add regression test to test mapping based charsets (generated at build time)

Reviewed-by: stuefe, sgehwolf
Backport-of: cfe34ed89c4f6ef9a49dceef30da1e43b418b152

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

PR: https://git.openjdk.org/jdk8u/pull/43

From andrew at openjdk.org  Fri Jun 23 10:04:47 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 10:04:47 GMT
Subject: [jdk8u] RFR: 8241311: Move some charset mapping tests from closed
 to open [v2]
In-Reply-To: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>
References: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>
Message-ID: <4plnax0RoD78_7cI10uhQnTM-RripqjFOfhRieRSWE8=.a86b79fb-56b3-479d-9ebd-d8213fa963ee@github.com>

> This is a second pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It adds more tests for character mappings, including GB18030.
> 
> The patch only introduces new tests, shuffled to the correct location. The one change to an existing file (`TestCharsetMapping.java`) is dropped, as it only adds an unneeded `@modules` line. Similarly, `@modules` is dropped from `CoderTest.java`, `ConverterTest.java` and `TestConv.java`.
> 
> The remaining change is to `MS950.c2b-irreversible`. 8u does not have [JDK-8232161](https://bugs.openjdk.org/browse/JDK-8232161), a change with an associated CSR that changed some of the mappings in the MS950 character set. We removed the four mappings from the test set, so as to match 8u's behaviour and avoid the `CoderTest.java` test from failing.
> 
> All `sun.nio.cs` tests pass with this patch applied.

Andrew John Hughes 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.

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

Changes:
  - all: https://git.openjdk.org/jdk8u/pull/44/files
  - new: https://git.openjdk.org/jdk8u/pull/44/files/c4850a96..c4850a96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u&pr=44&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u&pr=44&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u/pull/44.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u.git pull/44/head:pull/44

PR: https://git.openjdk.org/jdk8u/pull/44

From andrew at openjdk.org  Fri Jun 23 10:14:24 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 10:14:24 GMT
Subject: [jdk8u] RFR: 8241311: Move some charset mapping tests from closed
 to open [v3]
In-Reply-To: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>
References: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>
Message-ID: <Egt1UBq58Sij4czdUz1lZo0pCI2h6t5ZxEFTs90Qe2Q=.5d4fcdd4-c0e5-461c-be5e-593413590dca@github.com>

> This is a second pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It adds more tests for character mappings, including GB18030.
> 
> The patch only introduces new tests, shuffled to the correct location. The one change to an existing file (`TestCharsetMapping.java`) is dropped, as it only adds an unneeded `@modules` line. Similarly, `@modules` is dropped from `CoderTest.java`, `ConverterTest.java` and `TestConv.java`.
> 
> The remaining change is to `MS950.c2b-irreversible`. 8u does not have [JDK-8232161](https://bugs.openjdk.org/browse/JDK-8232161), a change with an associated CSR that changed some of the mappings in the MS950 character set. We removed the four mappings from the test set, so as to match 8u's behaviour and avoid the `CoderTest.java` test from failing.
> 
> All `sun.nio.cs` tests pass with this patch applied.

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge remote-tracking branch 'jdk8u/master' into JDK-8241311
 - Backport c809c9944400f7ee9bc296e40d6068273bde5912
 - Backport cfe34ed89c4f6ef9a49dceef30da1e43b418b152

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

Changes: https://git.openjdk.org/jdk8u/pull/44/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u&pr=44&range=02
  Stats: 732192 lines in 166 files changed: 732192 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u/pull/44.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u.git pull/44/head:pull/44

PR: https://git.openjdk.org/jdk8u/pull/44

From andrew at openjdk.org  Fri Jun 23 10:18:09 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 10:18:09 GMT
Subject: [jdk8u] RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <iTP8fNZDLRo1eoSjCYmk6rSvoL2lO8XWbzVCWHmEkpU=.1015b3bb-509a-42f0-bbd3-51e0eb1a579c@github.com>
References: <iTP8fNZDLRo1eoSjCYmk6rSvoL2lO8XWbzVCWHmEkpU=.1015b3bb-509a-42f0-bbd3-51e0eb1a579c@github.com>
Message-ID: <OTJ72ho9Xl8Tx5vlF-SKhdC_K6asQaK0ii9sjVKeH0g=.85be3b84-24f7-48d4-97ec-881b277e30f7@github.com>

> This is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`.
> 
> With the preceding test changes in place (#43 and #44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the `SPI.java` generator tool moves into `ExtendedCharsets.java` in the class library, as the file is not auto-generated in 8u. The change to `StandardCharsets.java.template` lands in `AbstractCharsetProvider.java`.
> 
> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allows `IS_2000` to be package-private to `sun.nio.cs`, whereas we need to make it public in `sun.nio.cs.ext` so it can be accessed from `sun.nio.cs`.
> 
> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to awk.
> 
> The only adjustment to `GB18030.java`, other than copyright headers, is to replace the use of `jdk.internal.misc.VM.initLevel` with that of `sun.misc.VM.isBooted`. 8u does not provide as fine-grained access to the initialisation status as 11u, and so may force the use of the 2022 standard until a later stage in the bootup (`BOOTED` is `initLevel() = 4` in 11u).
> 
> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Se...

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Backport 5c4e744dabcf7785c35168db5d0458ccebfd41e6

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

Changes: https://git.openjdk.org/jdk8u/pull/45/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u&pr=45&range=01
  Stats: 1019 lines in 9 files changed: 909 ins; 10 del; 100 mod
  Patch: https://git.openjdk.org/jdk8u/pull/45.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u.git pull/45/head:pull/45

PR: https://git.openjdk.org/jdk8u/pull/45

From andrew at openjdk.org  Fri Jun 23 10:44:06 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 10:44:06 GMT
Subject: [jdk8u] RFR: 8241311: Move some charset mapping tests from closed
 to open [v3]
In-Reply-To: <Egt1UBq58Sij4czdUz1lZo0pCI2h6t5ZxEFTs90Qe2Q=.5d4fcdd4-c0e5-461c-be5e-593413590dca@github.com>
References: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>
 <Egt1UBq58Sij4czdUz1lZo0pCI2h6t5ZxEFTs90Qe2Q=.5d4fcdd4-c0e5-461c-be5e-593413590dca@github.com>
Message-ID: <dSBL4e3pqGJubK9Jnm1Nkr_s9TApB3w_-z0N8PvuKf0=.56669b24-a445-41c4-8272-4102b3631ec0@github.com>

On Fri, 23 Jun 2023 10:14:24 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This is a second pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It adds more tests for character mappings, including GB18030.
>> 
>> The patch only introduces new tests, shuffled to the correct location. The one change to an existing file (`TestCharsetMapping.java`) is dropped, as it only adds an unneeded `@modules` line. Similarly, `@modules` is dropped from `CoderTest.java`, `ConverterTest.java` and `TestConv.java`.
>> 
>> The remaining change is to `MS950.c2b-irreversible`. 8u does not have [JDK-8232161](https://bugs.openjdk.org/browse/JDK-8232161), a change with an associated CSR that changed some of the mappings in the MS950 character set. We removed the four mappings from the test set, so as to match 8u's behaviour and avoid the `CoderTest.java` test from failing.
>> 
>> All `sun.nio.cs` tests pass with this patch applied.
>
> Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'jdk8u/master' into JDK-8241311
>  - Backport c809c9944400f7ee9bc296e40d6068273bde5912
>  - Backport cfe34ed89c4f6ef9a49dceef30da1e43b418b152

I see `jdk8u-critical-yes` so will integrate when testing of the merge version completes.

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

PR Comment: https://git.openjdk.org/jdk8u/pull/44#issuecomment-1604092124

From andrew at openjdk.org  Fri Jun 23 12:24:08 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 12:24:08 GMT
Subject: [jdk8u] Integrated: 8241311: Move some charset mapping tests from
 closed to open
In-Reply-To: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>
References: <pVLL8O_rkupr3BqGek5nPHZQ0CM0OdxhBgusosc40-A=.60a317be-b7d7-4b44-93ce-739fbc8b7057@github.com>
Message-ID: <akN2Y-p4UV2eMPeYFxR3k0uHW4YOXREtzJFv3VcNIzk=.aad5476a-cb92-4760-a93d-8a536561c3dd@github.com>

On Wed, 21 Jun 2023 01:18:23 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This is a second pre-requisite for [JDK-8301119](https://bugs.openjdk.org/browse/JDK-8301119) ("Support for GB18030-2022") and so is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It adds more tests for character mappings, including GB18030.
> 
> The patch only introduces new tests, shuffled to the correct location. The one change to an existing file (`TestCharsetMapping.java`) is dropped, as it only adds an unneeded `@modules` line. Similarly, `@modules` is dropped from `CoderTest.java`, `ConverterTest.java` and `TestConv.java`.
> 
> The remaining change is to `MS950.c2b-irreversible`. 8u does not have [JDK-8232161](https://bugs.openjdk.org/browse/JDK-8232161), a change with an associated CSR that changed some of the mappings in the MS950 character set. We removed the four mappings from the test set, so as to match 8u's behaviour and avoid the `CoderTest.java` test from failing.
> 
> All `sun.nio.cs` tests pass with this patch applied.

This pull request has now been integrated.

Changeset: 0bec498f
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u/commit/0bec498fc945a49f1134e02eb477e0af15db3b5b
Stats:     732192 lines in 166 files changed: 732192 ins; 0 del; 0 mod

8241311: Move some charset mapping tests from closed to open

Reviewed-by: sgehwolf
Backport-of: c809c9944400f7ee9bc296e40d6068273bde5912

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

PR: https://git.openjdk.org/jdk8u/pull/44

From andrew at openjdk.org  Fri Jun 23 12:58:19 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 12:58:19 GMT
Subject: [jdk8u] RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <iTP8fNZDLRo1eoSjCYmk6rSvoL2lO8XWbzVCWHmEkpU=.1015b3bb-509a-42f0-bbd3-51e0eb1a579c@github.com>
References: <iTP8fNZDLRo1eoSjCYmk6rSvoL2lO8XWbzVCWHmEkpU=.1015b3bb-509a-42f0-bbd3-51e0eb1a579c@github.com>
Message-ID: <la9VKleEAePnTem7KY8mJfxpNtPd3j8FGbXLBdGmtcM=.6ba453a9-a67e-478e-9a87-0c3775e55b5e@github.com>

> This is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`.
> 
> With the preceding test changes in place (#43 and #44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the `SPI.java` generator tool moves into `ExtendedCharsets.java` in the class library, as the file is not auto-generated in 8u. The change to `StandardCharsets.java.template` lands in `AbstractCharsetProvider.java`.
> 
> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allows `IS_2000` to be package-private to `sun.nio.cs`, whereas we need to make it public in `sun.nio.cs.ext` so it can be accessed from `sun.nio.cs`.
> 
> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to awk.
> 
> The only adjustment to `GB18030.java`, other than copyright headers, is to replace the use of `jdk.internal.misc.VM.initLevel` with that of `sun.misc.VM.isBooted`. 8u does not provide as fine-grained access to the initialisation status as 11u, and so may force the use of the 2022 standard until a later stage in the bootup (`BOOTED` is `initLevel() = 4` in 11u).
> 
> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Se...

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Backport 5c4e744dabcf7785c35168db5d0458ccebfd41e6

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

Changes: https://git.openjdk.org/jdk8u/pull/45/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u&pr=45&range=02
  Stats: 1019 lines in 9 files changed: 909 ins; 10 del; 100 mod
  Patch: https://git.openjdk.org/jdk8u/pull/45.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u.git pull/45/head:pull/45

PR: https://git.openjdk.org/jdk8u/pull/45

From sgehwolf at openjdk.org  Fri Jun 23 13:39:08 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 23 Jun 2023 13:39:08 GMT
Subject: [jdk8u] RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <la9VKleEAePnTem7KY8mJfxpNtPd3j8FGbXLBdGmtcM=.6ba453a9-a67e-478e-9a87-0c3775e55b5e@github.com>
References: <iTP8fNZDLRo1eoSjCYmk6rSvoL2lO8XWbzVCWHmEkpU=.1015b3bb-509a-42f0-bbd3-51e0eb1a579c@github.com>
 <la9VKleEAePnTem7KY8mJfxpNtPd3j8FGbXLBdGmtcM=.6ba453a9-a67e-478e-9a87-0c3775e55b5e@github.com>
Message-ID: <zNqrmsJwiaCdiGpHMGYDaTKzzRLz3sQXlScZnQqJy8k=.7433ae1e-f4ff-44c9-8003-8285e5b3c927@github.com>

On Fri, 23 Jun 2023 12:58:19 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`.
>> 
>> With the preceding test changes in place (#43 and #44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the `SPI.java` generator tool moves into `ExtendedCharsets.java` in the class library, as the file is not auto-generated in 8u. The change to `StandardCharsets.java.template` lands in `AbstractCharsetProvider.java`.
>> 
>> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allows `IS_2000` to be package-private to `sun.nio.cs`, whereas we need to make it public in `sun.nio.cs.ext` so it can be accessed from `sun.nio.cs`.
>> 
>> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to awk.
>> 
>> The only adjustment to `GB18030.java`, other than copyright headers, is to replace the use of `jdk.internal.misc.VM.initLevel` with that of `sun.misc.VM.isBooted`. 8u does not provide as fine-grained access to the initialisation status as 11u, and so may force the use of the 2022 standard until a later stage in the bootup (`BOOTED` is `initLevel() = 4` in 11u).
>> 
>> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u....
>
> Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Backport 5c4e744dabcf7785c35168db5d0458ccebfd41e6

These 4 tests consistently fail for me with a fastdebug build:


FAILED: java/nio/charset/Charset/RegisteredCharsets.java
FAILED: sun/nio/cs/mapping/CoderTest.java
FAILED: sun/nio/cs/mapping/TestConv.java
FAILED: sun/nio/cs/TestGB18030.java


`RegisteredCharsets.java` failure is:

java.nio.charset.UnsupportedCharsetException: gb18030-2022
        at java.nio.charset.Charset.forName(Charset.java:531)
        at RegisteredCharsets.aliasCheck(RegisteredCharsets.java:182)
        at RegisteredCharsets.main(RegisteredCharsets.java:255)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.lang.Thread.run(Thread.java:750)


`CoderTest.java` failure is:


java.lang.Exception: Errors detected in 1 charset
        at CoderTest.main(CoderTest.java:526)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.lang.Thread.run(Thread.java:750)


specifically:


GB18030 (GB18030)
  1 byte/char
    decode
    decode (direct)
    encode
    encode (direct)
  2 bytes/char
    decode
      Error: a8bc --> U+e7c7, expected U+1e3f
      Error: a6d9 --> U+e78d, expected U+fe10
      Error: a6da --> U+e78e, expected U+fe12
      Error: a6db --> U+e78f, expected U+fe11
      Error: a6dc --> U+e790, expected U+fe13
      Error: a6dd --> U+e791, expected U+fe14
      Error: a6de --> U+e792, expected U+fe15
      Error: a6df --> U+e793, expected U+fe16
      Error: a6ec --> U+e794, expected U+fe17
      Error: a6ed --> U+e795, expected U+fe18
      Too many errors, giving up
    decode (direct)
      Error: a8bc --> U+e7c7, expected U+1e3f
      Error: a6d9 --> U+e78d, expected U+fe10
      Error: a6da --> U+e78e, expected U+fe12
      Error: a6db --> U+e78f, expected U+fe11
      Error: a6dc --> U+e790, expected U+fe13
      Error: a6dd --> U+e791, expected U+fe14
      Error: a6de --> U+e792, expected U+fe15
      Error: a6df --> U+e793, expected U+fe16
      Error: a6ec --> U+e794, expected U+fe17
      Error: a6ed --> U+e795, expected U+fe18
      Too many errors, giving up
    encode
      Error: U+1e3f --> 8135, expected a8bc
      Error: U+2010 --> f437, expected a95c
      Error: U+2013 --> a95c, expected a843
      Error: U+2014 --> a843, expected a1aa
      Error: U+2015 --> a1aa, expected a844
      Error: U+2016 --> a844, expected a1ac
      Error: U+2018 --> a1ac, expected a1ae
      Error: U+2019 --> a1ae, expected a1af
      Error: U+201c --> a1af, expected a1b0
      Error: U+201d --> a1b0, expected a1b1
      Too many errors, giving up
    encode (direct)
      Error: U+1e3f --> 8135, expected a8bc
      Error: U+2010 --> f437, expected a95c
      Error: U+2013 --> a95c, expected a843
      Error: U+2014 --> a843, expected a1aa
      Error: U+2015 --> a1aa, expected a844
      Error: U+2016 --> a844, expected a1ac
      Error: U+2018 --> a1ac, expected a1ae
      Error: U+2019 --> a1ae, expected a1af
      Error: U+201c --> a1af, expected a1b0
      Error: U+201d --> a1b0, expected a1b1
      Too many errors, giving up
  3 bytes/char
    decode
    decode (direct)
    encode
    encode (direct)
  4 bytes/char
    decode
      Error: 82359037 --> U+9fb4, expected U+e81e
      Error: 82359038 --> U+9fb5, expected U+e826
      Error: 82359039 --> U+9fb6, expected U+e82b
      Error: 82359130 --> U+9fb7, expected U+e82c
      Error: 82359131 --> U+9fb8, expected U+e832
      Error: 82359132 --> U+9fb9, expected U+e843
      Error: 82359133 --> U+9fba, expected U+e854
      Error: 82359134 --> U+9fbb, expected U+e864
      Error: 8135f437 --> U+1e3f, expected U+e7c7
      Error: 84318236 --> U+fe10, expected U+e78d
      Too many errors, giving up
    decode (direct)
      Error: 82359037 --> U+9fb4, expected U+e81e
      Error: 82359038 --> U+9fb5, expected U+e826
      Error: 82359039 --> U+9fb6, expected U+e82b
      Error: 82359130 --> U+9fb7, expected U+e82c
      Error: 82359131 --> U+9fb8, expected U+e832
      Error: 82359132 --> U+9fb9, expected U+e843
      Error: 82359133 --> U+9fba, expected U+e854
      Error: 82359134 --> U+9fbb, expected U+e864
      Error: 8135f437 --> U+1e3f, expected U+e7c7
      Error: 84318236 --> U+fe10, expected U+e78d
      Too many errors, giving up
    encode
      Error: U+e81e --> fe59fe61, expected 82359037
      Error: U+e826 --> fe66fe67, expected 82359038
      Error: U+e82b --> fe6dfe7e, expected 82359039
      Error: U+e82c --> fe90fea0, expected 82359130
      Error: U+e832 --> 82359135, expected 82359131
      Error: U+e843 --> 82359136, expected 82359132
      Error: U+e854 --> 82359137, expected 82359133
      Error: U+e864 --> 82359138, expected 82359134
      Error: U+9fbc --> 82359139, expected 82359135
      Error: U+9fbd --> 82359230, expected 82359136
      Too many errors, giving up
    encode (direct)
      Error: U+e81e --> fe59fe61, expected 82359037
      Error: U+e826 --> fe66fe67, expected 82359038
      Error: U+e82b --> fe6dfe7e, expected 82359039
      Error: U+e82c --> fe90fea0, expected 82359130
      Error: U+e832 --> 82359135, expected 82359131
      Error: U+e843 --> 82359136, expected 82359132
      Error: U+e854 --> 82359137, expected 82359133
      Error: U+e864 --> 82359138, expected 82359134
      Error: U+9fbc --> 82359139, expected 82359135
      Error: U+9fbd --> 82359230, expected 82359136
      Too many errors, giving up


`TestConv.java` failure is:


Checking GB18030_2000...
Not supported: GB18030_2000
[...]
Checking GB18030...
Warning 1: 0xA8BC -> \\uE7C7  multi-mapping? \\u1E3F
Warning 2: 0x82359037 -> \\u9FB4  multi-mapping? \\uE81E
Warning 3: 0x82359038 -> \\u9FB5  multi-mapping? \\uE826
Warning 4: 0x82359039 -> \\u9FB6  multi-mapping? \\uE82B
Warning 5: 0x82359130 -> \\u9FB7  multi-mapping? \\uE82C
Warning 6: 0x82359131 -> \\u9FB8  multi-mapping? \\uE832
Warning 7: 0x82359132 -> \\u9FB9  multi-mapping? \\uE843
Warning 8: 0x82359133 -> \\u9FBA  multi-mapping? \\uE854
Warning 9: 0x82359134 -> \\u9FBB  multi-mapping? \\uE864
Warning 10: 0xA6D9 -> \\uE78D  multi-mapping? \\uFE10
Warning 11: 0xA6DA -> \\uE78E  multi-mapping? \\uFE12
Warning 12: 0xA6DB -> \\uE78F  multi-mapping? \\uFE11
Warning 13: 0xA6DC -> \\uE790  multi-mapping? \\uFE13
Warning 14: 0xA6DD -> \\uE791  multi-mapping? \\uFE14
Warning 15: 0xA6DE -> \\uE792  multi-mapping? \\uFE15
Warning 16: 0xA6DF -> \\uE793  multi-mapping? \\uFE16
Warning 17: 0xA6EC -> \\uE794  multi-mapping? \\uFE17
Warning 18: 0xA6ED -> \\uE795  multi-mapping? \\uFE18
Warning 19: 0xA6F3 -> \\uE796  multi-mapping? \\uFE19
Warning 20: 0x8135F437 -> \\u1E3F  multi-mapping? \\uE7C7
Warning 21: 0xFE59 -> \\uE81E  multi-mapping? \\u9FB4
Warning 22: 0xFE61 -> \\uE826  multi-mapping? \\u9FB5
Warning 23: 0xFE66 -> \\uE82B  multi-mapping? \\u9FB6
Warning 24: 0xFE67 -> \\uE82C  multi-mapping? \\u9FB7
Warning 25: 0xFE6D -> \\uE832  multi-mapping? \\u9FB8
Warning 26: 0xFE7E -> \\uE843  multi-mapping? \\u9FB9
Warning 27: 0xFE90 -> \\uE854  multi-mapping? \\u9FBA
Warning 28: 0xFEA0 -> \\uE864  multi-mapping? \\u9FBB
Warning 29: 0x84318236 -> \\uFE10  multi-mapping? \\uE78D
Warning 30: 0x84318237 -> \\uFE11  multi-mapping? \\uE78F
Warning 31: 0x84318238 -> \\uFE12  multi-mapping? \\uE78E
Warning 32: 0x84318239 -> \\uFE13  multi-mapping? \\uE790
Warning 33: 0x84318330 -> \\uFE14  multi-mapping? \\uE791
Warning 34: 0x84318331 -> \\uFE15  multi-mapping? \\uE792
Warning 35: 0x84318332 -> \\uFE16  multi-mapping? \\uE793
Warning 36: 0x84318333 -> \\uFE17  multi-mapping? \\uE794
Warning 37: 0x84318334 -> \\uFE18  multi-mapping? \\uE795
Warning 38: 0x84318335 -> \\uFE19  multi-mapping? \\uE796
----------System.err:(14/735)----------
java.lang.RuntimeException: 38 Warning(s).
        at TestConv.check(TestConv.java:124)
        at TestConv.main(TestConv.java:47)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.lang.Thread.run(Thread.java:750)

JavaTest Message: Test threw exception: java.lang.RuntimeException: 38 Warning(s).
JavaTest Message: shutting down test


`TestGB18030.java` failure is:


checkAlias(): IS_2000: false, expected: [gb18030-2022], found: [gb18030-2000]
----------System.err:(14/754)----------
java.lang.RuntimeException: Result mismatch
        at TestGB18030.checkAlias(TestGB18030.java:89)
        at TestGB18030.main(TestGB18030.java:95)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.lang.Thread.run(Thread.java:750)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Result mismatch

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

PR Review: https://git.openjdk.org/jdk8u/pull/45#pullrequestreview-1495164844

From andrew at openjdk.org  Fri Jun 23 14:57:11 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Jun 2023 14:57:11 GMT
Subject: [jdk8u] RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <la9VKleEAePnTem7KY8mJfxpNtPd3j8FGbXLBdGmtcM=.6ba453a9-a67e-478e-9a87-0c3775e55b5e@github.com>
References: <iTP8fNZDLRo1eoSjCYmk6rSvoL2lO8XWbzVCWHmEkpU=.1015b3bb-509a-42f0-bbd3-51e0eb1a579c@github.com>
 <la9VKleEAePnTem7KY8mJfxpNtPd3j8FGbXLBdGmtcM=.6ba453a9-a67e-478e-9a87-0c3775e55b5e@github.com>
Message-ID: <wKE7LNUxowDmG11cBE7ImHmToauokgeFUzMSBX3Nz1w=.8baebf88-bc6a-47e2-a70f-4b720c45da52@github.com>

On Fri, 23 Jun 2023 12:58:19 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`.
>> 
>> With the preceding test changes in place (#43 and #44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the `SPI.java` generator tool moves into `ExtendedCharsets.java` in the class library, as the file is not auto-generated in 8u. The change to `StandardCharsets.java.template` lands in `AbstractCharsetProvider.java`.
>> 
>> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allows `IS_2000` to be package-private to `sun.nio.cs`, whereas we need to make it public in `sun.nio.cs.ext` so it can be accessed from `sun.nio.cs`.
>> 
>> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to awk.
>> 
>> The only adjustment to `GB18030.java`, other than copyright headers, is to replace the use of `jdk.internal.misc.VM.initLevel` with that of `sun.misc.VM.isBooted`. 8u does not provide as fine-grained access to the initialisation status as 11u, and so may force the use of the 2022 standard until a later stage in the bootup (`BOOTED` is `initLevel() = 4` in 11u).
>> 
>> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u....
>
> Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Backport 5c4e744dabcf7785c35168db5d0458ccebfd41e6

I'm not able to reproduce these failures locally, which makes it hard to diagnose what's going on here.

I can try and move the character set to `sun.nio.cs` after all and see if it makes a difference for you.

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

PR Comment: https://git.openjdk.org/jdk8u/pull/45#issuecomment-1604398918

From gnu.andrew at redhat.com  Tue Jun 27 00:56:34 2023
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 27 Jun 2023 01:56:34 +0100
Subject: [FREEZE] 8u382 NOW FROZEN
Message-ID: <ZJozwvulano0ABwO@hex.discworld.ac.uk>

The release tree:

https://github.com/openjdk/jdk8u

is now frozen in preparation for release on or after 2023-07-18.

The final pre-release tag is jdk8u382-b04, which I will publish
following build testing.

The final release tag will be no lower than jdk8u382-b05.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Principal Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Please contact via e-mail, not proprietary chat networks
Available on Libera Chat & OFTC IRC networks as gnu_andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20230627/11fec609/signature.asc>

From sgehwolf at openjdk.org  Tue Jun 27 08:35:09 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 27 Jun 2023 08:35:09 GMT
Subject: [jdk8u] RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <zNqrmsJwiaCdiGpHMGYDaTKzzRLz3sQXlScZnQqJy8k=.7433ae1e-f4ff-44c9-8003-8285e5b3c927@github.com>
References: <iTP8fNZDLRo1eoSjCYmk6rSvoL2lO8XWbzVCWHmEkpU=.1015b3bb-509a-42f0-bbd3-51e0eb1a579c@github.com>
 <la9VKleEAePnTem7KY8mJfxpNtPd3j8FGbXLBdGmtcM=.6ba453a9-a67e-478e-9a87-0c3775e55b5e@github.com>
 <zNqrmsJwiaCdiGpHMGYDaTKzzRLz3sQXlScZnQqJy8k=.7433ae1e-f4ff-44c9-8003-8285e5b3c927@github.com>
Message-ID: <J5q_37klfzgI_IHOZEABHiFdbhp2QP-H5x13L7P29ag=.9e08b4ab-b7a7-4625-9d6d-65b986875332@github.com>

On Fri, 23 Jun 2023 13:36:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> These 4 tests consistently fail for me with a fastdebug build:
> 
> ```
> FAILED: java/nio/charset/Charset/RegisteredCharsets.java
> FAILED: sun/nio/cs/mapping/CoderTest.java
> FAILED: sun/nio/cs/mapping/TestConv.java
> FAILED: sun/nio/cs/TestGB18030.java
> ```

That was my bad. Ran on the wrong JDK build (so have hidden the comment). Sorry. I'll post a review of the patch today.

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

PR Comment: https://git.openjdk.org/jdk8u/pull/45#issuecomment-1609041649

From sgehwolf at openjdk.org  Tue Jun 27 13:04:15 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 27 Jun 2023 13:04:15 GMT
Subject: [jdk8u] RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <la9VKleEAePnTem7KY8mJfxpNtPd3j8FGbXLBdGmtcM=.6ba453a9-a67e-478e-9a87-0c3775e55b5e@github.com>
References: <iTP8fNZDLRo1eoSjCYmk6rSvoL2lO8XWbzVCWHmEkpU=.1015b3bb-509a-42f0-bbd3-51e0eb1a579c@github.com>
 <la9VKleEAePnTem7KY8mJfxpNtPd3j8FGbXLBdGmtcM=.6ba453a9-a67e-478e-9a87-0c3775e55b5e@github.com>
Message-ID: <199UnSMs1ldhavLSr052L01YC2tN7ATTqtBunSGw-yY=.2a92e8cd-0b26-4f97-8b7e-85aba4f2c6d8@github.com>

On Fri, 23 Jun 2023 12:58:19 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`.
>> 
>> With the preceding test changes in place (#43 and #44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the `SPI.java` generator tool moves into `ExtendedCharsets.java` in the class library, as the file is not auto-generated in 8u. The change to `StandardCharsets.java.template` lands in `AbstractCharsetProvider.java`.
>> 
>> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allows `IS_2000` to be package-private to `sun.nio.cs`, whereas we need to make it public in `sun.nio.cs.ext` so it can be accessed from `sun.nio.cs`.
>> 
>> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to awk.
>> 
>> The only adjustment to `GB18030.java`, other than copyright headers, is to replace the use of `jdk.internal.misc.VM.initLevel` with that of `sun.misc.VM.isBooted`. 8u does not provide as fine-grained access to the initialisation status as 11u, and so may force the use of the 2022 standard until a later stage in the bootup (`BOOTED` is `initLevel() = 4` in 11u).
>> 
>> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u....
>
> Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Backport 5c4e744dabcf7785c35168db5d0458ccebfd41e6

I'd suggest to use the late init hook in `AbstractCharsetProvider.charsetForName()` instead which would make this patch cleaner IMO. See https://github.com/gnu-andrew/jdk8u/pull/1

jdk/src/share/classes/sun/nio/cs/AbstractCharsetProvider.java line 37:

> 35: import java.util.Map;
> 36: import sun.misc.ASCIICaseInsensitiveComparator;
> 37: import sun.nio.cs.ext.GB18030;

Depending on `GB18030` class (`sun.nio.cs.ext.` in `charsets.jar`) in package `sun.nio.cs` (`rt.jar`) seems worrisome.

jdk/src/share/classes/sun/nio/cs/AbstractCharsetProvider.java line 125:

> 123:             String acn = aliasMap.get(csn);
> 124:             return (acn != null) ? acn : csn;
> 125:         }

I believe if we hooked into the late initialization hook instead we wouldn't need this canonicalization as the `aliasMap` would map it back to the correct class name.

jdk/src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java line 117:

> 115:         charset("GB18030", "GB18030",
> 116:                 new String[] {
> 117:                     GB18030.IS_2000 ? "gb18030-2000" : "gb18030-2022"

This initialization will be wrong when run with `LANG=zh_CN.GB18030` and `-Djdk.charset.GB18030=2000`as in that case the `GB18030.IS_2000` will be `false` as the JVM won't have properly initialized yet. Again a suggestion to use the late init hook instead. See https://bugs.openjdk.org/browse/JDK-8310947

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

PR Review: https://git.openjdk.org/jdk8u/pull/45#pullrequestreview-1500782990
PR Review Comment: https://git.openjdk.org/jdk8u/pull/45#discussion_r1243684354
PR Review Comment: https://git.openjdk.org/jdk8u/pull/45#discussion_r1243682487
PR Review Comment: https://git.openjdk.org/jdk8u/pull/45#discussion_r1243688456

From gnu.andrew at redhat.com  Wed Jun 28 10:58:55 2023
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 28 Jun 2023 11:58:55 +0100
Subject: [FREEZE] 8u382 NOW FROZEN
In-Reply-To: <ZJozwvulano0ABwO@hex.discworld.ac.uk>
References: <ZJozwvulano0ABwO@hex.discworld.ac.uk>
Message-ID: <ZJwSbzJyt6jYvu8K@hex.discworld.ac.uk>

On 01:56 Tue 27 Jun     , Andrew Hughes wrote:
> The release tree:
> 
> https://github.com/openjdk/jdk8u
> 
> is now frozen in preparation for release on or after 2023-07-18.
> 
> The final pre-release tag is jdk8u382-b04, which I will publish
> following build testing.
> 
> The final release tag will be no lower than jdk8u382-b05.
> 
> Thanks,
> -- 
> Andrew :)
> Pronouns: he / him or they / them
> Principal Free Java Software Engineer
> OpenJDK Package Owner
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> 
> Please contact via e-mail, not proprietary chat networks
> Available on Libera Chat & OFTC IRC networks as gnu_andrew

https://github.com/openjdk/jdk8u/releases/tag/jdk8u382-b04
-- 
Andrew :)
Pronouns: he / him or they / them
Principal Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Please contact via e-mail, not proprietary chat networks
Available on Libera Chat & OFTC IRC networks as gnu_andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20230628/c94b205d/signature.asc>

From andrew at openjdk.org  Wed Jun 28 11:56:13 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 28 Jun 2023 11:56:13 GMT
Subject: [jdk8u-dev] RFR: 8200468: Port the native GSS-API bridge to
 Windows
In-Reply-To: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>
References: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>
Message-ID: <q6eFbcd0aAS-y0olUAQB1qkQsRNgfDEZalu7QQApxIA=.07c1e821-7089-4063-a718-59491a735bd2@github.com>

On Mon, 12 Jun 2023 06:20:11 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Hello,
> I'd like to backport JDK-8200568: port the native GSS-API bridge to Windows to JDK8u
> This is a prerequisite of the JDK-6722928 and JDK-8225687
> 
> The backport is not clean. I have to to make the following changes:
> jdk/make/lib/SecurityLibraries.gmk
> - Patched manually, just removed platform dependency
> 
> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.c
> - Clean merge except for copyright year
> 
> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.h
> - Visual Studio 2010-2012 doesn't provide inttypes.h so provide appropriate definitions the header file
> - Manually updated copyright year
> 
> jdk/src/share/classes/sun/security/jgss/GSSManagerImpl.java
> - Manually removed platform OS dependency
> 
> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.c
> - All changes applied manually because of JDK-8238388 already applied 
> 
> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.h
> - All changes applied clean 
> 
> jdk/test/sun/security/krb5/auto/BasicProc.java
> - Manually added Windows platform dependency code
> 
> jdk/test/java/security/testlibrary/Proc.java
> - Manually extended debug output
> 
> All related jtreg tests passed successfully on Windows

Mostly looks good but there are a couple of issues:

* You mention adjusting the copyright header for `NativeUtil.c` and `NativeUtil.h`, but I don't see them in the patch. They should be bumped from 2014 to 2018. The other omissions are correct, as the files already have newer copyright headers.
* The change of the `@library` line in `BasicProc.java` is unneeded. There is a Platform class in `jdk.testlibrary` which can be imported as `jdk.testlibrary.Platform`. We should aim to resolve this duplication (caused by the JFR import) going forward, but I think for now, the test should stick to one test library. Adding the `/lib` reference means it could potentially mix the two test libraries together as they have duplicated classes, so please drop the `lib` and use `jdk.testlibrary.Platform` for now.
* In the 11u patch, the `pc.env` line is outside the `!Platform.isWindows` block, but seems to be inside in the 8u version.
11u:
~~~
+            if (!Platform.isWindows()) {
+                Files.setPosixFilePermissions(Paths.get(label + ".ccache"),
+                        Set.of(PosixFilePermission.OWNER_READ,
+                                PosixFilePermission.OWNER_WRITE));
+            }
+            pc.env("KRB5CCNAME", "FILE:" + label + ".ccache");

$ find jdk/test/ -name 'Platform.java'
jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java
jdk/test/lib/jdk/test/lib/Platform.java

~~~

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

PR Review: https://git.openjdk.org/jdk8u-dev/pull/335#pullrequestreview-1502913957

From abakhtin at openjdk.org  Wed Jun 28 22:19:12 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 28 Jun 2023 22:19:12 GMT
Subject: [jdk8u-dev] RFR: 8200468: Port the native GSS-API bridge to
 Windows [v2]
In-Reply-To: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>
References: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>
Message-ID: <VNIToTVXGbc2IIZFTsJmRB0gKywIZPHbgEt6Ofa36C4=.c4cbfcef-5b1d-4d34-af31-8a4f405fca47@github.com>

> Hello,
> I'd like to backport JDK-8200568: port the native GSS-API bridge to Windows to JDK8u
> This is a prerequisite of the JDK-6722928 and JDK-8225687
> 
> The backport is not clean. I have to to make the following changes:
> jdk/make/lib/SecurityLibraries.gmk
> - Patched manually, just removed platform dependency
> 
> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.c
> - Clean merge except for copyright year
> 
> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.h
> - Visual Studio 2010-2012 doesn't provide inttypes.h so provide appropriate definitions the header file
> - Manually updated copyright year
> 
> jdk/src/share/classes/sun/security/jgss/GSSManagerImpl.java
> - Manually removed platform OS dependency
> 
> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.c
> - All changes applied manually because of JDK-8238388 already applied 
> 
> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.h
> - All changes applied clean 
> 
> jdk/test/sun/security/krb5/auto/BasicProc.java
> - Manually added Windows platform dependency code
> 
> jdk/test/java/security/testlibrary/Proc.java
> - Manually extended debug output
> 
> All related jtreg tests passed successfully on Windows

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year and BasicProc test

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/335/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/335/files/36507223..2b34dd7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=335&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=335&range=00-01

  Stats: 7 lines in 3 files changed: 2 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/335.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/335/head:pull/335

PR: https://git.openjdk.org/jdk8u-dev/pull/335

From abakhtin at openjdk.org  Wed Jun 28 22:23:03 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 28 Jun 2023 22:23:03 GMT
Subject: [jdk8u-dev] RFR: 8200468: Port the native GSS-API bridge to
 Windows [v2]
In-Reply-To: <VNIToTVXGbc2IIZFTsJmRB0gKywIZPHbgEt6Ofa36C4=.c4cbfcef-5b1d-4d34-af31-8a4f405fca47@github.com>
References: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>
 <VNIToTVXGbc2IIZFTsJmRB0gKywIZPHbgEt6Ofa36C4=.c4cbfcef-5b1d-4d34-af31-8a4f405fca47@github.com>
Message-ID: <sneTLJrrAOnejEIXoL3IHgY1VeIZ7XvaEj1vnNMgKbE=.1a29d6a0-012c-4aba-ab5d-afa5eadd9b0b@github.com>

On Wed, 28 Jun 2023 22:19:12 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> I'd like to backport JDK-8200568: port the native GSS-API bridge to Windows to JDK8u
>> This is a prerequisite of the JDK-6722928 and JDK-8225687
>> 
>> The backport is not clean. I have to to make the following changes:
>> jdk/make/lib/SecurityLibraries.gmk
>> - Patched manually, just removed platform dependency
>> 
>> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.c
>> - Clean merge except for copyright year
>> 
>> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.h
>> - Visual Studio 2010-2012 doesn't provide inttypes.h so provide appropriate definitions the header file
>> - Manually updated copyright year
>> 
>> jdk/src/share/classes/sun/security/jgss/GSSManagerImpl.java
>> - Manually removed platform OS dependency
>> 
>> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.c
>> - All changes applied manually because of JDK-8238388 already applied 
>> 
>> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.h
>> - All changes applied clean 
>> 
>> jdk/test/sun/security/krb5/auto/BasicProc.java
>> - Manually added Windows platform dependency code
>> 
>> jdk/test/java/security/testlibrary/Proc.java
>> - Manually extended debug output
>> 
>> All related jtreg tests passed successfully on Windows
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year and BasicProc test

Hello Andrew!
Thank you for the review.
I agree with the Platform usage. Switched to the  jdk.testlibrary.Platform version.
The rest findings are also fixed.

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/335#issuecomment-1612192814

From abakhtin at openjdk.org  Wed Jun 28 22:23:05 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 28 Jun 2023 22:23:05 GMT
Subject: [jdk8u-dev] Withdrawn: 8200468: Port the native GSS-API bridge to
 Windows
In-Reply-To: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>
References: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>
Message-ID: <AMgT7wIznh3KaH5nnLu8IfCcZ2AaX9kHLXwlV7olOgs=.eb210740-4cdd-44eb-b768-7f0a5913bf6e@github.com>

On Mon, 12 Jun 2023 06:20:11 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Hello,
> I'd like to backport JDK-8200568: port the native GSS-API bridge to Windows to JDK8u
> This is a prerequisite of the JDK-6722928 and JDK-8225687
> 
> The backport is not clean. I have to to make the following changes:
> jdk/make/lib/SecurityLibraries.gmk
> - Patched manually, just removed platform dependency
> 
> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.c
> - Clean merge except for copyright year
> 
> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.h
> - Visual Studio 2010-2012 doesn't provide inttypes.h so provide appropriate definitions the header file
> - Manually updated copyright year
> 
> jdk/src/share/classes/sun/security/jgss/GSSManagerImpl.java
> - Manually removed platform OS dependency
> 
> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.c
> - All changes applied manually because of JDK-8238388 already applied 
> 
> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.h
> - All changes applied clean 
> 
> jdk/test/sun/security/krb5/auto/BasicProc.java
> - Manually added Windows platform dependency code
> 
> jdk/test/java/security/testlibrary/Proc.java
> - Manually extended debug output
> 
> All related jtreg tests passed successfully on Windows

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/335

From t.glaser at tarent.de  Thu Jun 29 20:32:54 2023
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Thu, 29 Jun 2023 22:32:54 +0200 (CEST)
Subject: questionable licence in one file
Message-ID: <13d7aff8-14a-a8da-fdd8-dedb24d28b5@tarent.de>

jdk/test/sun/nio/cs/mapping/JIS0212.b2c.private

# This file contains modifications from the original Unicode

but

#  [?] in the creation of products supporting Unicode.  Unicode, Inc.
#      specifically excludes the right to re-distribute this file directly
#      to third parties or other organizations whether for profit or not.

This file should probably be regenerated based on information
from this file, or an updated baseline with a proper OSS licence
be obtained from the Unicode people.

Thanks,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From t.glaser at tarent.de  Thu Jun 29 21:31:48 2023
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Thu, 29 Jun 2023 23:31:48 +0200 (CEST)
Subject: massive amounts of bogus whitespace
Message-ID: <c61c2f6e-f62c-464-1af9-5142ae4f9ad@tarent.de>

Hi,

reviewing the diff from 8u362-ga to 8u382~b04 (which is something
I always do anyway, to update debian/copyright), I found way too
many of the added lines having bogus whitespace at EOL/EOF, DOS
line endings, or both.

If you add?

[mbsd]
	binfiles = \\.(png|jpe?g|gif|[ct]?[glx]z)$
[alias]
	check-emptylines = "!cd \"${GIT_PREFIX:-.}\" || exit 255; git find -gitfiles -print0 | grep -Ezvie \"$(git config mbsd.binfiles)\" | xargs -0r mksh -c 'pcregrep -l -M $'\\''\\n\\n\\n'\\'' \"$@\"; test $? -eq 1' git-check-emptylines-helper #"
	check3emptylines = "!cd \"${GIT_PREFIX:-.}\" || exit 255; git find -gitfiles -print0 | grep -Ezvie \"$(git config mbsd.binfiles)\" | xargs -0r mksh -c 'pcregrep -l -M $'\\''\\n\\n\\n\\n'\\'' \"$@\"; test $? -eq 1' git-check-emptylines-helper #"
	check-whitespace = "!cd \"${GIT_PREFIX:-.}\" || exit 255; git -c diff.relative=true diff --check \"$(git hash-object -t tree /dev/null)\" -- | grep -v '^[+]'; rv=$?; git find -gitfiles -print0 | grep -Ezvie \"$(git config mbsd.binfiles)\" | (test $rv = 1; rv=$?; while IFS= read -r -d '' name; do test -n \"$(tail -c -1 \"$name\")\" || continue; printf '%s:: no newline at EOF\\n' \"$name\"; rv=1; done; exit $rv) #"

? to your ~/.gitconfig, you can then use the command?

	$ git check-whitespace

? to check for where such things are (adjust the mbsd.binfiles
exclusion list suitably in .git/config in your jdk working copy).

This is somewhat reliant on GNU coreutils? features, pcregrep and mksh.
These should be packaged for most distros.

You can also use 'git check3emptylines' to show files where more
than two empty lines separate paragraphs, to fix that. (There?s
git check-emptylines, which ensures a maximum of one blank line,
as well, but your coding style probably has two in some places.)

To fix them up, either press ^K] in the jupp text editor, which
normalises whitespace at EOL and EOF, or do something like?

	$ perl -pi -e 's![\t\cK\cL\cM ]+$!!' file ?

? for whitespace at EOL and to fix whitespace at EOF, ensure
that there?s exactly one linefeed (\n) at the end of the file.

Unless you?re in DOS line endings mode, these will fix that, too.

For ?space before tab in indent?, remove the extra spaces.
(In jupp, use ^K.^K, to indent the marked block first one
level more then one level less, which will convert everything
leading to the proper amount of tabs.)

bye,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From andrew at openjdk.org  Fri Jun 30 11:40:00 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 30 Jun 2023 11:40:00 GMT
Subject: [jdk8u-dev] RFR: 8200468: Port the native GSS-API bridge to
 Windows [v2]
In-Reply-To: <VNIToTVXGbc2IIZFTsJmRB0gKywIZPHbgEt6Ofa36C4=.c4cbfcef-5b1d-4d34-af31-8a4f405fca47@github.com>
References: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>
 <VNIToTVXGbc2IIZFTsJmRB0gKywIZPHbgEt6Ofa36C4=.c4cbfcef-5b1d-4d34-af31-8a4f405fca47@github.com>
Message-ID: <UuQ6URXJ5Lk66ORFEuKuLpJYjVH40wRphjg6VWnJFe8=.1dc530af-dfc9-4f6e-8474-3fbcd5f21c51@github.com>

On Wed, 28 Jun 2023 22:19:12 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> I'd like to backport JDK-8200568: port the native GSS-API bridge to Windows to JDK8u
>> This is a prerequisite of the JDK-6722928 and JDK-8225687
>> 
>> The backport is not clean. I have to to make the following changes:
>> jdk/make/lib/SecurityLibraries.gmk
>> - Patched manually, just removed platform dependency
>> 
>> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.c
>> - Clean merge except for copyright year
>> 
>> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.h
>> - Visual Studio 2010-2012 doesn't provide inttypes.h so provide appropriate definitions the header file
>> - Manually updated copyright year
>> 
>> jdk/src/share/classes/sun/security/jgss/GSSManagerImpl.java
>> - Manually removed platform OS dependency
>> 
>> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.c
>> - All changes applied manually because of JDK-8238388 already applied 
>> 
>> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.h
>> - All changes applied clean 
>> 
>> jdk/test/sun/security/krb5/auto/BasicProc.java
>> - Manually added Windows platform dependency code
>> 
>> jdk/test/java/security/testlibrary/Proc.java
>> - Manually extended debug output
>> 
>> All related jtreg tests passed successfully on Windows
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year and BasicProc test

Thanks. It looks good with the additional changes. If you flag with `jdk8u-fix-request`, I'll approve for 8u too.

What's the end goal here? [JDK-6722928](https://bugs.openjdk.org/browse/JDK-6722928)? I'm just wondering because that one will need a CSR, essentially a clone of what [was done for 11u](https://bugs.openjdk.org/browse/JDK-8256559)

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

Marked as reviewed by andrew (Reviewer).

PR Review: https://git.openjdk.org/jdk8u-dev/pull/335#pullrequestreview-1507032858

From t.glaser at tarent.de  Fri Jun 30 16:41:34 2023
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Fri, 30 Jun 2023 18:41:34 +0200 (CEST)
Subject: bad encoding in source file
Message-ID: <ff5e8873-5983-f7c2-a952-65fad0af31ef@tarent.de>

Hi,

jdk/src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html
has some raw 8-bit bytes that are not UTF-8 characters.

Please reencode that file.

Thanks,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From t.glaser at tarent.de  Fri Jun 30 16:55:45 2023
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Fri, 30 Jun 2023 18:55:45 +0200 (CEST)
Subject: crashes during testsuite run
Message-ID: <94f95bf9-2a2c-f988-b46c-e13863a3e1b5@tarent.de>

Hi,

I (still) get four core dumps each time I build openjdk-8 with
running the testsuite.

They are all in (dashes are slashes, I presume):
tmp-buildd-openjdk-8-8u382-b04-build-bootcycle-build-images-j2sdk-image-bin-java

bye,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From abakhtin at openjdk.org  Fri Jun 30 21:01:03 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 30 Jun 2023 21:01:03 GMT
Subject: [jdk8u-dev] RFR: 8200468: Port the native GSS-API bridge to
 Windows [v2]
In-Reply-To: <UuQ6URXJ5Lk66ORFEuKuLpJYjVH40wRphjg6VWnJFe8=.1dc530af-dfc9-4f6e-8474-3fbcd5f21c51@github.com>
References: <N-BxKFCoKzc7XxBIXg_cq_waTH_1RJtrLHmRyYMLprU=.5e1688bb-7002-4f10-a75b-f645a83cbda5@github.com>
 <VNIToTVXGbc2IIZFTsJmRB0gKywIZPHbgEt6Ofa36C4=.c4cbfcef-5b1d-4d34-af31-8a4f405fca47@github.com>
 <UuQ6URXJ5Lk66ORFEuKuLpJYjVH40wRphjg6VWnJFe8=.1dc530af-dfc9-4f6e-8474-3fbcd5f21c51@github.com>
Message-ID: <YTHFpb6aSAMzkH_5rzrQ6ftHNEEpUeT38VQns6M0KqU=.1da93abe-c63f-408f-a85d-ccde69414a3d@github.com>

On Fri, 30 Jun 2023 11:37:10 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> What's the end goal here? [JDK-6722928](https://bugs.openjdk.org/browse/JDK-6722928)? I'm just wondering because that one will need a CSR, essentially a clone of what [was done for 11u](https://bugs.openjdk.org/browse/JDK-8256559)

Thank you for the review. Yes, you are right. The final goal is to backport the native GSS-API library for Windows on the basis of Windows SSPI APIs (JDK-6722928) and corresponding fixes (like JDK-8225687). The CSR for JDK-6722928 is a part of backport activity, so I'm going to submit it also.

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/335#issuecomment-1615189773