From asotona at openjdk.org  Thu Jun  1 10:15:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 10:15:06 GMT
Subject: RFR: 8308943: jdk.internal.le build fails on AIX [v2]
In-Reply-To: <JLZSQbv8DU9PP1qTPD8OHa1amO6tv4mti6YY1-yorEY=.30e7c130-8dd5-4ecd-9e99-2024ffc455a3@github.com>
References: <JHSLDdbdlIvqLwaIj5e428Yq4fh3knM8dzNOTI9Ln28=.48ac0dff-d607-4c2d-a755-cd5e265bbe7e@github.com>
 <JLZSQbv8DU9PP1qTPD8OHa1amO6tv4mti6YY1-yorEY=.30e7c130-8dd5-4ecd-9e99-2024ffc455a3@github.com>
Message-ID: <vFhUab9R9Mq0RpJxLqzqvSuqcLwo0MLGJVHDyvRSgJE=.af1156a8-a04a-4ce0-8571-98cfc7e17c80@github.com>

On Wed, 31 May 2023 17:15:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A simpler alternative to https://github.com/openjdk/jdk/pull/14176 - it only creates a stub of `JDKNativePty` for AIX, throwing `UnsupportedOperationException`. JLine will then either use the next provider (i.e. "exec", for JShell), or dumb terminal.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing unnecessary import of a class that does not exist for this system.

The code builds for me in simulated AIX profile and it works as expected.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14247#pullrequestreview-1455088942

From jlahoda at openjdk.org  Thu Jun  1 11:16:15 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Jun 2023 11:16:15 GMT
Subject: RFR: 8308943: jdk.internal.le build fails on AIX
In-Reply-To: <nLnpkThhJw5C7XiPK38jn_znrL56ngPxcYbQEN-AM6o=.bd421c59-ce1e-4fb1-b594-54aaa65ba13a@github.com>
References: <nLnpkThhJw5C7XiPK38jn_znrL56ngPxcYbQEN-AM6o=.bd421c59-ce1e-4fb1-b594-54aaa65ba13a@github.com>
Message-ID: <7v8Lo9whO5Cdv-_YvrRidaxr4gCXi2cOFQcUSewvkOA=.864fd9f7-3ae2-486b-83eb-0a4dbfddb19c@github.com>

On Fri, 26 May 2023 11:49:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Build of `jdk.internal.le` fails on AIX, because code in the `unix` directory expects `jdk.internal.org.jline.terminal.impl.jna.JDKNativePty` for each platform (unix-like), but it does not for AIX.
> 
> We could add a stub of this class into the `aix` directory (methods could throw an exception, which would automatically switch JLine into the "external executable" mode, if enabled). But, it might be better to use the `ServiceLoader`, and simply register a platform-specific provider as a service. This patch is attempting to do the latter.

In the end, I've used a simpler version that was done under https://github.com/openjdk/jdk/pull/14247. Thanks for the review/efforts anyway!

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

PR Comment: https://git.openjdk.org/jdk/pull/14176#issuecomment-1571852225

From jlahoda at openjdk.org  Thu Jun  1 11:16:16 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Jun 2023 11:16:16 GMT
Subject: Withdrawn: 8308943: jdk.internal.le build fails on AIX
In-Reply-To: <nLnpkThhJw5C7XiPK38jn_znrL56ngPxcYbQEN-AM6o=.bd421c59-ce1e-4fb1-b594-54aaa65ba13a@github.com>
References: <nLnpkThhJw5C7XiPK38jn_znrL56ngPxcYbQEN-AM6o=.bd421c59-ce1e-4fb1-b594-54aaa65ba13a@github.com>
Message-ID: <aQRiHUanrbSE2gXjBxi1L3IbwYhVVZzzc6ZdvGXqcZA=.f71a9ef6-3d51-49f0-b383-56c871b9b133@github.com>

On Fri, 26 May 2023 11:49:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Build of `jdk.internal.le` fails on AIX, because code in the `unix` directory expects `jdk.internal.org.jline.terminal.impl.jna.JDKNativePty` for each platform (unix-like), but it does not for AIX.
> 
> We could add a stub of this class into the `aix` directory (methods could throw an exception, which would automatically switch JLine into the "external executable" mode, if enabled). But, it might be better to use the `ServiceLoader`, and simply register a platform-specific provider as a service. This patch is attempting to do the latter.

This pull request has been closed without being integrated.

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

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

From jlahoda at openjdk.org  Thu Jun  1 11:17:18 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Jun 2023 11:17:18 GMT
Subject: Integrated: 8308943: jdk.internal.le build fails on AIX
In-Reply-To: <JHSLDdbdlIvqLwaIj5e428Yq4fh3knM8dzNOTI9Ln28=.48ac0dff-d607-4c2d-a755-cd5e265bbe7e@github.com>
References: <JHSLDdbdlIvqLwaIj5e428Yq4fh3knM8dzNOTI9Ln28=.48ac0dff-d607-4c2d-a755-cd5e265bbe7e@github.com>
Message-ID: <XoNdoKgDc5bOyL-9jFkCPWZgsKSxN7otzQF8_5XtOfY=.4d0b4ebd-a93c-4e05-83ca-3b7bc6f8926d@github.com>

On Wed, 31 May 2023 13:12:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A simpler alternative to https://github.com/openjdk/jdk/pull/14176 - it only creates a stub of `JDKNativePty` for AIX, throwing `UnsupportedOperationException`. JLine will then either use the next provider (i.e. "exec", for JShell), or dumb terminal.

This pull request has now been integrated.

Changeset: 6adc242c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6adc242cf33941f1cbaa1f9e920c8700fd59aefc
Stats:     50 lines in 1 file changed: 50 ins; 0 del; 0 mod

8308943: jdk.internal.le build fails on AIX

Reviewed-by: asotona

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

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

From asotona at openjdk.org  Thu Jun  1 14:49:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 14:49:25 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s)
Message-ID: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>

Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.

Please review.

Thanks,
Adam

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

Commit messages:
 - fixed snippets and added SnippetsTest
 - fixed javadoc
 - added Classfile context parameter to ClasRemapper::remapClass
 - records and methods implementations moved from Classfile to ClassfileImpl
 - added Classfile::buildTo override
 - implementation of Classfile::withOptions(Option... options)
 - added test for StackMapsOption.ALWAYS_GENERATE_STACK_MAPS
 - fixed tests
 - fixed options and jdk/classfile tests
 - fixed jdk/classfile tests
 - ... and 9 more: https://git.openjdk.org/jdk/compare/7d2a7ce2...bcdf0f11

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308899
  Stats: 1579 lines in 106 files changed: 478 ins; 195 del; 906 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From liach at openjdk.org  Thu Jun  1 14:49:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Jun 2023 14:49:29 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s)
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <pJ0ZckI59uozf8hx94Vs0OXZG_A9KedB6_ANNvZKgpM=.63cba4b6-5f3e-4818-b330-942f7cc5f001@github.com>

On Fri, 26 May 2023 14:56:57 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

A side comment about the API changes:
I think we should recommend users to store Classfile instances in static final variables if sharing is reasonable, like in Module and BindingSpecializer; this way, we can cache class hierarchy resolution information across builds.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 87:

> 85:      * @param r a function mapping attribute names to attribute mappers
> 86:      */
> 87:     record AttributeMapperOption(Function<Utf8Entry, AttributeMapper<?>> attributeMapper) implements Option {

We might want to convert these options into interfaces and move the implementation records into ClassfileImpl, like Brian suggested about ClassHierarchyInfo.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 208:

> 206:      */
> 207:     default ClassModel parse(byte[] bytes) {
> 208:         return new ClassImpl(bytes, (ClassfileImpl)this);

Should we implement this in ClassfileImpl to avoid the redundant cast?

src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 102:

> 100:      * @return re-mapped class file bytes
> 101:      */
> 102:     default byte[] remapClass(ClassModel clm) {

This api should ask for a Classfile object instead. Thankfully, the new Classfile object actually allows us to find potentially bugs in our code (say if the remapped class refer to declared types outside of system class loader)

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

PR Review: https://git.openjdk.org/jdk/pull/14180#pullrequestreview-1452244549
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1211113876
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1211114779
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1211116312

From asotona at openjdk.org  Thu Jun  1 14:49:30 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 14:49:30 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s)
In-Reply-To: <pJ0ZckI59uozf8hx94Vs0OXZG_A9KedB6_ANNvZKgpM=.63cba4b6-5f3e-4818-b330-942f7cc5f001@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <pJ0ZckI59uozf8hx94Vs0OXZG_A9KedB6_ANNvZKgpM=.63cba4b6-5f3e-4818-b330-942f7cc5f001@github.com>
Message-ID: <yPXU2tkzTy7_4HKwsz4-jef3mjwlU2tg6XhosqFeMvU=.45efafb5-cd16-4e11-9626-40f0e0fb8116@github.com>

On Wed, 31 May 2023 05:42:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 87:
> 
>> 85:      * @param r a function mapping attribute names to attribute mappers
>> 86:      */
>> 87:     record AttributeMapperOption(Function<Utf8Entry, AttributeMapper<?>> attributeMapper) implements Option {
> 
> We might want to convert these options into interfaces and move the implementation records into ClassfileImpl, like Brian suggested about ClassHierarchyInfo.

Will fix it, thanks.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 208:
> 
>> 206:      */
>> 207:     default ClassModel parse(byte[] bytes) {
>> 208:         return new ClassImpl(bytes, (ClassfileImpl)this);
> 
> Should we implement this in ClassfileImpl to avoid the redundant cast?

yes, several methods should move to ClassfileImpl, thanks.

> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 102:
> 
>> 100:      * @return re-mapped class file bytes
>> 101:      */
>> 102:     default byte[] remapClass(ClassModel clm) {
> 
> This api should ask for a Classfile object instead. Thankfully, the new Classfile object actually allows us to find potentially bugs in our code (say if the remapped class refer to declared types outside of system class loader)

yes, I'll add the parameter, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1212084790
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1212094893
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1212117128

From asotona at openjdk.org  Thu Jun  1 15:20:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 15:20:27 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed benchmarks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/bcdf0f11..eae9bed3

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

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

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

From liach at openjdk.org  Thu Jun  1 15:25:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Jun 2023 15:25:12 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
Message-ID: <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>

On Thu, 1 Jun 2023 15:20:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed benchmarks

In fact, I think we can probably mark Classfile as value-based. Then, whether it's created from a factory at every call or if it's cached (my first 2 review comments) no longer matters as much; the caching behavior will be handled by individual option instances (such as class hierarchy caching in the class hierarchy option's resolver)

src/java.base/share/classes/java/lang/Module.java line 1593:

> 1591:     private Class<?> loadModuleInfoClass(InputStream in) throws IOException {
> 1592:         final String MODULE_INFO = "module-info";
> 1593:         var cc = Classfile.of(Classfile.ConstantPoolSharingOption.DO_NOT_SHARE_CONSTANT_POOL);

This `cc` can be stored in a static final field instead.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 55:

> 53: 
> 54:     static Classfile of() {
> 55:         return new ClassfileImpl();

We can create a static final field in `ClassfileImpl` holding a default instance equivalent to that created by `new ClassfileImpl()` and have the `of()` factory return that instance instead.

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 840:

> 838:         try {
> 839:             //clone SplitConstantPool with alternate context
> 840:             var cc = Classfile.of(Classfile.StackMapsOption.DO_NOT_GENERATE_STACK_MAPS);

This should set the Class hierarchy resolver, patch dead code, and filter dead labels options from the original context.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1572260124
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213300095
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213302665
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213314212

From asotona at openjdk.org  Thu Jun  1 19:28:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 19:28:11 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
 <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
Message-ID: <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>

On Thu, 1 Jun 2023 15:04:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed benchmarks
>
> src/java.base/share/classes/java/lang/Module.java line 1593:
> 
>> 1591:     private Class<?> loadModuleInfoClass(InputStream in) throws IOException {
>> 1592:         final String MODULE_INFO = "module-info";
>> 1593:         var cc = Classfile.of(Classfile.ConstantPoolSharingOption.DO_NOT_SHARE_CONSTANT_POOL);
> 
> This `cc` can be stored in a static final field instead.

Yes, we can avoid repeated construction of default class hierarchy resolver here.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 55:
> 
>> 53: 
>> 54:     static Classfile of() {
>> 55:         return new ClassfileImpl();
> 
> We can create a static final field in `ClassfileImpl` holding a default instance equivalent to that created by `new ClassfileImpl()` and have the `of()` factory return that instance instead.

Global static default context will hold global shared cached class hierarchy resolver and that we want to avoid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213583268
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213585474

From asotona at openjdk.org  Thu Jun  1 19:39:12 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 19:39:12 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
 <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
Message-ID: <hnv6pYscv-C_QReT1OLqmmO1XJZlzb5xnEIbpfWzMQQ=.3783bb21-f1e6-498a-bdca-50a320696844@github.com>

On Thu, 1 Jun 2023 15:14:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed benchmarks
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 840:
> 
>> 838:         try {
>> 839:             //clone SplitConstantPool with alternate context
>> 840:             var cc = Classfile.of(Classfile.StackMapsOption.DO_NOT_GENERATE_STACK_MAPS);
> 
> This should set the Class hierarchy resolver, patch dead code, and filter dead labels options from the original context.

Here the other options are irrelevant. The error report wraps already generated incomplete code attribute into a fake class to be able to print details to the error.
I think even the stack map generation suppression is irrelevant here, will double check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213598996

From asotona at openjdk.org  Fri Jun  2 10:47:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Jun 2023 10:47:06 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
 <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
 <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>
Message-ID: <KT4S1E_g7e5V_K70VjcMCr7AhA3rh6O-LX9pjzxbPCs=.cd34c67e-f5c5-4d09-8dc6-b0239fa8031d@github.com>

On Thu, 1 Jun 2023 19:23:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Module.java line 1593:
>> 
>>> 1591:     private Class<?> loadModuleInfoClass(InputStream in) throws IOException {
>>> 1592:         final String MODULE_INFO = "module-info";
>>> 1593:         var cc = Classfile.of(Classfile.ConstantPoolSharingOption.DO_NOT_SHARE_CONSTANT_POOL);
>> 
>> This `cc` can be stored in a static final field instead.
>
> Yes, we can avoid repeated construction of default class hierarchy resolver here.

In this situation the ClassHierarchyResolver is never used and have no caching function.
Adding static field with initializer does not make much sense here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1214214987

From asotona at openjdk.org  Fri Jun  2 11:24:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Jun 2023 11:24:20 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v3]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <MAyCvxZOkEK7oPuPM7JmMZItULNwGpbo0oV6vVoOHM8=.c96f9021-9c7f-417a-81b2-a44c863ea6c3@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona 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 22 additional commits since the last revision:

 - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
 - Merge branch 'master' into JDK-8308899-context
 - fixed benchmarks
 - fixed snippets and added SnippetsTest
 - fixed javadoc
 - added Classfile context parameter to ClasRemapper::remapClass
 - records and methods implementations moved from Classfile to ClassfileImpl
 - added Classfile::buildTo override
 - implementation of Classfile::withOptions(Option... options)
   ClassfileImpl made immutable
   "options" use across implementation renamed to "context"
 - added test for StackMapsOption.ALWAYS_GENERATE_STACK_MAPS
   fixed DirectCodeBuilder and added fast bypass when stack map is not needed
 - ... and 12 more: https://git.openjdk.org/jdk/compare/0945a741...f8915f91

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/eae9bed3..f8915f91

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

  Stats: 20638 lines in 447 files changed: 15729 ins; 1904 del; 3005 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Mon Jun  5 14:31:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 14:31:46 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v4]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <LbUgxZSUkT-Ekx4__NEMMaFw1w_KqVJB0L_DArsJzYk=.61f6c5eb-7999-47f0-a3ef-3397989577b5@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona 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 23 additional commits since the last revision:

 - Merge branch 'master' into JDK-8308899-context
 - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
 - Merge branch 'master' into JDK-8308899-context
 - fixed benchmarks
 - fixed snippets and added SnippetsTest
 - fixed javadoc
 - added Classfile context parameter to ClasRemapper::remapClass
 - records and methods implementations moved from Classfile to ClassfileImpl
 - added Classfile::buildTo override
 - implementation of Classfile::withOptions(Option... options)
   ClassfileImpl made immutable
   "options" use across implementation renamed to "context"
 - ... and 13 more: https://git.openjdk.org/jdk/compare/7990f646...7d431af9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/f8915f91..7d431af9

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

  Stats: 6081 lines in 122 files changed: 4664 ins; 863 del; 554 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Mon Jun  5 14:42:32 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 14:42:32 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v5]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/7d431af9..965dcba8

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

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

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

From briangoetz at openjdk.org  Mon Jun  5 16:38:20 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Mon, 5 Jun 2023 16:38:20 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v5]
In-Reply-To: <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>
Message-ID: <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>

On Mon, 5 Jun 2023 14:42:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed copyright header

Overall this looks pretty clean.  I like how simply it flows through the implementation classes.  There are a number of methods and classes, especially in Classfile, which need some more spec.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 50:

> 48: /**
> 49:  * Main entry points for parsing, transforming, and generating classfiles.
> 50:  */

Now that this is not just a bag of static methods any more, we need to have some spec text about what a Classfile is.  Something like:

Represents a context for parsing, transforming, and generating classfiles.  A `Classfile` has a set of options that condition how parsing and generation is done.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 54:

> 52:         permits ClassfileImpl {
> 53: 
> 54:     static Classfile of() {

Classfile::of needs specification

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 63:

> 61: 
> 62:     Classfile withOptions(Option... options);
> 63: 

Classfile::withOptions needs specification

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 66:

> 64:     /**
> 65:      * An option that affects the writing of classfiles.
> 66:      */

Options affect parsing as well as writing now

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 82:

> 80:     static ConstantPoolBuilder of() {
> 81:         return new SplitConstantPool();
> 82:     }

The old ctors here were (ClassModel) and (Options), where the ClassModel version had a trail of breadcrumbs back to options.  The new ctors are (ClassModel) and no-args, which is a slight departure.  What use did CPB make of options in the first place, if any?

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

PR Review: https://git.openjdk.org/jdk/pull/14180#pullrequestreview-1462788383
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218222043
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218223437
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218223102
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218223991
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218316864

From asotona at openjdk.org  Mon Jun  5 17:42:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 17:42:07 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v5]
In-Reply-To: <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>
 <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>
Message-ID: <WfgarsYk8njBoRYiaNLB9gZxQHK5MGLe2-6SZdeqgDs=.738f4acf-1ee6-466e-a376-e9333d640c98@github.com>

On Mon, 5 Jun 2023 16:30:16 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed copyright header
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 82:
> 
>> 80:     static ConstantPoolBuilder of() {
>> 81:         return new SplitConstantPool();
>> 82:     }
> 
> The old ctors here were (ClassModel) and (Options), where the ClassModel version had a trail of breadcrumbs back to options.  The new ctors are (ClassModel) and no-args, which is a slight departure.  What use did CPB make of options in the first place, if any?

CPB was only holder of options and others took the options from CPB.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218391052

From asotona at openjdk.org  Mon Jun  5 18:23:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 18:23:52 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v6]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <erbC-r7QGPLY-J2CQZ3KalgtekkaS90JX2MmDc9yuBM=.19bbe475-3a07-48a8-a518-4832d9e5f2eb@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - added missing javadoc
 - simplified options names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/965dcba8..9c20d929

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=04-05

  Stats: 81 lines in 20 files changed: 13 ins; 5 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Mon Jun  5 18:23:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 18:23:58 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v5]
In-Reply-To: <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>
 <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>
Message-ID: <xCfunkBUsxMwBz2806kCEjo818D8W0JtqMe6jClZAzE=.cc905cb9-47e2-4d05-8557-e6e840b5d3df@github.com>

On Mon, 5 Jun 2023 15:14:35 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed copyright header
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 50:
> 
>> 48: /**
>> 49:  * Main entry points for parsing, transforming, and generating classfiles.
>> 50:  */
> 
> Now that this is not just a bag of static methods any more, we need to have some spec text about what a Classfile is.  Something like:
> 
> Represents a context for parsing, transforming, and generating classfiles.  A `Classfile` has a set of options that condition how parsing and generation is done.

Fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 54:
> 
>> 52:         permits ClassfileImpl {
>> 53: 
>> 54:     static Classfile of() {
> 
> Classfile::of needs specification

Fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 63:
> 
>> 61: 
>> 62:     Classfile withOptions(Option... options);
>> 63: 
> 
> Classfile::withOptions needs specification

Fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 66:
> 
>> 64:     /**
>> 65:      * An option that affects the writing of classfiles.
>> 66:      */
> 
> Options affect parsing as well as writing now

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218431266
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218431345
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218431300
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218431386

From asotona at openjdk.org  Mon Jun  5 18:59:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 18:59:07 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v7]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <tUOLpZqt3ikr1-fNNxDlS-zfxXF8SKVbuipXpxXJyaM=.c27de293-2ca8-4452-b405-966895376f98@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge branch 'master' into JDK-8308899-context
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
   #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
   #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
   #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - added missing javadoc
 - simplified options names
 - fixed copyright header
 - Merge branch 'master' into JDK-8308899-context
 - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
 - Merge branch 'master' into JDK-8308899-context
 - fixed benchmarks
 - fixed snippets and added SnippetsTest
 - fixed javadoc
 - ... and 17 more: https://git.openjdk.org/jdk/compare/4b8922f5...0c3c1913

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

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=06
  Stats: 1603 lines in 106 files changed: 491 ins; 212 del; 900 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From abimpoudis at openjdk.org  Tue Jun  6 15:12:56 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 6 Jun 2023 15:12:56 GMT
Subject: RFR: 8309235: Unnamed Variables (_) can't be used in JShell
Message-ID: <jtvcEh6_UkpvZWoZ-_iIylqjylG94wsH-zo3vW4HBAc=.709cfa1b-2565-44a5-bada-a72d7f54a312@github.com>

This PR addresses the issue of JShell not accepting unnamed local variables. This solution prints all local variables via the `/vars` command. e.g.,


jshell> int _ = 42;
 ==> 42

jshell> int _ = 43;
 ==> 43

jshell> String _ = "44";
 ==> "44"

jshell> /vars
|    int _ = 42
|    int _ = 43
|    String _ = "44"

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

Commit messages:
 - Remove whitespace
 - 8309235: Unnamed Variables (_) can't be used in JShell

Changes: https://git.openjdk.org/jdk/pull/14337/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14337&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309235
  Stats: 92 lines in 8 files changed: 77 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14337/head:pull/14337

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

From abimpoudis at openjdk.org  Tue Jun  6 15:33:14 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 6 Jun 2023 15:33:14 GMT
Subject: RFR: 8309235: Unnamed Variables (_) can't be used in JShell [v2]
In-Reply-To: <jtvcEh6_UkpvZWoZ-_iIylqjylG94wsH-zo3vW4HBAc=.709cfa1b-2565-44a5-bada-a72d7f54a312@github.com>
References: <jtvcEh6_UkpvZWoZ-_iIylqjylG94wsH-zo3vW4HBAc=.709cfa1b-2565-44a5-bada-a72d7f54a312@github.com>
Message-ID: <VlxjahxWP44lNfXQFciKLt0yYFPGdHs3XGokbjmO8Bs=.89f968d2-de42-4e68-833f-45a87d1e5e8d@github.com>

> This PR addresses the issue of JShell not accepting unnamed local variables. This solution prints all local variables via the `/vars` command. e.g.,
> 
> 
> jshell> int _ = 42;
>  ==> 42
> 
> jshell> int _ = 43;
>  ==> 43
> 
> jshell> String _ = "44";
>  ==> "44"
> 
> jshell> /vars
> |    int _ = 42
> |    int _ = 43
> |    String _ = "44"

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix NPE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14337/files
  - new: https://git.openjdk.org/jdk/pull/14337/files/2e44300a..953b5846

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

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

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

From aturbanov at openjdk.org  Tue Jun  6 15:45:58 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 6 Jun 2023 15:45:58 GMT
Subject: RFR: 8309235: Unnamed Variables (_) can't be used in JShell [v2]
In-Reply-To: <VlxjahxWP44lNfXQFciKLt0yYFPGdHs3XGokbjmO8Bs=.89f968d2-de42-4e68-833f-45a87d1e5e8d@github.com>
References: <jtvcEh6_UkpvZWoZ-_iIylqjylG94wsH-zo3vW4HBAc=.709cfa1b-2565-44a5-bada-a72d7f54a312@github.com>
 <VlxjahxWP44lNfXQFciKLt0yYFPGdHs3XGokbjmO8Bs=.89f968d2-de42-4e68-833f-45a87d1e5e8d@github.com>
Message-ID: <otF2AK0Ylxcf5TF7cfDxE7baJ7toCh7vc6jb2qd6bMQ=.66ce8cf5-501c-4f15-ad85-b81811d20df2@github.com>

On Tue, 6 Jun 2023 15:33:14 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR addresses the issue of JShell not accepting unnamed local variables. This solution prints all local variables via the `/vars` command. e.g.,
>> 
>> 
>> jshell> int _ = 42;
>>  ==> 42
>> 
>> jshell> int _ = 43;
>>  ==> 43
>> 
>> jshell> String _ = "44";
>>  ==> "44"
>> 
>> jshell> /vars
>> |    int _ = 42
>> |    int _ = 43
>> |    String _ = "44"
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix NPE

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java line 3354:

> 3352:                     : getResourceString("jshell.msg.vars.not.active");
> 3353:             String varName = vk.name();
> 3354:             hard("  %s %s = %s", vk.typeName(),  varName.isEmpty() ? "_" : varName, val);

Suggestion:

            hard("  %s %s = %s", vk.typeName(), varName.isEmpty() ? "_" : varName, val);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14337#discussion_r1219887603

From asotona at openjdk.org  Wed Jun  7 17:44:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 7 Jun 2023 17:44:46 GMT
Subject: RFR: 8309235: Unnamed Variables (_) can't be used in JShell [v2]
In-Reply-To: <VlxjahxWP44lNfXQFciKLt0yYFPGdHs3XGokbjmO8Bs=.89f968d2-de42-4e68-833f-45a87d1e5e8d@github.com>
References: <jtvcEh6_UkpvZWoZ-_iIylqjylG94wsH-zo3vW4HBAc=.709cfa1b-2565-44a5-bada-a72d7f54a312@github.com>
 <VlxjahxWP44lNfXQFciKLt0yYFPGdHs3XGokbjmO8Bs=.89f968d2-de42-4e68-833f-45a87d1e5e8d@github.com>
Message-ID: <cW6G-TdmFgyGzkR_gyrwQwA8QdcHW783sJ3nj7um8JU=.8eb92fd3-9ac1-4ced-99f3-a57140c5fcb7@github.com>

On Tue, 6 Jun 2023 15:33:14 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR addresses the issue of JShell not accepting unnamed local variables. This solution prints all local variables via the `/vars` command. e.g.,
>> 
>> 
>> jshell> int _ = 42;
>>  ==> 42
>> 
>> jshell> int _ = 43;
>>  ==> 43
>> 
>> jshell> String _ = "44";
>>  ==> "44"
>> 
>> jshell> /vars
>> |    int _ = 42
>> |    int _ = 43
>> |    String _ = "44"
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix NPE

Looks good ?

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14337#pullrequestreview-1468252642

From abimpoudis at openjdk.org  Thu Jun  8 07:26:16 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 8 Jun 2023 07:26:16 GMT
Subject: RFR: 8309235: Unnamed Variables (_) can't be used in JShell [v3]
In-Reply-To: <jtvcEh6_UkpvZWoZ-_iIylqjylG94wsH-zo3vW4HBAc=.709cfa1b-2565-44a5-bada-a72d7f54a312@github.com>
References: <jtvcEh6_UkpvZWoZ-_iIylqjylG94wsH-zo3vW4HBAc=.709cfa1b-2565-44a5-bada-a72d7f54a312@github.com>
Message-ID: <Td9QJPkv-pyqouYtFqmdfXQUcXJU2QySrrmcpOkf8mA=.bb402375-ef8d-46d3-92aa-7c9fb21b7e12@github.com>

> This PR addresses the issue of JShell not accepting unnamed local variables. This solution prints all local variables via the `/vars` command. e.g.,
> 
> 
> jshell> int _ = 42;
>  ==> 42
> 
> jshell> int _ = 43;
>  ==> 43
> 
> jshell> String _ = "44";
>  ==> "44"
> 
> jshell> /vars
> |    int _ = 42
> |    int _ = 43
> |    String _ = "44"

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14337/files
  - new: https://git.openjdk.org/jdk/pull/14337/files/953b5846..970a7635

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

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

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

From abimpoudis at openjdk.org  Thu Jun  8 07:28:59 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 8 Jun 2023 07:28:59 GMT
Subject: Integrated: 8309235: Unnamed Variables (_) can't be used in JShell
In-Reply-To: <jtvcEh6_UkpvZWoZ-_iIylqjylG94wsH-zo3vW4HBAc=.709cfa1b-2565-44a5-bada-a72d7f54a312@github.com>
References: <jtvcEh6_UkpvZWoZ-_iIylqjylG94wsH-zo3vW4HBAc=.709cfa1b-2565-44a5-bada-a72d7f54a312@github.com>
Message-ID: <dqUAhjBDX6aijmChikftCZb_99pyXqrOWwMTT-4j4kc=.314fa96e-aa8b-46bc-b733-bdc9d09c9191@github.com>

On Tue, 6 Jun 2023 14:59:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR addresses the issue of JShell not accepting unnamed local variables. This solution prints all local variables via the `/vars` command. e.g.,
> 
> 
> jshell> int _ = 42;
>  ==> 42
> 
> jshell> int _ = 43;
>  ==> 43
> 
> jshell> String _ = "44";
>  ==> "44"
> 
> jshell> /vars
> |    int _ = 42
> |    int _ = 43
> |    String _ = "44"

This pull request has now been integrated.

Changeset: 79a4ac79
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79a4ac791c826656b3e984fe54dc472c62efd028
Stats:     92 lines in 8 files changed: 77 ins; 1 del; 14 mod

8309235: Unnamed Variables (_) can't be used in JShell

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: asotona

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

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

From asotona at openjdk.org  Thu Jun  8 09:26:10 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 09:26:10 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v8]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
   introduction of ClassHierarchyResolver::ofSystem factory method
   ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
 - Merge branch 'master' into JDK-8308899-context
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/Options.java
   #	src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java
   #	test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
   #	test/jdk/jdk/classfile/VerifierSelfTest.java
 - Merge branch 'master' into JDK-8308899-context
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
   #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
   #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
   #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - added missing javadoc
 - simplified options names
 - fixed copyright header
 - Merge branch 'master' into JDK-8308899-context
 - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
 - Merge branch 'master' into JDK-8308899-context
 - fixed benchmarks
 - ... and 19 more: https://git.openjdk.org/jdk/compare/ac3ce2bf...aa691842

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

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=07
  Stats: 1651 lines in 109 files changed: 501 ins; 244 del; 906 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From briangoetz at openjdk.org  Thu Jun  8 11:11:52 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 8 Jun 2023 11:11:52 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v8]
In-Reply-To: <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
Message-ID: <pzg4x9XGLRC73o4OFTiP7eU3mkZnSNpnnHoPrPVsesQ=.61e1783b-c1ba-47c7-8b3f-574043f0c7c6@github.com>

On Thu, 8 Jun 2023 09:26:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>    introduction of ClassHierarchyResolver::ofSystem factory method
>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>  - Merge branch 'master' into JDK-8308899-context
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/Options.java
>    #	src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java
>    #	test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
>    #	test/jdk/jdk/classfile/VerifierSelfTest.java
>  - Merge branch 'master' into JDK-8308899-context
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
>    #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
>    #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
>    #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
>    #	test/jdk/jdk/classfile/StackMapsTest.java
>  - added missing javadoc
>  - simplified options names
>  - fixed copyright header
>  - Merge branch 'master' into JDK-8308899-context
>  - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
>  - Merge branch 'master' into JDK-8308899-context
>  - fixed benchmarks
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/ac3ce2bf...aa691842

Agreed.? The need for sync came from the shared static cache.

On 6/8/2023 7:07 AM, liach wrote:
>
> ***@***.**** commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In 
> src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java 
> <https://github.com/openjdk/jdk/pull/14180#discussion_r1222886769>:
>
> >       */
> -    static ClassHierarchyResolver defaultResolver() {
> -        return ClassHierarchyImpl.DEFAULT_RESOLVER;
> +    static ClassHierarchyResolver ofSystem() {
> +        var sysLoader = ClassLoader.getSystemClassLoader();
> +        return ClassHierarchyResolver
> +            .ofResourceParsing(sysLoader)
> +            .orElse(ClassHierarchyResolver.ofClassLoading(sysLoader))
> +            .cached(new Supplier<>() {
> +                @Override
> +                public Map<ClassDesc, ClassHierarchyResolver.ClassHierarchyInfo> get() {
> +                    return new ConcurrentHashMap<>();
>
> Don't think we need to synchronize the cache if we have dedicated CHRs.
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://github.com/openjdk/jdk/pull/14180#pullrequestreview-1469667725>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/AABJ4REUYN64IMQFDM5XPO3XKGW7JANCNFSM6AAAAAAYQLACYQ>.
> You are receiving this because you commented.Message ID: 
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582385327

From liach at openjdk.org  Thu Jun  8 11:11:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Jun 2023 11:11:54 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v8]
In-Reply-To: <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
Message-ID: <n-8npYheFCO9G3t4SEjIzMJgueklY-kPfYJNBal1T_Y=.5cb92ce8-1ccd-430c-b130-802efd92b08a@github.com>

On Thu, 8 Jun 2023 09:26:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>    introduction of ClassHierarchyResolver::ofSystem factory method
>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>  - Merge branch 'master' into JDK-8308899-context
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/Options.java
>    #	src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java
>    #	test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
>    #	test/jdk/jdk/classfile/VerifierSelfTest.java
>  - Merge branch 'master' into JDK-8308899-context
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
>    #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
>    #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
>    #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
>    #	test/jdk/jdk/classfile/StackMapsTest.java
>  - added missing javadoc
>  - simplified options names
>  - fixed copyright header
>  - Merge branch 'master' into JDK-8308899-context
>  - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
>  - Merge branch 'master' into JDK-8308899-context
>  - fixed benchmarks
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/ac3ce2bf...aa691842

src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java line 66:

> 64:                 @Override
> 65:                 public Map<ClassDesc, ClassHierarchyResolver.ClassHierarchyInfo> get() {
> 66:                     return new ConcurrentHashMap<>();

Don't think we need to synchronize the cache if we have dedicated CHRs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1222886769

From asotona at openjdk.org  Thu Jun  8 11:26:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 11:26:39 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v9]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassHierarchyResolver::ofSystem is now thread-unsafe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/aa691842..f3099cd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=07-08

  Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Thu Jun  8 11:26:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 11:26:43 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v8]
In-Reply-To: <n-8npYheFCO9G3t4SEjIzMJgueklY-kPfYJNBal1T_Y=.5cb92ce8-1ccd-430c-b130-802efd92b08a@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
 <n-8npYheFCO9G3t4SEjIzMJgueklY-kPfYJNBal1T_Y=.5cb92ce8-1ccd-430c-b130-802efd92b08a@github.com>
Message-ID: <K48k_NhTJaYNJ8ZdIufM5tvaMlkM7C2adLXbCKRNIFI=.ad78e05c-063c-4275-855d-e06bb235aacb@github.com>

On Thu, 8 Jun 2023 11:07:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>>    introduction of ClassHierarchyResolver::ofSystem factory method
>>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>>  - Merge branch 'master' into JDK-8308899-context
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/classfile/impl/Options.java
>>    #	src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java
>>    #	test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
>>    #	test/jdk/jdk/classfile/VerifierSelfTest.java
>>  - Merge branch 'master' into JDK-8308899-context
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
>>    #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
>>    #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
>>    #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
>>    #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
>>    #	test/jdk/jdk/classfile/StackMapsTest.java
>>  - added missing javadoc
>>  - simplified options names
>>  - fixed copyright header
>>  - Merge branch 'master' into JDK-8308899-context
>>  - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
>>  - Merge branch 'master' into JDK-8308899-context
>>  - fixed benchmarks
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/ac3ce2bf...aa691842
>
> src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java line 66:
> 
>> 64:                 @Override
>> 65:                 public Map<ClassDesc, ClassHierarchyResolver.ClassHierarchyInfo> get() {
>> 66:                     return new ConcurrentHashMap<>();
> 
> Don't think we need to synchronize the cache if we have dedicated CHRs.

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1222902932

From asotona at openjdk.org  Thu Jun  8 13:26:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 13:26:55 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v9]
In-Reply-To: <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>
Message-ID: <BtKBI04H2enVA_iX7hBDqSIZPjGdtRrysVo4zJJIobc=.37f6497b-b922-4830-b3ad-89b0b7d0b658@github.com>

On Thu, 8 Jun 2023 11:26:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassHierarchyResolver::ofSystem is now thread-unsafe

Unfortunately thread-unsafe context makes sharing of it in tests executed in parallel a nightmare.
I can fix our Corpus tests and hope the race condition won't raise also somewhere else later.
However how to explain this limitation to users?

I suggest to make it always thread-safe (as the context is primary expected to be shared in multi-threaded environment) and users may make it faster in specific cases by providing non-synchronized map.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582576426

From asotona at openjdk.org  Thu Jun  8 13:37:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 13:37:33 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
  
  This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/f3099cd5..41fdb2fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=08-09

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From briangoetz at openjdk.org  Thu Jun  8 14:09:58 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 8 Jun 2023 14:09:58 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
Message-ID: <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>

On Thu, 8 Jun 2023 13:37:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>   
>   This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.

Most entities in the system are immutable and therefore freely sharable 
without additional coordination.? Some have lazily-inflated single-field 
caches that conform to the "benign race" (there is only one possible 
non-default value) criteria.

The main hole is the CHA resolution cache.? There are two ways to 
address this: protect the cache, or don't share the context.

Unfortunately now that ClassModel refers back to the context, there's a 
risk of unexpected context sharing.? Here are a few options:

 ?- Make the CHA cache thread-safe using, say, CHM;
 ?- Make the CHA cache unshared, by using a ThreadLocal (this brings the 
context back to being immutable)
 ?- Detect when implicit use of a context happens on a thread other than 
the creating thread (currently the only vector for this is 
Classfile::transform), and inflate a new context with empty cache in 
that case;
 ?- Always create a fresh context with an empty cache in 
Classfile::transform





On 6/8/2023 9:24 AM, Adam Sotona wrote:
>
> Unfortunately thread-unsafe context makes sharing of it in tests 
> executed in parallel a nightmare.
> I can fix our Corpus tests and hope the race condition won't raise 
> also somewhere else later.
> However how to explain this limitation to users?
>
> I suggest to make it always thread-safe (as the context is primary 
> expected to be shared in multi-threaded environment) and users may 
> make it faster in specific cases by providing non-synchronized map.
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://github.com/openjdk/jdk/pull/14180#issuecomment-1582576426>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/AABJ4RHSMWR5Q3ANYK3RPSLXKHG7RANCNFSM6AAAAAAYQLACYQ>.
> You are receiving this because you commented.Message ID: 
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582643016

From adam.sotona at oracle.com  Thu Jun  8 15:00:00 2023
From: adam.sotona at oracle.com (Adam Sotona)
Date: Thu, 8 Jun 2023 15:00:00 +0000
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
 <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>
Message-ID: <CY4PR1001MB21509683FB0276CE208A58D28C50A@CY4PR1001MB2150.namprd10.prod.outlook.com>



From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Brian Goetz <briangoetz at openjdk.org>

Most entities in the system are immutable and therefore freely sharable
without additional coordination.  Some have lazily-inflated single-field
caches that conform to the "benign race" (there is only one possible
non-default value) criteria.

The main hole is the CHA resolution cache.  There are two ways to
address this: protect the cache, or don't share the context.

Unfortunately now that ClassModel refers back to the context, there's a
risk of unexpected context sharing.  Here are a few options:

  - Make the CHA cache thread-safe using, say, CHM;
This is current solution for the default system CH cache. We may also remove ClassHierarchyResolver::cached() method to force user think about it and always call ClassHierarchyResolver::cached(Supplier<Map<ClassDesc, ClassHierarchyInfo>> cacheFactory) for all non-default cases.
Or we may also use a bit less strict custom semi-synchronization (just enough to be thread safe) instead of fully-synchronized CHM::computeIfAbsent, for example CHM:get ? <compute if absent without lock> ... CHM::put.

  - Make the CHA cache unshared, by using a ThreadLocal (this brings the
context back to being immutable)
This is interesting option for small number of threads, however it makes big footprint for heavy-parallel systems.

  - Detect when implicit use of a context happens on a thread other than
the creating thread (currently the only vector for this is
Classfile::transform), and inflate a new context with empty cache in
that case;
This would degrade the caching completely by triggering a new context for each transformed method in case there are two threads working synchronously.

  - Always create a fresh context with an empty cache in
Classfile::transform
This would destroy the caching. Such cache would work only in scope of one method.






On 6/8/2023 9:24 AM, Adam Sotona wrote:
>
> Unfortunately thread-unsafe context makes sharing of it in tests
> executed in parallel a nightmare.
> I can fix our Corpus tests and hope the race condition won't raise
> also somewhere else later.
> However how to explain this limitation to users?
>
> I suggest to make it always thread-safe (as the context is primary
> expected to be shared in multi-threaded environment) and users may
> make it faster in specific cases by providing non-synchronized map.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/14180#issuecomment-1582576426>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABJ4RHSMWR5Q3ANYK3RPSLXKHG7RANCNFSM6AAAAAAYQLACYQ>.
> You are receiving this because you commented.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582643016
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230608/6a5f965b/attachment-0001.htm>

From asotona at openjdk.org  Thu Jun  8 16:11:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 16:11:49 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
 <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>
Message-ID: <hwyMC0TxWo_6aLxzM6bxorHhCLQsMrUxKfMjV_VLrq8=.233f074a-de21-4cee-b844-2d2a08a58339@github.com>

On Thu, 8 Jun 2023 14:07:24 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>  Here are a few options: 
?- Make the CHA cache thread-safe using, say, CHM; 

This is current solution for the default system CH cache. 

We may also use a bit less strict custom semi-synchronization (just enough to be thread safe) instead of fully-synchronized `CHM::computeIfAbsent`, for example `CHM:get ? (compute if absent without lock) ... CHM::put`.
CHM does not lock on get, so the only penalty would be synchronous put call. 

>?- Make the CHA cache unshared, by using a ThreadLocal (this brings the context back to being immutable)

This is interesting option for small number of threads, however it makes big footprint for heavy-parallel systems.

>?- Detect when implicit use of a context happens on a thread other than the creating thread (currently the only vector for this is Classfile::transform), and inflate a new context with empty cache in that case;

This would degrade the caching completely by triggering a new context for each transformed method in case there are two threads working synchronously.

>?- Always create a fresh context with an empty cache in Classfile::transform

This would destroy the caching. Such cache would work only in scope of one method.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582943385

From asotona at openjdk.org  Thu Jun  8 16:37:22 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 16:37:22 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - proposed semi-synchronized caching, where the map is not locked during delegate call
 - used Factory.INSTANCE for system ClassHierarchyResolver cache

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/41fdb2fc..ae287751

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=09-10

  Stats: 28 lines in 2 files changed: 13 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From briangoetz at openjdk.org  Thu Jun  8 16:37:45 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 8 Jun 2023 16:37:45 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
Message-ID: <QU1ZsVotsQTwtlp6E42zqsDWiB4stkj4lJbO1yZQz5c=.a5030342-8858-4bb2-9bdf-992ccfd44dda@github.com>

On Thu, 8 Jun 2023 13:37:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>   
>   This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.

On 6/8/2023 12:09 PM, Adam Sotona wrote:
>
>     Here are a few options:
>     ?- Make the CHA cache thread-safe using, say, CHM;
>
> This is current solution for the default system CH cache.
>
> We may also use a bit less strict custom semi-synchronization (just 
> enough to be thread safe) instead of fully-synchronized 
> |CHM::computeIfAbsent|, for example |CHM:get ? (compute if absent 
> without lock) ... CHM::put|.
> CHM does not lock on get, so the only penalty would be synchronous put 
> call.
>
>     ?- Make the CHA cache unshared, by using a ThreadLocal (this
>     brings the context back to being immutable)
>
> This is interesting option for small number of threads, however it 
> makes big footprint for heavy-parallel systems.
>

I have a hard time imagining heavy parallel use here; concurrency 
against the same cache would most likely come from accidental sharing.? 
So this is not necessarily a problem.? Are you imagining differnet use 
cases?

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1583003584

From brian.goetz at oracle.com  Thu Jun  8 19:57:54 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 8 Jun 2023 15:57:54 -0400
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v9]
In-Reply-To: <BtKBI04H2enVA_iX7hBDqSIZPjGdtRrysVo4zJJIobc=.37f6497b-b922-4830-b3ad-89b0b7d0b658@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>
 <BtKBI04H2enVA_iX7hBDqSIZPjGdtRrysVo4zJJIobc=.37f6497b-b922-4830-b3ad-89b0b7d0b658@github.com>
Message-ID: <2cff101c-d1cb-e557-ff16-cf8240c6f799@oracle.com>

I still don't understand this point.? Why are separate tests sharing a 
context at all?

On 6/8/2023 9:26 AM, Adam Sotona wrote:
> Unfortunately thread-unsafe context makes sharing of it in tests executed in parallel a nightmare.
> I can fix our Corpus tests and hope the race condition won't raise also somewhere else later.
> However how to explain this limitation to users?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230608/affe7e76/attachment-0001.htm>

From asotona at openjdk.org  Fri Jun  9 06:19:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 9 Jun 2023 06:19:42 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <QU1ZsVotsQTwtlp6E42zqsDWiB4stkj4lJbO1yZQz5c=.a5030342-8858-4bb2-9bdf-992ccfd44dda@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
 <QU1ZsVotsQTwtlp6E42zqsDWiB4stkj4lJbO1yZQz5c=.a5030342-8858-4bb2-9bdf-992ccfd44dda@github.com>
Message-ID: <XNBfxW7noKrBQYi3Mx-3-L5W00lROMimOKlL6jm6jjI=.24394135-e32f-46e8-bc8e-56cfcaba7265@github.com>

On Thu, 8 Jun 2023 16:35:28 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

> I have a hard time imagining heavy parallel use here; concurrency against the same cache would most likely come from accidental sharing.? So this is not necessarily a problem.? Are you imagining differnet use cases?

I think it is common practice for example in web services to pre-configure as much of the common parts as possible (and Classfile context logically falls into that category) and then register the service to the server, which use group of thread workers to handle individual requests.
With (non-reusable) virtual threads and structured concurrency on the table makes internal use of thread locals even less sense. I can imagine a new virtual thread launched (and finished) for each individual transformation. Our `CorpusTest` relying on Junit parallelization  is not so far from that scenario (I'm not sure if Junit already uses virtual threads or just a group of workers).

It is technically irrelevant if user will share the context directly or through a `ClassModel` (for example an instrumentor class used to transform all incoming code - this BTW an idea of faster `j.l.r.ProxyGenerator` I'm thinking about). I think we should be sure that `Classfile` context (and also expansion of `ClassModel`) does not fail in parallel environments.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1584034695

From asotona at openjdk.org  Fri Jun  9 06:38:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 9 Jun 2023 06:38:47 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
Message-ID: <I1oi--jOrgA4cAMIQhpiL7q3DdHCxMWaf6To9d0LGGU=.73eb9ca8-941c-4283-9154-dfce8d0594a2@github.com>

On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache

I'll run our standard benchmarks to compare following scenarios:
- static synchronized single instance cache (current master)
- context-based non-synchronized caches  `HM::computeIfAbsent`
- context-based fully synchronized caches `CHM::computeIfAbsent`
- context-based thread-safe lazy synchronized caches `CHM::get ... compute ... CHM::put`

And let's see the performance impact.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1584050539

From adam.sotona at oracle.com  Fri Jun  9 06:54:54 2023
From: adam.sotona at oracle.com (Adam Sotona)
Date: Fri, 9 Jun 2023 06:54:54 +0000
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v9]
In-Reply-To: <2cff101c-d1cb-e557-ff16-cf8240c6f799@oracle.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>
 <BtKBI04H2enVA_iX7hBDqSIZPjGdtRrysVo4zJJIobc=.37f6497b-b922-4830-b3ad-89b0b7d0b658@github.com>
 <2cff101c-d1cb-e557-ff16-cf8240c6f799@oracle.com>
Message-ID: <CY4PR1001MB215054D2CB7F056FAFA0D0F08C51A@CY4PR1001MB2150.namprd10.prod.outlook.com>

The tests use statically specified Transforms and each transformation also held set of options.
Now the transformations hold static instance of Classfile context instead.
Junit execute them in parallel for each individual class file being transformed, so one context is used in parallel environment.
If we fall back to store List<Option> and create new Classfile context for each invocation ? we will degrade the performance significantly (starting always with an empty cache).
Trying to stick Classfile context with thread locality is possible, however it requires to re-design our CorpusTest and Transforms and performance will be randomly dependent on Junit decision about threads assignment. Also Junit may silently move to virtual threads (unless it already did) and performance will be back to an empty cache for each invocation.


From: Brian Goetz <brian.goetz at oracle.com>
Date: Thursday, 8 June 2023 21:58
To: Adam Sotona <asotona at openjdk.org>, core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>, kulla-dev at openjdk.org <kulla-dev at openjdk.org>
Subject: Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v9]
I still don't understand this point.  Why are separate tests sharing a context at all?
On 6/8/2023 9:26 AM, Adam Sotona wrote:

Unfortunately thread-unsafe context makes sharing of it in tests executed in parallel a nightmare.

I can fix our Corpus tests and hope the race condition won't raise also somewhere else later.

However how to explain this limitation to users?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230609/68a83b95/attachment-0001.htm>

From brian.goetz at oracle.com  Fri Jun  9 11:02:33 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 9 Jun 2023 07:02:33 -0400
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <I1oi--jOrgA4cAMIQhpiL7q3DdHCxMWaf6To9d0LGGU=.73eb9ca8-941c-4283-9154-dfce8d0594a2@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
 <I1oi--jOrgA4cAMIQhpiL7q3DdHCxMWaf6To9d0LGGU=.73eb9ca8-941c-4283-9154-dfce8d0594a2@github.com>
Message-ID: <e5b34f5e-216c-8938-b91a-5836b6b01541@oracle.com>

Observation: It's dramatic how injecting a tiny amount of shared mutable 
state ripples throughout the design.

After thinking about this some more, I think the main problem is that we 
are still trying to have the cache be transparent, which means that 
Classfile is taking on all the complexity of unbounded shared mutability 
"just in case" the user wants some.

The other part of this refactor, which we've not done yet, is 
refactoring the caching of the CHR data (through Option) so it is more 
explicit.? I think part of what we're running into here is that we've 
not done that part yet, so we are stills stuck in the as-if-static world.

So let's take a step back and sketch out what the CHR/caching options 
might look like.? If we make caching explicit, we can make sharability 
explicit too, and then we are not trying to add thread-safety back into 
a seemingly-immutable-but-not-really object.

On 6/9/2023 2:38 AM, Adam Sotona wrote:
> On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona<asotona at openjdk.org>  wrote:
>
>>> Classfile context object and multi-state options have been discussed athttps://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>>>
>>> Please review.
>>>
>>> Thanks,
>>> Adam
>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>>
>>   - proposed semi-synchronized caching, where the map is not locked during delegate call
>>   - used Factory.INSTANCE for system ClassHierarchyResolver cache
> I'll run our standard benchmarks to compare following scenarios:
> - static synchronized single instance cache (current master)
> - context-based non-synchronized caches  `HM::computeIfAbsent`
> - context-based fully synchronized caches `CHM::computeIfAbsent`
> - context-based thread-safe lazy synchronized caches `CHM::get ... compute ... CHM::put`
>
> And let's see the performance impact.
>
> -------------
>
> PR Comment:https://git.openjdk.org/jdk/pull/14180#issuecomment-1584050539
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230609/e065f743/attachment.htm>

From asotona at openjdk.org  Fri Jun  9 11:35:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 9 Jun 2023 11:35:48 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
Message-ID: <Zy8zwtxdiqQ9MTETR6eWNdc27qul2XiDlE8rG5C3Z-I=.e9e1877f-31ac-4a37-b14a-b79a629391fa@github.com>

On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache

I've performed a lot of benchmarking and the key result is that introduction of `Classfile` context (or rather say context specific CHR instead of global static field) cause a lot of regressions in our benchmarks.

Below are aggregated only relative results of benchmarks with significant regressions.
Current `master` with global static cache instance is the base for relative regressions in the table.
- `ConcurrentHashMap::computeIfAbsent` represents the initial fully-synchronized cache implementation.
- `HashMap::computeIfAbsent` is the thread-unsafe option.
- `ConcurrentHashMap::get and put` is the lazy-synchronized solution
- **Always create a fresh context with an empty cache** is what Brian proposed as one of the options
- **Class loading with local cache only** is a step back to what ASM is using.


Interesting point is that **Always create a fresh context with an empty cache** works with similar performance as the others, except for `GenerateStackMaps.benchmark`, where it causes significant regression.

**Class loading with local cache only** assumes `ClassLoader` would do the caching for us. Even the class loading is initially slower and does not work for all use cases, it may be the best for the default CHR. And we could skip any `CHR::cached` in the API. 

Also interesting is that `ConcurrentHashMap::computeIfAbsent` cause 10% regression of **ParseOptions.transformNoStackmap** benchmark, where it should have no or minimal effect.

? | `ConcurrentHashMap::computeIfAbsent` | `HashMap::computeIfAbsent` | `ConcurrentHashMap::get and put` | Always create a fresh context with an empty cache | Class loading with local cache only
-- | -- | -- | -- | -- | --
AdHocAdapt.transform LIFT | -19% | -17% | -16% | -17% | -17%
AdHocAdapt.transform LIFT1 | -24% | -25% | -23% | -26% | -23%
AdHocAdapt.transform LIFT2 | -23% | -26% | -23% | -25% | -23%
AdaptInjectNoop.transform NOP_SHARED | -16% | -19% | -16% | -18% | -7%
AdaptNull.transform SHARED_3 | -18% | -21% | -19% | -17% | -18%
AdaptNull.transform SHARED_3_NO_DEBUG | -22% | -22% | -25% | -21% | -22%
GenerateStackMaps.benchmark | ? | ? | ? | -27% | ?
ParseOptions.transformNoDebug | -31% | -20% | -20% | -19% | -18%
ParseOptions.transformNoLineNumbers | -25% | -24% | -20% | -20% | -20%
ParseOptions.transformNoStackmap | -10% | ? | ? | ? | ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1584430448

From briangoetz at openjdk.org  Fri Jun  9 11:47:47 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Fri, 9 Jun 2023 11:47:47 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
Message-ID: <fw7mnM-TCfmyIIRzZ4SUvoj_oqqGYpiYzLU21LEq5mQ=.2a85f959-ec34-4730-bec0-7e29bb9ea737@github.com>

On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache

FWIW: I have found AdaptNull.SHARED_3 to be among the most useful 
benchmarks for finding unexpected regressions.

I think there's something fishy going on.? Given that the baseline 
(static shared cache) has to protect against concurrent access already, 
and that there should be little or no other significant difference 
between the static version and the context version aside from caching, I 
can't see how those differences explain these regressions.? Are we 
making an apples-to-apples comparison of what CHR algorithm we're using? 
Is the creation of the CHR instances is perturbing the results?

Let's try to take CHR operation out of the equation: runt both baseline 
and context versions using a CHR that does almost nothing (e.g., says 
LUB(a,b) is always Object) or which uses a precomputed static cache.? 
I'm guessing this shows no regression, and if so, this will likely tell 
us that the _context_ refactor is not the problem, but attempting to 
unshare the CHR cache.? Then we can drill into that problem.



On 6/9/2023 7:31 AM, Adam Sotona wrote:
>
> I've performed a lot of benchmarking and the key result is that 
> introduction of |Classfile| context cause a lot of regressions in our 
> benchmarks.
>
> Below are aggregated only relative results of benchmarks with 
> significant regressions.
> Current |master| with global static cache instance is a base for the 
> relative regressions in the table.
>
>   * |ConcurrentHashMap::computeIfAbsent| represents the initial
>     fully-synchronized cache implementation.
>   * |HashMap::computeIfAbsent| is the thread-unsafe option.
>   * |ConcurrentHashMap::get and put| is the lazy-synchronized solution
>   * *Always create a fresh context with an empty cache* is what Brian
>     proposed as one of the options
>   * *Class loading with local cache only* is a step back to what ASM
>     is using.
>
> Interesting point is that *Always create a fresh context with an empty 
> cache* works with similar performance as the others, except for 
> |GenerateStackMaps.benchmark|, where it causes significant regression.
>
> *Class loading with local cache only* assumes |ClassLoader| would do 
> the caching for us. Even the class loading is initially slower and 
> does not work for all use cases, it may be the best for the default 
> CHR. And we could skip any |CHR::cached| in the API.
>
> Also interesting is that |ConcurrentHashMap::computeIfAbsent| cause 
> 10% regression of *ParseOptions.transformNoStackmap* benchmark, where 
> it should have no or minimal effect.
>
> 	|ConcurrentHashMap::computeIfAbsent| 	|HashMap::computeIfAbsent| 
> |ConcurrentHashMap::get and put| 	Always create a fresh context with 
> an empty cache 	Class loading with local cache only
> AdHocAdapt.transform LIFT 	-19% 	-17% 	-16% 	-17% 	-17%
> AdHocAdapt.transform LIFT1 	-24% 	-25% 	-23% 	-26% 	-23%
> AdHocAdapt.transform LIFT2 	-23% 	-26% 	-23% 	-25% 	-23%
> AdaptInjectNoop.transform NOP_SHARED 	-16% 	-19% 	-16% 	-18% 	-7%
> AdaptNull.transform SHARED_3 	-18% 	-21% 	-19% 	-17% 	-18%
> AdaptNull.transform SHARED_3_NO_DEBUG 	-22% 	-22% 	-25% 	-21% 	-22%
> GenerateStackMaps.benchmark 				-27% 	
> ParseOptions.transformNoDebug 	-31% 	-20% 	-20% 	-19% 	-18%
> ParseOptions.transformNoLineNumbers 	-25% 	-24% 	-20% 	-20% 	-20%
> ParseOptions.transformNoStackmap 	-10% 				
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://github.com/openjdk/jdk/pull/14180#issuecomment-1584430448>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/AABJ4RD7CBCQU3MSP4LJVILXKMCP3ANCNFSM6AAAAAAYQLACYQ>.
> You are receiving this because you commented.Message ID: 
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1584445113

From adam.sotona at oracle.com  Fri Jun  9 13:23:11 2023
From: adam.sotona at oracle.com (Adam Sotona)
Date: Fri, 9 Jun 2023 13:23:11 +0000
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <fw7mnM-TCfmyIIRzZ4SUvoj_oqqGYpiYzLU21LEq5mQ=.2a85f959-ec34-4730-bec0-7e29bb9ea737@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
 <fw7mnM-TCfmyIIRzZ4SUvoj_oqqGYpiYzLU21LEq5mQ=.2a85f959-ec34-4730-bec0-7e29bb9ea737@github.com>
Message-ID: <CY4PR1001MB2150BA412E3934747E77B62E8C51A@CY4PR1001MB2150.namprd10.prod.outlook.com>



From: kulla-dev <kulla-dev-retn at openjdk.org> on behalf of Brian Goetz <briangoetz at openjdk.org>

>  I think there's something fishy going on.
Yes, transformation lambdas become significantly slower when moved from ClassModel to Classfile (unless I missed anything else).
I?ll do some experiments to get the performance back.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230609/3a925b12/attachment.htm>

From asotona at openjdk.org  Fri Jun  9 16:25:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 9 Jun 2023 16:25:06 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v12]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <nK2l6I95xSA7v8lf3J_sKGQHvgpviCjmcjzz7m8e6Hc=.ea13157b-bfe8-46e8-8065-70c0d2e0fe32@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed StackMapsOption dispatching in DirectCodeBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/ae287751..fd65c367

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=10-11

  Stats: 90 lines in 1 file changed: 50 ins; 16 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Mon Jun 12 11:20:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 12 Jun 2023 11:20:40 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v13]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <WVxhI78Zmqpf6nWEUjjjSmc0pTDCXQ4jP7EVDawuJqg=.cd623a45-bd58-4ffc-8037-08159ad52bc7@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
   esolver.java
 - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
   
   This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/fd65c367..344ccede

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=11-12

  Stats: 83 lines in 7 files changed: 42 ins; 25 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Mon Jun 12 15:34:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 12 Jun 2023 15:34:06 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v13]
In-Reply-To: <WVxhI78Zmqpf6nWEUjjjSmc0pTDCXQ4jP7EVDawuJqg=.cd623a45-bd58-4ffc-8037-08159ad52bc7@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WVxhI78Zmqpf6nWEUjjjSmc0pTDCXQ4jP7EVDawuJqg=.cd623a45-bd58-4ffc-8037-08159ad52bc7@github.com>
Message-ID: <TyV0mIE2kay3vvly70fLLubjmqdiXbYzaBKX2B9TZLs=.1cda6ce9-3fa2-40e5-8216-2ce66c478519@github.com>

On Mon, 12 Jun 2023 11:20:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
>    esolver.java
>  - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
>    
>    This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.

I've fixed stack map generator dispatching code and reverted the cache-related changes to focus on performance regression caused by the Classfile context introduction and unfortunately it is still there.
Affected by at least 12% regression are all code transformations, with the worst case AdHocAdapt.transform LIFT2 (22% regression).
Detailed profiling shows regressions in self-time spent in code transformation lambda calls, for example `ChainedCodeBuilder::with` only calls `consumer.accept` and in ~30s benchmark it spent 2s in self-time (which is half of the whole regression).

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1587575761

From asotona at openjdk.org  Mon Jun 12 15:55:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 12 Jun 2023 15:55:49 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:

 - Merge branch 'master' into JDK-8308899-context
 - Revert of DirectCodeBuilder.needsStackMap pre-calculation
 - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
   esolver.java
 - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
   
   This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
 - fixed StackMapsOption dispatching in DirectCodeBuilder
 - proposed semi-synchronized caching, where the map is not locked during delegate call
 - used Factory.INSTANCE for system ClassHierarchyResolver cache
 - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
   
   This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
 - ClassHierarchyResolver::ofSystem is now thread-unsafe
 - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
   introduction of ClassHierarchyResolver::ofSystem factory method
   ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
 - ... and 28 more: https://git.openjdk.org/jdk/compare/5d5ae352...9e0d141e

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

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=13
  Stats: 1681 lines in 106 files changed: 536 ins; 245 del; 900 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

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

Commit messages:
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk21/pull/11/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

PR: https://git.openjdk.org/jdk21/pull/11

From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <-g_p5DXIJa2iFx-wYX9Fl024cy_wOxNlIN3g8TB5V1E=.84d95609-9341-4a50-afa2-e9dcb462a0bb@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588123540

From jlu at openjdk.org  Mon Jun 12 21:29:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:29:54 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588130775

From kcr at openjdk.org  Mon Jun 12 21:45:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Jun 2023 21:45:55 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
Message-ID: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>

On Mon, 12 Jun 2023 21:27:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

@justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.

See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588146416

From jlu at openjdk.org  Mon Jun 12 21:55:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:55:48 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
 <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
Message-ID: <ZVzi-lqSlf4r01XSuWXwqs8_Ku3uEGgB_f2BRDOqsvQ=.9c38d799-5e1e-4ec7-8f74-81a9603cde4d@github.com>

On Mon, 12 Jun 2023 21:42:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.
>
> @justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.
> 
> See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

@kevinrushforth Thanks for the reminder, will make the change in ML first.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588156115

From jlu at openjdk.org  Mon Jun 12 22:07:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:07:11 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

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

Commit messages:
 - Merge remote-tracking branch 'justinJDK21/JDK21-RDP1-L10nDrop' into JDK21-L10NDrop-RDP1
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk/pull/14430/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

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

From jlu at openjdk.org  Mon Jun 12 22:16:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:16:50 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <sLPcMLisa0Fflyr2kNxtrP3t6X2r7TFh7K59biOLnuw=.cb69b335-cac4-4565-9587-93d4abfae7ed@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1588180092

From duke at openjdk.org  Mon Jun 12 22:20:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 12 Jun 2023 22:20:53 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227296089

From jlu at openjdk.org  Mon Jun 12 22:32:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:14 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

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

  Revert 'main.help.opt.any.file' value for _de

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/ee072231..8ee7bf88

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

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

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

From jlu at openjdk.org  Mon Jun 12 22:32:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:34 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
Message-ID: <QG0atcb6MH7fn3CaUG7kFAU8Z-0dx0lvt8vPPzz6fD4=.750f4a45-f895-49f6-becd-7d9e6c994207@github.com>

On Mon, 12 Jun 2023 22:17:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:
> 
>> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
>> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
>> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)
> 
> This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

Thanks for catching that. The translation tool incorrectly translated this, and we had manually fixed it with `Auslassen` in the last translation drop. This was an instance of the tool simply overwriting it this time. Will file a bug against the translation tool regarding this, to prevent it in future translation drops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227305807

From liach at openjdk.org  Tue Jun 13 04:08:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Jun 2023 04:08:54 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v6]
In-Reply-To: <cA2Ib1xUESlaN_rbKu0migmJCwnioAEuoakc6refeLQ=.49fe6bc9-91ef-4141-8df7-80e88f91359d@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <cA2Ib1xUESlaN_rbKu0migmJCwnioAEuoakc6refeLQ=.49fe6bc9-91ef-4141-8df7-80e88f91359d@github.com>
Message-ID: <SQFlxiZB4rkVOnVLDKuoyJ0klmLp9H4D-F_kgstvYpc=.42e95ef3-1bac-4547-9d8c-27243b16faa1@github.com>

On Fri, 26 May 2023 21:32:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - Merge branch 'master' into SuperInit
>  - Use @enablePreview in tests in preference to explicit command line flags.
>  - Make "statements before super()" support a preview feature.
>    
>    Thanks to Jim Laskey for help with preview logic.
>  - Small refactoring to avoid redundant test.
>  - Fix typo in comment.
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/c72b5474...276e449d

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 241:

> 239:         RECORD_PATTERNS(JDK21, Fragments.FeatureDeconstructionPatterns, DiagKind.PLURAL),
> 240:         STRING_TEMPLATES(JDK21, Fragments.FeatureStringTemplates, DiagKind.PLURAL),
> 241:         SUPER_INIT(JDK21, Fragments.FeatureSuperInit, DiagKind.NORMAL),

Now JDK mainline is 22, this should update the target version too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1227499959

From liach at openjdk.org  Tue Jun 13 09:23:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Jun 2023 09:23:01 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
Message-ID: <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>

On Mon, 12 Jun 2023 15:55:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
> 
>  - Merge branch 'master' into JDK-8308899-context
>  - Revert of DirectCodeBuilder.needsStackMap pre-calculation
>  - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
>    esolver.java
>  - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
>    
>    This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
>  - fixed StackMapsOption dispatching in DirectCodeBuilder
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache
>  - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>    
>    This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
>  - ClassHierarchyResolver::ofSystem is now thread-unsafe
>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>    introduction of ClassHierarchyResolver::ofSystem factory method
>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/5d5ae352...9e0d141e

I have found the cause of the regression: there's redundant stack map generation in DirectCodeBuilder for methods with trivial stack map table (null).

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 334:

> 332:                     maxLocals = original.maxLocals();
> 333:                     maxStack = original.maxStack();
> 334:                     stackMapAttr = original.findAttribute(Attributes.STACK_MAP_TABLE).orElse(null);

On the baseline, if a stack map table attribute can be reused but this findAttribute doesn't find an attribute (implying an implicit stack map, potentially for simple code?), we will not perform a stack map generation and simply reuse a trivial stack map (null), which should be a correct algorithm.

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 349:

> 347:             }
> 348: 
> 349:             private boolean writeOriginalAttribute(BufWriterImpl buf) {

As a result (see previous comment), we will run into a redundant stack map generation when the original stack map table is trivial (absent). Maybe we want to consider user-configured selective stack map regeneration to replace this faulty logiic.

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

PR Review: https://git.openjdk.org/jdk/pull/14180#pullrequestreview-1476665044
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1227803483
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1227808744

From liach at openjdk.org  Tue Jun 13 09:36:49 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Jun 2023 09:36:49 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
Message-ID: <j007AqIU2A6le9fIs3atyZ7yTaUhGKVNNIJW0PJUsSk=.76ec71ae-dc4d-4615-b535-665abb68e57f@github.com>

On Mon, 12 Jun 2023 15:55:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
> 
>  - Merge branch 'master' into JDK-8308899-context
>  - Revert of DirectCodeBuilder.needsStackMap pre-calculation
>  - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
>    esolver.java
>  - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
>    
>    This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
>  - fixed StackMapsOption dispatching in DirectCodeBuilder
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache
>  - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>    
>    This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
>  - ClassHierarchyResolver::ofSystem is now thread-unsafe
>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>    introduction of ClassHierarchyResolver::ofSystem factory method
>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/5d5ae352...9e0d141e

Since "not generating stack maps" really means to use an implicit stack map, I suggest renaming the `STACK_MAPS_NEVER` to `STACK_MAPS_IMPLICIT` to indicate such a confusing feature of StackMapTable. (In fact, the enum element names of StackMapsOption doesn't fit in with other options, they should be ALWAYS_STACK_MAPS, NEVER_STACK_MAPS, etc.)

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1588916612

From asotona at openjdk.org  Tue Jun 13 10:56:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 10:56:07 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v15]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <17guRBlm6Qq_d1542Vh26NjFp2nF3zkmPBuBUht6idA=.b6b523df-1d73-4448-b886-15945ebadc78@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - performance fix
 - Merge branch 'master' into JDK-8308899-context
 - Merge branch 'master' into JDK-8308899-context
 - Revert of DirectCodeBuilder.needsStackMap pre-calculation
 - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
   esolver.java
 - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
   
   This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
 - fixed StackMapsOption dispatching in DirectCodeBuilder
 - proposed semi-synchronized caching, where the map is not locked during delegate call
 - used Factory.INSTANCE for system ClassHierarchyResolver cache
 - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
   
   This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
 - ... and 30 more: https://git.openjdk.org/jdk/compare/5d716121...074b60e3

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

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=14
  Stats: 1668 lines in 106 files changed: 523 ins; 246 del; 899 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Tue Jun 13 11:32:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 11:32:59 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v16]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <KGxZNYjrXI1EcJn6x7ILD2DyU9cOVsRYaq1UWwmJHkM=.fe575184-dd5c-45ff-889a-ce7c33c87e8b@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassHierarchyResolver.DEFAULT_RESOLVER gets info from system class loader and does not cache
  method-level caching is enabled if the provided resolver is not already cached

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/074b60e3..45c69314

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=14-15

  Stats: 23 lines in 3 files changed: 7 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Tue Jun 13 11:56:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 11:56:49 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v16]
In-Reply-To: <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
 <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>
Message-ID: <9qmpHTGGm4ZoO77dehRY5ad8uYHrbMLpmUDqHZFiRus=.1f85092f-09c5-444f-86b6-96841636960d@github.com>

On Tue, 13 Jun 2023 09:15:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ClassHierarchyResolver.DEFAULT_RESOLVER gets info from system class loader and does not cache
>>   method-level caching is enabled if the provided resolver is not already cached
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 334:
> 
>> 332:                     maxLocals = original.maxLocals();
>> 333:                     maxStack = original.maxStack();
>> 334:                     stackMapAttr = original.findAttribute(Attributes.STACK_MAP_TABLE).orElse(null);
> 
> On the baseline, if a stack map table attribute can be reused but this findAttribute doesn't find an attribute (implying an implicit stack map, potentially for simple code?), we will not perform a stack map generation and simply reuse a trivial stack map (null), which should be a correct algorithm.

Yes, I caused this regression by "Revert of DirectCodeBuilder.needsStackMap pre-calculation" commit above.
The needStackMap pre-calculation on the other side caused regression in lambda performance, so one regression has been replaced with another.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1228001362

From asotona at openjdk.org  Tue Jun 13 11:56:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 11:56:53 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
 <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>
Message-ID: <QgGBCHJo-nKDCjRi-gbasLVuPrPq255aOXqwe76l6fw=.d714457a-6031-4e79-b17f-d29b03b31076@github.com>

On Tue, 13 Jun 2023 09:19:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
>> 
>>  - Merge branch 'master' into JDK-8308899-context
>>  - Revert of DirectCodeBuilder.needsStackMap pre-calculation
>>  - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
>>    esolver.java
>>  - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
>>    
>>    This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
>>  - fixed StackMapsOption dispatching in DirectCodeBuilder
>>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>>  - used Factory.INSTANCE for system ClassHierarchyResolver cache
>>  - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>>    
>>    This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
>>  - ClassHierarchyResolver::ofSystem is now thread-unsafe
>>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>>    introduction of ClassHierarchyResolver::ofSystem factory method
>>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>>  - ... and 28 more: https://git.openjdk.org/jdk/compare/5d5ae352...9e0d141e
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 349:
> 
>> 347:             }
>> 348: 
>> 349:             private boolean writeOriginalAttribute(BufWriterImpl buf) {
> 
> As a result (see previous comment), we will run into a redundant stack map generation when the original stack map table is trivial (absent). Maybe we want to consider user-configured selective stack map regeneration to replace this faulty logiic.

I've fixed the logic in the commit below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1228002306

From asotona at openjdk.org  Tue Jun 13 12:09:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 12:09:58 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v16]
In-Reply-To: <KGxZNYjrXI1EcJn6x7ILD2DyU9cOVsRYaq1UWwmJHkM=.fe575184-dd5c-45ff-889a-ce7c33c87e8b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <KGxZNYjrXI1EcJn6x7ILD2DyU9cOVsRYaq1UWwmJHkM=.fe575184-dd5c-45ff-889a-ce7c33c87e8b@github.com>
Message-ID: <6RbdrJxMLrBVPWEfRzclm42KT6MXBgLzbmGztAxPExA=.41950b62-9a94-4533-b615-92b47a579ddd@github.com>

On Tue, 13 Jun 2023 11:32:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassHierarchyResolver.DEFAULT_RESOLVER gets info from system class loader and does not cache
>   method-level caching is enabled if the provided resolver is not already cached

All the performance regressions have been found and fixed.
Stackmaps generation logic is following:
- `STACK_MAPS_WHEN_REQUIRED` is the default option and performance-critical. It keeps original stack maps if code match and generate them only when required.
- `STACK_MAPS_ALWAYS` always (re)generate stack maps no matter if exist in the original
- `STACK_MAPS_NEVER` stack maps are not generated and dropped if already exist

Naming convention can be still adjusted.

Default `ClassHierarchyResolver` now use reflection from system class loader and it is not globally cached (so no dilemma about CHM vs HM). Any CHR is cached on method level if not already cached.

Benchmarks comparison of this PR vs master now shows even slight improvement:

Benchmark                                  (transform)    master  this PR Units
AdHocAdapt.transform                              LIFT     8.704    9.629 ops/s
AdHocAdapt.transform                             LIFT1     8.622    9.275 ops/s
AdHocAdapt.transform                             LIFT2     9.257    9.378 ops/s
AdaptInjectNoop.transform                   NOP_SHARED     4.709    4.978 ops/s
AdaptNull.transform                           SHARED_1    96.686   98.027 ops/s
AdaptNull.transform                           SHARED_2    48.820   49.257 ops/s
AdaptNull.transform                           SHARED_3     9.611    9.691 ops/s
AdaptNull.transform                  SHARED_3_NO_DEBUG    12.218   12.343 ops/s
AdaptNull.transform                         UNSHARED_3     3.614    3.603 ops/s
ParseOptions.transformNoDebug                      N/A    11.169   11.084 ops/s
ParseOptions.transformNoLineNumbers                N/A    10.590   10.523 ops/s
ParseOptions.transformNoStackmap                   N/A     6.220    9.646 ops/s

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1589174024

From asotona at openjdk.org  Tue Jun 13 13:12:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 13:12:56 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <j007AqIU2A6le9fIs3atyZ7yTaUhGKVNNIJW0PJUsSk=.76ec71ae-dc4d-4615-b535-665abb68e57f@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
 <j007AqIU2A6le9fIs3atyZ7yTaUhGKVNNIJW0PJUsSk=.76ec71ae-dc4d-4615-b535-665abb68e57f@github.com>
Message-ID: <WImBCc_ec27tlGyJeBneKoSAOotsQw8BLKSlD2HzYAY=.cb983319-2db3-4c32-9ab1-dd419efead3c@github.com>

On Tue, 13 Jun 2023 09:34:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>StackMapsOption doesn't fit in with other options, they should be ALWAYS_STACK_MAPS, NEVER_STACK_MAPS, etc.)

What about `STACK_MAPS_WHEN_REQUIRED`, `GENERATE_STACK_MAPS` and `DROP_STACK_MAPS`?

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1589282092

From acobbs at openjdk.org  Tue Jun 13 15:14:41 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 13 Jun 2023 15:14:41 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'master' into SuperInit
 - Fix mistake in previous merge commit 80ba6be4.
 - Merge branch 'master' into SuperInit
 - Rename unit test to be consistent with other feature exampless.
 - Update unit test after merged-in commit eaa80ad08.
 - Add unit tests with local class decl's prior to super().
 - Merge branch 'master' into SuperInit
 - Use @enablePreview in tests in preference to explicit command line flags.
 - Make "statements before super()" support a preview feature.
   
   Thanks to Jim Laskey for help with preview logic.
 - Small refactoring to avoid redundant test.
 - ... and 15 more: https://git.openjdk.org/jdk/compare/c0aa6bf4...a5f8cc5e

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

Changes: https://git.openjdk.org/jdk/pull/13656/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=06
  Stats: 1400 lines in 24 files changed: 1130 ins; 163 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

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

From acobbs at openjdk.org  Tue Jun 13 15:14:45 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 13 Jun 2023 15:14:45 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v6]
In-Reply-To: <SQFlxiZB4rkVOnVLDKuoyJ0klmLp9H4D-F_kgstvYpc=.42e95ef3-1bac-4547-9d8c-27243b16faa1@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <cA2Ib1xUESlaN_rbKu0migmJCwnioAEuoakc6refeLQ=.49fe6bc9-91ef-4141-8df7-80e88f91359d@github.com>
 <SQFlxiZB4rkVOnVLDKuoyJ0klmLp9H4D-F_kgstvYpc=.42e95ef3-1bac-4547-9d8c-27243b16faa1@github.com>
Message-ID: <RB8Ubj6aG5XWIMCRAkqV_X3ZRSLe2jUpxvOGd4asGg0=.4a183516-aa09-4a70-96ad-e91f54a692d2@github.com>

On Tue, 13 Jun 2023 04:06:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Fix mistake in previous merge commit 80ba6be4.
>>  - Merge branch 'master' into SuperInit
>>  - Rename unit test to be consistent with other feature exampless.
>>  - Update unit test after merged-in commit eaa80ad08.
>>  - Add unit tests with local class decl's prior to super().
>>  - Merge branch 'master' into SuperInit
>>  - Use @enablePreview in tests in preference to explicit command line flags.
>>  - Make "statements before super()" support a preview feature.
>>    
>>    Thanks to Jim Laskey for help with preview logic.
>>  - Small refactoring to avoid redundant test.
>>  - Fix typo in comment.
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/c72b5474...276e449d
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 241:
> 
>> 239:         RECORD_PATTERNS(JDK21, Fragments.FeatureDeconstructionPatterns, DiagKind.PLURAL),
>> 240:         STRING_TEMPLATES(JDK21, Fragments.FeatureStringTemplates, DiagKind.PLURAL),
>> 241:         SUPER_INIT(JDK21, Fragments.FeatureSuperInit, DiagKind.NORMAL),
> 
> Now JDK mainline is 22, this should update the target version too.

Thanks - should be fixed in a5f8cc5e8ff.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1228297557

From naoto at openjdk.org  Tue Jun 13 18:41:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:41:52 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

The translation seems wrong. It means to *add* the selected file, which is not the same meaning as in English file

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:

> 138: 
> 139: # 0: type, 1: name
> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf

Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 505:

> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059
> 505: 

These translations are very cryptic. Cannot understand it at first hand.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:

> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 959: 

The translation of "well-formed" is incorrect. It is not ???

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

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477795175
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228530280
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228521409
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228538758
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228529769

From jlu at openjdk.org  Tue Jun 13 18:56:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 18:56:44 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>

On Tue, 13 Jun 2023 18:13:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
> 
>> 138: 
>> 139: # 0: type, 1: name
>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
> 
> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let ask about this specific instance.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:
> 
>> 957: 
>> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
>> 959: 
> 
> The translation of "well-formed" is incorrect. It is not ???

For translations that are incorrect, I can file a bug against the tool. Such a fix would probably not happen soon, can you suggest an alternative for now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228567669
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228570665

From naoto at openjdk.org  Tue Jun 13 20:24:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 20:24:46 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some suggestions. Should be looked at by translators later.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

Suggestion:

FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 502:

> 500: compiler.warn.forward.ref=\u521D\u671F\u5316\u3055\u308C\u308B\u524D\u306E\u5909\u6570''{0}''\u3092\u53C2\u7167\u3057\u3088\u3046\u3068\u3057\u307E\u3057\u305F
> 501: 
> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape=\u30b5\u30d6\u30af\u30e9\u30b9\u304c\u521d\u671f\u5316\u3055\u308c\u308b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306e\u53ef\u80fd\u6027\u304c\u3042\u308a\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 504:

> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059
> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape.location=\u4e8b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306f\u3053\u306e\u547c\u3073\u51fa\u3057\u3067\u51fa\u73fe\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 956:

> 954: compiler.err.unclosed.text.block=\u9589\u3058\u3089\u308C\u3066\u3044\u306A\u3044\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF
> 955: 
> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.string.template.is.not.well.formed=\u6587\u5b57\u5217\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 958:

> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.text.block.template.is.not.well.formed=\u30c6\u30ad\u30b9\u30c8\u30fb\u30d6\u30ed\u30c3\u30af\u30fb\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

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

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477963618
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228635514
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228648714
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228651272
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228653057
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228654384

From weijun at openjdk.org  Tue Jun 13 20:58:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jun 2023 20:58:51 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Some comments:

- `src/java.base/share/classes/sun/launcher/resources/launcher`

`? private`. "private" should be translated, just like the "static" in the 2nd box.

- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`

`compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?

`compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.

`compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".


- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:

`javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.

- `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`

I don't think the new translation is better than the old one.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590013825

From jlu at openjdk.org  Tue Jun 13 21:06:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:25 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v3]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <geYM5H0XN5NNvVmRzx5TxgqMaD17xbb7-DCnO_oFVbw=.d00caade-f19d-466e-a71d-7f7cbba183cc@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

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

  Review: use Naoto's recommended ja values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/8ee7bf88..7801eefb

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

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

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

From jlu at openjdk.org  Tue Jun 13 21:06:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:28 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
Message-ID: <Kj4eUHsEVJoYJLTG7eTiBVFd68yRljmoagn0pAEqPdI=.0c0cf9b7-9710-4802-9cce-aad8c0f35a71@github.com>

On Tue, 13 Jun 2023 19:59:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:
> 
>> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
>> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
>> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059
> 
> Suggestion:
> 
> FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

Thank you Naoto, all your recommended translations have been updated. The HTML diffs have also been updated as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228692234

From jlu at openjdk.org  Tue Jun 13 22:09:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:40 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with three additional commits since the last revision:

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/7801eefb..f7c06512

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

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

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

From jlu at openjdk.org  Tue Jun 13 22:09:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:43 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
Message-ID: <eUpEuDxtBW4zFIazvfci4moBpPFzPDXyAkpgYNd4F9E=.61170e21-43a3-40d7-a5cc-fc9685a8a2e2@github.com>

On Tue, 13 Jun 2023 20:56:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> Some comments:
> 
> - `src/java.base/share/classes/sun/launcher/resources/launcher`
> 
> `? private`. "private" should be translated, just like the "static" in the 2nd box.
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`
> 
> `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?
> 
> `compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.
> 
> `compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".
> 
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
> - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> I don't think the new translation is better than the old one.

Thank you for the review @wangweij,

I have addressed these recommendations

>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
>     * `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> 
> I don't think the new translation is better than the old one.

For the other comments, I will bring them to the language specialist for updated translations. Ideally we can get those in for this translation drop, but if not, they can go in during the second translation drop during RDP2. 

I am also hesitant to make too many manual changes, as they will just get overwritten by the tool in the future, so it's best to get it fixed in the tool first.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590087839

From naoto at openjdk.org  Wed Jun 14 00:09:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 00:09:03 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
In-Reply-To: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
Message-ID: <sGkMLbM6Iyp04SnzPdG_CLR9wMlzypOQwrpdy_9iheM=.1f136a3d-f264-42a2-85e5-c4506564eb74@github.com>

On Tue, 13 Jun 2023 22:09:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value

Looks good, Justin

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1478236336

From dholmes at openjdk.org  Wed Jun 14 05:22:19 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 05:22:19 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
Message-ID: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>

Updated the version to 22-ea and year to 2024.

The following unpublished changes will also be included in this update:
- [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
- [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
- [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option

The following changes were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
- [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
- [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor

Thanks.

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

Commit messages:
 - 8304478: Initial nroff manpage generation for JDK 22

Changes: https://git.openjdk.org/jdk/pull/14462/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304478
  Stats: 140 lines in 28 files changed: 1 ins; 105 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/14462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14462/head:pull/14462

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

From alanb at openjdk.org  Wed Jun 14 06:11:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 06:11:55 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <u7cexPiA_MtAjwCteuLZ8dx5RxqHvokGd62Tq9SGUlA=.4aac4c19-e2af-492d-9c06-f8b8d44d11a3@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

Looks fine.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1478549017

From dholmes at openjdk.org  Wed Jun 14 06:11:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 06:11:55 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <u7cexPiA_MtAjwCteuLZ8dx5RxqHvokGd62Tq9SGUlA=.4aac4c19-e2af-492d-9c06-f8b8d44d11a3@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <u7cexPiA_MtAjwCteuLZ8dx5RxqHvokGd62Tq9SGUlA=.4aac4c19-e2af-492d-9c06-f8b8d44d11a3@github.com>
Message-ID: <W9Zscls7-cKxv0kjUNUgbwnOWOEWCiCfaXX9xsXjOug=.3406ce3f-a12c-40b0-aeeb-a2598dcf299e@github.com>

On Wed, 14 Jun 2023 06:08:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updated the version to 22-ea and year to 2024.
>> 
>> The following unpublished changes will also be included in this update:
>> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
>> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
>> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
>> 
>> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
>> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
>> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
>> 
>> Thanks.
>
> Looks fine.

Thanks @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1590531861

From asotona at openjdk.org  Wed Jun 14 07:53:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Jun 2023 07:53:41 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v17]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <QHXgQ6QFat4MMVc6C89Fbp7qh4ybxkGmgDJon_V7jD8=.918095e2-94c8-43c3-97df-f91eb5f651f6@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Classfile.StackMapsOption names change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/45c69314..b5fa9ed0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=15-16

  Stats: 15 lines in 10 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Wed Jun 14 08:06:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Jun 2023 08:06:34 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v18]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <gnJKz6XSLLLFgvGQKpxpxgA1Jz40gtewmfzp_3Hopq0=.55c096fa-1b43-43bf-bd12-1730a899c291@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  static instance of default Classfile context

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/b5fa9ed0..df432763

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=16-17

  Stats: 19 lines in 2 files changed: 0 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Wed Jun 14 08:06:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Jun 2023 08:06:34 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v18]
In-Reply-To: <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
 <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
 <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>
Message-ID: <RYmdOSx5gMTe-SdyDhFkYXWuf4L_RkFIz44DlbYQAEY=.071e3800-2e45-4116-86c5-0b8e66e6e6cb@github.com>

On Thu, 1 Jun 2023 19:25:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 55:
>> 
>>> 53: 
>>> 54:     static Classfile of() {
>>> 55:         return new ClassfileImpl();
>> 
>> We can create a static final field in `ClassfileImpl` holding a default instance equivalent to that created by `new ClassfileImpl()` and have the `of()` factory return that instance instead.
>
> Global static default context will hold global shared cached class hierarchy resolver and that we want to avoid.

As the default CHR stays static instance and it is no more cached, we can have also static holder for the default Classfile instance now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1229182694

From sspitsyn at openjdk.org  Wed Jun 14 09:28:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Jun 2023 09:28:11 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <PzXXmQJzScDG52LEySE0srWf3GF5QkLDolW9Vd-WHCg=.41a493c7-cc28-4f11-9687-ff1857171380@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

The Serviceability changes look good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1478940868

From jlu at openjdk.org  Wed Jun 14 16:25:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 Jun 2023 16:25:00 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
Message-ID: <i2xpAM4Cbkg3wxLwU6xXUsAerpA3w3n1wHE9BFFtI0Q=.49a5cd2b-b201-4322-af3a-dd198470a544@github.com>

On Tue, 13 Jun 2023 18:50:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
>> 
>>> 138: 
>>> 139: # 0: type, 1: name
>>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
>> 
>> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.
>
> I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let me ask about this specific instance.

The language specialist confirmed the double quotes are locale specific for de.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1229881212

From mchung at openjdk.org  Wed Jun 14 18:43:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Jun 2023 18:43:57 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <K4hEuZ0tOGwmXOhjV3akufh4EWm7Ssj9tehW3-UV3uc=.804e1b1b-c860-4529-ae56-ada4ce326c95@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1480088199

From lancea at openjdk.org  Wed Jun 14 18:51:10 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Jun 2023 18:51:10 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <pun50s0fljjG983cJ983N7coIJWbOdKdcT6LhkbOdK4=.bad2c612-56ee-45c9-a6c3-89203e19aa4d@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1480097706

From acobbs at openjdk.org  Wed Jun 14 19:23:59 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 14 Jun 2023 19:23:59 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The following changes, to javac.1, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22

Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion?

To be clear, I'm not blaming you for this situation - the problem is that there exist "closed sources" at all (why??) - but that doesn't seem like a good excuse for deleting work without a clear path to ensuring it is preserved (and the simplest way to do that is to do it yourself). Obviously I'd do it myself if I could.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1591849483

From dholmes at openjdk.org  Wed Jun 14 21:31:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 21:31:00 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>
Message-ID: <BLpvFy8u6sXytaJhhmA_Fa3I3ITTlixJsRyfkv5ASyc=.ee363700-c516-46e4-b10d-d9490615b802@github.com>

On Wed, 14 Jun 2023 19:21:01 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion?

@archiecobbs  we (Oracle) will take care of restoring this text so please don't be concerned about that. It will just be a temporary glitch. It should have been handled when the original PRs were done. It needs to be handled as a separate issue and PR though - whether that were to happen before or after this PR is somewhat immaterial.

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592014026

From dholmes at openjdk.org  Wed Jun 14 21:31:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 21:31:03 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <PzXXmQJzScDG52LEySE0srWf3GF5QkLDolW9Vd-WHCg=.41a493c7-cc28-4f11-9687-ff1857171380@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <PzXXmQJzScDG52LEySE0srWf3GF5QkLDolW9Vd-WHCg=.41a493c7-cc28-4f11-9687-ff1857171380@github.com>
Message-ID: <RN3gF2SqClnHGc2V8rBkDumSLXd4Tab0-oCaO3rQ0TA=.d59d4324-c7b6-44e8-8be6-088e7c0b3a52@github.com>

On Wed, 14 Jun 2023 09:25:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Updated the version to 22-ea and year to 2024.
>> 
>> The following unpublished changes will also be included in this update:
>> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
>> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
>> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
>> 
>> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
>> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
>> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
>> 
>> Thanks.
>
> The Serviceability changes look good.
> Thanks,
> Serguei

Thanks for the additional reviews @sspitsyn , @LanceAndersen  and @mlchung !

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592014943

From acobbs at openjdk.org  Wed Jun 14 21:40:57 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 14 Jun 2023 21:40:57 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <BLpvFy8u6sXytaJhhmA_Fa3I3ITTlixJsRyfkv5ASyc=.ee363700-c516-46e4-b10d-d9490615b802@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>
 <BLpvFy8u6sXytaJhhmA_Fa3I3ITTlixJsRyfkv5ASyc=.ee363700-c516-46e4-b10d-d9490615b802@github.com>
Message-ID: <okk5G3GqQV8MOBuFOOfytJMRx9WMoL0s19P8GBKXnUE=.ad36d5f6-ec18-4e0e-824a-bef478f66bd5@github.com>

On Wed, 14 Jun 2023 21:28:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion?
> 
> @archiecobbs we (Oracle) will take care of restoring this text so please don't be concerned about that. It will just be a temporary glitch. 

OK thanks. Putting my trust in you :)

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592023452

From dholmes at openjdk.org  Wed Jun 14 22:11:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 22:11:57 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <KXanlp-XRQ3wM7NK9pRkfFdQdHZB6UzXYETEpBqd2J4=.08b3dc2b-34df-481f-b99a-9a14b715e6de@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

I've filed https://bugs.openjdk.org/browse/JDK-8310067 for the javac manpage fixup.

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592056009

From asotona at openjdk.org  Thu Jun 15 16:25:32 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Jun 2023 16:25:32 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v19]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <WRdo5OQBZKeH0YuiLoSzAtYG6YviBCkmDvxFvzQR_FM=.7f06a07f-a7c8-4644-874b-019dd20d00c7@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added new ClassfileBenchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/df432763..a45246db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=17-18

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

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

From asotona at openjdk.org  Thu Jun 15 16:34:18 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Jun 2023 16:34:18 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v20]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <eL-zGzL8Bhq0U05IoY1xdwZ92ncPyL7U6Y-pOAB8eYQ=.12ce1fdf-9955-45f5-abfe-0c95761c3d64@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassfileBenchmark minor fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/a45246db..6e53057c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=18-19

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

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

From asotona at openjdk.org  Thu Jun 15 17:22:32 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Jun 2023 17:22:32 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/6e53057c..baa01584

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=19-20

  Stats: 17 lines in 1 file changed: 13 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From jlu at openjdk.org  Thu Jun 15 19:45:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 19:45:52 GMT
Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <wHemDob1LcBUGrp94CGVymYmeivv2G9ccgjfngb7m84=.a4d37dbb-54fd-4920-8734-dd2080aeaf32@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: 81bfd789
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81bfd78901ff540ad0355a466cfad097e701028a
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto

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

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

From kcr at openjdk.org  Thu Jun 15 20:05:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 20:05:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <lk-HQVh3RGdNHbBiHftYiYZQzEq5Hp6CCtCXPjSbAPs=.ae8c0707-7daf-4142-8147-1ea24323364a@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

I was 

> @kevinrushforth Thanks for the reminder, will make the change in ML first.

Thanks. And I see you made this PR Draft, which is a good idea. Once the mainline PR is integrated, you can change the title of this PR to `Backport NNNNNNNNNNN`, where `NNNNNNNNNNN` is the 40 character commit hash of the jdk master commit. Then Skara will note this as a Backport, and also note whether it is a clean backport.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588176435

From duke at openjdk.org  Thu Jun 15 20:05:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 15 Jun 2023 20:05:31 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <j-x2Vg89HAUcCaDz51mqofqhoX932hkfEGlaF-FvKIo=.8473b365-250a-47c3-b052-9d78947374de@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

(Review comment moved to mainline PR)

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

PR Review Comment: https://git.openjdk.org/jdk21/pull/11#discussion_r1227287139

From kcr at openjdk.org  Thu Jun 15 21:09:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 21:09:09 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593724465

From jlu at openjdk.org  Thu Jun 15 21:13:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 21:13:00 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
Message-ID: <8055MPxK8nGDItLuewscD0HhRwu4yJHWRoWg1H_SEu4=.7a2b5b3b-422c-4d32-8b68-d856a6ac8c05@github.com>

On Thu, 15 Jun 2023 21:06:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

Hi Kevin, yes it is. I still need to grab the changes from mainline and include them in this PR.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593728784

From jlu at openjdk.org  Fri Jun 16 04:39:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 04:39:42 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with five additional commits since the last revision:

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value
 - Review: use Naoto's recommended ja values
 - Revert 'main.help.opt.any.file' value for _de

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

Changes:
  - all: https://git.openjdk.org/jdk21/pull/11/files
  - new: https://git.openjdk.org/jdk21/pull/11/files/13b8b309..a2e52373

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

  Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

PR: https://git.openjdk.org/jdk21/pull/11

From jjg at openjdk.org  Fri Jun 16 15:09:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 16 Jun 2023 15:09:14 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>

On Tue, 13 Jun 2023 18:38:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594844435

From naoto at openjdk.org  Fri Jun 16 17:16:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 17:16:33 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
Message-ID: <mnwQXQ-yvvAdB4JlfTC3NwMpbuEENwDTX0GeETglGh0=.9054a675-049f-4dfb-a847-4e93fea5020f@github.com>

On Fri, 16 Jun 2023 15:06:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
>
>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
> 
> 1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
> 2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.
> 3. The iteration order would be undefined when resources are removed from one or more resource files

Makes sense. Thanks for the explanation @jonathan-gibbons

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594999086

From naoto at openjdk.org  Fri Jun 16 21:02:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 21:02:17 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
Message-ID: <Jfrbn9kav_htg9Xsi2K0qX_DMxUTs4QAEzMKI77gj-4=.089cfa89-dcf3-4441-817b-f6a575cb4d9c@github.com>

On Fri, 16 Jun 2023 04:39:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value
>  - Review: use Naoto's recommended ja values
>  - Revert 'main.help.opt.any.file' value for _de

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/11#pullrequestreview-1484380340

From jlu at openjdk.org  Fri Jun 16 21:14:20 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 21:14:20 GMT
Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <yxBFAdo-tYodL8exo3y2xbRz6pYcTIvYVJ8Tnbzp1WM=.80ad659c-02ea-476d-8e2a-ed80b3187880@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: a1c1d97a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/a1c1d97a4e07bae872b5608b4d8d8f85195edd82
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto
Backport-of: 81bfd78901ff540ad0355a466cfad097e701028a

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

PR: https://git.openjdk.org/jdk21/pull/11

From dholmes at openjdk.org  Mon Jun 19 22:32:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:32:05 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 [v2]
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <NuoEwbq5aPlw8_pQqyR8pHnCRBJJ9SxulvKOGyd9YJI=.a10acc7c-38dc-49d4-8e93-a46ff2cbcb0b@github.com>

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Pick up javac and jshell changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14462/files
  - new: https://git.openjdk.org/jdk/pull/14462/files/3efc518f..e8ff96d1

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

  Stats: 74 lines in 2 files changed: 71 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14462/head:pull/14462

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

From dholmes at openjdk.org  Mon Jun 19 22:32:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:32:07 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <bunHkJGm3C7xSU0JqdU8O-z3rPLQw3xFScOef_2KnKo=.123f7217-2057-4ac6-b0fb-fd46c0c4c481@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

The javac changes have been restored so I am merging them into this PR - the only difference should be minor formatting changes.

This has also now picked up the jshell changes from JDK-8308988.

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1597836257

From dholmes at openjdk.org  Mon Jun 19 22:34:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:34:28 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <NBHlggX8F55iGpoySMQ3Ye20dSFyUnav1vexQ5yB8vI=.b5d8058d-4186-4584-877e-ca1b02688e48@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

The javac update has also now pulled in JDK-8308456

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1597839767

From dholmes at openjdk.org  Mon Jun 19 22:34:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:34:29 GMT
Subject: Integrated: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <ZKcpvmC0cM2_o-sQJXe4-0F5A2z95lDQQ5VX5Qu4-HI=.d6b1c8bc-4110-4d09-ac97-098202d295e7@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

This pull request has now been integrated.

Changeset: b2e86aef
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2e86aef65f4d579896b6db83aaad408b6c580d4
Stats:     129 lines in 28 files changed: 24 ins; 57 del; 48 mod

8304478: Initial nroff manpage generation for JDK 22

Reviewed-by: alanb, sspitsyn, mchung, lancea

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

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

From asotona at openjdk.org  Wed Jun 21 06:32:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Jun 2023 06:32:13 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
Message-ID: <tljEeFn3OP_CPwsaV8VwNnlcPJszv4wn0BNMt79TFNA=.305b3b2d-11cc-4fec-b224-6c202640a7a8@github.com>

On Thu, 15 Jun 2023 17:22:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP

I think we've resolved controversy about global static CHR cache (by having no global static CHR cache ;) and turned all performance issues into minor improvements. A new `ClassfileBenchmark` has been added for more precise future continuous performance monitoring.

This PR is now waiting for review to unblock all follow-up conversion work.

Thank you,
Adam

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1600258409

From liach at openjdk.org  Wed Jun 21 06:53:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 06:53:14 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
Message-ID: <GikEE5gtWmAln7XuANzUdPafagfuscv1b17uOMUuijE=.73568960-9d49-425f-ad08-a6bbb74f51e1@github.com>

On Thu, 15 Jun 2023 17:22:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP

src/java.base/share/classes/jdk/internal/classfile/impl/ClassfileImpl.java line 63:

> 61:             DeadCodeOption.PATCH_DEAD_CODE,
> 62:             DeadLabelsOption.FAIL_ON_DEAD_LABELS,
> 63:             new ClassHierarchyResolverOptionImpl(ClassHierarchyResolver.defaultResolver()),

Don't users of the default context still share a non-thread-safe-cached version of the default resolver? We might still need to convert DEFAULT_CONTEXT field to a static defaultContext() method that returns a `new ClassfileImpl(...);` (the attribute mapper option can be shared).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236461953

From liach at openjdk.org  Wed Jun 21 06:57:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 06:57:17 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <GikEE5gtWmAln7XuANzUdPafagfuscv1b17uOMUuijE=.73568960-9d49-425f-ad08-a6bbb74f51e1@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
 <GikEE5gtWmAln7XuANzUdPafagfuscv1b17uOMUuijE=.73568960-9d49-425f-ad08-a6bbb74f51e1@github.com>
Message-ID: <Eg5lu-hqUZ5zS5i_nfJDC92YS9g1mzkcmE-bX0Asdmc=.295031d6-7496-4606-9425-650508abaa6e@github.com>

On Wed, 21 Jun 2023 06:50:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassfileImpl.java line 63:
> 
>> 61:             DeadCodeOption.PATCH_DEAD_CODE,
>> 62:             DeadLabelsOption.FAIL_ON_DEAD_LABELS,
>> 63:             new ClassHierarchyResolverOptionImpl(ClassHierarchyResolver.defaultResolver()),
> 
> Don't users of the default context still share a non-thread-safe-cached version of the default resolver? We might still need to convert DEFAULT_CONTEXT field to a static defaultContext() method that returns a `new ClassfileImpl(...);` (the attribute mapper option can be shared).

Please disregard this comment: Now the distinction of cache of resolvers is done in `StackMapGenerator`, meaning each stack map generation task has its own cache. Didn't see it early on.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236465502

From liach at openjdk.org  Wed Jun 21 08:10:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 08:10:17 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
Message-ID: <uyyUFf2zLihyCnma261PNzyX-OWWAxZm9swU_ence_g=.ceba6b83-59bf-4e26-8ed5-25b2fdf7a3ff@github.com>

On Thu, 15 Jun 2023 17:22:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 57:

> 55: 
> 56:     /**
> 57:      * {@return a new context with default options}

Suggestion:

     * {@return a context with default options}

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 272:

> 270:     /**
> 271:      * Build a classfile into a file using the provided constant pool
> 272:      * builder (which encapsulates classfile processing options.)

The CP is now simply a data holder; it no longer holds the processing options. Same update is needed for the other few build methods taking a CP instance.
Suggestion:

     * builder.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 340:

> 338:      *
> 339:      * @implNote
> 340:      * <p>This method behaves as if:

Suggestion:

     * This method behaves as if:

Redundant break

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 343:

> 341:      * {@snippet lang=java :
> 342:      *     Classfile.of().build(thisClass(), ConstantPoolBuilder.of(this),
> 343:      *                     b -> b.transform(this, transform));

Suggestion:

     *     this.build(model.thisClass(), ConstantPoolBuilder.of(model),
     *                     b -> b.transform(model, transform));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236575941
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236572387
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236548304
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236570476

From asotona at openjdk.org  Wed Jun 21 09:25:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Jun 2023 09:25:25 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v22]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <J3tCGZ395B5j0PcKO4b7NuNJr1iaA9UwLBAZi0Gl6D8=.a3febbd7-245c-48ff-a323-9b0fd03ed8ee@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/baa01584..4017e28b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=20-21

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

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

From liach at openjdk.org  Sun Jun 25 03:08:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jun 2023 03:08:10 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields
Message-ID: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>

This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.

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

Commit messages:
 - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

Changes: https://git.openjdk.org/jdk/pull/14640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310848
  Stats: 242 lines in 6 files changed: 62 ins; 93 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/14640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14640/head:pull/14640

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

From liach at openjdk.org  Sun Jun 25 04:20:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jun 2023 04:20:14 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v2]
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <KqRmmONiSSKwyn6k6hB5ufOArHj7kuoDOpRZacrCeZw=.4c410db9-6518-4675-bf23-69bbc0f22578@github.com>

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14640/files
  - new: https://git.openjdk.org/jdk/pull/14640/files/3194e6b7..82442aac

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

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

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

From liach at openjdk.org  Sun Jun 25 04:36:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jun 2023 04:36:29 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <tljEeFn3OP_CPwsaV8VwNnlcPJszv4wn0BNMt79TFNA=.305b3b2d-11cc-4fec-b224-6c202640a7a8@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
 <tljEeFn3OP_CPwsaV8VwNnlcPJszv4wn0BNMt79TFNA=.305b3b2d-11cc-4fec-b224-6c202640a7a8@github.com>
Message-ID: <-RWaMlgoehLJsFigEgnktx_G294VsF5qsC612ZRWlDI=.55f8566c-ed56-4a96-b07b-139399f21101@github.com>

On Wed, 21 Jun 2023 06:29:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP
>
> I think we've resolved controversy about global static CHR cache (by having no global static CHR cache ;) and turned all performance issues into minor improvements. A new `ClassfileBenchmark` has been added for more precise future continuous performance monitoring.
> 
> This PR is now waiting for review to unblock all follow-up conversion work.
> 
> Thank you,
> Adam

@asotona I've sent a patch to your fork for a few API problems spotted a while ago and reported on the mailing list. Feel free to review my patch when you are back to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1605866429

From asotona at openjdk.org  Mon Jun 26 08:30:21 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 08:30:21 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v23]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <0xM98KB1so7P2R2B3PvqPgb2RAwIJYSBsnYNi0xvN_M=.37db35eb-8501-4021-b5e6-03a4ed35da59@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #1 from liachmodded/fix/sotona-cf-obj-improvements
   
   Changes discussed on mailing list plus minor doc error
 - Changes discussed on mailing list plus minor doc error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/4017e28b..700b5b60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=21-22

  Stats: 56 lines in 4 files changed: 25 ins; 2 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Mon Jun 26 08:52:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 08:52:13 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v24]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <7cP9PBaTb3kovEA4bwUp-WSfhbIvAxxu2KpPIeayGlw=.5e273d1d-dfe3-4fe7-a29e-b24d6a909e64@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - fixed String format arguments
 - Classfile API javadoc make patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/700b5b60..73b5ca9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=22-23

  Stats: 41 lines in 3 files changed: 37 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From liach at openjdk.org  Mon Jun 26 12:15:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 12:15:11 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v3]
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <kkIgmVsYJ5mfMI40wNd3DyDlSkYI0NLLVW8j3H4SlSU=.4f4d3ce9-479b-488b-a33b-7f32ab5537f6@github.com>

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.

Chen Liang 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 three additional commits since the last revision:

 - Merge branch 'master' into fix/cd-usage
 - Fix build
 - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14640/files
  - new: https://git.openjdk.org/jdk/pull/14640/files/82442aac..04cec5e9

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

  Stats: 332 lines in 30 files changed: 129 ins; 20 del; 183 mod
  Patch: https://git.openjdk.org/jdk/pull/14640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14640/head:pull/14640

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

From liach at openjdk.org  Mon Jun 26 13:10:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 13:10:15 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v24]
In-Reply-To: <7cP9PBaTb3kovEA4bwUp-WSfhbIvAxxu2KpPIeayGlw=.5e273d1d-dfe3-4fe7-a29e-b24d6a909e64@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <7cP9PBaTb3kovEA4bwUp-WSfhbIvAxxu2KpPIeayGlw=.5e273d1d-dfe3-4fe7-a29e-b24d6a909e64@github.com>
Message-ID: <XFsl5a2XOOg7pcT3RBcNXtfNp3F4tSed53_V3vzGZIE=.ce4c50d5-e20b-4f2b-bf4a-963c37354079@github.com>

On Mon, 26 Jun 2023 08:52:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed String format arguments
>  - Classfile API javadoc make patch

Since you fixed the string format typos, can you fix this typo as well? https://bugs.openjdk.org/browse/JDK-8308646 and remember to include that issue with `/issue add JDK-8308646` if you do.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607433774

From asotona at openjdk.org  Mon Jun 26 13:33:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 13:33:38 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v25]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  8308646: Typo in ConstantValueAttribute

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/73b5ca9f..5723e66a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=23-24

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

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

From liach at openjdk.org  Mon Jun 26 14:59:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 14:59:24 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v25]
In-Reply-To: <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
Message-ID: <yosFTn7Qjr_2YovB-RqToUbZ3LEFmhSOfgyk2hrueok=.e17d197d-e07e-4acf-8807-7483cf472677@github.com>

On Mon, 26 Jun 2023 13:33:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308646: Typo in ConstantValueAttribute

I ran `make docs-classfile-api-javadoc` and the results look good in general. There are a few spec and API issues scattered across the whole API, which I think I will probably collect and list them in the mailing list later.

One thing of note is that the JDK itself has a `@sealedGraph` taglet to render the sealed class hierarchy of any class. We might want to add that tag to all our sealed public classes or interfaces. But it requires a somewhat more complicated build process (including generating dot files with graphviz and rendering them to svg) and you might tweak the `SetupExecute` to a full-on `SetupApiDocsGeneration`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607661040

From mcimadamore at openjdk.org  Mon Jun 26 15:43:13 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jun 2023 15:43:13 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
 <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>
Message-ID: <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>

On Mon, 26 Jun 2023 15:39:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The API changes look great. I like the instance usages of ClassFile, and how CF is now used in a centralized fashion to double down as a cache/option store (and entry point for transformation). Seems like a step in a good direction, and make the API feel a little more cohesive.
> 
> A small subjective comment - I'm not too fond of using "context" as a variable/accessor name for all the places where we use a classfile. E.g. if classfile is the context, perhaps these variable/accessor should just be named "classfile" ?

Also, another observation: the number of updates snippets in javadoc seems rather low for something that touches the main entry point by which client interacts with classfiles. This seems a sign of perhaps not having many end to end examples in the API javadoc?

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607741386

From mcimadamore at openjdk.org  Mon Jun 26 15:43:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jun 2023 15:43:12 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
Message-ID: <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>

On Mon, 26 Jun 2023 13:33:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308646: Typo in ConstantValueAttribute

The API changes look great. I like the instance usages of ClassFile, and how CF is now used in a centralized fashion to double down as a cache/option store (and entry point for transformation). Seems like a step in a good direction, and make the API feel a little more cohesive.

A small subjective comment - I'm not too fond of using "context" as a variable/accessor name for all the places where we use a classfile. E.g. if classfile is the context, perhaps these variable/accessor should just be named "classfile" ?

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14180#pullrequestreview-1498842746

From liach at openjdk.org  Mon Jun 26 15:57:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 15:57:14 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
 <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>
 <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>
Message-ID: <8p7b9v3BV-JeWZ9rxt3FieJRMBbkuR6sk_CToOgH7BA=.b37309b1-82bc-4d87-8685-10d72fcc18be@github.com>

On Mon, 26 Jun 2023 15:40:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Also, another observation: the number of updates snippets in javadoc seems rather low for something that touches the main entry point by which client interacts with classfiles. This seems a sign of perhaps not having many end to end examples in the API javadoc?

This is because the Classfile object update mostly affects the obtaining of ClassModel and how a ClassBuilder is converted to bytecode. Many examples interact with existing models, or builders for methods/fields/code, so they 
stay unchanged during the snippet update.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607765692

From asotona at openjdk.org  Mon Jun 26 16:33:12 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 16:33:12 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
 <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>
 <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>
Message-ID: <gsNtfgNBTYx8qOGoTodHpJPr3uj16Au-pS9Lcqqdf30=.438ab44a-5567-4198-ab5c-46e0304fda59@github.com>

On Mon, 26 Jun 2023 15:40:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The API changes look great. I like the instance usages of ClassFile, and how CF is now used in a centralized fashion to double down as a cache/option store (and entry point for transformation). Seems like a step in a good direction, and make the API feel a little more cohesive.
>> 
>> A small subjective comment - I'm not too fond of using "context" as a variable/accessor name for all the places where we use a classfile. E.g. if classfile is the context, perhaps these variable/accessor should just be named "classfile" ?
>
>> The API changes look great. I like the instance usages of ClassFile, and how CF is now used in a centralized fashion to double down as a cache/option store (and entry point for transformation). Seems like a step in a good direction, and make the API feel a little more cohesive.
>> 
>> A small subjective comment - I'm not too fond of using "context" as a variable/accessor name for all the places where we use a classfile. E.g. if classfile is the context, perhaps these variable/accessor should just be named "classfile" ?
> 
> Also, another observation: the number of updates snippets in javadoc seems rather low for something that touches the main entry point by which client interacts with classfiles. This seems a sign of perhaps not having many end to end examples in the API javadoc?

@mcimadamore thank you for review!
Description of `Classfile` instances as "context" is intentional compromise between discoverability (as originally proposed `Classfile.Context` didn't work very well) and clarity of the function (as `Classfile` instances may be simply confused with `ClassModel` instances).

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607827611

From asotona at openjdk.org  Mon Jun 26 16:47:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 16:47:48 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <yosFTn7Qjr_2YovB-RqToUbZ3LEFmhSOfgyk2hrueok=.e17d197d-e07e-4acf-8807-7483cf472677@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
 <yosFTn7Qjr_2YovB-RqToUbZ3LEFmhSOfgyk2hrueok=.e17d197d-e07e-4acf-8807-7483cf472677@github.com>
Message-ID: <GPxU-CoyMYg2g2jbVmjSN5SGNEhCs1CmvLYMM4SCuko=.77bc7fd0-4847-4308-9164-63e5144c2e8f@github.com>

On Mon, 26 Jun 2023 14:56:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> I ran `make docs-classfile-api-javadoc` 

Thanks for pointing this out. The makefile patches accidentally fell into this PR.

> One thing of note is that the JDK itself has a `@sealedGraph` taglet to render the sealed class hierarchy of any class. 

I'll look at adding the tags, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607840084

From asotona at openjdk.org  Mon Jun 26 16:47:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 16:47:46 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v26]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <-cKMdI--Y3dO60Pyt4xnqkpal7yHUyTflvTi18f8uh0=.2100aac0-9d5e-42af-91c9-692558279f3b@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Classfile API javadoc make patch"
  
  This reverts commit dad094d1686e4e16ccd379c091db258bec0087c5.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/5723e66a..d3d3831c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=24-25

  Stats: 39 lines in 2 files changed: 0 ins; 37 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From liach at openjdk.org  Tue Jun 27 05:08:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 05:08:26 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v26]
In-Reply-To: <-cKMdI--Y3dO60Pyt4xnqkpal7yHUyTflvTi18f8uh0=.2100aac0-9d5e-42af-91c9-692558279f3b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <-cKMdI--Y3dO60Pyt4xnqkpal7yHUyTflvTi18f8uh0=.2100aac0-9d5e-42af-91c9-692558279f3b@github.com>
Message-ID: <mn-gFz_kkL8AnACy1nLkW52I6XqwhfRhuyjqZs-q8lo=.92267d53-4012-4dc9-8230-dbcb0f836127@github.com>

On Mon, 26 Jun 2023 16:47:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Classfile API javadoc make patch"
>   
>   This reverts commit dad094d1686e4e16ccd379c091db258bec0087c5.

Congrats, now I can update many of my patches that depend on this API update.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1608804156

From asotona at openjdk.org  Tue Jun 27 05:08:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 27 Jun 2023 05:08:29 GMT
Subject: Integrated: 8308899: Introduce Classfile context and improve Classfile
 options
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <6oAP6R1nWRyObRhl6iR25H7pnaynqLN3zA6FrSGHSjk=.ec72c9fd-be2c-46cb-a130-b24da9971e43@github.com>

On Fri, 26 May 2023 14:56:57 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 990e3a70
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/990e3a700dce3441bd9506ca571c1790e57849a9
Stats:     1863 lines in 113 files changed: 669 ins; 257 del; 937 mod

8308899: Introduce Classfile context and improve Classfile options
8306650: Improve control of stack maps generation in Classfile API
8308646: Typo in ConstantValueAttribute

Reviewed-by: mcimadamore

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

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

From liach at openjdk.org  Tue Jun 27 14:20:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 14:20:20 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v4]
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into fix/cd-usage
 - Merge branch 'master' into fix/cd-usage
 - Fix build
 - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

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

Changes: https://git.openjdk.org/jdk/pull/14640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=03
  Stats: 241 lines in 6 files changed: 61 ins; 94 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/14640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14640/head:pull/14640

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

From liach at openjdk.org  Wed Jun 28 06:16:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 06:16:09 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v4]
In-Reply-To: <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
 <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
Message-ID: <8d8hNz_cwdKGnSgSleFt9YdRIj73R-lNWvWdByZiB70=.c580ba78-2404-4a84-96c2-50fee3f760fd@github.com>

On Tue, 27 Jun 2023 14:20:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Fix build
>  - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

@asotona Can you review this patch that migrates MethodTypeDesc creation to static final field access whenever possible? This allows to reuse cached descriptor strings and avoid revalidation. In addition, I dropped the jdkTreePrimitive benchmark for jdk.classfile.Write, which is identical to jdkTree as far as I see.

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

PR Comment: https://git.openjdk.org/jdk/pull/14640#issuecomment-1610809614

From asotona at openjdk.org  Wed Jun 28 12:10:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 28 Jun 2023 12:10:05 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v4]
In-Reply-To: <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
 <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
Message-ID: <MWHnZxnOIPeYIYkdp80fWAJDVcFdFBG464VPbqfq_VA=.5b0fa7aa-677d-482b-a9ad-eb0bf608e884@github.com>

On Tue, 27 Jun 2023 14:20:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Fix build
>  - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

This code replacing repeated symbols instantiation with static fields looks good.

However the patch also contains significant refactoring of jdk.jlink SystemModulesPlugin
and significant refactoring of the JMH benchmarks Write class.

I suggest to split this PR or link additional issues to it.

There is missing description of the problems so the proposed solution cannot be reviewed.

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

PR Comment: https://git.openjdk.org/jdk/pull/14640#issuecomment-1611284383

From liach at openjdk.org  Wed Jun 28 15:30:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 15:30:37 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v5]
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <aogvhejpk3oWNObvY2pYy40tmfNbEv3K8wVJs_jVd_g=.84bf7f83-6739-437c-a428-8afdd4102a55@github.com>

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Revert irrelevant changes
 - Merge branch 'master' into fix/cd-usage
 - Merge branch 'master' into fix/cd-usage
 - Merge branch 'master' into fix/cd-usage
 - Fix build
 - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

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

Changes: https://git.openjdk.org/jdk/pull/14640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=04
  Stats: 131 lines in 6 files changed: 39 ins; 19 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/14640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14640/head:pull/14640

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

From liach at openjdk.org  Wed Jun 28 15:33:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 15:33:10 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v4]
In-Reply-To: <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
 <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
Message-ID: <6m11IpeWXdPJkMPli3V3SWj40Z-N1DoM3HtP9eRXens=.1a5b2693-26aa-4695-a762-27d20172b980@github.com>

On Tue, 27 Jun 2023 14:20:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Fix build
>  - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

I have reverted the changes to SystemModulesPlugin and Write. Can you review this patch again?

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

PR Comment: https://git.openjdk.org/jdk/pull/14640#issuecomment-1611654121

From asotona at openjdk.org  Wed Jun 28 16:01:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 28 Jun 2023 16:01:27 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v5]
In-Reply-To: <aogvhejpk3oWNObvY2pYy40tmfNbEv3K8wVJs_jVd_g=.84bf7f83-6739-437c-a428-8afdd4102a55@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
 <aogvhejpk3oWNObvY2pYy40tmfNbEv3K8wVJs_jVd_g=.84bf7f83-6739-437c-a428-8afdd4102a55@github.com>
Message-ID: <BuMb5o0-JFRRFpQmCjRJbQZKhjVtPx0S-8tD7NlxHQI=.e4043c3d-b1a9-4a82-9821-e0c8778e0a8a@github.com>

On Wed, 28 Jun 2023 15:30:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Revert irrelevant changes
>  - Merge branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Fix build
>  - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

It looks good ?

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14640#pullrequestreview-1503464828

From lkorinth at openjdk.org  Wed Jun 28 17:04:24 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 28 Jun 2023 17:04:24 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
Message-ID: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>

Remove trailing "blank" lines in source files.

I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.

The fix removes trailing lines matching ^[[:space:]]*$ in

- *.java
- *.cpp
- *.hpp
- *.c
- *.h 

I have applied the following bash script to each file:

    file="$1"
    
    while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
        truncate -s -1 "$file"
    done

`git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
`git diff --ignore-blank-lines  master` displays one change

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

Commit messages:
 - h
 - c
 - hpp
 - cpp
 - 8311043: Remove trailing blank lines in source files

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

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

From erikj at openjdk.org  Thu Jun 29 07:23:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 07:23:54 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <nuJPc-yjOE7DrniF-EEjhLk-HQOBXJs4Ju4rWV4xxpw=.29e0f50a-084f-4091-8d96-ef05ab41427b@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14698#pullrequestreview-1504702261

From dholmes at openjdk.org  Thu Jun 29 07:43:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 07:43:58 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

It also seems far too large and disruptive.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612567676

From erikj at openjdk.org  Thu Jun 29 08:00:58 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 08:00:58 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <Jo4ev4ByTzxMNpDvKGyYL9G8TzbpVerc1YXde4iu_5Q=.afe5e6d2-63a5-4956-9d5c-17675789a051@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

The patch is leaving exactly one newline at the end of the file.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612588091

From lkorinth at openjdk.org  Thu Jun 29 08:58:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 08:58:59 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <z1LaNlMKfruphxc495xDHe2Ou64psUrXMobtiqqnqqk=.cdf515c9-2243-42ba-bea6-d24967ce3634@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.
>
> It also seems far too large and disruptive.

Do you still think it is too disruptive after Erik's explanation?  I could split it in more reviews, but I thought that maybe it would just make the review harder. I was hoping the two `git diff` commands I gave in my first comment in combination with the clean script would make the change seem reviewable.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612660457

From coleenp at openjdk.org  Thu Jun 29 12:03:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:03:56 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Why do we care about this?

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613018234

From dholmes at openjdk.org  Thu Jun 29 12:14:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 12:14:55 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

But to me this is too disruptive with no tangible benefit. And you need buy-in from all the different areas affected by this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613043398

From liach at openjdk.org  Thu Jun 29 12:36:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 12:36:04 GMT
Subject: Integrated: 8310848: Convert ClassDesc and MethodTypeDesc to be stored
 in static final fields
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <CKTHgwyK_hpXlkZRSYRQTfaX1I1T4ud6_ycRjukjzMQ=.cd602e71-4a1c-48d0-9bbc-4041a03cfed0@github.com>

On Sun, 25 Jun 2023 02:57:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html

This pull request has now been integrated.

Changeset: 07734f6d
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07734f6dde2b29574b6ef98eeb9e007d8801a3ea
Stats:     131 lines in 6 files changed: 39 ins; 19 del; 73 mod

8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

Reviewed-by: asotona

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

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

From lkorinth at openjdk.org  Thu Jun 29 12:38:57 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 12:38:57 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
Message-ID: <vkPgWAbLJRXEPOQ0alkrWJ7Gv7jLDEF3ak1ipe9xxZw=.5b93f57d-7ddb-42fb-b41b-76f4e3193d78@github.com>

On Thu, 29 Jun 2023 12:01:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Why do we care about this?

I care because of global-whitespace-cleanup-mode (in emacs). It helps me remove trailing whitespaces and blanklines when saving but it will not fix a file that was "dirty" when it was opened. Trailing blank lines triggers it not to clean whitespaces for me.

And it does not look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613095390

From coleenp at openjdk.org  Thu Jun 29 12:42:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:42:56 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

You could fix your emacs functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613106245

From lkorinth at openjdk.org  Thu Jun 29 13:08:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 13:08:59 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
Message-ID: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>

On Thu, 29 Jun 2023 12:11:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

My changes look like this in the diff output

 }
-

Removal of the last newline would look like this:

-}
+}
\ No newline at end of file

(both with `git diff` and `git diff --unified`) 

I have not tested if this is also true for the generated webrevs, but I think that is precisely how they are created.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613152641

From lkorinth at openjdk.org  Thu Jun 29 14:12:55 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 14:12:55 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
Message-ID: <pfRQFPE48dsB4zX-Rf7hnkzlyMzdctcY-veiO1KeN70=.bffbbead-ef44-461c-8362-21418c7db00e@github.com>

On Thu, 29 Jun 2023 12:40:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> You could fix your emacs functions.

It is a *very nice* feature of global-whitespace-cleanup-mode

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613252347

From coleenp at openjdk.org  Thu Jun 29 15:46:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 15:46:57 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <DR0fysIfEikX8EG5J7RlPyej6GFMsw-_WkeuS7pM6HM=.36fca2c0-54a4-4563-b40a-c626bc7e1587@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Per had an emacs feature to remove whitespaces at the end of the line, and gave me the vim version of that.  That's a nice feature.  I object to this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613437709

From lkorinth at openjdk.org  Thu Jun 29 16:55:05 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:05 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <azIQJToZ2tpGJTsICHpL96zs9mmHI3fW-laYwy3H-Xk=.99615245-24f9-4b95-b66d-eaba04c8318c@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This was not liked, I will close it.

I will possibly do it under another PR for the GC code.

Thanks for reviewing.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613526703

From lkorinth at openjdk.org  Thu Jun 29 16:55:06 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:06 GMT
Subject: Withdrawn: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <Hsf1WhdMKL5I-3HmOkCZQJWI3MPIHPnFUpo_oMkZj6I=.1ca1f233-3eb8-4d1e-ae3e-eb19729dc1c9@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Fri Jun 30 01:24:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 01:24:05 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
 <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
Message-ID: <ufj18ITz-S_VgkscmrxacxLtfQB-4I5hpgs8c61kOmA=.15f34364-70ac-4279-8669-f01e109b8411@github.com>

On Thu, 29 Jun 2023 13:05:58 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My changes look like this in the diff output
> ```
>  }
> -
> ```

Thanks for showing  this and other output. To me this looked like the final newline had been removed. I would have expected to see something that more obviously showed more than one blank line before hand and exactly one after.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613985636

From dcubed at openjdk.org  Fri Jun 30 15:21:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 15:21:10 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <1HPsLLkrre-aTNkUCrJ2Os1Ba20NZW-s3bYL1nJU17Q=.47ea0d5b-f382-48a5-ba1b-957a003277d6@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Ending the file with a blank line? I would not have expected that at all.
I expect a single EOL at the end of the file; from a visual POV, the last
line of non-blank text ends with an EOL. No more, no less.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1614806396