From jwaters at openjdk.org  Thu Jun  1 06:52:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Jun 2023 06:52:05 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <4atS6_AQCdSp76e4kyyUjAjV-X20m_a7KIkeS8KBgbk=.f9bea8a2-caaa-4d03-9031-560739068b2b@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Ah, that's good to know, now we'll just have to wait for the CSR review

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1571457172

From jlaskey at openjdk.org  Thu Jun  1 12:27:36 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 12:27:36 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v25]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <HRyc0-xwkrLya5U6LFlZ6eHdVGJNxNfTVWWgXv9nMlY=.a8cb4970-59ca-459d-a6cf-0d0b4a6223f9@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Restrict access to unnamed class members when doing separate compilation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/d0189fc2..4bfb8020

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=23-24

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

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

From jlaskey at openjdk.org  Thu Jun  1 12:38:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 12:38:30 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v26]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <s1U0r4ACsoSsz76y0GYlFEzbhTL21jCpjkhJl0S_qSI=.8e4270e2-40de-47e6-a8de-c8f9f6f1d22f@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Missing Preview feature enum

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/4bfb8020..850a2152

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=24-25

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

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

From alanb at openjdk.org  Thu Jun  1 12:58:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 12:58:19 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <Hv1ITXYgGt-Wchfd4GXWuzmnbuIo4LMXL1Cb5mQCgQk=.72247468-b69e-4f47-b80e-9e1f937f0f93@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
 <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>
 <Hv1ITXYgGt-Wchfd4GXWuzmnbuIo4LMXL1Cb5mQCgQk=.72247468-b69e-4f47-b80e-9e1f937f0f93@github.com>
Message-ID: <SGH897tX6D03BJl_BSq0BWBuwMc9J6tqLPu0PMEIS64=.e442eaba-f702-42bb-8519-27302dd97d3d@github.com>

On Tue, 23 May 2023 18:09:03 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Yes. There is some juggling going on to get the code to align with the requirement and the interpretation thereof.

Is this stable now, specifically the "Selecting a main method" section and the behavior change where an instance main takes precedence over an "inherited" static main? Just checking before doing another pass over the method finder.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1213112842

From jlaskey at openjdk.org  Thu Jun  1 13:13:20 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 13:13:20 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <SGH897tX6D03BJl_BSq0BWBuwMc9J6tqLPu0PMEIS64=.e442eaba-f702-42bb-8519-27302dd97d3d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
 <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>
 <Hv1ITXYgGt-Wchfd4GXWuzmnbuIo4LMXL1Cb5mQCgQk=.72247468-b69e-4f47-b80e-9e1f937f0f93@github.com>
 <SGH897tX6D03BJl_BSq0BWBuwMc9J6tqLPu0PMEIS64=.e442eaba-f702-42bb-8519-27302dd97d3d@github.com>
Message-ID: <QrvF_RpGAqY6aoXDTN4iGaZIYvr7KkvW_eqWEKGY8us=.f987251d-3827-48b9-8ba5-b23c9ea240c6@github.com>

On Thu, 1 Jun 2023 12:55:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yes. There is some juggling going on to get the code to align with the requirement and the interpretation thereof.
>
>> Yes. There is some juggling going on to get the code to align with the requirement and the interpretation thereof.
> 
> Is this stable now, specifically the "Selecting a main method" section and the behavior change where an instance main takes precedence over an "inherited" static main? Just checking before doing another pass over the method finder.

I think so - additional changes will be coming from Joe via https://github.com/openjdk/jdk/pull/14165

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1213132645

From hannesw at openjdk.org  Thu Jun  1 13:20:06 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 1 Jun 2023 13:20:06 GMT
Subject: RFR: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>"
In-Reply-To: <agyvNcy18QQHLDyfJTYoVCLSWXr_MRtofuL86Veu384=.204db998-6642-4cd0-9262-7d82465fc06d@github.com>
References: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
 <agyvNcy18QQHLDyfJTYoVCLSWXr_MRtofuL86Veu384=.204db998-6642-4cd0-9262-7d82465fc06d@github.com>
Message-ID: <fVmLAbk4mq--sFv_rKWYtEJwRitjGAKpIBJ0g74vx8M=.926ac320-0142-4523-a2f6-19897ab0d9dd@github.com>

On Wed, 24 May 2023 20:15:45 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to downgrade from error to warning if the label of a `<a>` element or reference tag contains an HTML block element. Before HTML 5, elements were clearly divided into block and inline elements, and the latter were not allowed to contain the former. 
>> 
>> With HTML5, the division between block and inline elements is delegated to CSS, and although elements have default styles, styles can be freely customized by the author. This applies especially true for the `<a>` element which is commonly used both with inline and block layout. That was the rationale for downgrading from error to warning for the `<a>` element only. See the JBS issue comments for details and references.
>> 
>> The error message for the warning was enhanced to refer to the default style for the `<a>` element.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 80:
> 
>> 78: dc.tag.not.allowed = element not allowed in documentation comments: <{0}>
>> 79: dc.tag.not.allowed.inline.element = block element not allowed within inline element <{1}>: {0}
>> 80: dc.tag.not.allowed.element.default.style = block element not allowed within element <{1}> with default style: {0}
> 
> Is it possible to improve the wording?
> 
> As written, it is ambiguous/confusing: it seems like `{0}` is the default style, which I don't think is what you intend.
> Also, inconsistent pointy brackets `<{1}>` but just `{0}`

Would the following be better?


block element <{0}> not allowed within element <{1}> with default style


I found inconsistent use of angle brackets in several other messages in that file. Attempting to fix that causes a lot of breaking doclint tests, not sure if it is worth doing that as part of this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13990#discussion_r1213141539

From jlaskey at openjdk.org  Thu Jun  1 17:18:29 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 17:18:29 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v27]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <2qIU0N6p64RU24IJ3EUaeMFo3GKnYYdd1BdN8cfeI8Y=.4d6b67be-aaf3-44b3-af5e-0d37d28e8414@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Integrate JDK-8308916 and  JDK-8308831 - javax.model

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/850a2152..9d111c26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=25-26

  Stats: 313 lines in 6 files changed: 302 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From jlahoda at openjdk.org  Thu Jun  1 17:29:05 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Jun 2023 17:29:05 GMT
Subject: RFR: 8309093: Underscore with brackets
In-Reply-To: <f0aKlVcOaJ338DZjkEsMD0R9uAKDDMqIU0FTzKx9kow=.c2c14876-e0ba-4955-a70c-a52db284b89d@github.com>
References: <f0aKlVcOaJ338DZjkEsMD0R9uAKDDMqIU0FTzKx9kow=.c2c14876-e0ba-4955-a70c-a52db284b89d@github.com>
Message-ID: <pQ2UJsdYTj1BcU7JH4aFLvExR9oxV60_ild9zk3M1Fg=.520b2bc2-1c9b-42c0-b39d-63590d5503e7@github.com>

On Tue, 30 May 2023 13:13:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Currently `<type> _[]` passes compilation while it is prohibited by the [spec](https://cr.openjdk.org/~abimpoudis/unnamed/jep443-20230322/specs/unnamed-jls.html#jls-14.14.2). This PR addresses that.

Looks reasonable.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14217#pullrequestreview-1455972110

From jlaskey at openjdk.org  Thu Jun  1 19:09:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 19:09:18 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v28]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <HVtDkCc1zYlCIwt10GViT4WLgAQ1zMK_hz-hIzrdmwU=.c314c9bc-f8e8-4ff5-8ca7-3d2ccfb4eb06@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Integrating JDK-8308913

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/9d111c26..f1acdb04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=26-27

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

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

From jlaskey at openjdk.org  Thu Jun  1 20:07:40 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 20:07:40 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v29]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <6uEQPQcZ9b-RmEk42cpkRONL_BSNGufigOGBtKqbGFA=.a37c1ed8-e5b0-4720-8a6a-56c32d056256@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Merge branch 'master' into 8306112
 - Integrating JDK-8308913
 - Integrate JDK-8308916 and  JDK-8308831 - javax.model
 - Missing Preview feature enum
 - Restrict access to unnamed class members when doing separate compilation.
 - Merge branch 'master' into 8306112
 - Remove mandated flag
 - Remove trailing whitespace
 - Add main  tests for inferface/enum/record
 - Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
   
   Author: Jan Lahoda <jlahoda at openjdk.org>
 - ... and 35 more: https://git.openjdk.org/jdk/compare/2bb19724...e39e3fe9

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=28
  Stats: 1648 lines in 41 files changed: 1471 ins; 32 del; 145 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From darcy at openjdk.org  Thu Jun  1 21:04:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Jun 2023 21:04:30 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v5]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <HTAFR7FhcvE_E-uaYsDZmSwQwx254-o0D9fYMLFH7GE=.f20d3c43-9db9-4ed5-812f-99e35c87bebf@github.com>

> Time to get JDK 22 underway...

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

 - Update symbol files for JDK 21 build 25.
 - Merge branch 'master' into JDK-8306584
 - Refactor a few more enums.
 - Respond to review comments.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Sync in symbol changes for JDK 21 build 24.
 - Merge branch 'master' into JDK-8306584
 - ... and 19 more: https://git.openjdk.org/jdk/compare/0ab09630...075a2ab6

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

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=04
  Stats: 5956 lines in 69 files changed: 5902 ins; 0 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

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

From abimpoudis at openjdk.org  Fri Jun  2 06:18:16 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 2 Jun 2023 06:18:16 GMT
Subject: Integrated: 8309093: Underscore with brackets
In-Reply-To: <f0aKlVcOaJ338DZjkEsMD0R9uAKDDMqIU0FTzKx9kow=.c2c14876-e0ba-4955-a70c-a52db284b89d@github.com>
References: <f0aKlVcOaJ338DZjkEsMD0R9uAKDDMqIU0FTzKx9kow=.c2c14876-e0ba-4955-a70c-a52db284b89d@github.com>
Message-ID: <VJh7Zb3XI9BCoyurUEtRad7iQf_UATezNFpMfeTCmwI=.218631c0-05b8-431d-be2d-c5a8f956281b@github.com>

On Tue, 30 May 2023 13:13:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Currently `<type> _[]` passes compilation while it is prohibited by the [spec](https://cr.openjdk.org/~abimpoudis/unnamed/jep443-20230322/specs/unnamed-jls.html#jls-14.14.2). This PR addresses that.

This pull request has now been integrated.

Changeset: 80075997
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8007599756ad9052afaa64044bb4703e813dc080
Stats:     50 lines in 6 files changed: 47 ins; 0 del; 3 mod

8309093: Underscore with brackets

Reviewed-by: jlahoda

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

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

From jlaskey at openjdk.org  Fri Jun  2 11:51:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Jun 2023 11:51:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v30]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <NWJ1FTjFDNJvCy3OixcD-CZYrSQtRs8ql6RlFD_tcl0=.890c5a56-545f-44e4-94e1-d2f52101ea78@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:

 - Merge branch 'master' into 8306112
 - Update reflection to follow spec
 - Merge branch 'master' into 8306112
 - Integrating JDK-8308913
 - Integrate JDK-8308916 and  JDK-8308831 - javax.model
 - Missing Preview feature enum
 - Restrict access to unnamed class members when doing separate compilation.
 - Merge branch 'master' into 8306112
 - Remove mandated flag
 - Remove trailing whitespace
 - ... and 37 more: https://git.openjdk.org/jdk/compare/dc8bc6c9...0edcd9ae

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=29
  Stats: 1678 lines in 41 files changed: 1500 ins; 32 del; 146 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From jlahoda at openjdk.org  Fri Jun  2 12:54:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 Jun 2023 12:54:24 GMT
Subject: RFR: 8309336: Incorrect switch in enum not reported properly
Message-ID: <q2wYfZnU-2qSEVqeXhjAtqR86LZT1qdZe8g1bX7R298=.5eac22a4-9383-48c0-9cd5-9470e9ad2696@github.com>

As of JDK 21, enum constants may be qualified in switches. But there's a bug in the way these "constants" are attributed. Having code like:

class EnumLabelMustBeEnumConstant {
    enum E { A };

    void m(E e) {
        switch (e) {
            case EA -> {}
            default -> {}
        }
    }

    static final E EA;
}


javac will attribute `EA`, which will turn out to exist, and have the correct type (`E`), so that it will be accepted (and may crash javac later in the backend).

The proposed fix is simply to check that the given expression is an enum constant.

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

Commit messages:
 - Improving error messages.
 - Fixing tests.
 - Improving error messages for non-enum switch
 - 8309336: Incorrect switch in enum not reported properly

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

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

From asotona at openjdk.org  Fri Jun  2 14:04:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Jun 2023 14:04:05 GMT
Subject: RFR: 8305225: A service broken error despite annotation processor
 generating it if directives listed
In-Reply-To: <TQLzFVYWrFYcW2HQMCmIYOzUSx6oQ3J9JjtSGgV8A60=.ea3a0960-00c2-45b6-bd92-77cbf340c6ef@github.com>
References: <TQLzFVYWrFYcW2HQMCmIYOzUSx6oQ3J9JjtSGgV8A60=.ea3a0960-00c2-45b6-bd92-77cbf340c6ef@github.com>
Message-ID: <FRAIMZf1odHJfqLATGXxPJhCrsaMuWQQLSH-RjeYtBI=.19e9d1a8-b940-4003-b8a6-a80cf537b1a8@github.com>

On Thu, 18 May 2023 13:21:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> module m {
>      provides api.Api with impl.Impl; //impl.Impl is not in sources, but is generated by an annotation processor
> }
> 
> 
> This works fine, until the processor asks for the given module's directives, in which case the build fails with an error like:
> 
> testCreateProvidesWithAP/src/m/module-info.java:2: error: the service implementation does not have a default constructor: Test
>     provides api.Api with test.Test;
> 
> 
> The cause for this error is that when the directive is analyzed, the `test.Test` is attributed (and any errors from that are delayed due to the annotation processing), but even though it attributes to an erroneous type, it will still be checked whether it has the appropriate constructor, etc.
> 
> The proposal is to skip the additional checks when the type is an erroneous type. Errors for it should have been reported and handled appropriately (i.e. ignored if resolved by an AP, or reported if not), there does not seem to be any reason to produce any further errors related to the missing type.

It looks good ?

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14046#pullrequestreview-1457554605

From vromero at openjdk.org  Fri Jun  2 17:08:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Jun 2023 17:08:05 GMT
Subject: RFR: 8309336: Incorrect switch in enum not reported properly
In-Reply-To: <q2wYfZnU-2qSEVqeXhjAtqR86LZT1qdZe8g1bX7R298=.5eac22a4-9383-48c0-9cd5-9470e9ad2696@github.com>
References: <q2wYfZnU-2qSEVqeXhjAtqR86LZT1qdZe8g1bX7R298=.5eac22a4-9383-48c0-9cd5-9470e9ad2696@github.com>
Message-ID: <M0SczLFqob6CcibSZu26k3hRRKGQ7ov5z8t9mqFIv_w=.9e96af38-a7f6-4e79-a256-52d33526116e@github.com>

On Fri, 2 Jun 2023 12:47:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As of JDK 21, enum constants may be qualified in switches. But there's a bug in the way these "constants" are attributed. Having code like:
> 
> class EnumLabelMustBeEnumConstant {
>     enum E { A };
> 
>     void m(E e) {
>         switch (e) {
>             case EA -> {}
>             default -> {}
>         }
>     }
> 
>     static final E EA;
> }
> 
> 
> javac will attribute `EA`, which will turn out to exist, and have the correct type (`E`), so that it will be accepted (and may crash javac later in the backend).
> 
> The proposed fix is simply to check that the given expression is an enum constant.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14284#pullrequestreview-1458056913

From jlaskey at openjdk.org  Fri Jun  2 20:18:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Jun 2023 20:18:07 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v31]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <HK1h-vFWbotQHsYTAQyQFHjH6WsclwZ_cm0cBuq1XhU=.16f2e30b-393c-434f-9c97-ddc3aae86c7c@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Use getQualifiedName() to indicate unnamed class
 - ClassSymbol#getSimpleName() returning empty name breaks some tools

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/0edcd9ae..97a522f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=29-30

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

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

From jlaskey at openjdk.org  Fri Jun  2 22:10:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Jun 2023 22:10:44 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/97a522f7..55b6be5b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=30-31

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

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

From darcy at openjdk.org  Sat Jun  3 01:56:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Jun 2023 01:56:18 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
Message-ID: <EL34kCYqNb-9aFTsl57w1WI5GyCSIRjzk3Wu6dkZ0D8=.bbd33dfe-a52f-4a5a-b73e-555371dbc94d@github.com>

On Fri, 2 Jun 2023 22:10:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

src/java.base/share/classes/java/lang/Class.java line 1884:

> 1882:                     reflective=true)
> 1883:     public boolean isUnnamedClass() {
> 1884:         return PreviewFeatures.isEnabled() && isSynthetic() && isTopLevelClass();

Please add a check for final-ness as @mlchung suggested in the other PR of the reflection changes stand-alone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1215095660

From duke at openjdk.org  Sat Jun  3 05:46:39 2023
From: duke at openjdk.org (Sebastian Stenzel)
Date: Sat, 3 Jun 2023 05:46:39 GMT
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits [v2]
In-Reply-To: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
Message-ID: <61JoRbYu5N5bUzVxrA7HyVn5x5DNU2vzcSMoAEutCpI=.5f14d799-995d-4dc3-a0a2-94b187e81617@github.com>

> Since this is a rather trivial change, I didn't start a new discussion, as I deem this sufficiently discussed [back in early 2021](https://mail.openjdk.org/pipermail/discuss/2021-March/005779.html).

Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision:

  applied latest proposal
  
  result of discussion openjdk/jdk#14099

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14099/files
  - new: https://git.openjdk.org/jdk/pull/14099/files/a7f0e92d..eed69a03

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

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

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

From duke at openjdk.org  Sat Jun  3 05:46:39 2023
From: duke at openjdk.org (Sebastian Stenzel)
Date: Sat, 3 Jun 2023 05:46:39 GMT
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits [v2]
In-Reply-To: <RGCbJI6iR3v4LMfFjsvUwDtOb6HS94uJMLXwX5P4KYk=.65f58098-d578-4386-9433-094b91c038eb@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <RGCbJI6iR3v4LMfFjsvUwDtOb6HS94uJMLXwX5P4KYk=.65f58098-d578-4386-9433-094b91c038eb@github.com>
Message-ID: <a4cy_Y7zzp69tsblBB00I696MQ5zB-czi3E2RDWM5Tg=.8c677ad6-3da4-4c05-a5ad-ce88778e85f3@github.com>

On Wed, 24 May 2023 20:00:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied latest proposal
>>   
>>   result of discussion openjdk/jdk#14099
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1864:
> 
>> 1862: # 0: name
>> 1863: compiler.warn.poor.choice.for.module.name=\
>> 1864:     module name component {0} ends with a digit. Module names should not encode version information in module names
> 
> Duplicate text
> 
> _Module names_. should not ... in _module names_

fixed in eed69a0

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14099#discussion_r1215244676

From darcy at openjdk.org  Sat Jun  3 23:18:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Jun 2023 23:18:17 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
Message-ID: <xU8SseGoaVwCC4YQqfbcwwnP6oNS9Q5QKd8xjggg0fU=.a056412f-7100-4167-bcbf-5be09337d030@github.com>

On Fri, 2 Jun 2023 22:10:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1379:

> 1377:          @Override @DefinedBy(Api.LANGUAGE_MODEL)
> 1378:          public Name getSimpleName() {
> 1379:              // return isUnnamed() ? name.subName(0, 0) /* empty name */ : name;

This line could be deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1215925243

From darcy at openjdk.org  Sat Jun  3 23:24:19 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Jun 2023 23:24:19 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
Message-ID: <cDe8Kz-rNxvDiulsEk0HkuXfGFkb6ZnIUflU059nRes=.e8784f29-9eb2-48cd-ba8c-b541a53b42bf@github.com>

On Fri, 2 Jun 2023 22:10:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 140:

> 138:         }
> 139: 
> 140:         if (unnamedClass.getSimpleName().isEmpty()) {

Presumably the sense of the predicates testing names needs to now be reserved due to subsequent updates to the javax.lang.model support.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1215928629

From darcy at openjdk.org  Sat Jun  3 23:33:19 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Jun 2023 23:33:19 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
Message-ID: <lkZ4DQ50wb5ccDRl2SSpRPPdAAg8VK5UdVHywUXS4WA=.7a890a19-d87d-42cf-aaff-337c1727371b@github.com>

On Fri, 2 Jun 2023 22:10:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

Core reflection and javax.lang.model APIs look fine.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1460430032

From darcy at openjdk.org  Mon Jun  5 02:24:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 02:24:07 GMT
Subject: RFR: JDK-8309416: Misstatement in semantics of methods in
 javax.lang.model.ElementFilter
Message-ID: <bcRNjP_6QZ55a_HkJCnYU0UuALnhMxJMDDIxKdm2tIA=.3ccfb214-e5e7-4c96-8e7a-9ae0b67bdc78@github.com>

Correct typo in API and make related improvements.

CSR to review: https://bugs.openjdk.org/browse/JDK-8309417

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

Commit messages:
 - JDK-8309417: Misstatement in semantics of methods in javax.lang.model.ElementFilter

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

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

From jlahoda at openjdk.org  Mon Jun  5 06:28:18 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Jun 2023 06:28:18 GMT
Subject: Integrated: 8309336: Incorrect switch in enum not reported properly
In-Reply-To: <q2wYfZnU-2qSEVqeXhjAtqR86LZT1qdZe8g1bX7R298=.5eac22a4-9383-48c0-9cd5-9470e9ad2696@github.com>
References: <q2wYfZnU-2qSEVqeXhjAtqR86LZT1qdZe8g1bX7R298=.5eac22a4-9383-48c0-9cd5-9470e9ad2696@github.com>
Message-ID: <dxSs3m_2-JeRa8gXhuRwRKKng7FLijvglEvl3mtyT8A=.886ee6c3-f96f-41d0-b090-8c1a1db1c174@github.com>

On Fri, 2 Jun 2023 12:47:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As of JDK 21, enum constants may be qualified in switches. But there's a bug in the way these "constants" are attributed. Having code like:
> 
> class EnumLabelMustBeEnumConstant {
>     enum E { A };
> 
>     void m(E e) {
>         switch (e) {
>             case EA -> {}
>             default -> {}
>         }
>     }
> 
>     static final E EA;
> }
> 
> 
> javac will attribute `EA`, which will turn out to exist, and have the correct type (`E`), so that it will be accepted (and may crash javac later in the backend).
> 
> The proposed fix is simply to check that the given expression is an enum constant.

This pull request has now been integrated.

Changeset: 05fb6c66
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05fb6c6648bc759853c5a9c5b932706592d87ba9
Stats:     121 lines in 7 files changed: 112 ins; 1 del; 8 mod

8309336: Incorrect switch in enum not reported properly

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Mon Jun  5 06:34:16 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Jun 2023 06:34:16 GMT
Subject: Integrated: 8305225: A service broken error despite annotation
 processor generating it if directives listed
In-Reply-To: <TQLzFVYWrFYcW2HQMCmIYOzUSx6oQ3J9JjtSGgV8A60=.ea3a0960-00c2-45b6-bd92-77cbf340c6ef@github.com>
References: <TQLzFVYWrFYcW2HQMCmIYOzUSx6oQ3J9JjtSGgV8A60=.ea3a0960-00c2-45b6-bd92-77cbf340c6ef@github.com>
Message-ID: <4fVvoFDzb0Y7JKpWzjx7WDiLtrjTYpUlMpgv4BtZbn4=.b3955e57-d5ab-476c-9f4b-b4b18d9f99f4@github.com>

On Thu, 18 May 2023 13:21:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> module m {
>      provides api.Api with impl.Impl; //impl.Impl is not in sources, but is generated by an annotation processor
> }
> 
> 
> This works fine, until the processor asks for the given module's directives, in which case the build fails with an error like:
> 
> testCreateProvidesWithAP/src/m/module-info.java:2: error: the service implementation does not have a default constructor: Test
>     provides api.Api with test.Test;
> 
> 
> The cause for this error is that when the directive is analyzed, the `test.Test` is attributed (and any errors from that are delayed due to the annotation processing), but even though it attributes to an erroneous type, it will still be checked whether it has the appropriate constructor, etc.
> 
> The proposal is to skip the additional checks when the type is an erroneous type. Errors for it should have been reported and handled appropriately (i.e. ignored if resolved by an AP, or reported if not), there does not seem to be any reason to produce any further errors related to the missing type.

This pull request has now been integrated.

Changeset: b6c9232b
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6c9232b8b2010e360abfba6f0d294dc27187911
Stats:     94 lines in 2 files changed: 91 ins; 0 del; 3 mod

8305225: A service broken error despite annotation processor generating it if directives listed

Reviewed-by: asotona

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

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

From jwaters at openjdk.org  Mon Jun  5 07:51:10 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Jun 2023 07:51:10 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <-qDWUBwRoK-Ty6z6xBK28ryhHjOzk-i0yvsMOatMVGk=.5703051d-42ab-4ef7-945a-451303a67e33@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1576254290

From prappo at openjdk.org  Mon Jun  5 08:46:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 5 Jun 2023 08:46:05 GMT
Subject: RFR: JDK-8309416: Misstatement in semantics of methods in
 javax.lang.model.ElementFilter
In-Reply-To: <bcRNjP_6QZ55a_HkJCnYU0UuALnhMxJMDDIxKdm2tIA=.3ccfb214-e5e7-4c96-8e7a-9ae0b67bdc78@github.com>
References: <bcRNjP_6QZ55a_HkJCnYU0UuALnhMxJMDDIxKdm2tIA=.3ccfb214-e5e7-4c96-8e7a-9ae0b67bdc78@github.com>
Message-ID: <lFy5Iuqk_mDeBBhqgj3ALlM-EazPAYh8DVMDBGx9iFo=.c030b9a1-8c17-460f-b081-6f69f411ef91@github.com>

On Mon, 5 Jun 2023 02:16:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Correct typo in API and make related improvements.
> 
> CSR to review: https://bugs.openjdk.org/browse/JDK-8309417

Marked as reviewed by prappo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14306#pullrequestreview-1462032146

From jlaskey at openjdk.org  Mon Jun  5 12:47:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 12:47:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <EL34kCYqNb-9aFTsl57w1WI5GyCSIRjzk3Wu6dkZ0D8=.bbd33dfe-a52f-4a5a-b73e-555371dbc94d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
 <EL34kCYqNb-9aFTsl57w1WI5GyCSIRjzk3Wu6dkZ0D8=.bbd33dfe-a52f-4a5a-b73e-555371dbc94d@github.com>
Message-ID: <pw2yRgYcMnfgehgmT8Tjv3ZD8x56Fx3Qe47R9gBbyF4=.f277b668-1af5-4156-9035-85bf2717b7d2@github.com>

On Sat, 3 Jun 2023 01:53:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName
>
> src/java.base/share/classes/java/lang/Class.java line 1884:
> 
>> 1882:                     reflective=true)
>> 1883:     public boolean isUnnamedClass() {
>> 1884:         return PreviewFeatures.isEnabled() && isSynthetic() && isTopLevelClass();
> 
> Please add a check for final-ness as @mlchung suggested in the other PR of the reflection changes stand-alone.

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1379:
> 
>> 1377:          @Override @DefinedBy(Api.LANGUAGE_MODEL)
>> 1378:          public Name getSimpleName() {
>> 1379:              // return isUnnamed() ? name.subName(0, 0) /* empty name */ : name;
> 
> This line could be deleted.

Changing

> test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 140:
> 
>> 138:         }
>> 139: 
>> 140:         if (unnamedClass.getSimpleName().isEmpty()) {
> 
> Presumably the sense of the predicates testing names needs to now be reserved due to subsequent updates to the javax.lang.model support.

True, but we should ensure that what we are shipping now does what we claim.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1218020010
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1218020222
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1218022085

From jlaskey at openjdk.org  Mon Jun  5 13:40:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 13:40:07 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v33]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <IPaVnv3u_QCrSAxgofGpRMWZKygUOP8SXffRk39YDks=.016315fc-4cd9-4452-9eea-7d2c095fa8c9@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:

 - Merge branch 'master' into 8306112
 - Requested clean ups
 - Source code launcher to use getSimpleName() when launching unnamed class
 - Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName
 - Use getQualifiedName() to indicate unnamed class
 - ClassSymbol#getSimpleName() returning empty name breaks some tools
 - Merge branch 'master' into 8306112
 - Update reflection to follow spec
 - Merge branch 'master' into 8306112
 - Integrating JDK-8308913
 - ... and 43 more: https://git.openjdk.org/jdk/compare/6d511f13...94d1eefd

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=32
  Stats: 1690 lines in 41 files changed: 1512 ins; 32 del; 146 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From jlahoda at openjdk.org  Mon Jun  5 14:54:20 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Jun 2023 14:54:20 GMT
Subject: RFR: 8309469: Pattern dominance should be adjusted
Message-ID: <o8ZiChq14w881qMrqaEczOZqj0xdKeQ_JbDQMb0O-vI=.d6b08fa4-73c1-4691-810a-c64536fd8fb0@github.com>

Currently, when a switch contains both patterns and constant labels, any pattern case dominates the constant label. E.g. the following example currently produces a compile-time error:

switch (...) {
    case Integer i when i == 0 -> {}
    case 1 -> {} //dominated by the preceding case
    case Integer i -> {}
}


But, the rules are now (to be) relaxed in the spec, so that guarded cases (with patterns) don't dominate cases with constant labels. I.e. the above example is supposed to compile and run fine.

This PR is implementing this change - when checking patter-constant dominance, we only consider unguarded cases.

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

Commit messages:
 - Fixing test.
 - 8309469: Pattern dominance should be adjusted

Changes: https://git.openjdk.org/jdk/pull/14314/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14314&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309469
  Stats: 80 lines in 4 files changed: 62 ins; 10 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14314/head:pull/14314

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

From jlaskey at openjdk.org  Mon Jun  5 16:11:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 16:11:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v34]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <ZPAfVZ7RRWfoKFFwuxbPe16WP5HK46MUrMUQSkP2ZJ0=.b43e3dc3-21c2-4c4c-818c-00890ef9afc3@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merge branch 'master' into 8306112
 - Final clean up
 - Merge branch 'master' into 8306112
 - Requested clean ups
 - Source code launcher to use getSimpleName() when launching unnamed class
 - Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName
 - Use getQualifiedName() to indicate unnamed class
 - ClassSymbol#getSimpleName() returning empty name breaks some tools
 - Merge branch 'master' into 8306112
 - Update reflection to follow spec
 - ... and 45 more: https://git.openjdk.org/jdk/compare/5cd8af76...663ca88f

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=33
  Stats: 1685 lines in 40 files changed: 1510 ins; 32 del; 143 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From darcy at openjdk.org  Mon Jun  5 16:39:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 16:39:20 GMT
Subject: Integrated: JDK-8309416: Misstatement in semantics of methods in
 javax.lang.model.ElementFilter
In-Reply-To: <bcRNjP_6QZ55a_HkJCnYU0UuALnhMxJMDDIxKdm2tIA=.3ccfb214-e5e7-4c96-8e7a-9ae0b67bdc78@github.com>
References: <bcRNjP_6QZ55a_HkJCnYU0UuALnhMxJMDDIxKdm2tIA=.3ccfb214-e5e7-4c96-8e7a-9ae0b67bdc78@github.com>
Message-ID: <0pcUGw60vfqV_gWLxPCknzqrwP2UlPlCu8oXmtjAV68=.462df6a2-e601-489a-b6bf-3f7691bb43f7@github.com>

On Mon, 5 Jun 2023 02:16:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Correct typo in API and make related improvements.
> 
> CSR to review: https://bugs.openjdk.org/browse/JDK-8309417

This pull request has now been integrated.

Changeset: 2b38343e
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b38343e4db75aabd3825c766092df75ba44c930
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8309416: Misstatement in semantics of methods in javax.lang.model.ElementFilter

Reviewed-by: prappo

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

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

From darcy at openjdk.org  Mon Jun  5 16:46:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 16:46:10 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <4atS6_AQCdSp76e4kyyUjAjV-X20m_a7KIkeS8KBgbk=.f9bea8a2-caaa-4d03-9031-560739068b2b@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
 <4atS6_AQCdSp76e4kyyUjAjV-X20m_a7KIkeS8KBgbk=.f9bea8a2-caaa-4d03-9031-560739068b2b@github.com>
Message-ID: <YXR91kzp1JqAvi7z8_yXBHV_hO4h5eYRQzysZu7MZUQ=.42299d34-b10f-4ed0-a370-684c61e97be7@github.com>

On Thu, 1 Jun 2023 06:49:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Ah, that's good to know, now we'll just have to wait for the CSR review

Note that the CSR for this issue is in "Draft" state, which means it is not on the list of CSRs being considered for review. See https://wiki.openjdk.org/display/csr/Main for details.

To request a review, move the CSR to either Proposed or Finalized; HTH.

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1577131683

From jwaters at openjdk.org  Mon Jun  5 16:53:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Jun 2023 16:53:08 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <8cbej5EHC3L6C4V6CuQjcJh260EnC8TfiEab87zPSXc=.602f330a-e489-46a8-aee1-a9f3ed993fcb@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Oops, thanks for the heads up

CSR moved to "Proposed"

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1577138249
PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1577139259

From jlaskey at openjdk.org  Mon Jun  5 16:55:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 16:55:08 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v35]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <LiCt6Krocrs0tWjbMb1gEx7ReeTu2KuqqZp-flpCEg0=.18cc8168-1789-431c-b0bd-89191a061f20@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  -Xprint unnamed classes to use  e.getSimpleName()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/663ca88f..d0fdf694

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=33-34

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

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

From jjg at openjdk.org  Mon Jun  5 17:17:08 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 5 Jun 2023 17:17:08 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <VsG9XGwrOEbiKEEGddWKF0fmxbG-NbV3vgmlm5zrow0=.b7accea5-3a50-47b9-9a45-93ebb0874bcf@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

A conservative solution would be to change the default but provide a mechanism like a hidden option to restore the old behavior in case anyone needs it.

The current behavior is not specified (but that's a different bug!) so a CSR should not be necessary, but in that case, I would advise a [Release Note](https://openjdk.org/guide/#release-notes).

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1577176688

From jlaskey at openjdk.org  Mon Jun  5 18:48:56 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 18:48:56 GMT
Subject: Integrated: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview)
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <wgo5PLPjk9AGBUnL1OZHyZmjYvYA9YKuqIadaHHC0YA=.426c5759-14d2-4afb-9ade-d998e05a3f37@github.com>

On Thu, 27 Apr 2023 12:38:11 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Add flexible main methods and anonymous main classes to the Java language.

This pull request has now been integrated.

Changeset: 98b53c06
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98b53c06cfffe7b2e21968546b4aa1523f31132e
Stats:     1685 lines in 40 files changed: 1510 ins; 32 del; 143 mod

8306112: Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview)
8308613: javax.lang.model updates for JEP 445 (preview)
8308913: Update core reflection for JEP 445 (preview)

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Co-authored-by: Joe Darcy <darcy at openjdk.org>
Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Jim Laskey <jlaskey at openjdk.org>
Co-authored-by: Adam Sotona <asotona at openjdk.org>
Reviewed-by: mcimadamore, vromero, darcy

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

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

From darcy at openjdk.org  Mon Jun  5 22:00:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 22:00:54 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445
Message-ID: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>

Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.

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

Commit messages:
 - JDK-8309503: Improve javax.lang.model tests for JEP 445

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

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

From jjg at openjdk.org  Mon Jun  5 23:33:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 5 Jun 2023 23:33:53 GMT
Subject: RFR: 8305671: javac rejects semicolons in compilation units with
 no imports [v4]
In-Reply-To: <6ecE1A13Oq3SckPoWi7nRLH-CBXfYK9zAA6bU5zE_5k=.39610068-c6b7-417c-a208-97f8f9ce3ea7@github.com>
References: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
 <PsVXPqXGBpjYcshNJaakY-6w7lcqH20i4PG3fbjDVZI=.937d6676-fe67-4558-8bfa-028701263b1a@github.com>
 <6ecE1A13Oq3SckPoWi7nRLH-CBXfYK9zAA6bU5zE_5k=.39610068-c6b7-417c-a208-97f8f9ce3ea7@github.com>
Message-ID: <1gzvy8P7YQfQlVre9yw8p0rEo_oQFMeFJ8tZrMlLo_Q=.321d55a8-e3f3-45a6-91b7-43abf1030dec@github.com>

On Tue, 18 Apr 2023 01:39:51 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> I'll add more tests, but extra semicolons prior to import statements aren't allowed;

That would make it a negative test, and you would check that an appropriate error is generated.
That being said, the test case might be included in the tests for [JDK-8027682].

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13361#discussion_r1218704669

From jjg at openjdk.org  Mon Jun  5 23:44:52 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 5 Jun 2023 23:44:52 GMT
Subject: RFR: 8305671: javac rejects semicolons in compilation units with
 no imports [v4]
In-Reply-To: <1gzvy8P7YQfQlVre9yw8p0rEo_oQFMeFJ8tZrMlLo_Q=.321d55a8-e3f3-45a6-91b7-43abf1030dec@github.com>
References: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
 <PsVXPqXGBpjYcshNJaakY-6w7lcqH20i4PG3fbjDVZI=.937d6676-fe67-4558-8bfa-028701263b1a@github.com>
 <6ecE1A13Oq3SckPoWi7nRLH-CBXfYK9zAA6bU5zE_5k=.39610068-c6b7-417c-a208-97f8f9ce3ea7@github.com>
 <1gzvy8P7YQfQlVre9yw8p0rEo_oQFMeFJ8tZrMlLo_Q=.321d55a8-e3f3-45a6-91b7-43abf1030dec@github.com>
Message-ID: <SupBTfKjIhb_Jh3AbG_9z9ANTYJuspREwckFulpMHqA=.81231b1f-7b45-465b-b2eb-89706dd64791@github.com>

On Mon, 5 Jun 2023 23:30:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> I'll add more tests, but extra semicolons prior to import statements aren't allowed; see [JDK-8027682].
>
>> I'll add more tests, but extra semicolons prior to import statements aren't allowed;
> 
> That would make it a negative test, and you would check that an appropriate error is generated.
> That being said, the test case might be included in the tests for [JDK-8027682].

I note there are no tests that *list* 8027682 in their list of bugs.  If a test is designed to test the fix for a bug, it should list the bug number in the `@bug` line in the test description.
I note that there is a test included in the patch for 8027682, but it lists an unrelated bug [JDK-5059679].
It's also a minimal test that does not include test cases for extra semicolons between a package statement and the first import statement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13361#discussion_r1218710067

From darcy at openjdk.org  Tue Jun  6 00:46:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 00:46:28 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445 [v2]
In-Reply-To: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
Message-ID: <g2o-Rv_4vEr02-ow0flWawLsQH8iMKriuOUwypinJBw=.9a49fe36-0ded-479f-93d8-8a64a09ae221@github.com>

> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Improve test to make sure some checking is done.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14321/files
  - new: https://git.openjdk.org/jdk/pull/14321/files/b142bb8b..5fd8a047

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

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

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

From acobbs at openjdk.org  Tue Jun  6 01:38:56 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 6 Jun 2023 01:38:56 GMT
Subject: RFR: 8305671: javac rejects semicolons in compilation units with
 no imports [v4]
In-Reply-To: <SupBTfKjIhb_Jh3AbG_9z9ANTYJuspREwckFulpMHqA=.81231b1f-7b45-465b-b2eb-89706dd64791@github.com>
References: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
 <PsVXPqXGBpjYcshNJaakY-6w7lcqH20i4PG3fbjDVZI=.937d6676-fe67-4558-8bfa-028701263b1a@github.com>
 <6ecE1A13Oq3SckPoWi7nRLH-CBXfYK9zAA6bU5zE_5k=.39610068-c6b7-417c-a208-97f8f9ce3ea7@github.com>
 <1gzvy8P7YQfQlVre9yw8p0rEo_oQFMeFJ8tZrMlLo_Q=.321d55a8-e3f3-45a6-91b7-43abf1030dec@github.com>
 <SupBTfKjIhb_Jh3AbG_9z9ANTYJuspREwckFulpMHqA=.81231b1f-7b45-465b-b2eb-89706dd64791@github.com>
Message-ID: <dcxfXg8Rp6d8l_ROd2zzJTXi5CTexxfqu4B5njwvPE8=.af9b7fb3-a302-4417-b663-57104b87ef05@github.com>

On Mon, 5 Jun 2023 23:41:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> I'll add more tests, but extra semicolons prior to import statements aren't allowed;
>> 
>> That would make it a negative test, and you would check that an appropriate error is generated.
>> That being said, the test case might be included in the tests for [JDK-8027682].
>
> I note there are no tests that *list* 8027682 in their list of bugs.  If a test is designed to test the fix for a bug, it should list the bug number in the `@bug` line in the test description.
> I note that there is a test included in the patch for 8027682, but it lists an unrelated bug [JDK-5059679].
> It's also a minimal test that does not include test cases for extra semicolons between a package statement and the first import statement.

> > I'll add more tests, but extra semicolons prior to import statements aren't allowed;
> 
> That would make it a negative test, and you would check that an appropriate error is generated. That being said, the test case might be included in the tests for [JDK-8027682].

Gotcha. Checking for proper detection of illegal extra semicolons is already covered in [the fix for JDK-8027682](https://github.com/openjdk/jdk/commit/4b8f7db6be80e425bebfaf6f68d49da74f29386a).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13361#discussion_r1218768216

From acobbs at openjdk.org  Tue Jun  6 01:52:58 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 6 Jun 2023 01:52:58 GMT
Subject: RFR: 8305671: javac rejects semicolons in compilation units with
 no imports [v5]
In-Reply-To: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
References: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
Message-ID: <OhEcqhwMH2DnsTy0_jGmTIOWfAEfzwCU9LF-xY33arI=.879835b7-66a5-4107-92b1-1df5a9651e6b@github.com>

> The fix for [JDK-8027682](https://bugs.openjdk.org/browse/JDK-8027682) created a new bug in which a program like this:
> 
> package p;;
> 
> would be rejected.
> 
> This is due to the previous fix swallowing all the semicolons. Instead, in the case of semicolons followed by EOF, it needs to swallow all but the last one.

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

 - Merge branch 'master' into JDK-8305671
 - Merge branch 'master' into JDK-8305671
 - Consume extra semicolons in a more straightforward way.
 - Merge branch 'master' into JDK-8305671
 - Use ToolBox and add more tests per review suggestion.
 - Allow a package declaration followed (only) by multiple commas.

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

Changes: https://git.openjdk.org/jdk/pull/13361/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13361&range=04
  Stats: 92 lines in 2 files changed: 89 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13361/head:pull/13361

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

From acobbs at openjdk.org  Tue Jun  6 01:53:00 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 6 Jun 2023 01:53:00 GMT
Subject: RFR: 8305671: javac rejects semicolons in compilation units with
 no imports [v5]
In-Reply-To: <dcxfXg8Rp6d8l_ROd2zzJTXi5CTexxfqu4B5njwvPE8=.af9b7fb3-a302-4417-b663-57104b87ef05@github.com>
References: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
 <PsVXPqXGBpjYcshNJaakY-6w7lcqH20i4PG3fbjDVZI=.937d6676-fe67-4558-8bfa-028701263b1a@github.com>
 <6ecE1A13Oq3SckPoWi7nRLH-CBXfYK9zAA6bU5zE_5k=.39610068-c6b7-417c-a208-97f8f9ce3ea7@github.com>
 <1gzvy8P7YQfQlVre9yw8p0rEo_oQFMeFJ8tZrMlLo_Q=.321d55a8-e3f3-45a6-91b7-43abf1030dec@github.com>
 <SupBTfKjIhb_Jh3AbG_9z9ANTYJuspREwckFulpMHqA=.81231b1f-7b45-465b-b2eb-89706dd64791@github.com>
 <dcxfXg8Rp6d8l_ROd2zzJTXi5CTexxfqu4B5njwvPE8=.af9b7fb3-a302-4417-b663-57104b87ef05@github.com>
Message-ID: <SfOZuwZQkkF7Xpa0bWRjnwiSkTjCrHUJ42XDAdWp5XE=.e8a4cbd9-c7d8-4d53-889b-5a8008cf04fb@github.com>

On Tue, 6 Jun 2023 01:35:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> I note there are no tests that *list* 8027682 in their list of bugs.  If a test is designed to test the fix for a bug, it should list the bug number in the `@bug` line in the test description.
>> I note that there is a test included in the patch for 8027682, but it lists an unrelated bug [JDK-5059679].
>> It's also a minimal test that does not include test cases for extra semicolons between a package statement and the first import statement.
>
>> > I'll add more tests, but extra semicolons prior to import statements aren't allowed;
>> 
>> That would make it a negative test, and you would check that an appropriate error is generated. That being said, the test case might be included in the tests for [JDK-8027682].
> 
> Gotcha. Checking for proper detection of illegal extra semicolons is already covered in [the fix for JDK-8027682](https://github.com/openjdk/jdk/commit/4b8f7db6be80e425bebfaf6f68d49da74f29386a).

> I note there are no tests that _list_ 8027682 in their list of bugs. If a test is designed to test the fix for a bug, it should list the bug number in the `@bug` line in the test description. I note that there is a test included in the patch for 8027682, but it lists an unrelated bug [JDK-5059679].

Ah yes - that's a bug bug (so to speak). Must have been a cut & paste error on my part.

I've filed [JDK-8309511](https://bugs.openjdk.org/browse/JDK-8309511) to fix that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13361#discussion_r1218774052

From acobbs at openjdk.org  Tue Jun  6 02:01:13 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 6 Jun 2023 02:01:13 GMT
Subject: RFR: 8309511: Regression test ExtraImportSemicolon.java refers to the
 wrong bug
Message-ID: <q0klSK94ZawvuTwY9MyS7q4eFTnpY81zcF66yFFFDBo=.4e4ee534-24ce-421f-a706-22e64c247213@github.com>

Please review this trivial fix for an incorrect `@bug` reference in `ExtraImportSemicolon.java`.

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

Commit messages:
 - Fix incorrect @bug reference in regression test for JDK-8027682.

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

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

From jlahoda at openjdk.org  Tue Jun  6 06:16:54 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 6 Jun 2023 06:16:54 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445 [v2]
In-Reply-To: <g2o-Rv_4vEr02-ow0flWawLsQH8iMKriuOUwypinJBw=.9a49fe36-0ded-479f-93d8-8a64a09ae221@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
 <g2o-Rv_4vEr02-ow0flWawLsQH8iMKriuOUwypinJBw=.9a49fe36-0ded-479f-93d8-8a64a09ae221@github.com>
Message-ID: <TNuH6zrtrQ0cfoCt5YGaKF-LSgo8l1sZd7reUbV0TvE=.93082a50-23a2-4b41-b618-a93121e953a6@github.com>

On Tue, 6 Jun 2023 00:46:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test to make sure some checking is done.

Looks OK to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14321#pullrequestreview-1464341424

From asotona at openjdk.org  Tue Jun  6 12:15:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Jun 2023 12:15:07 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v4]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <1l1hrTeZ3i2uTju6KVyTWCoSIJJ-A7nWOATG6b6FGQ8=.a327ed72-3e20-4f2b-8c94-ca257c69bdf8@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> 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 218 commits:

 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
 - fixed build
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - consolidated safeguarding of IAE in javap
 - consolidation of constant pool originating IAEs and IOOBEs into ConstantPoolException extending IAE
 - Safeguarding CP errors + test
 - ... and 208 more: https://git.openjdk.org/jdk/compare/98b53c06...a688bf49

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=03
  Stats: 3638 lines in 22 files changed: 835 ins; 1716 del; 1087 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From jwaters at openjdk.org  Tue Jun  6 15:35:55 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 Jun 2023 15:35:55 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <fUeea5hmWj5ys8Tx5LsTtq-nMQpg6UPQ5QvFsJGorco=.7110b934-1a01-4fe0-8d43-7f5fad3efdba@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Release Note created as https://bugs.openjdk.org/browse/JDK-8309551



> @TheShermanTanker only [Reviewers](https://openjdk.org/bylaws#reviewer) can determine that a CSR is not needed.

...

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1578992948

From jjg at openjdk.org  Tue Jun  6 16:09:57 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 6 Jun 2023 16:09:57 GMT
Subject: RFR: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>"
In-Reply-To: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
References: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
Message-ID: <7R2bLoTRFvFplHI56vJCZKju---ju3FdMlBWVYPZbxo=.f82dfc52-3406-40b8-b882-8b4e09b8045b@github.com>

On Mon, 15 May 2023 14:43:15 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to downgrade from error to warning if the label of a `<a>` element or reference tag contains an HTML block element. Before HTML 5, elements were clearly divided into block and inline elements, and the latter were not allowed to contain the former. 
> 
> With HTML5, the division between block and inline elements is delegated to CSS, and although elements have default styles, styles can be freely customized by the author. This applies especially true for the `<a>` element which is commonly used both with inline and block layout. That was the rationale for downgrading from error to warning for the `<a>` element only. See the JBS issue comments for details and references.
> 
> The error message for the warning was enhanced to refer to the default style for the `<a>` element.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13990#pullrequestreview-1465570748

From jjg at openjdk.org  Tue Jun  6 16:10:03 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 6 Jun 2023 16:10:03 GMT
Subject: RFR: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>"
In-Reply-To: <fVmLAbk4mq--sFv_rKWYtEJwRitjGAKpIBJ0g74vx8M=.926ac320-0142-4523-a2f6-19897ab0d9dd@github.com>
References: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
 <agyvNcy18QQHLDyfJTYoVCLSWXr_MRtofuL86Veu384=.204db998-6642-4cd0-9262-7d82465fc06d@github.com>
 <fVmLAbk4mq--sFv_rKWYtEJwRitjGAKpIBJ0g74vx8M=.926ac320-0142-4523-a2f6-19897ab0d9dd@github.com>
Message-ID: <rtfUHObjD0Fs7HcZg6osMq9CP0Shzoxz8lmsBuM2oLc=.5ef59120-a329-46fd-85db-f8032b176600@github.com>

On Thu, 1 Jun 2023 13:17:32 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 80:
>> 
>>> 78: dc.tag.not.allowed = element not allowed in documentation comments: <{0}>
>>> 79: dc.tag.not.allowed.inline.element = block element not allowed within inline element <{1}>: {0}
>>> 80: dc.tag.not.allowed.element.default.style = block element not allowed within element <{1}> with default style: {0}
>> 
>> Is it possible to improve the wording?
>> 
>> As written, it is ambiguous/confusing: it seems like `{0}` is the default style, which I don't think is what you intend.
>> Also, inconsistent pointy brackets `<{1}>` but just `{0}`
>
> Would the following be better?
> 
> 
> block element <{0}> not allowed within element <{1}> with default style
> 
> 
> I found inconsistent use of angle brackets in several other messages in that file. Attempting to fix that causes a lot of breaking doclint tests, not sure if it is worth doing that as part of this change.

That looks good

Optionally, we could file a followup RFE to try and make more resources more stylistically consistent

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13990#discussion_r1219926810

From darcy at openjdk.org  Tue Jun  6 17:57:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 17:57:30 GMT
Subject: RFR: JDK-8309554: Update descriptions in SourceVersion
Message-ID: <RIqPOXUzdjRJWhc8rhQn6lo6AyuScFlX9k6bJiVai3g=.644782cf-22dc-440d-9a86-e0ace7d7275e@github.com>

Update SourceVersion to user terminology under consideration for the related ClassFileFormatVersion enum, changing "recognized by" to "introduced by".

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

Commit messages:
 - JDK-8309554: Update descriptions in SourceVersion

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

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

From jlaskey at openjdk.org  Tue Jun  6 17:57:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 6 Jun 2023 17:57:30 GMT
Subject: RFR: JDK-8309554: Update descriptions in SourceVersion
In-Reply-To: <RIqPOXUzdjRJWhc8rhQn6lo6AyuScFlX9k6bJiVai3g=.644782cf-22dc-440d-9a86-e0ace7d7275e@github.com>
References: <RIqPOXUzdjRJWhc8rhQn6lo6AyuScFlX9k6bJiVai3g=.644782cf-22dc-440d-9a86-e0ace7d7275e@github.com>
Message-ID: <xG8hP1xhxSVpBD_saVVD65RzhPkW6ojO-ghvmIvpkfQ=.ce64cc79-8a96-47ae-8115-5f0ba2602661@github.com>

On Tue, 6 Jun 2023 17:46:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update SourceVersion to user terminology under consideration for the related ClassFileFormatVersion enum, changing "recognized by" to "introduced by".

Marked as reviewed by jlaskey (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14340#pullrequestreview-1465766202

From jjg at openjdk.org  Tue Jun  6 18:01:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 6 Jun 2023 18:01:53 GMT
Subject: RFR: JDK-8309554: Update descriptions in SourceVersion
In-Reply-To: <RIqPOXUzdjRJWhc8rhQn6lo6AyuScFlX9k6bJiVai3g=.644782cf-22dc-440d-9a86-e0ace7d7275e@github.com>
References: <RIqPOXUzdjRJWhc8rhQn6lo6AyuScFlX9k6bJiVai3g=.644782cf-22dc-440d-9a86-e0ace7d7275e@github.com>
Message-ID: <7nbVN_98l1kxMs-6SgreE7DxLmCFEUGyQUpG6CoLM7U=.2483f5e7-c787-42a5-8036-f1875801c9cc@github.com>

On Tue, 6 Jun 2023 17:46:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update SourceVersion to user terminology under consideration for the related ClassFileFormatVersion enum, changing "recognized by" to "introduced by".

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14340#pullrequestreview-1465781311

From rriggs at openjdk.org  Tue Jun  6 18:20:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Jun 2023 18:20:12 GMT
Subject: RFR: JDK-8309554: Update descriptions in SourceVersion
In-Reply-To: <RIqPOXUzdjRJWhc8rhQn6lo6AyuScFlX9k6bJiVai3g=.644782cf-22dc-440d-9a86-e0ace7d7275e@github.com>
References: <RIqPOXUzdjRJWhc8rhQn6lo6AyuScFlX9k6bJiVai3g=.644782cf-22dc-440d-9a86-e0ace7d7275e@github.com>
Message-ID: <jGStc7RsL0qW8WxEyROejuhA8VsocBi4TFYo9bzmgFU=.bb76eb68-3af9-47d6-bc2e-93d975c016a1@github.com>

On Tue, 6 Jun 2023 17:46:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update SourceVersion to user terminology under consideration for the related ClassFileFormatVersion enum, changing "recognized by" to "introduced by".

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14340#pullrequestreview-1465805599

From darcy at openjdk.org  Tue Jun  6 18:20:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 18:20:14 GMT
Subject: Integrated: JDK-8309554: Update descriptions in SourceVersion
In-Reply-To: <RIqPOXUzdjRJWhc8rhQn6lo6AyuScFlX9k6bJiVai3g=.644782cf-22dc-440d-9a86-e0ace7d7275e@github.com>
References: <RIqPOXUzdjRJWhc8rhQn6lo6AyuScFlX9k6bJiVai3g=.644782cf-22dc-440d-9a86-e0ace7d7275e@github.com>
Message-ID: <XzSDcegtmzY16B6XW_zLDS7n_FHV99noYOUobEDDAT8=.e1e6ad84-73e8-434f-8c8f-4436dd08bb37@github.com>

On Tue, 6 Jun 2023 17:46:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update SourceVersion to user terminology under consideration for the related ClassFileFormatVersion enum, changing "recognized by" to "introduced by".

This pull request has now been integrated.

Changeset: 7d1147ee
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d1147ee5c0135b966b08ecae9cfa66923998195
Stats:     29 lines in 1 file changed: 4 ins; 0 del; 25 mod

8309554: Update descriptions in SourceVersion

Reviewed-by: jlaskey, jjg, rriggs

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

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

From hannesw at openjdk.org  Tue Jun  6 19:39:47 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 6 Jun 2023 19:39:47 GMT
Subject: RFR: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>" [v2]
In-Reply-To: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
References: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
Message-ID: <O7VU80m_Odfdtn0iGqUTwAxYNgh-fQjTuzPLULhEKh0=.b0ba5a67-2552-4f89-95fe-4fd3515aabd6@github.com>

> Please review a change to downgrade from error to warning if the label of a `<a>` element or reference tag contains an HTML block element. Before HTML 5, elements were clearly divided into block and inline elements, and the latter were not allowed to contain the former. 
> 
> With HTML5, the division between block and inline elements is delegated to CSS, and although elements have default styles, styles can be freely customized by the author. This applies especially true for the `<a>` element which is commonly used both with inline and block layout. That was the rationale for downgrading from error to warning for the `<a>` element only. See the JBS issue comments for details and references.
> 
> The error message for the warning was enhanced to refer to the default style for the `<a>` element.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Rephrase doclint messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13990/files
  - new: https://git.openjdk.org/jdk/pull/13990/files/bb6228bc..b3590063

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

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

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

From hannesw at openjdk.org  Tue Jun  6 19:39:51 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 6 Jun 2023 19:39:51 GMT
Subject: Integrated: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>"
In-Reply-To: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
References: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
Message-ID: <2qh19TGUUCsvkoxDp-inYELK6v5Ue-2f2F0C-P7YjYE=.f3b76287-1db9-4761-a54c-97c6e14329dd@github.com>

On Mon, 15 May 2023 14:43:15 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to downgrade from error to warning if the label of a `<a>` element or reference tag contains an HTML block element. Before HTML 5, elements were clearly divided into block and inline elements, and the latter were not allowed to contain the former. 
> 
> With HTML5, the division between block and inline elements is delegated to CSS, and although elements have default styles, styles can be freely customized by the author. This applies especially true for the `<a>` element which is commonly used both with inline and block layout. That was the rationale for downgrading from error to warning for the `<a>` element only. See the JBS issue comments for details and references.
> 
> The error message for the warning was enhanced to refer to the default style for the `<a>` element.

This pull request has now been integrated.

Changeset: 0a4f9ad6
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a4f9ad637df2f602e47940d039bb12e316fb62a
Stats:     31 lines in 4 files changed: 13 ins; 0 del; 18 mod

8292157: Incorrect error: "block element not allowed within inline element <a>"

Reviewed-by: jjg

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

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

From hannesw at openjdk.org  Tue Jun  6 19:39:49 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 6 Jun 2023 19:39:49 GMT
Subject: RFR: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>" [v2]
In-Reply-To: <rtfUHObjD0Fs7HcZg6osMq9CP0Shzoxz8lmsBuM2oLc=.5ef59120-a329-46fd-85db-f8032b176600@github.com>
References: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
 <agyvNcy18QQHLDyfJTYoVCLSWXr_MRtofuL86Veu384=.204db998-6642-4cd0-9262-7d82465fc06d@github.com>
 <fVmLAbk4mq--sFv_rKWYtEJwRitjGAKpIBJ0g74vx8M=.926ac320-0142-4523-a2f6-19897ab0d9dd@github.com>
 <rtfUHObjD0Fs7HcZg6osMq9CP0Shzoxz8lmsBuM2oLc=.5ef59120-a329-46fd-85db-f8032b176600@github.com>
Message-ID: <RY2buYT-Jg6AvqFSewE2En5uko9iWmJ02r1amBsnsAk=.3ed88c23-361e-463a-8afc-ad62928066bf@github.com>

On Tue, 6 Jun 2023 16:06:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Would the following be better?
>> 
>> 
>> block element <{0}> not allowed within element <{1}> with default style
>> 
>> 
>> I found inconsistent use of angle brackets in several other messages in that file. Attempting to fix that causes a lot of breaking doclint tests, not sure if it is worth doing that as part of this change.
>
> That looks good
> 
> Optionally, we could file a followup RFE to try and make more resources more stylistically consistent

I changed the messages to the new format.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13990#discussion_r1220209960

From darcy at openjdk.org  Tue Jun  6 21:06:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 21:06:14 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445 [v3]
In-Reply-To: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
Message-ID: <VM-kK6EkrZQZqnfKhHp3JuTutcat6lkkvNr78jD2a44=.e83365d3-4ab2-4481-8b07-6115ad2a8c0a@github.com>

> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.

Joe Darcy 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 four additional commits since the last revision:

 - Refine semantics of what is tested.
 - Merge branch 'master' into JDK-8309503
 - Improve test to make sure some checking is done.
 - JDK-8309503: Improve javax.lang.model tests for JEP 445

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14321/files
  - new: https://git.openjdk.org/jdk/pull/14321/files/5fd8a047..7c629490

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

  Stats: 1545 lines in 54 files changed: 1081 ins; 170 del; 294 mod
  Patch: https://git.openjdk.org/jdk/pull/14321.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14321/head:pull/14321

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

From jlaskey at openjdk.org  Tue Jun  6 22:28:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 6 Jun 2023 22:28:24 GMT
Subject: RFR: JDK-8309568 javac crashes attempting to -Xprint on a class file
 of an unnamed class
Message-ID: <_OqrGGWpy_36jwPYEqiYM0YMjxdPtzUmRIU8cYVHqCs=.bf9d8d52-7153-4b45-84b2-c0b9259dfd30@github.com>

Test development for [JDK-8309503](https://bugs.openjdk.org/browse/JDK-8309503) found that javac crashed attempting to -Xprint on a class file of an unnamed class. The test for ClassReader detecting of unnamed class was forcing completion of the owner class. The new code uses a flags only test.

Related test is with https://bugs.openjdk.org/browse/JDK-8309503 .

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

Commit messages:
 - Better check for top level class (non-completing)

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

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

From darcy at openjdk.org  Tue Jun  6 22:52:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 22:52:56 GMT
Subject: RFR: JDK-8309568 javac crashes attempting to -Xprint on a class
 file of an unnamed class
In-Reply-To: <_OqrGGWpy_36jwPYEqiYM0YMjxdPtzUmRIU8cYVHqCs=.bf9d8d52-7153-4b45-84b2-c0b9259dfd30@github.com>
References: <_OqrGGWpy_36jwPYEqiYM0YMjxdPtzUmRIU8cYVHqCs=.bf9d8d52-7153-4b45-84b2-c0b9259dfd30@github.com>
Message-ID: <gZxPrEo9LkEOsuGoIyK1vbv2gXFcK0K88xJb-IFb-b8=.21d83e57-bcce-414c-ac73-5b7825384678@github.com>

On Tue, 6 Jun 2023 22:14:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Test development for [JDK-8309503](https://bugs.openjdk.org/browse/JDK-8309503) found that javac crashed attempting to -Xprint on a class file of an unnamed class. The test for ClassReader detecting of unnamed class was forcing completion of the owner class. The new code uses a flags only test.
> 
> Related test is with https://bugs.openjdk.org/browse/JDK-8309503 .

Approving in the sense of affirming the related test passes; one or more javac engineers should review the change too.

I confirm that the tests now in https://github.com/openjdk/jdk/pull/14321 pass when run with the changes in this PR.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14344#pullrequestreview-1466259160
PR Comment: https://git.openjdk.org/jdk/pull/14344#issuecomment-1579560542

From darcy at openjdk.org  Tue Jun  6 22:53:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 22:53:15 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445 [v4]
In-Reply-To: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
Message-ID: <Gee1ZJULuGvQchIDHgTQhfk0CmkcSxpUrVtSiUIacqc=.e7c26769-20e0-43c3-9f7d-18c67a286f64@github.com>

> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.

Joe Darcy 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 seven additional commits since the last revision:

 - Update test.
 - Merge branch 'master' into JDK-8309503
 - Merge branch 'master' into JDK-8309503
 - Refine semantics of what is tested.
 - Merge branch 'master' into JDK-8309503
 - Improve test to make sure some checking is done.
 - JDK-8309503: Improve javax.lang.model tests for JEP 445

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14321/files
  - new: https://git.openjdk.org/jdk/pull/14321/files/7c629490..e1b5328a

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

  Stats: 3321 lines in 37 files changed: 2847 ins; 267 del; 207 mod
  Patch: https://git.openjdk.org/jdk/pull/14321.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14321/head:pull/14321

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

From darcy at openjdk.org  Wed Jun  7 04:28:12 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Jun 2023 04:28:12 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445 [v5]
In-Reply-To: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
Message-ID: <UFdcQM9MMXv1-2pCbCk0l-ZtYgh1rS84UIjpT-3kofE=.57f1f1ff-3b50-4995-a9f5-6b887cf96df2@github.com>

> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Improve test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14321/files
  - new: https://git.openjdk.org/jdk/pull/14321/files/e1b5328a..248832b5

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

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

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

From darcy at openjdk.org  Wed Jun  7 04:29:55 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Jun 2023 04:29:55 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445 [v4]
In-Reply-To: <Gee1ZJULuGvQchIDHgTQhfk0CmkcSxpUrVtSiUIacqc=.e7c26769-20e0-43c3-9f7d-18c67a286f64@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
 <Gee1ZJULuGvQchIDHgTQhfk0CmkcSxpUrVtSiUIacqc=.e7c26769-20e0-43c3-9f7d-18c67a286f64@github.com>
Message-ID: <D3XCQ4WkYj0uAuCEILh9fEYNedGasTDGP-R_MDD6aDk=.2b731c47-9df6-42c7-8ccc-55de53105fa0@github.com>

On Tue, 6 Jun 2023 22:53:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.
>
> Joe Darcy 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 seven additional commits since the last revision:
> 
>  - Update test.
>  - Merge branch 'master' into JDK-8309503
>  - Merge branch 'master' into JDK-8309503
>  - Refine semantics of what is tested.
>  - Merge branch 'master' into JDK-8309503
>  - Improve test to make sure some checking is done.
>  - JDK-8309503: Improve javax.lang.model tests for JEP 445

Note using the enablePreview jtreg in the test rather than the explicit option to the compile commands didn't work; I didn't try to investigate in detail.

Note I'll revert the changes in ClassReader.java before pushing; they were borrowed from https://github.com/openjdk/jdk/pull/14344 to get the test working with a corrected javac.

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

PR Comment: https://git.openjdk.org/jdk/pull/14321#issuecomment-1579863718

From jlahoda at openjdk.org  Wed Jun  7 10:16:57 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Jun 2023 10:16:57 GMT
Subject: RFR: JDK-8309568 javac crashes attempting to -Xprint on a class
 file of an unnamed class
In-Reply-To: <_OqrGGWpy_36jwPYEqiYM0YMjxdPtzUmRIU8cYVHqCs=.bf9d8d52-7153-4b45-84b2-c0b9259dfd30@github.com>
References: <_OqrGGWpy_36jwPYEqiYM0YMjxdPtzUmRIU8cYVHqCs=.bf9d8d52-7153-4b45-84b2-c0b9259dfd30@github.com>
Message-ID: <ucgsYVHXp9Hs0QfRhvmL7r-Qs-dy6UpaomCj9bnvkIE=.7c23e96a-677e-4b40-a04b-196843468eca@github.com>

On Tue, 6 Jun 2023 22:14:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Test development for [JDK-8309503](https://bugs.openjdk.org/browse/JDK-8309503) found that javac crashed attempting to -Xprint on a class file of an unnamed class. The test for ClassReader detecting of unnamed class was forcing completion of the owner class. The new code uses a flags only test.
> 
> Related test is with https://bugs.openjdk.org/browse/JDK-8309503 .

Looks reasonable.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14344#pullrequestreview-1467246484

From jlaskey at openjdk.org  Wed Jun  7 11:37:03 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 7 Jun 2023 11:37:03 GMT
Subject: Integrated: JDK-8309568 javac crashes attempting to -Xprint on a class
 file of an unnamed class
In-Reply-To: <_OqrGGWpy_36jwPYEqiYM0YMjxdPtzUmRIU8cYVHqCs=.bf9d8d52-7153-4b45-84b2-c0b9259dfd30@github.com>
References: <_OqrGGWpy_36jwPYEqiYM0YMjxdPtzUmRIU8cYVHqCs=.bf9d8d52-7153-4b45-84b2-c0b9259dfd30@github.com>
Message-ID: <jGn2DT-3MnT0K3pd3acopNqMJefDOVLIlfB1i2ZiH3U=.dc872cf9-d25b-4c86-974c-7ed5dfec2669@github.com>

On Tue, 6 Jun 2023 22:14:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Test development for [JDK-8309503](https://bugs.openjdk.org/browse/JDK-8309503) found that javac crashed attempting to -Xprint on a class file of an unnamed class. The test for ClassReader detecting of unnamed class was forcing completion of the owner class. The new code uses a flags only test.
> 
> Related test is with https://bugs.openjdk.org/browse/JDK-8309503 .

This pull request has now been integrated.

Changeset: a6726b66
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6726b66dbb3ffa7b2245bb9c27c4bc87148f39c
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8309568: javac crashes attempting to -Xprint on a class file of an unnamed class

Reviewed-by: darcy, jlahoda

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

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

From jlaskey at openjdk.org  Wed Jun  7 11:49:56 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 7 Jun 2023 11:49:56 GMT
Subject: RFR: JDK-8309594 Cleanup naming in JavacParser related to unnamed
 classes
Message-ID: <8d9TPUbCY6FBo3kM9GAn7Dy6gwa5dleeQeJbprpO-5g=.8c001bae-635d-4bbe-b43b-2223089dfe74@github.com>

Some residual names (anon) from early unnamed classes work.

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

Commit messages:
 - Rename anon to unnamed

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

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

From jlahoda at openjdk.org  Wed Jun  7 11:49:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Jun 2023 11:49:56 GMT
Subject: RFR: JDK-8309594 Cleanup naming in JavacParser related to unnamed
 classes
In-Reply-To: <8d9TPUbCY6FBo3kM9GAn7Dy6gwa5dleeQeJbprpO-5g=.8c001bae-635d-4bbe-b43b-2223089dfe74@github.com>
References: <8d9TPUbCY6FBo3kM9GAn7Dy6gwa5dleeQeJbprpO-5g=.8c001bae-635d-4bbe-b43b-2223089dfe74@github.com>
Message-ID: <7K9Q9KvlS7yRYQqdDRCuQBrG0RYjgbcw2GGnauaaicM=.7ab3560a-6754-4246-b366-78a9f85769d7@github.com>

On Wed, 7 Jun 2023 11:42:11 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Some residual names (anon) from early unnamed classes work.

Looks good.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14351#pullrequestreview-1467435563

From jlaskey at openjdk.org  Wed Jun  7 11:58:03 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 7 Jun 2023 11:58:03 GMT
Subject: Integrated: JDK-8309594 Cleanup naming in JavacParser related to
 unnamed classes
In-Reply-To: <8d9TPUbCY6FBo3kM9GAn7Dy6gwa5dleeQeJbprpO-5g=.8c001bae-635d-4bbe-b43b-2223089dfe74@github.com>
References: <8d9TPUbCY6FBo3kM9GAn7Dy6gwa5dleeQeJbprpO-5g=.8c001bae-635d-4bbe-b43b-2223089dfe74@github.com>
Message-ID: <dQ02oyOeBwI-u874beYxFhnKdWCbBV8NjomtZGdc-B8=.95759945-4a48-4ac4-adcc-7c4409eb43c3@github.com>

On Wed, 7 Jun 2023 11:42:11 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Some residual names (anon) from early unnamed classes work.

This pull request has now been integrated.

Changeset: 16ebf47f
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16ebf47fe3b0fac7b67acfa589a26abf8843306b
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8309594: Cleanup naming in JavacParser related to unnamed classes

Reviewed-by: jlahoda

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

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

From prappo at openjdk.org  Wed Jun  7 14:26:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 14:26:36 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
Message-ID: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>

Please review this long-awaited change to documentation inheritance.

This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:

?{@inheritDoc S}

Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

Commit messages:
 - Disable problematic check
 - Counterbalance changes to method comments algorithm
 - Improve diagnostics
 - Update method comments algorithm
 - Implement directed documentation inheritance

Changes: https://git.openjdk.org/jdk/pull/14357/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285368
  Stats: 1827 lines in 32 files changed: 1693 ins; 29 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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

From jjg at openjdk.org  Wed Jun  7 15:29:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 15:29:55 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <6gQPb_srubW1AqMpi9WmzMRYJDAZXit3-c4xi_T6oVM=.aa70485e-bb3c-4d29-bc0e-868a51051c33@github.com>

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1325:

> 1323:                         //
> 1324:                         //     m.at(pos).newInheritDocTree(ref)
> 1325:                         //

Although the scary warning is not wrong, I think it would have been enough to say something more concise, like "_use the original legacy method if no ref is given_"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1221797159

From prappo at openjdk.org  Wed Jun  7 15:45:01 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 15:45:01 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <6gQPb_srubW1AqMpi9WmzMRYJDAZXit3-c4xi_T6oVM=.aa70485e-bb3c-4d29-bc0e-868a51051c33@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <6gQPb_srubW1AqMpi9WmzMRYJDAZXit3-c4xi_T6oVM=.aa70485e-bb3c-4d29-bc0e-868a51051c33@github.com>
Message-ID: <kMJ-UdMOezmkIu04LMPaFN1E8h0Mzu8jmDJgT7Y55QU=.02c110be-c7fd-4cc4-a71a-305db60003be@github.com>

On Wed, 7 Jun 2023 15:27:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1325:
> 
>> 1323:                         //
>> 1324:                         //     m.at(pos).newInheritDocTree(ref)
>> 1325:                         //
> 
> Although the scary warning is not wrong, I think it would have been enough to say something more concise, like "_use the original legacy method if no ref is given_"

I'll tone it down; thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1221821265

From prappo at openjdk.org  Wed Jun  7 15:51:56 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 15:51:56 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <wosayDaqqnU3b182aUqyDLiG57Iw-hMnXfwIKVaT_uo=.9ad4e309-a3a8-4fe5-849c-1392c39fcaab@github.com>

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

For details on changes to "methods comment algorithm", see the associated CSR: https://bugs.openjdk.org/browse/JDK-8287152

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1581099793

From prappo at openjdk.org  Wed Jun  7 16:02:40 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 16:02:40 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  feedback: make warning less scary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/a56253b3..c0fc69c2

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

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

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

From vromero at openjdk.org  Wed Jun  7 17:33:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 7 Jun 2023 17:33:52 GMT
Subject: RFR: 8309511: Regression test ExtraImportSemicolon.java refers to
 the wrong bug
In-Reply-To: <q0klSK94ZawvuTwY9MyS7q4eFTnpY81zcF66yFFFDBo=.4e4ee534-24ce-421f-a706-22e64c247213@github.com>
References: <q0klSK94ZawvuTwY9MyS7q4eFTnpY81zcF66yFFFDBo=.4e4ee534-24ce-421f-a706-22e64c247213@github.com>
Message-ID: <bv8ZJZUOwNMTA6IJ6vgC9-eqDbaISy6TJKraOxu0aO8=.effa7789-a9cf-4c92-afd0-5e0866dccc4f@github.com>

On Tue, 6 Jun 2023 01:52:34 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this trivial fix for an incorrect `@bug` reference in `ExtraImportSemicolon.java`.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14327#pullrequestreview-1468226696

From vromero at openjdk.org  Wed Jun  7 17:34:03 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 7 Jun 2023 17:34:03 GMT
Subject: RFR: 8309469: Pattern dominance should be adjusted
In-Reply-To: <o8ZiChq14w881qMrqaEczOZqj0xdKeQ_JbDQMb0O-vI=.d6b08fa4-73c1-4691-810a-c64536fd8fb0@github.com>
References: <o8ZiChq14w881qMrqaEczOZqj0xdKeQ_JbDQMb0O-vI=.d6b08fa4-73c1-4691-810a-c64536fd8fb0@github.com>
Message-ID: <FwGpqRzs8UU6a7cHlQ2LhWY2hCos7AmdZLUAFaB_bH0=.ed456894-b026-48d8-b029-a42c85131b3c@github.com>

On Mon, 5 Jun 2023 14:48:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, when a switch contains both patterns and constant labels, any pattern case dominates the constant label. E.g. the following example currently produces a compile-time error:
> 
> switch (...) {
>     case Integer i when i == 0 -> {}
>     case 1 -> {} //dominated by the preceding case
>     case Integer i -> {}
> }
> 
> 
> But, the rules are now (to be) relaxed in the spec, so that guarded cases (with patterns) don't dominate cases with constant labels. I.e. the above example is supposed to compile and run fine.
> 
> This PR is implementing this change - when checking patter-constant dominance, we only consider unguarded cases.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14314#pullrequestreview-1468222991

From prappo at openjdk.org  Wed Jun  7 17:34:22 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 17:34:22 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <Mf4lFV-lds3s3_tH5fBxTU31hdmdtmsQvpzacfwgb7U=.a6cdc2d2-aefc-4765-a992-1e82b8a86e09@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

Full disclosure. Here are all the files that are different before (1) and after (2) the change:

 - https://cr.openjdk.org/~prappo/8285368/1/api
 - https://cr.openjdk.org/~prappo/8285368/2/api

As you can see, the vast majority of differences are in "See Also" sections, which come from `@see` tags. Sadly, `@see` tags are inheritable "by omission". That said, `@see` is also underspecified, somewhat broken, and I believe is not as important as those parts of a doc comment that allow `{@inheritDoc}`.

I suggest that we integrate this PR and take care of `@see` in 22. But if the corrections are really required, I can try to introduce explicit `@see` tags, so there are no changes whatsoever.

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1581226538

From darcy at openjdk.org  Wed Jun  7 17:35:49 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Jun 2023 17:35:49 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445 [v6]
In-Reply-To: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
Message-ID: <1iGDgThYIbj7XXAz6Xbve6w_ieiHfXiOibF6wkBuSbs=.0033f2c1-078c-4e90-85f0-aa0cd6f83afb@github.com>

> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into JDK-8309503
 - Revert changes from other PR.
 - Improve test.
 - Update test.
 - Merge branch 'master' into JDK-8309503
 - Merge branch 'master' into JDK-8309503
 - Refine semantics of what is tested.
 - Merge branch 'master' into JDK-8309503
 - Improve test to make sure some checking is done.
 - JDK-8309503: Improve javax.lang.model tests for JEP 445

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

Changes: https://git.openjdk.org/jdk/pull/14321/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14321&range=05
  Stats: 57 lines in 1 file changed: 34 ins; 8 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/14321.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14321/head:pull/14321

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

From jjg at openjdk.org  Wed Jun  7 17:43:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 17:43:20 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445 [v6]
In-Reply-To: <1iGDgThYIbj7XXAz6Xbve6w_ieiHfXiOibF6wkBuSbs=.0033f2c1-078c-4e90-85f0-aa0cd6f83afb@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
 <1iGDgThYIbj7XXAz6Xbve6w_ieiHfXiOibF6wkBuSbs=.0033f2c1-078c-4e90-85f0-aa0cd6f83afb@github.com>
Message-ID: <CkJeBYHpBtRuCndgqHflvNwgE6iaLxCTML31VkEDeNQ=.693d5ee0-199e-4245-983b-53622011b275@github.com>

On Wed, 7 Jun 2023 17:35:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into JDK-8309503
>  - Revert changes from other PR.
>  - Improve test.
>  - Update test.
>  - Merge branch 'master' into JDK-8309503
>  - Merge branch 'master' into JDK-8309503
>  - Refine semantics of what is tested.
>  - Merge branch 'master' into JDK-8309503
>  - Improve test to make sure some checking is done.
>  - JDK-8309503: Improve javax.lang.model tests for JEP 445

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14321#pullrequestreview-1468251197

From jlaskey at openjdk.org  Wed Jun  7 17:46:20 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 7 Jun 2023 17:46:20 GMT
Subject: RFR: JDK-8309503: Improve javax.lang.model tests for JEP 445 [v6]
In-Reply-To: <1iGDgThYIbj7XXAz6Xbve6w_ieiHfXiOibF6wkBuSbs=.0033f2c1-078c-4e90-85f0-aa0cd6f83afb@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
 <1iGDgThYIbj7XXAz6Xbve6w_ieiHfXiOibF6wkBuSbs=.0033f2c1-078c-4e90-85f0-aa0cd6f83afb@github.com>
Message-ID: <hRZiIuo_O5yEBhpGZQwT6MmgNas4aXkbpsUGlEx5DDo=.b168c0d8-118c-4e7b-b5d6-be54591c5494@github.com>

On Wed, 7 Jun 2023 17:35:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into JDK-8309503
>  - Revert changes from other PR.
>  - Improve test.
>  - Update test.
>  - Merge branch 'master' into JDK-8309503
>  - Merge branch 'master' into JDK-8309503
>  - Refine semantics of what is tested.
>  - Merge branch 'master' into JDK-8309503
>  - Improve test to make sure some checking is done.
>  - JDK-8309503: Improve javax.lang.model tests for JEP 445

LGTM - ran test

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

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14321#pullrequestreview-1468254829

From darcy at openjdk.org  Wed Jun  7 17:59:08 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Jun 2023 17:59:08 GMT
Subject: Integrated: JDK-8309503: Improve javax.lang.model tests for JEP 445
In-Reply-To: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
References: <emDls1kRnD_TMFkf0kg4DhmrduF5QWeTefM5eyXk4-0=.60ce9ece-e087-4c75-97a7-778b07dac6ff@github.com>
Message-ID: <aRhKApgY4CTByHjVkZaYI7heKaTeSMqSNZkz41RV11s=.e948f68d-e1e3-4a41-a7ba-ccd0a4787059@github.com>

On Mon, 5 Jun 2023 21:54:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Improve testing methodology for unnamed classes in javax.lang.model, including coverage of binary names.

This pull request has now been integrated.

Changeset: c24b0bad
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c24b0bada244015b332f13ab5c810a8c9359aceb
Stats:     57 lines in 1 file changed: 34 ins; 8 del; 15 mod

8309503: Improve javax.lang.model tests for JEP 445

Reviewed-by: jlahoda, jjg, jlaskey

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

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

From jjg at openjdk.org  Wed Jun  7 19:00:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:00:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <vbjeNBm9q-RAtXNUM4Ely_r2OsXFUtz5Xe-QRrFiZPw=.551424dd-0bd1-47f6-b379-c56f23d3d46b@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 94:

> 92:             if (supertype == null) {
> 93:                 messages.error(inheritDocPath, "doclet.inheritDocBadSupertype");
> 94:                 return replacement;

`replacement` may be empty.
Consider using `HtmlDocletWriter.invalidTagOutput`.

(Later, we might want to provide a utility message to wrap `messages.error` and `invalidTagOutput`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 110:

> 108:             for (Element e : methods) {
> 109:                 ExecutableElement m = (ExecutableElement) e;
> 110:                 if (configuration.utils.elementUtils.overrides(method, m, (TypeElement) method.getEnclosingElement())) {

Suggestion for eventual future cleanup (not this PR): reduce need for chained fields like`config.utils.elementUtils`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 110:

> 108:             for (Element e : methods) {
> 109:                 ExecutableElement m = (ExecutableElement) e;
> 110:                 if (configuration.utils.elementUtils.overrides(method, m, (TypeElement) method.getEnclosingElement())) {

Note that `configuration.utils` is available as `utils`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 120:

> 118:                 // that this method overrides
> 119:                 messages.error(inheritDocPath, "doclet.inheritDocBadSupertype");
> 120:                 return replacement;

Another case for `invalidTagOutput` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222037366
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222032679
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222035009
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222037884

From jjg at openjdk.org  Wed Jun  7 19:10:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:10:55 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <n-oEDHNS-V_hrhyTbtNAGUJLhOPuN7-8fgks4CrRM9Q=.73a0158d-1614-48b0-bff8-df89f2c46b69@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritableTaglet.java line 53:

> 51:      *
> 52:      * In the future, this could be reworked using some other mechanism,
> 53:      * such as throwing an exception.

Should `ThrowsTaglet.Failure` (eventually?) be declared here in `InheritableTaglet`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222046447

From jjg at openjdk.org  Wed Jun  7 19:16:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:16:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <KagEZPKjNcxwtM3AHa87UQ13b8_XTWmulhVLtbnSnDk=.d297a76a-85f9-481d-8826-397eb9b768c0@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFinder.java line 54:

> 52: 
> 53:     @SuppressWarnings("serial")
> 54:     public static final class NoOverriddenMethodFound extends Exception {

General comment, for future work:
Maybe we can combine/merge/unify this exception with `ThrowsTaglet.Failure`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 671:

> 669: //                .anyMatch(t -> Objects.equals(typeUtils.asElement(t), typeUtils.asElement(t2)));
> 670: 
> 671:         return true; /* disabled for causing issues in JDK API Documentation build */

Please describe the issues and/or provide a JBS issue, so that we can decide when to revert the code to the commented-out form.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222051685
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222053011

From jjg at openjdk.org  Wed Jun  7 19:19:51 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:19:51 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <Eh-7SWOJK8iHaNnmZ_KqhiE5ZKPmNdp5SmYAZC1usOI=.a9adac42-7e06-4d02-b865-73899e52e005@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2847:

> 2845:                     break;
> 2846:                 }
> 2847:                 if (isPlainInterface(peek) && !isPublic(peek) && !isLinkable(peek)) {

What is the significance of the `isPublic` check?
I'm developing a knee-jerk reaction to such checks, in the face of access-related command-line options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222055578

From jjg at openjdk.org  Wed Jun  7 20:41:57 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 20:41:57 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 75:

> 73:         // code is OK, it likely isn't (after all, there's an unknown tag).
> 74:         setAutomaticCheckNoStacktrace(true);
> 75:         { // DocLint is on

"on" -> "explicit"

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 85:

> 83:             }
> 84:         }
> 85:         // DocLint is off

"off" -> "default"

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 289:

> 287: 
> 288:     /*
> 289:      * C1.m inherits documentation from B1.m explicitly and undirect.

possible typo: do you mean "indirect"

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 673:

> 671:      *
> 672:      * For now a warning is issued if a doc comment inherits from
> 673:      * an indirect supertype.

Not sure I agree with this. Can we discuss?

test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 61:

> 59: import toolbox.ToolBox;
> 60: 
> 61: /*

Great description! :-)

test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 111:

> 109:  *    built.
> 110:  */
> 111: public class TestMethodCommentsAlgorithm extends JavadocTester {

General comment for entire class:  great/clever test!

test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 273:

> 271:             }
> 272:         }
> 273:         System.err.println("Test suite root: " + p);

You might want to use `JavadocTester.out` instead of `System.err`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222117577
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222117867
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222119420
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222122630
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222124323
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222130052
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222126057

From prappo at openjdk.org  Wed Jun  7 20:51:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 20:51:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
Message-ID: <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>

On Wed, 7 Jun 2023 20:29:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 673:
> 
>> 671:      *
>> 672:      * For now a warning is issued if a doc comment inherits from
>> 673:      * an indirect supertype.
> 
> Not sure I agree with this. Can we discuss?

Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222141331

From prappo at openjdk.org  Wed Jun  7 20:54:52 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 20:54:52 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <KagEZPKjNcxwtM3AHa87UQ13b8_XTWmulhVLtbnSnDk=.d297a76a-85f9-481d-8826-397eb9b768c0@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <KagEZPKjNcxwtM3AHa87UQ13b8_XTWmulhVLtbnSnDk=.d297a76a-85f9-481d-8826-397eb9b768c0@github.com>
Message-ID: <k8rm3qEl5OMewrQO0KAUt7AJzBff-ERTGxvPk9gFz1s=.78a400ef-5a51-47eb-b303-1a9306bb51cd@github.com>

On Wed, 7 Jun 2023 19:13:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 671:
> 
>> 669: //                .anyMatch(t -> Objects.equals(typeUtils.asElement(t), typeUtils.asElement(t2)));
>> 670: 
>> 671:         return true; /* disabled for causing issues in JDK API Documentation build */
> 
> Please describe the issues and/or provide a JBS issue, so that we can decide when to revert the code to the commented-out form.

I mentioned it in the test, here: TestDirectedInheritance.testNotDirectSupertype. I reckon referring to code from a test is okay, but not the other way around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222148500

From prappo at openjdk.org  Wed Jun  7 21:04:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 21:04:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <Eh-7SWOJK8iHaNnmZ_KqhiE5ZKPmNdp5SmYAZC1usOI=.a9adac42-7e06-4d02-b865-73899e52e005@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <Eh-7SWOJK8iHaNnmZ_KqhiE5ZKPmNdp5SmYAZC1usOI=.a9adac42-7e06-4d02-b865-73899e52e005@github.com>
Message-ID: <jm474v09yfBS07FBRhAsNybvEs-uG3O1FCilzCRAi80=.cdf90791-5449-4bb7-b9a5-5b0e29bcef54@github.com>

On Wed, 7 Jun 2023 19:16:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2847:
> 
>> 2845:                     break;
>> 2846:                 }
>> 2847:                 if (isPlainInterface(peek) && !isPublic(peek) && !isLinkable(peek)) {
> 
> What is the significance of the `isPublic` check?
> I'm developing a knee-jerk reaction to such checks, in the face of access-related command-line options.

That directly mimics the current behaviour at addSuperInterfaces(Utils.java:802), which in turn is used at ImplementedMethods(VisibleMemberTable.java:1064) to collect overridden methods in superinterfaces. If you look around, it's quite an idiom and predates this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222173441

From cushon at openjdk.org  Wed Jun  7 21:24:58 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 7 Jun 2023 21:24:58 GMT
Subject: RFR: 8309499: javac fails to report compiler.err.no.java.lang with
 annotation processing enabled
Message-ID: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>

Hi,

Please consider this fix for an error handling bug in javac, which causes a deferred diagnostic to be lost when an `Abort` is thrown with annotation processing enabled. See https://bugs.openjdk.org/browse/JDK-8309499 for more details.

This fix is contributed by my colleague Paula Toth paulatoth at google.com.

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

Commit messages:
 - Fix trailing whitespace
 - 8309499: Don't swallow diagnostics with annotation processors.

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

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

From jjg at openjdk.org  Wed Jun  7 21:43:50 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 21:43:50 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <fWqllQItWFIRLwYdEjiJEqQWJDJnjc-Pyg7o-4KkS1A=.7385e24a-3930-4132-8920-c531aa1d806c@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

Great work in a difficult area overflowing with Technical Debt.

I've made various (optional) suggestions, I'll approve for now, but will look again if you want to make ore changes.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1468628610

From jjg at openjdk.org  Wed Jun  7 21:43:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 21:43:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
Message-ID: <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>

On Wed, 7 Jun 2023 20:48:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 673:
>> 
>>> 671:      *
>>> 672:      * For now a warning is issued if a doc comment inherits from
>>> 673:      * an indirect supertype.
>> 
>> Not sure I agree with this. Can we discuss?
>
> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011

The general criticism here is whether we should restrict in any way the set of super types from which one can inherit documentation, and/or what should the set of checks be?

For example, if a method in C inherits a method in B that has no comment but which inherits a method with a comment in A, then it seems unduly restrictive to stop the method in C explicitly referencing the method in A, as compared to only allowing a reference to B, which implicitly gets its comment from A.

That being said, there is merit in starting off with restrictions and loosening them in the face of experience, rather than trying to increase the stylistic restrictions later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222202085

From jjg at openjdk.org  Wed Jun  7 21:43:54 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 21:43:54 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
 <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>
Message-ID: <dDWnDozy5_hHsv1tYrdxHdz5K-3K-tJUbMvz2laM-Bc=.4555e482-b333-4e2a-b251-82d02ab38c61@github.com>

On Wed, 7 Jun 2023 21:37:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011
>
> The general criticism here is whether we should restrict in any way the set of super types from which one can inherit documentation, and/or what should the set of checks be?
> 
> For example, if a method in C inherits a method in B that has no comment but which inherits a method with a comment in A, then it seems unduly restrictive to stop the method in C explicitly referencing the method in A, as compared to only allowing a reference to B, which implicitly gets its comment from A.
> 
> That being said, there is merit in starting off with restrictions and loosening them in the face of experience, rather than trying to increase the stylistic restrictions later.

> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: [#14357 (comment)](https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011)

Thanks for tying these together; I had not realized they were related.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222203243

From darcy at openjdk.org  Thu Jun  8 00:37:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Jun 2023 00:37:07 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v6]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>

> Time to get JDK 22 underway...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Update wording to be consistent with JDK-8295071.
 - Merge branch 'master' into JDK-8306584
 - Update wording of new constant to be consistent with JDK-8309554.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - ... and 29 more: https://git.openjdk.org/jdk/compare/4ffc8cc2...a03bcd40

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

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=05
  Stats: 5954 lines in 69 files changed: 5902 ins; 0 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

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

From prappo at openjdk.org  Thu Jun  8 08:18:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 08:18:11 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v3]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <dMVI5gkY6g1Rua907np654TLzSOFYYSVuFUmj3OxI_Y=.eeb25216-e583-40f0-9f7f-5a2d095039ce@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo 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 seven additional commits since the last revision:

 - Merge branch 'master' into 8285368
 - feedback: make warning less scary
 - Disable problematic check
   
   This check is well-intended but problematic for JDK API Documentation
   build, which errors on warnings.
 - Counterbalance changes to method comments algorithm
   
   The changes are in the JDK API Documentation.
 - Improve diagnostics
 - Update method comments algorithm
 - Implement directed documentation inheritance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/c0fc69c2..011d7982

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

  Stats: 17117 lines in 199 files changed: 16677 ins; 145 del; 295 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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

From prappo at openjdk.org  Thu Jun  8 08:43:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 08:43:13 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v4]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <YCoswj2IrhNiZsAIFLp0fYU3rZiMj7nlywtP_JanSRw=.274888fc-181c-42a6-886e-416bc89d505d@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  feedback: use utils directly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/011d7982..d579a83c

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

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

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

From prappo at openjdk.org  Thu Jun  8 08:43:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 08:43:13 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <vbjeNBm9q-RAtXNUM4Ely_r2OsXFUtz5Xe-QRrFiZPw=.551424dd-0bd1-47f6-b379-c56f23d3d46b@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <vbjeNBm9q-RAtXNUM4Ely_r2OsXFUtz5Xe-QRrFiZPw=.551424dd-0bd1-47f6-b379-c56f23d3d46b@github.com>
Message-ID: <0nAoH6Na1dRqIGEGYd2-DpPBZb7AfdjApu40jdUkmzM=.37205779-ae2f-4577-86a8-8e8d592e7576@github.com>

On Wed, 7 Jun 2023 18:55:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 110:
> 
>> 108:             for (Element e : methods) {
>> 109:                 ExecutableElement m = (ExecutableElement) e;
>> 110:                 if (configuration.utils.elementUtils.overrides(method, m, (TypeElement) method.getEnclosingElement())) {
> 
> Note that `configuration.utils` is available as `utils`

Done in d579a83cc4a.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222652470

From prappo at openjdk.org  Thu Jun  8 09:26:16 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:26:16 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v5]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <bzy-mOnpcNQGfDeJiKXWPWNdQUbwA5Gr9UEA1wBbQvc=.c733051a-cd1e-482b-b248-e06610c2f7da@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  feedback: DocLint terminology

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/d579a83c..93adde63

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

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

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

From prappo at openjdk.org  Thu Jun  8 09:26:17 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:26:17 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
Message-ID: <Qhqev-aIAx8R4MLjC447r5JJ4l1N6rxJG_loDZL5Hso=.b9b27c67-6adb-4046-812e-1813e2f0cedb@github.com>

On Wed, 7 Jun 2023 20:23:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 75:
> 
>> 73:         // code is OK, it likely isn't (after all, there's an unknown tag).
>> 74:         setAutomaticCheckNoStacktrace(true);
>> 75:         { // DocLint is on
> 
> "on" -> "explicit"

Done in 93adde63ed0.

> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 85:
> 
>> 83:             }
>> 84:         }
>> 85:         // DocLint is off
> 
> "off" -> "default"

Done in 93adde63ed0.

> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 289:
> 
>> 287: 
>> 288:     /*
>> 289:      * C1.m inherits documentation from B1.m explicitly and undirect.
> 
> possible typo: do you mean "indirect"

I'm neither a grammarian nor a native English speaker, but my hunch is that _indirect_ would be wrong here. But again, I'm open to corrections.

I believe "directed inhertiance" came from an analogy with the graph theory, where a graph can be directed and undirected. The former has pointy arrows, the latter does not.

By that analogy, documentation inheritance can be directed `{@inheritDoc <FQN>}` (I choose), or undirected `{@inheritDoc}` (JavaDoc chooses / I'm Feeling Lucky). In addition to that, documentation inheritance can be implicit (i.e. by omission), which works the same way as undirected but without extra keystrokes.

While those concepts are lacking better names, can I suggest we use the following almost-made-up adverbs: _directedly_ and _undirectedly_? As a side note, we badly need a JavaDoc vocabulary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222703693
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222703773
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222700845

From alanb at openjdk.org  Thu Jun  8 09:27:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 09:27:54 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v6]
In-Reply-To: <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
Message-ID: <XMUO9juJRbeMiMQXX-5eAGeLVs2T8FbD8cmt0l4YMR8=.71b77e07-cd8a-4ba8-9a62-5c09de82ed76@github.com>

On Thu, 8 Jun 2023 00:37:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Update wording to be consistent with JDK-8295071.
>  - Merge branch 'master' into JDK-8306584
>  - Update wording of new constant to be consistent with JDK-8309554.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/4ffc8cc2...a03bcd40

Ready to go :-)

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

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1469406598

From prappo at openjdk.org  Thu Jun  8 09:31:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:31:08 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v6]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <eBdzCAsFsRLgFpL57dGSEb6JSNCFN97DG66FfGhcIc0=.a1c66346-3faf-4e61-99cb-ea346c546dcd@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  suggestion: vocabulary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/93adde63..3da4f473

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

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

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

From prappo at openjdk.org  Thu Jun  8 09:31:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:31:11 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <Qhqev-aIAx8R4MLjC447r5JJ4l1N6rxJG_loDZL5Hso=.b9b27c67-6adb-4046-812e-1813e2f0cedb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <Qhqev-aIAx8R4MLjC447r5JJ4l1N6rxJG_loDZL5Hso=.b9b27c67-6adb-4046-812e-1813e2f0cedb@github.com>
Message-ID: <dW06V3UKubxH8ow0uco0U7JqH-03Yos7o2nVtR17biY=.558d5dca-e1cf-4a06-8f0c-5be1ba6b89cf@github.com>

On Thu, 8 Jun 2023 09:18:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 289:
>> 
>>> 287: 
>>> 288:     /*
>>> 289:      * C1.m inherits documentation from B1.m explicitly and undirect.
>> 
>> possible typo: do you mean "indirect"
>
> I'm neither a grammarian nor a native English speaker, but my hunch is that _indirect_ would be wrong here. But again, I'm open to corrections.
> 
> I believe "directed inhertiance" came from an analogy with the graph theory, where a graph can be directed and undirected. The former has pointy arrows, the latter does not.
> 
> By that analogy, documentation inheritance can be directed `{@inheritDoc <FQN>}` (I choose), or undirected `{@inheritDoc}` (JavaDoc chooses / I'm Feeling Lucky). In addition to that, documentation inheritance can be implicit (i.e. by omission), which works the same way as undirected but without extra keystrokes.
> 
> While those concepts are lacking better names, can I suggest we use the following almost-made-up adverbs: _directedly_ and _undirectedly_? As a side note, we badly need a JavaDoc vocabulary.

Have a look at this commit: 3da4f473a7c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222709203

From dfuchs at openjdk.org  Thu Jun  8 09:36:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Jun 2023 09:36:50 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v5]
In-Reply-To: <bzy-mOnpcNQGfDeJiKXWPWNdQUbwA5Gr9UEA1wBbQvc=.c733051a-cd1e-482b-b248-e06610c2f7da@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <bzy-mOnpcNQGfDeJiKXWPWNdQUbwA5Gr9UEA1wBbQvc=.c733051a-cd1e-482b-b248-e06610c2f7da@github.com>
Message-ID: <PLCf0TKvR88eBAkckrd1Er8kTIju2SRe3KrpF937NRY=.aa620b43-011b-4c94-baf5-31d72fe881e3@github.com>

On Thu, 8 Jun 2023 09:26:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: DocLint terminology

I will only comment on the changes to the `java.base` classes.

I had a look at the changes to these and they looked right to me. Though I?m not an expert on collections it seemed that you picked the right ?semantically closer parent? to inherit from.
Probably @stuart-marks  could give a more authoritative opinion.

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

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1469424115

From prappo at openjdk.org  Thu Jun  8 09:55:27 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:55:27 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  feedback: remove unduly restrictive warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/3da4f473..dea776e2

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

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

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

From prappo at openjdk.org  Thu Jun  8 09:55:27 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:55:27 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <dDWnDozy5_hHsv1tYrdxHdz5K-3K-tJUbMvz2laM-Bc=.4555e482-b333-4e2a-b251-82d02ab38c61@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
 <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>
 <dDWnDozy5_hHsv1tYrdxHdz5K-3K-tJUbMvz2laM-Bc=.4555e482-b333-4e2a-b251-82d02ab38c61@github.com>
Message-ID: <5_hHiDRF_JOTG6DcmG_2ONSv9ZMcLJyYafTs5q7VNj4=.5149617c-4015-4f9b-b518-7d316a1e92eb@github.com>

On Wed, 7 Jun 2023 21:39:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> The general criticism here is whether we should restrict in any way the set of super types from which one can inherit documentation, and/or what should the set of checks be?
>> 
>> For example, if a method in C inherits a method in B that has no comment but which inherits a method with a comment in A, then it seems unduly restrictive to stop the method in C explicitly referencing the method in A, as compared to only allowing a reference to B, which implicitly gets its comment from A.
>> 
>> That being said, there is merit in starting off with restrictions and loosening them in the face of experience, rather than trying to increase the stylistic restrictions later.
>
>> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: [#14357 (comment)](https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011)
> 
> Thanks for tying these together; I had not realized they were related.

As agreed out of band, I removed that check and the test for now in dea776e285b.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222737390

From alanb at openjdk.org  Thu Jun  8 10:36:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 10:36:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

src/java.base/share/classes/java/util/TreeMap.java line 1199:

> 1197:      * {@code add} or {@code addAll} operations.
> 1198:      *
> 1199:      * @return {@inheritDoc SortedMap}

An alternative here might be  add `{@return ...}` to the first sentence of the method description so that the return description exactly matches.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222847956

From alanb at openjdk.org  Thu Jun  8 10:50:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 10:50:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <r_kzWNFCCjU2vL3e8WUtgR9dRPSLzg2HWRArVA8fTIk=.f2a36710-a531-4714-8ac6-e825b97ee1c3@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 635:

> 633:      * @return {@inheritDoc BlockingDeque}
> 634:      */
> 635:     public boolean offer(E e) {

Does this work for @param tags too? Just curious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222860792

From prappo at openjdk.org  Thu Jun  8 11:34:52 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 11:34:52 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
Message-ID: <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>

On Thu, 8 Jun 2023 10:33:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: remove unduly restrictive warning
>
> src/java.base/share/classes/java/util/TreeMap.java line 1199:
> 
>> 1197:      * {@code add} or {@code addAll} operations.
>> 1198:      *
>> 1199:      * @return {@inheritDoc SortedMap}
> 
> An alternative here might be  add `{@return ...}` to the first sentence of the method description so that the return description exactly matches.

If we were to (re-)structure doc comments in the way you propose, I'd suggest we do it in a separate, non-jdk.javadoc  PR. I was simply trying to keep JDK API documentation unchanged.

One thing with the `@return` documentation inherited from SortedMap is that compared to the first sentence of TreeMap, it provides one extra bit of information: a set view of the mappings contained in this map, **sorted in ascending key order**. In order to keep that bit, the suggested inline `{@return ...}` should include more than just the first sentence.

> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 635:
> 
>> 633:      * @return {@inheritDoc BlockingDeque}
>> 634:      */
>> 635:     public boolean offer(E e) {
> 
> Does this work for @param tags too? Just curious.

The directed `{@inheritDoc <FQN>}` works for the main description, `@throws`, `@param` and `@return` tags. If your question is about why that particular doc comment does not use this:

    @param e {@inheritDoc BlockingDeque}

then the answer is that it's not necessary for keeping the API documentation unchanged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222908801
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222910706

From prappo at openjdk.org  Thu Jun  8 11:41:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 11:41:51 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <zmbCcrz9xOw4-kohog4kdkGWwUqpjjRoDxgG7QvADo4=.8b3ecb99-46a5-40a2-b27d-83983bdf4f4d@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

@Martin-Buchholz, could you please have a look at changes to collections and, in particular, those in java.util.concurrent.*?

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1582426421

From prappo at openjdk.org  Thu Jun  8 12:17:57 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 12:17:57 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <ZNWvGneK5nZuriiAOR-2z51cMWFWZATiyFpoSX9EnZc=.62c29530-bfb4-4b34-80c1-16ac1747b5b6@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

Note that the change to "method comments algorithm" uncovers and fixes some bugs to Object- or Object-like- methods. 

Using the provided [before][] and [after][] outputs, compare documentation for:

 * toString() in java.time.chrono.{Hijrah,Japanese,Minguo,ThaiBuddhist}Date
 * hashCode() in Hashtable, ConcurrentHashMap.KeySetView, java.util.jar.Attributes, com.sun.net.httpserver.Headers, com.sun.management.GcInfo
 * equals() in ConcurrentHashMap.KeySetView, com.sun.net.httpserver.Headers, com.sun.management.GcInfo
 * clone() in javax.management.ImmutableDescriptor, javax.management.modelmbean.DescriptorSupport, javax.naming.directory.BasicAttribute, javax.naming.directory.BasicAttributes
 
Perhaps some of those could be further refined using directed documentation inheritance. For example, ConcurrentHashMap.KeySetView is first and foremost a set and only then a collection. That suggests that the documentation for Object-like methods could be inherited from (some) set rather than a "generic" collection.

Also, the javax.management.ImmutableDescriptor and javax.management.modelmbean.DescriptorSupport clone methods require some attention from area experts. It's likely that those methods' doc comments need to fully inherit documentation from Descriptor.clone(), not just its `@return` tag.

[before]: https://cr.openjdk.org/~prappo/8285368/1/api
[after]: https://cr.openjdk.org/~prappo/8285368/2/api

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1582477351

From alanb at openjdk.org  Thu Jun  8 12:28:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 12:28:55 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v6]
In-Reply-To: <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
Message-ID: <aoEfQ88fCCEDBQ--yCtg_LL4ow5bf8zwa-zKAbSecpQ=.c52378ad-9ef2-41d0-9032-924b4de868af@github.com>

On Thu, 8 Jun 2023 00:37:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Update wording to be consistent with JDK-8295071.
>  - Merge branch 'master' into JDK-8306584
>  - Update wording of new constant to be consistent with JDK-8309554.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/4ffc8cc2...a03bcd40

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1469794796

From jwaters at openjdk.org  Thu Jun  8 13:04:49 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 Jun 2023 13:04:49 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <juZqL9f-rWyjmnndcuL8Ryb1IgOc3kgauhFU9ri2JiQ=.e83bf2f5-b34a-4c1f-ae3c-ac596ae379df@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Anyone? I also need help in removing the CSR unfortunately

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1582541421

From alanb at openjdk.org  Thu Jun  8 13:37:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 13:37:51 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
Message-ID: <wxje5E9he5rhzViprJqwj4Q6fC8Kwd9am_ZxVfje9dU=.96fc348e-d257-4fc1-840b-4961c1e83720@github.com>

On Thu, 8 Jun 2023 11:27:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> If we were to (re-)structure doc comments in the way you propose, I'd suggest we do it in a separate, non-jdk.javadoc PR. I was simply trying to keep JDK API documentation unchanged.

Understood, it was just a passing comment that TreeMap::entrySet overrides the description so it's specifying what it returns and using inherited text for the @return description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223053378

From vromero at openjdk.org  Thu Jun  8 14:01:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 Jun 2023 14:01:51 GMT
Subject: RFR: 8309499: javac fails to report compiler.err.no.java.lang with
 annotation processing enabled
In-Reply-To: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
References: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
Message-ID: <gvwQUkmo36MUzuv4fzBVbBJbF89LPV0xmVcQrT0tnoo=.c9b0da3d-a157-4187-918c-d768a1154191@github.com>

On Wed, 7 Jun 2023 21:03:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi,
> 
> Please consider this fix for an error handling bug in javac, which causes a deferred diagnostic to be lost when an `Abort` is thrown with annotation processing enabled. See https://bugs.openjdk.org/browse/JDK-8309499 for more details.
> 
> This fix is contributed by my colleague Paula Toth paulatoth at google.com.

Marked as reviewed by vromero (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 982:

> 980:             // In case an Abort was thrown before processAnnotations could be called,
> 981:             // we could have deferred diagnostics that haven't been reported. At the
> 982:             // time of this comment's writing, this can only ever occur through a

looks good. Suggestion: I would remove the last sentence: `At the time of this comment...` documents an erroneous situation. We usually don't add that type of comments.

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

PR Review: https://git.openjdk.org/jdk/pull/14370#pullrequestreview-1469981671
PR Review Comment: https://git.openjdk.org/jdk/pull/14370#discussion_r1223083598

From iris at openjdk.org  Thu Jun  8 14:41:53 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 8 Jun 2023 14:41:53 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v6]
In-Reply-To: <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
Message-ID: <zy4pghHpgCqMi8Ltg8yGUvKeDBbpMubFemqlB8hO9UQ=.cf82ba01-ff19-4c2e-8dd8-9bd346a67c99@github.com>

On Thu, 8 Jun 2023 00:37:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Update wording to be consistent with JDK-8295071.
>  - Merge branch 'master' into JDK-8306584
>  - Update wording of new constant to be consistent with JDK-8309554.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/4ffc8cc2...a03bcd40

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1470093232

From prappo at openjdk.org  Thu Jun  8 14:47:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 14:47:13 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v8]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <s_V36_pNoxTdLaYD8EZR38Iso9Wdjm1TTh_R5-sgNJo=.a01574f0-d031-4856-9af2-7423cc45cb9d@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  feedback: use JavadocTester.out
  
  Also, trivially fixes grammar (word order) in a comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/dea776e2..cccffa66

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

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

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

From prappo at openjdk.org  Thu Jun  8 14:47:16 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 14:47:16 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
Message-ID: <82i8za9caZsJgAkr0hX9cR-ItoN94SJdcsHW0EfTswc=.8477eb23-93a7-4ac5-a558-384f9d956371@github.com>

On Wed, 7 Jun 2023 20:33:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 273:
> 
>> 271:             }
>> 272:         }
>> 273:         System.err.println("Test suite root: " + p);
> 
> You might want to use `JavadocTester.out` instead of `System.err`

Fixed in cccffa660a8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223144388

From aivanov at openjdk.org  Thu Jun  8 15:18:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 15:18:54 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
Message-ID: <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>

On Thu, 8 Jun 2023 11:29:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 635:
>> 
>>> 633:      * @return {@inheritDoc BlockingDeque}
>>> 634:      */
>>> 635:     public boolean offer(E e) {
>> 
>> Does this work for @param tags too? Just curious.
>
> The directed `{@inheritDoc <FQN>}` works for the main description, `@throws`, `@param` and `@return` tags. If your question is about why that particular doc comment does not use this:
> 
>     @param e {@inheritDoc BlockingDeque}
> 
> then the answer is that it's not necessary for keeping the API documentation unchanged.

I admit I can't parse this sentence:

> then the answer is that it's not necessary for keeping the API documentation unchanged.

Do you mean that you didn't add `@param e {@inheritDoc BlockingDeque}` here to keep the documentation unchanged?

You added `@inheritDoc` for `@param` tags in [FileCacheImageOutputStream.java](https://github.com/openjdk/jdk/pull/14357/files#diff-bc1e47b4c5c405826e7a062cabea04349ef72d5823b67e8616a680dcfcb5d4be) and others but not here.

So, do we need to add `@param` tags if the entire javadoc is inherited with `@inheritDoc`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223197961

From prappo at openjdk.org  Thu Jun  8 15:49:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 15:49:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
 <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
Message-ID: <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>

On Thu, 8 Jun 2023 15:16:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The directed `{@inheritDoc <FQN>}` works for the main description, `@throws`, `@param` and `@return` tags. If your question is about why that particular doc comment does not use this:
>> 
>>     @param e {@inheritDoc BlockingDeque}
>> 
>> then the answer is that it's not necessary for keeping the API documentation unchanged.
>
> I admit I can't parse this sentence:
> 
>> then the answer is that it's not necessary for keeping the API documentation unchanged.
> 
> Do you mean that you didn't add `@param e {@inheritDoc BlockingDeque}` here to keep the documentation unchanged?
> 
> You added `@inheritDoc` for `@param` tags in [FileCacheImageOutputStream.java](https://github.com/openjdk/jdk/pull/14357/files#diff-bc1e47b4c5c405826e7a062cabea04349ef72d5823b67e8616a680dcfcb5d4be) and others but not here.
> 
> So, do we need to add `@param` tags if the entire javadoc is inherited with `@inheritDoc`?

Copying an individual doc element using `{@inheritDoc}` never adds meta information on the generated HTML page to indicate where that doc element was copied from. It so happens in this particular case that the doc element's contents are the same in both possible supertypes (BlockingDeque and Queue) and look like this:

    @param e the element to add

If the end result _on the HTML page_ will look identical no mater if I add `@param e {@inheritDoc BlockingDeque}` or not, I will not add it in _this_ PR. This PR's goal is not restructuring the doc comment; in fact, such restructuring would be an anti-goal. It might be a goal for subsequent, area-specific PRs.

Above I said that "`{@inheritDoc}` never adds meta information on the generated HTML page". You might have immediately thought about cases where you saw the "Description copied from interface/class" headings. However, those do not come from `{@inheritDoc}`; those come from empty comments (which inherit their content by omission, if you wish). So those headings DO indicate the source of the complete doc comment.

Now about FileCacheImageOutputStream.java. If I hand't added directed inheritance there, the updated algorithm would've picked a different comment, which wouldn't have been identical to what was picked before:

 - javax.imageio.stream.ImageInputStream#flushBefore
    ```
     * @param pos a {@code long} containing the length of the
     * stream prefix that may be flushed.
    ```

 - javax.imageio.stream.ImageOutputStream#flushBefore:
    ```
     * @param pos a {@code long} containing the length of the
     * stream prefix that may be flushed to the destination.
    ```
Hence, the correction. Does it clarify the matter?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223236596

From prappo at openjdk.org  Thu Jun  8 15:53:58 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 15:53:58 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
 <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
 <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>
Message-ID: <iVcMmg2r9UXBrsTQBU7X2Y1GDvrCeTg-1l1Vc-uZOhQ=.6f272612-b970-41b0-b36d-b03204291b59@github.com>

On Thu, 8 Jun 2023 15:47:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I admit I can't parse this sentence:
>> 
>>> then the answer is that it's not necessary for keeping the API documentation unchanged.
>> 
>> Do you mean that you didn't add `@param e {@inheritDoc BlockingDeque}` here to keep the documentation unchanged?
>> 
>> You added `@inheritDoc` for `@param` tags in [FileCacheImageOutputStream.java](https://github.com/openjdk/jdk/pull/14357/files#diff-bc1e47b4c5c405826e7a062cabea04349ef72d5823b67e8616a680dcfcb5d4be) and others but not here.
>> 
>> So, do we need to add `@param` tags if the entire javadoc is inherited with `@inheritDoc`?
>
> Copying an individual doc element using `{@inheritDoc}` never adds meta information on the generated HTML page to indicate where that doc element was copied from. It so happens in this particular case that the doc element's contents are the same in both possible supertypes (BlockingDeque and Queue) and look like this:
> 
>     @param e the element to add
> 
> If the end result _on the HTML page_ will look identical no mater if I add `@param e {@inheritDoc BlockingDeque}` or not, I will not add it in _this_ PR. This PR's goal is not restructuring the doc comment; in fact, such restructuring would be an anti-goal. It might be a goal for subsequent, area-specific PRs.
> 
> Above I said that "`{@inheritDoc}` never adds meta information on the generated HTML page". You might have immediately thought about cases where you saw the "Description copied from interface/class" headings. However, those do not come from `{@inheritDoc}`; those come from empty comments (which inherit their content by omission, if you wish). So those headings DO indicate the source of the complete doc comment.
> 
> Now about FileCacheImageOutputStream.java. If I hand't added directed inheritance there, the updated algorithm would've picked a different comment, which wouldn't have been identical to what was picked before:
> 
>  - javax.imageio.stream.ImageInputStream#flushBefore
>     ```
>      * @param pos a {@code long} containing the length of the
>      * stream prefix that may be flushed.
>     ```
> 
>  - javax.imageio.stream.ImageOutputStream#flushBefore:
>     ```
>      * @param pos a {@code long} containing the length of the
>      * stream prefix that may be flushed to the destination.
>     ```
> Hence, the correction. Does it clarify the matter?

Also, for better or worse, a lone `{@inheritDoc}` never inherits "everything" from a supertype:

/** {@inheritDoc} */

It merely inherits the main description of a method. Other elements such as parameter, exception or return information are inherited individually.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223241132

From darcy at openjdk.org  Thu Jun  8 16:04:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Jun 2023 16:04:58 GMT
Subject: Integrated: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <E8OuMbiyCEH97OOx2HtX8BtCwKUzQ9J5-E22tezqZqk=.0a4cf8e5-7d9a-4703-8607-48a1845c06d0@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

This pull request has now been integrated.

Changeset: 5a706fb4
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a706fb403df0768ecef5b0ce14a3ca389a51efd
Stats:     5954 lines in 69 files changed: 5902 ins; 0 del; 52 mod

8306584: Start of release updates for JDK 22
8306585: Add SourceVersion.RELEASE_22
8306586: Add source 22 and target 22 to javac

Reviewed-by: erikj, iris, dholmes, jlahoda, alanb

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

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

From darcy at openjdk.org  Fri Jun  9 04:55:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 Jun 2023 04:55:13 GMT
Subject: RFR: JDK-8309142: Refactor
 test/langtools/tools/javac/versions/Versions.java
Message-ID: <Uqtx5OaVrs0FGiotsSXBkr_qT_OeJ6w93_M3y9dIJTs=.2b9a3bc6-9e13-41da-be3a-f652ca6eea92@github.com>

Test refactoring to reduce future maintenance: when source version gets a new language feature, a single enum constant with an example gets added to test all source versions against that sample.

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

Commit messages:
 - JDK-8309142: Refactor test/langtools/tools/javac/versions/Versions.java

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

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

From ethan at mccue.dev  Fri Jun  9 16:58:43 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 9 Jun 2023 12:58:43 -0400
Subject: Static methods of generic classes are treated differently
In-Reply-To: <CA+NR86jb7mGJsjbjZ8Y4VEmdNCNjgQtbcfMZCnvUuiMe5YE8ig@mail.gmail.com>
References: <CA+NR86jb7mGJsjbjZ8Y4VEmdNCNjgQtbcfMZCnvUuiMe5YE8ig@mail.gmail.com>
Message-ID: <CA+NR86hi-kqDL2sBRjrGcsqWOkNDjiEZpdFEknqntOKajrAKqQ@mail.gmail.com>

Following up on this just to see if there is an explanation of some sort I
am missing.

On Sun, Apr 30, 2023 at 8:40?AM Ethan McCue <ethan at mccue.dev> wrote:

> I've run into either a corner case in type resolution or a compiler bug
> and I'm not sure which.
>
> In an expression context, if a static method is referenced from a generic
> class then it won't properly target overloads that require primitive
> wrapper unboxing.
>
> package org.example;
>
> import java.time.Month;
> import java.util.function.Supplier;
>
>
> interface A {
>     static int f() {
>         return 1;
>     }
> }
>
> interface B<T> {
>     static int f() {
>         return 2;
>     }
> }
>
> final class C {
>     static int f() {
>         return 3;
>     }
> }
>
> final class D<T> {
>     static int f() {
>         return 4;
>     }
> }
>
>
> public class Main {
>     static void h(Month b) {}
>     static void h(int b) {}
>
>     static <T> T g(Supplier<? extends T> d) {
>         return d.get();
>     }
>
>
>     public static void main(String[] args) {
>         // Compiles
>         h(
>                 g(A::f)
>         );
>
>         // Doesn't compile
>         h(
>                 g(B::f)
>         );
>
>         // Compiles
>         var r1 = g(B::f);
>         h(r1);
>
>         // Compiles
>         h(
>                 g(C::f)
>         );
>
>         // Doesn't compile
>         h(
>                 g(D::f)
>         );
>
>         // Compiles
>         var r2 = g(D::f);
>         h(r2);
>     }
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230609/e5c1a42a/attachment.htm>

From darcy at openjdk.org  Fri Jun  9 18:12:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 Jun 2023 18:12:51 GMT
Subject: RFR: JDK-8309310: Update --release 21 symbol information for JDK 21
 build 26
Message-ID: <C4zApHUI_XZfW5FR_rD4JjTAxQ09rx8qQKX1I4xw9Mg=.253d8474-6dcd-4cd3-ad72-c6395833b3a6@github.com>

Usual symbol file update.

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

Commit messages:
 - JDK-8309310: Update --release 21 symbol information for JDK 21 build 26

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

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

From iris at openjdk.org  Fri Jun  9 18:12:51 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 9 Jun 2023 18:12:51 GMT
Subject: RFR: JDK-8309310: Update --release 21 symbol information for JDK
 21 build 26
In-Reply-To: <C4zApHUI_XZfW5FR_rD4JjTAxQ09rx8qQKX1I4xw9Mg=.253d8474-6dcd-4cd3-ad72-c6395833b3a6@github.com>
References: <C4zApHUI_XZfW5FR_rD4JjTAxQ09rx8qQKX1I4xw9Mg=.253d8474-6dcd-4cd3-ad72-c6395833b3a6@github.com>
Message-ID: <s79B6SlfEz66EomgCmhMI3syQsuFdM7spQvHd9L7rUY=.b9ac709f-37a4-4710-b906-82204dfb52e0@github.com>

On Fri, 9 Jun 2023 17:58:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual symbol file update.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14401#pullrequestreview-1472827540

From darcy at openjdk.org  Fri Jun  9 18:56:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 Jun 2023 18:56:46 GMT
Subject: Integrated: JDK-8309310: Update --release 21 symbol information for
 JDK 21 build 26
In-Reply-To: <C4zApHUI_XZfW5FR_rD4JjTAxQ09rx8qQKX1I4xw9Mg=.253d8474-6dcd-4cd3-ad72-c6395833b3a6@github.com>
References: <C4zApHUI_XZfW5FR_rD4JjTAxQ09rx8qQKX1I4xw9Mg=.253d8474-6dcd-4cd3-ad72-c6395833b3a6@github.com>
Message-ID: <XYbeAvC-3SQDWyPWTFnU601Hn4yzB-vDXpg1SzEpP4c=.1733424e-fb70-4360-aa6c-42cfeac5bb0e@github.com>

On Fri, 9 Jun 2023 17:58:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual symbol file update.

This pull request has now been integrated.

Changeset: 7a970b25
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a970b251d25edb7969d4f5a72f4dcb0a5c30ba5
Stats:     128 lines in 3 files changed: 125 ins; 1 del; 2 mod

8309310: Update --release 21 symbol information for JDK 21 build 26

Reviewed-by: iris

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

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

From jjg at openjdk.org  Fri Jun  9 19:45:42 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Jun 2023 19:45:42 GMT
Subject: RFR: JDK-8309142: Refactor
 test/langtools/tools/javac/versions/Versions.java
In-Reply-To: <Uqtx5OaVrs0FGiotsSXBkr_qT_OeJ6w93_M3y9dIJTs=.2b9a3bc6-9e13-41da-be3a-f652ca6eea92@github.com>
References: <Uqtx5OaVrs0FGiotsSXBkr_qT_OeJ6w93_M3y9dIJTs=.2b9a3bc6-9e13-41da-be3a-f652ca6eea92@github.com>
Message-ID: <XzJbz4W53IASw2yBomhFi7TqfDFZe15ExVNxpYsPORI=.90030219-12c1-40b0-a34e-3a0b90ad5e4d@github.com>

On Fri, 9 Jun 2023 04:47:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Test refactoring to reduce future maintenance: when source version gets a new language feature, a single enum constant with an example gets added to test all source versions against that sample.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14387#pullrequestreview-1472969935

From darcy at openjdk.org  Fri Jun  9 19:58:55 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 Jun 2023 19:58:55 GMT
Subject: Integrated: JDK-8309142: Refactor
 test/langtools/tools/javac/versions/Versions.java
In-Reply-To: <Uqtx5OaVrs0FGiotsSXBkr_qT_OeJ6w93_M3y9dIJTs=.2b9a3bc6-9e13-41da-be3a-f652ca6eea92@github.com>
References: <Uqtx5OaVrs0FGiotsSXBkr_qT_OeJ6w93_M3y9dIJTs=.2b9a3bc6-9e13-41da-be3a-f652ca6eea92@github.com>
Message-ID: <DgD05-eL2OkkWljpimTjdazr_ZxWp516tpfxtPka0FM=.29113ff9-ff84-48a3-aa05-8152504c3e65@github.com>

On Fri, 9 Jun 2023 04:47:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Test refactoring to reduce future maintenance: when source version gets a new language feature, a single enum constant with an example gets added to test all source versions against that sample.

This pull request has now been integrated.

Changeset: 7d824790
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d82479096d9ecc14881bf9b639507eee43f547b
Stats:     340 lines in 1 file changed: 89 ins; 181 del; 70 mod

8309142: Refactor test/langtools/tools/javac/versions/Versions.java

Reviewed-by: jjg

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

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

From archie.cobbs at gmail.com  Sat Jun 10 22:06:56 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sat, 10 Jun 2023 17:06:56 -0500
Subject: Static methods of generic classes are treated differently
In-Reply-To: <CA+NR86hi-kqDL2sBRjrGcsqWOkNDjiEZpdFEknqntOKajrAKqQ@mail.gmail.com>
References: <CA+NR86jb7mGJsjbjZ8Y4VEmdNCNjgQtbcfMZCnvUuiMe5YE8ig@mail.gmail.com>
 <CA+NR86hi-kqDL2sBRjrGcsqWOkNDjiEZpdFEknqntOKajrAKqQ@mail.gmail.com>
Message-ID: <CANSoFxtLK3TovhZvLMOZ1L4PaETUWi1WmXRdaJyikWpEZvbCRA@mail.gmail.com>

Looks like a legitimate bug to me...

You'd think how the compiler treats a static method reference shouldn't be
at all determined by whether the class containing that static method is
generic or not...

I've created https://bugs.openjdk.org/browse/JDK-8309767 to track this.

-Archie

On Fri, Jun 9, 2023 at 11:59?AM Ethan McCue <ethan at mccue.dev> wrote:

> Following up on this just to see if there is an explanation of some sort I
> am missing.
>
> On Sun, Apr 30, 2023 at 8:40?AM Ethan McCue <ethan at mccue.dev> wrote:
>
>> I've run into either a corner case in type resolution or a compiler bug
>> and I'm not sure which.
>>
>> In an expression context, if a static method is referenced from a generic
>> class then it won't properly target overloads that require primitive
>> wrapper unboxing.
>>
>> package org.example;
>>
>> import java.time.Month;
>> import java.util.function.Supplier;
>>
>>
>> interface A {
>>     static int f() {
>>         return 1;
>>     }
>> }
>>
>> interface B<T> {
>>     static int f() {
>>         return 2;
>>     }
>> }
>>
>> final class C {
>>     static int f() {
>>         return 3;
>>     }
>> }
>>
>> final class D<T> {
>>     static int f() {
>>         return 4;
>>     }
>> }
>>
>>
>> public class Main {
>>     static void h(Month b) {}
>>     static void h(int b) {}
>>
>>     static <T> T g(Supplier<? extends T> d) {
>>         return d.get();
>>     }
>>
>>
>>     public static void main(String[] args) {
>>         // Compiles
>>         h(
>>                 g(A::f)
>>         );
>>
>>         // Doesn't compile
>>         h(
>>                 g(B::f)
>>         );
>>
>>         // Compiles
>>         var r1 = g(B::f);
>>         h(r1);
>>
>>         // Compiles
>>         h(
>>                 g(C::f)
>>         );
>>
>>         // Doesn't compile
>>         h(
>>                 g(D::f)
>>         );
>>
>>         // Compiles
>>         var r2 = g(D::f);
>>         h(r2);
>>     }
>> }
>>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230610/405c1db4/attachment.htm>

From jlahoda at openjdk.org  Mon Jun 12 08:20:58 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 Jun 2023 08:20:58 GMT
Subject: Integrated: 8309467: Pattern dominance should be adjusted
In-Reply-To: <o8ZiChq14w881qMrqaEczOZqj0xdKeQ_JbDQMb0O-vI=.d6b08fa4-73c1-4691-810a-c64536fd8fb0@github.com>
References: <o8ZiChq14w881qMrqaEczOZqj0xdKeQ_JbDQMb0O-vI=.d6b08fa4-73c1-4691-810a-c64536fd8fb0@github.com>
Message-ID: <4HuCk1x_Aze6lTj4jklqIDQmaZxPOXYEfDsAlXmmA8E=.80450988-064a-4367-95d7-291028615b16@github.com>

On Mon, 5 Jun 2023 14:48:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, when a switch contains both patterns and constant labels, any pattern case dominates the constant label. E.g. the following example currently produces a compile-time error:
> 
> switch (...) {
>     case Integer i when i == 0 -> {}
>     case 1 -> {} //dominated by the preceding case
>     case Integer i -> {}
> }
> 
> 
> But, the rules are now (to be) relaxed in the spec, so that guarded cases (with patterns) don't dominate cases with constant labels. I.e. the above example is supposed to compile and run fine.
> 
> This PR is implementing this change - when checking patter-constant dominance, we only consider unguarded cases.

This pull request has now been integrated.

Changeset: 408cadb3
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/408cadb351eb3b3a96e81e26e1c39c89dac176ca
Stats:     80 lines in 4 files changed: 62 ins; 10 del; 8 mod

8309467: Pattern dominance should be adjusted

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Mon Jun 12 08:57:41 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 Jun 2023 08:57:41 GMT
Subject: RFR: 8309467: Pattern dominance should be adjusted
Message-ID: <pOBPUERAuAyT2y3UZxVePa9OsKUOrYY5wEmvnDm1ycE=.fc8d564b-6679-4e5c-ad9a-b27cc6374f38@github.com>

Hi all,

This pull request contains a backport of commit [408cadb3](https://github.com/openjdk/jdk/commit/408cadb351eb3b3a96e81e26e1c39c89dac176ca) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 12 Jun 2023 and was reviewed by Vicente Romero.

Thanks!

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

Commit messages:
 - Backport 408cadb351eb3b3a96e81e26e1c39c89dac176ca

Changes: https://git.openjdk.org/jdk21/pull/6/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=6&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309467
  Stats: 80 lines in 4 files changed: 62 ins; 10 del; 8 mod
  Patch: https://git.openjdk.org/jdk21/pull/6.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/6/head:pull/6

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

From vromero at openjdk.org  Mon Jun 12 13:30:16 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Jun 2023 13:30:16 GMT
Subject: RFR: 8309467: Pattern dominance should be adjusted
In-Reply-To: <pOBPUERAuAyT2y3UZxVePa9OsKUOrYY5wEmvnDm1ycE=.fc8d564b-6679-4e5c-ad9a-b27cc6374f38@github.com>
References: <pOBPUERAuAyT2y3UZxVePa9OsKUOrYY5wEmvnDm1ycE=.fc8d564b-6679-4e5c-ad9a-b27cc6374f38@github.com>
Message-ID: <Z21cuieJommM8255SPB9nVC4na5RtkDpmGUUyrPMGoE=.edced3ae-a4bd-4f87-b4a6-645f4cb7a9aa@github.com>

On Mon, 12 Jun 2023 08:49:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [408cadb3](https://github.com/openjdk/jdk/commit/408cadb351eb3b3a96e81e26e1c39c89dac176ca) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 12 Jun 2023 and was reviewed by Vicente Romero.
> 
> Thanks!

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/6#pullrequestreview-1474926474

From acobbs at openjdk.org  Mon Jun 12 15:02:46 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 12 Jun 2023 15:02:46 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v2]
In-Reply-To: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
Message-ID: <x-Rxw4lDuUoyqSvj6lj_J5GUFRQj_1KeLBc-PfBauDg=.904d293c-467c-41e7-b176-1bee7c7ca387@github.com>

> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
> 
> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
> 
> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
> 
> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag. 
> 
> I have not done any performance testing or comparisons of `StringNameTable`; see also [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) which argues that a `String`-based implementation should be faster.
> 
> Changes:
> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
> * Add new `StringNameTable` implementation.

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

 - Merge branch 'master' into JDK-8269957
 - Merge branch 'master' into JDK-8269957
 - Move equals() table check into common superclass.
 - Add Name.Table factory methods to Names class.
 - Add StringNameTable as a new (optional) Name.Table implementation.
 - Add a few more default method implementations to Name superclass.
 - Revert some unnecessary changes.
 - Merge branch 'master' into JDK-8269957
 - Refactor Name and friends to facilitate future improvements.

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

Changes: https://git.openjdk.org/jdk/pull/13282/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13282&range=01
  Stats: 834 lines in 11 files changed: 571 ins; 162 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/13282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13282/head:pull/13282

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

From darcy at openjdk.org  Mon Jun 12 17:36:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Jun 2023 17:36:10 GMT
Subject: RFR: JDK-8309870: Using -proc:full should be considered requesting
 explicit annotation processing
Message-ID: <bBqDp6j61VdvfuPJkZD-Pd6yxHyWJuy23OSWQE6dJ1w=.4f943b9e-f51e-42c7-b226-544c245ac925@github.com>

Address a small omission to the recent addition of "javac -proc:full", regard "-proc:full" as explicitly requesting annotation processing. Also add "-A" to the list of options indicating explicit annotation processing was requested.

The intention is to backport this bug fix to JDK 21 too.

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

Commit messages:
 - JDK-8309870: Using -proc:full should be considered requesting explicit annotation processing

Changes: https://git.openjdk.org/jdk/pull/14423/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14423&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309870
  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14423.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14423/head:pull/14423

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

From jjg at openjdk.org  Mon Jun 12 17:52:40 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 12 Jun 2023 17:52:40 GMT
Subject: RFR: JDK-8309870: Using -proc:full should be considered requesting
 explicit annotation processing
In-Reply-To: <bBqDp6j61VdvfuPJkZD-Pd6yxHyWJuy23OSWQE6dJ1w=.4f943b9e-f51e-42c7-b226-544c245ac925@github.com>
References: <bBqDp6j61VdvfuPJkZD-Pd6yxHyWJuy23OSWQE6dJ1w=.4f943b9e-f51e-42c7-b226-544c245ac925@github.com>
Message-ID: <W2h4NRrxnZB9dTjWPvXjEmUtjNUz-c3L3gSxzmE7foM=.2607b7c9-a78b-4e2f-bfc3-bb6c33f8a0cf@github.com>

On Mon, 12 Jun 2023 17:28:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Address a small omission to the recent addition of "javac -proc:full", regard "-proc:full" as explicitly requesting annotation processing. Also add "-A" to the list of options indicating explicit annotation processing was requested.
> 
> The intention is to backport this bug fix to JDK 21 too.

Approved, with suggestion to relocate comment.

src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 96:

> 94:      * options, the list of options regarded as requesting explicit
> 95:      * annotation processing in JavaCompiler should be updated.
> 96:      */

(minor) consider moving this option to before the declaration of `Option` so that it seems less like it applies to the first member.  It could even be an `@implNote` on the enum.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14423#pullrequestreview-1475494129
PR Review Comment: https://git.openjdk.org/jdk/pull/14423#discussion_r1227037098

From cushon at openjdk.org  Mon Jun 12 18:02:49 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 12 Jun 2023 18:02:49 GMT
Subject: RFR: 8309499: javac fails to report compiler.err.no.java.lang with
 annotation processing enabled
In-Reply-To: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
References: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
Message-ID: <uOwQ7z9G_IXUweqsPK4T6UBCX_nLRaxkaW58jjVT948=.391f495f-ba94-46c0-b4e5-4fe7041c4ee6@github.com>

On Wed, 7 Jun 2023 21:03:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi,
> 
> Please consider this fix for an error handling bug in javac, which causes a deferred diagnostic to be lost when an `Abort` is thrown with annotation processing enabled. See https://bugs.openjdk.org/browse/JDK-8309499 for more details.
> 
> This fix is contributed by my colleague Paula Toth paulatoth at google.com.

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 985:

> 983:             // missing java.lang error.
> 984:             if (deferredDiagnosticHandler != null) {
> 985:                 deferredDiagnosticHandler.reportDeferredDiagnostics();

The CI run shows some real test failures that still need to be addressed


java.lang.NullPointerException: Cannot invoke "java.util.Queue.poll()" because "this.deferred" is null
        at jdk.compiler/com.sun.tools.javac.util.Log$DeferredDiagnosticHandler.reportDeferredDiagnostics(Log.java:169)
        at jdk.compiler/com.sun.tools.javac.util.Log$DeferredDiagnosticHandler.reportDeferredDiagnostics(Log.java:163)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:985)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)


It looks like `reportDeferredDiagnostics` is now being called twice for some invocations, and when it is called it sets the queue of deferred diagnostics to `null`, so the second call fails: https://github.com/openjdk/jdk/blob/45414fc2dfa41cbbfc6de7fec15eb47f41cf8986/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java#L173

One option would be to set `deferredDiagnosticHandler` to `null` after calling `reportDeferredDiagnostics` in `JavaCompiler`, so we can keep track of whether the deferred diagnostics have already been reported

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14370#discussion_r1227048009

From darcy at openjdk.org  Mon Jun 12 18:19:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Jun 2023 18:19:58 GMT
Subject: RFR: JDK-8309870: Using -proc:full should be considered requesting
 explicit annotation processing [v2]
In-Reply-To: <bBqDp6j61VdvfuPJkZD-Pd6yxHyWJuy23OSWQE6dJ1w=.4f943b9e-f51e-42c7-b226-544c245ac925@github.com>
References: <bBqDp6j61VdvfuPJkZD-Pd6yxHyWJuy23OSWQE6dJ1w=.4f943b9e-f51e-42c7-b226-544c245ac925@github.com>
Message-ID: <iNLh5-k9c_3Hj_l-Z6Lbxx1t7RxTHPJB3NnzpXW245Q=.ff4f5716-7a9f-4c84-8831-b6936b29f452@github.com>

> Address a small omission to the recent addition of "javac -proc:full", regard "-proc:full" as explicitly requesting annotation processing. Also add "-A" to the list of options indicating explicit annotation processing was requested.
> 
> The intention is to backport this bug fix to JDK 21 too.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14423/files
  - new: https://git.openjdk.org/jdk/pull/14423/files/dd952303..7c143568

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

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

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

From darcy at openjdk.org  Mon Jun 12 18:19:59 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Jun 2023 18:19:59 GMT
Subject: Integrated: JDK-8309870: Using -proc:full should be considered
 requesting explicit annotation processing
In-Reply-To: <bBqDp6j61VdvfuPJkZD-Pd6yxHyWJuy23OSWQE6dJ1w=.4f943b9e-f51e-42c7-b226-544c245ac925@github.com>
References: <bBqDp6j61VdvfuPJkZD-Pd6yxHyWJuy23OSWQE6dJ1w=.4f943b9e-f51e-42c7-b226-544c245ac925@github.com>
Message-ID: <ltCQtCPlQ-vEUDBAkRVZh7XcrVgRTei8QnEtjojm-9g=.ac9212ea-03b1-49ab-9a76-0b3d0e9f1486@github.com>

On Mon, 12 Jun 2023 17:28:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Address a small omission to the recent addition of "javac -proc:full", regard "-proc:full" as explicitly requesting annotation processing. Also add "-A" to the list of options indicating explicit annotation processing was requested.
> 
> The intention is to backport this bug fix to JDK 21 too.

This pull request has now been integrated.

Changeset: 3ce1240c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ce1240ca1b4139980444c171e317f4bfeff9314
Stats:     10 lines in 2 files changed: 8 ins; 0 del; 2 mod

8309870: Using -proc:full should be considered requesting explicit annotation processing

Reviewed-by: jjg

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

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

From darcy at openjdk.org  Mon Jun 12 19:43:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Jun 2023 19:43:30 GMT
Subject: RFR: 8309870: Using -proc:full should be considered requesting
 explicit annotation processing
Message-ID: <NiJNonMXjzeFkhgeUkYpLQjXUIJ0YunVzxXpPFB7Zjk=.7a03a885-b24e-4972-9f23-a8b5b40c1e58@github.com>

Minor fix to new-in-JDK-21 functionality.

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

Commit messages:
 - Backport 3ce1240ca1b4139980444c171e317f4bfeff9314

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

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

From jjg at openjdk.org  Mon Jun 12 19:54:56 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 12 Jun 2023 19:54:56 GMT
Subject: RFR: 8309870: Using -proc:full should be considered requesting
 explicit annotation processing
In-Reply-To: <NiJNonMXjzeFkhgeUkYpLQjXUIJ0YunVzxXpPFB7Zjk=.7a03a885-b24e-4972-9f23-a8b5b40c1e58@github.com>
References: <NiJNonMXjzeFkhgeUkYpLQjXUIJ0YunVzxXpPFB7Zjk=.7a03a885-b24e-4972-9f23-a8b5b40c1e58@github.com>
Message-ID: <K6qv9rsoUKDQ8XbKIsVfJ0X0Si_jLpcCIKYE2VcNfHc=.4d0d06c4-166b-427d-a029-6bb21ca69ae2@github.com>

On Mon, 12 Jun 2023 19:35:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Minor fix to new-in-JDK-21 functionality.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/10#pullrequestreview-1475702072

From darcy at openjdk.org  Mon Jun 12 20:06:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Jun 2023 20:06:54 GMT
Subject: Integrated: 8309870: Using -proc:full should be considered requesting
 explicit annotation processing
In-Reply-To: <NiJNonMXjzeFkhgeUkYpLQjXUIJ0YunVzxXpPFB7Zjk=.7a03a885-b24e-4972-9f23-a8b5b40c1e58@github.com>
References: <NiJNonMXjzeFkhgeUkYpLQjXUIJ0YunVzxXpPFB7Zjk=.7a03a885-b24e-4972-9f23-a8b5b40c1e58@github.com>
Message-ID: <cDe562y-MeYJ47Lymd6G8GtWtH9jDsoyte5mrVU4_cg=.bb5f15f2-76f6-41e6-8d8c-434df7f04a97@github.com>

On Mon, 12 Jun 2023 19:35:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Minor fix to new-in-JDK-21 functionality.

This pull request has now been integrated.

Changeset: b7434050
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/b74340503317feab323a69835ac3969f8756bfc1
Stats:     10 lines in 2 files changed: 8 ins; 0 del; 2 mod

8309870: Using -proc:full should be considered requesting explicit annotation processing

Reviewed-by: jjg
Backport-of: 3ce1240ca1b4139980444c171e317f4bfeff9314

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

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

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 jjg at openjdk.org  Mon Jun 12 23:24:59 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 12 Jun 2023 23:24:59 GMT
Subject: RFR: JDK-8309883: no @since info in com.sun.tools.javac
 package-info.java,Main.java
Message-ID: <m-y3bbiCne667UuTW0IvRpZO0mp-JRw7cKttjqxNlSk=.22a20912-a927-46c0-b5ad-b30c67a69470@github.com>

Please review a trivial update to add some long-overdue `@since` tags to public API in `com.sun.tools.javac`.

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

Commit messages:
 - JDK-8309883: no @since info in com.sun.tools.javac package-info.java, Main.java

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

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

From iris at openjdk.org  Mon Jun 12 23:31:50 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 12 Jun 2023 23:31:50 GMT
Subject: RFR: JDK-8309883: no @since info in com.sun.tools.javac
 package-info.java,Main.java
In-Reply-To: <m-y3bbiCne667UuTW0IvRpZO0mp-JRw7cKttjqxNlSk=.22a20912-a927-46c0-b5ad-b30c67a69470@github.com>
References: <m-y3bbiCne667UuTW0IvRpZO0mp-JRw7cKttjqxNlSk=.22a20912-a927-46c0-b5ad-b30c67a69470@github.com>
Message-ID: <Yq5vl2L2qgyKoQrb_0-7aBZd-5rQLlhedufy3J-VSnA=.ea9f3031-0f64-4e37-9134-c88530a05ded@github.com>

On Mon, 12 Jun 2023 23:17:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to add some long-overdue `@since` tags to public API in `com.sun.tools.javac`.

Wow.  Surprised to see that one escape for so long!

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14431#pullrequestreview-1475958250

From darcy at openjdk.org  Mon Jun 12 23:31:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Jun 2023 23:31:51 GMT
Subject: RFR: JDK-8309883: no @since info in com.sun.tools.javac
 package-info.java,Main.java
In-Reply-To: <m-y3bbiCne667UuTW0IvRpZO0mp-JRw7cKttjqxNlSk=.22a20912-a927-46c0-b5ad-b30c67a69470@github.com>
References: <m-y3bbiCne667UuTW0IvRpZO0mp-JRw7cKttjqxNlSk=.22a20912-a927-46c0-b5ad-b30c67a69470@github.com>
Message-ID: <np7nPoY9jUzj64ap7O_ETvrew2Zj63I3rPzq_aQmXyU=.dad0cee9-c204-40e7-b139-96783d7d9629@github.com>

On Mon, 12 Jun 2023 23:17:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to add some long-overdue `@since` tags to public API in `com.sun.tools.javac`.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14431#pullrequestreview-1475959736

From jjg at openjdk.org  Tue Jun 13 00:27:54 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 13 Jun 2023 00:27:54 GMT
Subject: RFR: JDK-8309884: missing @since tags in `com.sun.source.*`
Message-ID: <t7b62G3rpqoI83uz_0lzsR1x8--dP-pMXxyqQBBU0Yw=.9f64b75d-081b-4b63-9057-b2eca8bb31e4@github.com>

Please review a trivial docs fix to address missing `@since` tags in `com.sun.source` API.

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

Commit messages:
 - JDK-8309884: missing @since tags in `com.sun.source.*`

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

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

From darcy at openjdk.org  Tue Jun 13 00:32:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Jun 2023 00:32:39 GMT
Subject: RFR: JDK-8309884: missing @since tags in `com.sun.source.*`
In-Reply-To: <t7b62G3rpqoI83uz_0lzsR1x8--dP-pMXxyqQBBU0Yw=.9f64b75d-081b-4b63-9057-b2eca8bb31e4@github.com>
References: <t7b62G3rpqoI83uz_0lzsR1x8--dP-pMXxyqQBBU0Yw=.9f64b75d-081b-4b63-9057-b2eca8bb31e4@github.com>
Message-ID: <0FiN1KEgu_-SZcj-lD9lBKFfnXXnlK3LdyGf0pb_C40=.ca9a1314-2e18-4fbf-b356-bc66fe59dd77@github.com>

On Tue, 13 Jun 2023 00:20:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial docs fix to address missing `@since` tags in `com.sun.source` API.

Approving, but suggest double checking if "8" or "1.8" is more commonly used for since tag.

src/jdk.compiler/share/classes/com/sun/source/tree/LambdaExpressionTree.java line 40:

> 38:  * }</pre>
> 39:  *
> 40:  * @since 8

I think "1.8" was predominantly used at the time.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14434#pullrequestreview-1476004751
PR Review Comment: https://git.openjdk.org/jdk/pull/14434#discussion_r1227366273

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 jlahoda at openjdk.org  Tue Jun 13 07:36:59 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 13 Jun 2023 07:36:59 GMT
Subject: Integrated: 8309467: Pattern dominance should be adjusted
In-Reply-To: <pOBPUERAuAyT2y3UZxVePa9OsKUOrYY5wEmvnDm1ycE=.fc8d564b-6679-4e5c-ad9a-b27cc6374f38@github.com>
References: <pOBPUERAuAyT2y3UZxVePa9OsKUOrYY5wEmvnDm1ycE=.fc8d564b-6679-4e5c-ad9a-b27cc6374f38@github.com>
Message-ID: <fKPmQbDU323_VhEvnRB4Gdv-Mplv-I7erL6-ABySx0o=.3ecaa8ef-e720-49cd-8fa5-890bdb5a52d4@github.com>

On Mon, 12 Jun 2023 08:49:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [408cadb3](https://github.com/openjdk/jdk/commit/408cadb351eb3b3a96e81e26e1c39c89dac176ca) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 12 Jun 2023 and was reviewed by Vicente Romero.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 83ea2935
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/83ea2935815141bd7a930f3920889b1f2233d208
Stats:     80 lines in 4 files changed: 62 ins; 10 del; 8 mod

8309467: Pattern dominance should be adjusted

Reviewed-by: vromero
Backport-of: 408cadb351eb3b3a96e81e26e1c39c89dac176ca

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

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

From prappo at openjdk.org  Tue Jun 13 10:11:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 13 Jun 2023 10:11:28 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo 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 14 additional commits since the last revision:

 - fix failing SourceDocTreeScannerTest
 - Merge branch 'master' into 8285368
 - feedback: use JavadocTester.out
   
   Also, trivially fixes grammar (word order) in a comment.
 - feedback: remove unduly restrictive warning
 - suggestion: vocabulary
 - feedback: DocLint terminology
 - feedback: use utils directly
 - Merge branch 'master' into 8285368
 - feedback: make warning less scary
 - Disable problematic check
   
   This check is well-intended but problematic for JDK API Documentation
   build, which errors on warnings.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/e7a50303...563a8761

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/cccffa66..563a8761

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

  Stats: 11904 lines in 355 files changed: 9502 ins; 1007 del; 1395 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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

From prappo at openjdk.org  Tue Jun 13 10:13:50 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 13 Jun 2023 10:13:50 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v8]
In-Reply-To: <s_V36_pNoxTdLaYD8EZR38Iso9Wdjm1TTh_R5-sgNJo=.a01574f0-d031-4856-9af2-7423cc45cb9d@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <s_V36_pNoxTdLaYD8EZR38Iso9Wdjm1TTh_R5-sgNJo=.a01574f0-d031-4856-9af2-7423cc45cb9d@github.com>
Message-ID: <gl2P0tzBbsQgl6CXhFtwG12d0aX_d2b4G1sIiaOepmY=.a6c0bdaa-1a47-4abb-9a0e-3fb8c8dfe4b7@github.com>

On Thu, 8 Jun 2023 14:47:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: use JavadocTester.out
>   
>   Also, trivially fixes grammar (word order) in a comment.

core-libs, client: any reviewers?

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1588987444

From jjg at openjdk.org  Tue Jun 13 14:48:43 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 13 Jun 2023 14:48:43 GMT
Subject: RFR: JDK-8309884: missing @since tags in `com.sun.source.*`
In-Reply-To: <0FiN1KEgu_-SZcj-lD9lBKFfnXXnlK3LdyGf0pb_C40=.ca9a1314-2e18-4fbf-b356-bc66fe59dd77@github.com>
References: <t7b62G3rpqoI83uz_0lzsR1x8--dP-pMXxyqQBBU0Yw=.9f64b75d-081b-4b63-9057-b2eca8bb31e4@github.com>
 <0FiN1KEgu_-SZcj-lD9lBKFfnXXnlK3LdyGf0pb_C40=.ca9a1314-2e18-4fbf-b356-bc66fe59dd77@github.com>
Message-ID: <kYUaagzGF1RI1h_SQBVKDVS9KmxhtAdpwFfKVuKksAY=.6d459cc3-9b14-4dd6-9428-a025445ff526@github.com>

On Tue, 13 Jun 2023 00:29:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review a trivial docs fix to address missing `@since` tags in `com.sun.source` API.
>
> Approving, but suggest double checking if "8" or "1.8" is more commonly used for since tag.

@jddarcy I'll run a scan to see the dominant values for each release.

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

PR Comment: https://git.openjdk.org/jdk/pull/14434#issuecomment-1589459855

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 jjg at openjdk.org  Tue Jun 13 16:57:51 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 13 Jun 2023 16:57:51 GMT
Subject: RFR: JDK-8309884: missing @since tags in `com.sun.source.*` [v2]
In-Reply-To: <t7b62G3rpqoI83uz_0lzsR1x8--dP-pMXxyqQBBU0Yw=.9f64b75d-081b-4b63-9057-b2eca8bb31e4@github.com>
References: <t7b62G3rpqoI83uz_0lzsR1x8--dP-pMXxyqQBBU0Yw=.9f64b75d-081b-4b63-9057-b2eca8bb31e4@github.com>
Message-ID: <7q96hELm9HdrVWv9LQ65tStGt7vRoPlz6lXhDyoJKZs=.7379274c-a587-4050-a8b5-2e1a8e6e028d@github.com>

> Please review a trivial docs fix to address missing `@since` tags in `com.sun.source` API.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  change @since 8 to 1.8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14434/files
  - new: https://git.openjdk.org/jdk/pull/14434/files/2ad464c1..f80758b8

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

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

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

From ljnelson at gmail.com  Tue Jun 13 17:01:53 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Tue, 13 Jun 2023 10:01:53 -0700
Subject: javac's allparams(): returns type arguments, yes?
Message-ID: <CAHNdxukxm7bLngUTjrDcC-niP3kj98ag2gbY4X4aQkuBuYvRWg@mail.gmail.com>

I am reading some javac code to satisfy some curiosity and wanted to
quickly confirm something.

I noticed that the com.sun.tools.javac.code.Type#allparams() method
actually operates on type *arguments*, correct, despite its name implying
(to me, used to the Java language model terminology) otherwise?

So in the case of a type representing Outer<String>.Inner<Number>,
allparams(innerType) would presumably return the String and Number type
*arguments*, and not the formal type parameter elements (S and N or
whatever) corresponding to them?

Related: the getTypeArguments() method works on a field called
typarams_field; I'm assuming again that the typarams_field field stores
type *arguments*, not formal type parameter elements?

L
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230613/c5730c41/attachment.htm>

From jjg at openjdk.org  Tue Jun 13 17:43:59 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 13 Jun 2023 17:43:59 GMT
Subject: Integrated: JDK-8309884: missing @since tags in `com.sun.source.*`
In-Reply-To: <t7b62G3rpqoI83uz_0lzsR1x8--dP-pMXxyqQBBU0Yw=.9f64b75d-081b-4b63-9057-b2eca8bb31e4@github.com>
References: <t7b62G3rpqoI83uz_0lzsR1x8--dP-pMXxyqQBBU0Yw=.9f64b75d-081b-4b63-9057-b2eca8bb31e4@github.com>
Message-ID: <FVAIUPuuKViWeP0tCyNYRcbsT4JcM4SyXj6q_wmhkYQ=.6691526f-9804-4a93-954d-d90030050033@github.com>

On Tue, 13 Jun 2023 00:20:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial docs fix to address missing `@since` tags in `com.sun.source` API.

This pull request has now been integrated.

Changeset: b5b5b7ce
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5b5b7ce7220df650f6142c40d6e89c0462877ce
Stats:     7 lines in 4 files changed: 7 ins; 0 del; 0 mod

8309884: missing @since tags in `com.sun.source.*`

Reviewed-by: darcy

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

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

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 rriggs at openjdk.org  Tue Jun 13 18:43:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Jun 2023 18:43:54 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <G-5lUrL5o1mHBF518jX21fRDl9mfxMVsTU07-gS2piA=.d9caf34d-c126-4168-a6c1-5748f3ba9c74@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo 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 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/6992bbe1...563a8761

Look ok for core-libs classes

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1477840678

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 aivanov at openjdk.org  Tue Jun 13 19:31:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Jun 2023 19:31:58 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <YN_XIXW4Pky8-d7C7JXyQiDrT5B98PQjkKd3EhgKoVs=.d8fe969f-d5be-48d6-8814-31e951becf84@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo 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 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/79d4fbab...563a8761

Looks good to me for client changes.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1477876414

From aivanov at openjdk.org  Tue Jun 13 19:31:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Jun 2023 19:31:59 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <iVcMmg2r9UXBrsTQBU7X2Y1GDvrCeTg-1l1Vc-uZOhQ=.6f272612-b970-41b0-b36d-b03204291b59@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
 <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
 <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>
 <iVcMmg2r9UXBrsTQBU7X2Y1GDvrCeTg-1l1Vc-uZOhQ=.6f272612-b970-41b0-b36d-b03204291b59@github.com>
Message-ID: <XryojXZM0ga3TLZZDfzG85pI_XAwPs7ZY4uNgb3PahM=.fa4efe54-e45d-4567-af0a-f1f431321c14@github.com>

On Thu, 8 Jun 2023 15:51:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Copying an individual doc element using `{@inheritDoc}` never adds meta information on the generated HTML page to indicate where that doc element was copied from. It so happens in this particular case that the doc element's contents are the same in both possible supertypes (BlockingDeque and Queue) and look like this:
>> 
>>     @param e the element to add
>> 
>> If the end result _on the HTML page_ will look identical no mater if I add `@param e {@inheritDoc BlockingDeque}` or not, I will not add it in _this_ PR. This PR's goal is not restructuring the doc comment; in fact, such restructuring would be an anti-goal. It might be a goal for subsequent, area-specific PRs.
>> 
>> Above I said that "`{@inheritDoc}` never adds meta information on the generated HTML page". You might have immediately thought about cases where you saw the "Description copied from interface/class" headings. However, those do not come from `{@inheritDoc}`; those come from empty comments (which inherit their content by omission, if you wish). So those headings DO indicate the source of the complete doc comment.
>> 
>> Now about FileCacheImageOutputStream.java. If I hand't added directed inheritance there, the updated algorithm would've picked a different comment, which wouldn't have been identical to what was picked before:
>> 
>>  - javax.imageio.stream.ImageInputStream#flushBefore
>>     ```
>>      * @param pos a {@code long} containing the length of the
>>      * stream prefix that may be flushed.
>>     ```
>> 
>>  - javax.imageio.stream.ImageOutputStream#flushBefore:
>>     ```
>>      * @param pos a {@code long} containing the length of the
>>      * stream prefix that may be flushed to the destination.
>>     ```
>> Hence, the correction. Does it clarify the matter?
>
> Also, for better or worse, a lone `{@inheritDoc}` never inherits "everything" from a supertype:
> 
> /** {@inheritDoc} */
> 
> It merely inherits the main description of a method. Other elements such as parameter, exception or return information are inherited individually.

Thank you, it helps.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1228577519

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 smarks at openjdk.org  Tue Jun 13 23:28:06 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 Jun 2023 23:28:06 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <QnkmxlgG_SEw_psGvx_Dk8XdtnkX5pMLzR3fV70R67A=.406d338a-7b88-435d-8e07-0ab4775d52f2@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo 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 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/332eaf7c...563a8761

I reviewed the changes in java.base. They look fine. I support the notion of keeping these changes minimal, with the narrow goal of keeping the resulting javadoc output the same. There are many opportunities for improving the actual docs, but those should be handled separately.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1478203733

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 martin at openjdk.org  Wed Jun 14 00:53:08 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 14 Jun 2023 00:53:08 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <QnkmxlgG_SEw_psGvx_Dk8XdtnkX5pMLzR3fV70R67A=.406d338a-7b88-435d-8e07-0ab4775d52f2@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <QnkmxlgG_SEw_psGvx_Dk8XdtnkX5pMLzR3fV70R67A=.406d338a-7b88-435d-8e07-0ab4775d52f2@github.com>
Message-ID: <exFXZi0DI28DB807MgElHWkyA2xeAEybsLjwb3Vm7GI=.c0d93736-d6cb-4a97-bead-cc817b24c2dc@github.com>

On Tue, 13 Jun 2023 23:24:46 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I reviewed the changes in java.base. They look fine. I support the notion of keeping these changes minimal, with the narrow goal of keeping the resulting javadoc output the same. There are many opportunities for improving the actual docs, but those should be handled separately.

I agree with stuart-marks@

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1590262295

From martin at openjdk.org  Wed Jun 14 01:23:20 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 14 Jun 2023 01:23:20 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo 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 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/0db0007a...563a8761

We don't currently have a way to diff rendered javadoc, like my ancient BlenderRev hack?

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1534:

> 1532: 
> 1533:     /**
> 1534:      * {@inheritDoc ConcurrentMap}

This clarifies the authors' intent, so is clear progress. 

Semantic difficulties remain:
- it would be nice to somehow declare that we never ever want to inherit doc from AbstractMap (or even at the module level, declare that AbstractFoo classes are specified only for subclass writers, not users).  Private inheritance?
- we never want to inherit AbstractFoo @implNotes
- ConcurrentMap does *not* have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should *not* be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.

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

Marked as reviewed by martin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1478285774
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1228861243

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 prappo at openjdk.org  Wed Jun 14 09:02:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Jun 2023 09:02:08 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
Message-ID: <1l4rCRZlweJ91CBc-cVcKLnqMAfXZtLThPK2EQ_hk-Y=.e7349c38-3bf7-46c9-95a6-3127959488d3@github.com>

On Wed, 14 Jun 2023 01:19:57 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> We don't currently have a way to diff rendered javadoc, like my ancient BlenderRev hack?

I've generated something you might find helpful: https://cr.openjdk.org/~prappo/8285368/specdiff/overview-summary.html

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1590779943

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 prappo at openjdk.org  Wed Jun 14 10:10:02 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Jun 2023 10:10:02 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
Message-ID: <wvgrrZUkfRMQ3rNy7Uphe5-57WTk0A10EdPKbeGWOko=.f35bd62f-c094-4ec5-91f8-ae1ecff726ca@github.com>

On Wed, 14 Jun 2023 01:15:51 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> * we never want to inherit AbstractFoo @implNotes

`@implNote`, `@apiNote` and `@implSpec` can only be inherited via explicit `{@inheritDoc}`:

    @implSpec {@inheritDoc}

> * ConcurrentMap does _not_ have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should _not_ be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.

That state of affairs predates this PR and is merely highlighted by it. Sadly, I'm not sure how JavaDoc can help here. Annotations, contracts, inspections, and doc tests come to mind; but none of these are supported by JavaDoc at the moment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1229354100

From cushon at openjdk.org  Wed Jun 14 15:22:01 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 14 Jun 2023 15:22:01 GMT
Subject: RFR: 8309499: javac fails to report compiler.err.no.java.lang with
 annotation processing enabled [v2]
In-Reply-To: <gvwQUkmo36MUzuv4fzBVbBJbF89LPV0xmVcQrT0tnoo=.c9b0da3d-a157-4187-918c-d768a1154191@github.com>
References: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
 <gvwQUkmo36MUzuv4fzBVbBJbF89LPV0xmVcQrT0tnoo=.c9b0da3d-a157-4187-918c-d768a1154191@github.com>
Message-ID: <gJM4zddQFRxDXSN91zAq4j3UHyl1plyRAdSPXJjC8eg=.bbb67721-e813-4fb3-8276-19212c717c53@github.com>

On Thu, 8 Jun 2023 13:58:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Move deferred diagnostic reporting to catch clause. Remove unnecessary
>>    comment.
>>  - Update a comment as suggested in review
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 982:
> 
>> 980:             // In case an Abort was thrown before processAnnotations could be called,
>> 981:             // we could have deferred diagnostics that haven't been reported. At the
>> 982:             // time of this comment's writing, this can only ever occur through a
> 
> looks good. Suggestion: I would remove the last sentence: `At the time of this comment...` documents an erroneous situation. We usually don't add that type of comments.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14370#discussion_r1229791904

From cushon at openjdk.org  Wed Jun 14 15:21:57 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 14 Jun 2023 15:21:57 GMT
Subject: RFR: 8309499: javac fails to report compiler.err.no.java.lang with
 annotation processing enabled [v2]
In-Reply-To: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
References: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
Message-ID: <MFh4Jq6GnAmhKjsdwWEKkbUVV81d5BUstJSxM6p-3JY=.368c2205-2e4a-42e0-9d5d-f6b457843f38@github.com>

> Hi,
> 
> Please consider this fix for an error handling bug in javac, which causes a deferred diagnostic to be lost when an `Abort` is thrown with annotation processing enabled. See https://bugs.openjdk.org/browse/JDK-8309499 for more details.
> 
> This fix is contributed by my colleague Paula Toth paulatoth at google.com.

Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:

 - Move deferred diagnostic reporting to catch clause. Remove unnecessary
   comment.
 - Update a comment as suggested in review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14370/files
  - new: https://git.openjdk.org/jdk/pull/14370/files/03944bf4..0be60cfa

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

  Stats: 14 lines in 1 file changed: 6 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14370/head:pull/14370

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

From cushon at openjdk.org  Wed Jun 14 15:22:05 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 14 Jun 2023 15:22:05 GMT
Subject: RFR: 8309499: javac fails to report compiler.err.no.java.lang with
 annotation processing enabled [v2]
In-Reply-To: <uOwQ7z9G_IXUweqsPK4T6UBCX_nLRaxkaW58jjVT948=.391f495f-ba94-46c0-b4e5-4fe7041c4ee6@github.com>
References: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
 <uOwQ7z9G_IXUweqsPK4T6UBCX_nLRaxkaW58jjVT948=.391f495f-ba94-46c0-b4e5-4fe7041c4ee6@github.com>
Message-ID: <pFRMSFg4eTdDeotViBNrw6wNgibm6NeRrhMqTZXHpQ4=.4b930880-189a-4cd5-bdf9-fc897163d7e3@github.com>

On Mon, 12 Jun 2023 17:56:36 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> One option would be to set `deferredDiagnosticHandler` to `null` after calling `reportDeferredDiagnostics` in `JavaCompiler`, so we can keep track of whether the deferred diagnostics have already been reported

Paula had a better suggestion of moving the new logic to the `Abort` handler, which ensures it's only called once and fixes the test regressions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14370#discussion_r1229793706

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 vromero at openjdk.org  Wed Jun 14 20:27:00 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 14 Jun 2023 20:27:00 GMT
Subject: RFR: 8309499: javac fails to report compiler.err.no.java.lang with
 annotation processing enabled [v2]
In-Reply-To: <MFh4Jq6GnAmhKjsdwWEKkbUVV81d5BUstJSxM6p-3JY=.368c2205-2e4a-42e0-9d5d-f6b457843f38@github.com>
References: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
 <MFh4Jq6GnAmhKjsdwWEKkbUVV81d5BUstJSxM6p-3JY=.368c2205-2e4a-42e0-9d5d-f6b457843f38@github.com>
Message-ID: <-bB0PZA15sfcznxXP5f2V1eozIadEKCon5Kwh2CjbRE=.23248bde-2a65-4d35-93b7-242178f6c921@github.com>

On Wed, 14 Jun 2023 15:21:57 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Hi,
>> 
>> Please consider this fix for an error handling bug in javac, which causes a deferred diagnostic to be lost when an `Abort` is thrown with annotation processing enabled. See https://bugs.openjdk.org/browse/JDK-8309499 for more details.
>> 
>> This fix is contributed by my colleague Paula Toth paulatoth at google.com.
>
> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move deferred diagnostic reporting to catch clause. Remove unnecessary
>    comment.
>  - Update a comment as suggested in review

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14370#pullrequestreview-1480237363

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 jwaters at openjdk.org  Thu Jun 15 06:06:00 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Jun 2023 06:06:00 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <nivCHA8nRAblnomFGNzYyFA9PEvRmODerBnvK9THnDM=.ebb3d3b9-66ae-49e8-94c0-3e4ef7117975@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Bumping...

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1592419395

From prappo at openjdk.org  Thu Jun 15 09:22:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Jun 2023 09:22:32 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v10]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <RTK5UMJBqQsB7k4QpgCptUAEC16Mu_K4D-zPYyAghNI=.cf02b6f1-dc02-44fe-a880-a4b2635eff90@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo 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 17 additional commits since the last revision:

 - Merge branch 'master' into 8285368
 - Update @since tags
 - Add a test
 - fix failing SourceDocTreeScannerTest
 - Merge branch 'master' into 8285368
 - feedback: use JavadocTester.out
   
   Also, trivially fixes grammar (word order) in a comment.
 - feedback: remove unduly restrictive warning
 - suggestion: vocabulary
 - feedback: DocLint terminology
 - feedback: use utils directly
 - ... and 7 more: https://git.openjdk.org/jdk/compare/5a217d2b...5b6af244

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/563a8761..5b6af244

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

  Stats: 8391 lines in 228 files changed: 1225 ins; 6803 del; 363 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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

From abimpoudis at openjdk.org  Thu Jun 15 10:35:03 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 15 Jun 2023 10:35:03 GMT
Subject: RFR: 8310128: Switch with unnamed patterns erroneously non-exhaustive
Message-ID: <H7f846SIbX5mTdJc3eTrd1TQWZt5Aot3AaMgXXfZ0R8=.36186255-a9e7-478a-b709-6363e30f6c99@github.com>

When a record pattern has an unnamed pattern with the type of the corresponding record component being primitive, the switch is erroneously deemed as non-exhaustive. This PR addresses this issue by introducing the correct type for unnamed patterns during exhaustivity check.

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

Commit messages:
 - 8310128: Switch with unnamed patterns erroneously non-exhaustive

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

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

From jlahoda at openjdk.org  Thu Jun 15 16:32:49 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 15 Jun 2023 16:32:49 GMT
Subject: RFR: 8310133: Effectivelly final condition not enforced in guards for
 binding variables from the same case
Message-ID: <vqB9pzieRa4_1mhYPP-xJTQeAS8E8XA3XUJgsZO6qis=.3fb5d9ca-d335-4a92-9e0b-69688f9e35c5@github.com>

Consider code containing snippet like:

...
case String s when s.isEmpty() -> {
s = null;
}
...


The `s` binding variable is obviously not effectively final, but the specification currently requires variables used inside the guard to be effectively final or final.

The cause here is in a position check - for error reporting we need to sent a shared variable `currentTree` to the case, but the effectively final check will only check variables declared before the start of `currentTree` (to avoid reporting issues for variables inside a lambda, for example). The proposed fix is to keep the case inside `currentTree`, but ensure the guard's starting position is used, to allow a proper effectively final check.

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

Commit messages:
 - 8310133: Effectivelly final condition not enforced in guards for binding variables from the same case

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

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

From abimpoudis at openjdk.org  Thu Jun 15 16:39:30 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 15 Jun 2023 16:39:30 GMT
Subject: RFR: 8310128: Switch with unnamed patterns erroneously
 non-exhaustive [v2]
In-Reply-To: <H7f846SIbX5mTdJc3eTrd1TQWZt5Aot3AaMgXXfZ0R8=.36186255-a9e7-478a-b709-6363e30f6c99@github.com>
References: <H7f846SIbX5mTdJc3eTrd1TQWZt5Aot3AaMgXXfZ0R8=.36186255-a9e7-478a-b709-6363e30f6c99@github.com>
Message-ID: <DRegjF7XKcenUn8TUSu3qai0OUp-AKSOYxkB4tNiu1E=.3f8d1648-705a-4df9-b0a0-dc1ac558a222@github.com>

> When a record pattern has an unnamed pattern with the type of the corresponding record component being primitive, the switch is erroneously deemed as non-exhaustive. This PR addresses this issue by introducing the correct type for unnamed patterns during exhaustivity check.

Aggelos Biboudis 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:

 - Address comment
 - Merge branch 'master' into fix-#8310128
 - 8310128: Switch with unnamed patterns erroneously non-exhaustive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14488/files
  - new: https://git.openjdk.org/jdk/pull/14488/files/b39cc777..f7aa8a16

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

  Stats: 984 lines in 25 files changed: 107 ins; 846 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/14488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14488/head:pull/14488

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

From vromero at openjdk.org  Thu Jun 15 16:39:30 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 Jun 2023 16:39:30 GMT
Subject: RFR: 8310128: Switch with unnamed patterns erroneously
 non-exhaustive [v2]
In-Reply-To: <DRegjF7XKcenUn8TUSu3qai0OUp-AKSOYxkB4tNiu1E=.3f8d1648-705a-4df9-b0a0-dc1ac558a222@github.com>
References: <H7f846SIbX5mTdJc3eTrd1TQWZt5Aot3AaMgXXfZ0R8=.36186255-a9e7-478a-b709-6363e30f6c99@github.com>
 <DRegjF7XKcenUn8TUSu3qai0OUp-AKSOYxkB4tNiu1E=.3f8d1648-705a-4df9-b0a0-dc1ac558a222@github.com>
Message-ID: <nRrNpbFYSBWdYP8izFuItxOGgMwaxDZeNRkAbaLrvd4=.7f47ab4c-3a64-4778-a678-52cee4bd53a3@github.com>

On Thu, 15 Jun 2023 16:34:22 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> When a record pattern has an unnamed pattern with the type of the corresponding record component being primitive, the switch is erroneously deemed as non-exhaustive. This PR addresses this issue by introducing the correct type for unnamed patterns during exhaustivity check.
>
> Aggelos Biboudis 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:
> 
>  - Address comment
>  - Merge branch 'master' into fix-#8310128
>  - 8310128: Switch with unnamed patterns erroneously non-exhaustive

just a nit comment

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3504:

> 3502:             return new RecordPattern(record.type, componentTypes, nestedDescriptions);
> 3503:         } else if (pattern instanceof JCAnyPattern) {
> 3504:             Type type = types.isSubtype(selectorType, syms.objectType) || selectorType.isPrimitive()

it seems to me like we can drop this condition and just use the selectorType

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14488#pullrequestreview-1481999891
PR Review Comment: https://git.openjdk.org/jdk/pull/14488#discussion_r1231275796

From prappo at openjdk.org  Thu Jun 15 17:58:25 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Jun 2023 17:58:25 GMT
Subject: Integrated: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <kmzmr-8-gt-5ci-p2iA9RDGNokxRQBmVXqBIfjvc_4M=.45624b22-f898-4fc2-b244-a97279663743@github.com>

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

This pull request has now been integrated.

Changeset: 3e0bbd29
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e0bbd290c534b0f9729c54cd45308d505907797
Stats:     1768 lines in 32 files changed: 1634 ins; 32 del; 102 mod

8285368: Overhaul doc-comment inheritance
6376959: Algorithm for Inheriting Method Comments seems to go not as documented
6934301: Support directed inheriting of class comments with @inheritDoc

Reviewed-by: jjg, rriggs, aivanov, smarks, martin

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

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

From jlahoda at openjdk.org  Thu Jun 15 18:37:48 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 15 Jun 2023 18:37:48 GMT
Subject: RFR: 8310128: Switch with unnamed patterns erroneously
 non-exhaustive [v2]
In-Reply-To: <DRegjF7XKcenUn8TUSu3qai0OUp-AKSOYxkB4tNiu1E=.3f8d1648-705a-4df9-b0a0-dc1ac558a222@github.com>
References: <H7f846SIbX5mTdJc3eTrd1TQWZt5Aot3AaMgXXfZ0R8=.36186255-a9e7-478a-b709-6363e30f6c99@github.com>
 <DRegjF7XKcenUn8TUSu3qai0OUp-AKSOYxkB4tNiu1E=.3f8d1648-705a-4df9-b0a0-dc1ac558a222@github.com>
Message-ID: <8RHIFhUOeZ0UJTCb6JJcn4FDphp_TtmlATnsGmu1GNE=.12a53a9f-3287-4f00-90f7-c88b79eed3aa@github.com>

On Thu, 15 Jun 2023 16:39:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> When a record pattern has an unnamed pattern with the type of the corresponding record component being primitive, the switch is erroneously deemed as non-exhaustive. This PR addresses this issue by introducing the correct type for unnamed patterns during exhaustivity check.
>
> Aggelos Biboudis 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:
> 
>  - Address comment
>  - Merge branch 'master' into fix-#8310128
>  - 8310128: Switch with unnamed patterns erroneously non-exhaustive

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14488#pullrequestreview-1482182093

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 darcy at openjdk.org  Thu Jun 15 22:26:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 15 Jun 2023 22:26:28 GMT
Subject: RFR: JDK-8309964: Use directed inheritDoc for javax.lang.model API
Message-ID: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>

Update javax.lang.model and javax.annotation.processing to use directed inhertitDoc.

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

Commit messages:
 - Misc improvements.
 - Revert inadvertant change to JavaCompiler.
 - Merge branch 'master' into JDK-8309964
 - Update copyrights.
 - Merge branch 'master' into JDK-8309964
 - Checkpoint changes.
 - JDK-8309964: Use directed inheritDoc for javax.lang.model API
 - JDK-8306819: Consider disabling the compiler's default active annotation processing

Changes: https://git.openjdk.org/jdk/pull/14477/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14477&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309964
  Stats: 352 lines in 30 files changed: 73 ins; 5 del; 274 mod
  Patch: https://git.openjdk.org/jdk/pull/14477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14477/head:pull/14477

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

From darcy at openjdk.org  Thu Jun 15 22:26:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 15 Jun 2023 22:26:28 GMT
Subject: RFR: JDK-8309964: Use directed inheritDoc for javax.lang.model API
In-Reply-To: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
References: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
Message-ID: <TiBW11vShQuOuATpwu54yrX4WZdyGV7PXTmeZBj7DoY=.e3986845-1e98-4985-86d0-e964da8f430e@github.com>

On Wed, 14 Jun 2023 20:05:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update javax.lang.model and javax.annotation.processing to use directed inhertitDoc.

The bulk of this change is a refactoring of the inheritDoc tags to be better structured. The user-visible differences are detailed in the specdiff of the CSR; in summary:

-     Improvements to general spec vs implSpec for AbstractProcessor
-     Minor update to AbstractTypeVisitor8
-     Add explicit visitRecordComponent override to ElementScanner6; this changes where ElementScanner{7, 8, 9, 14} inherit the method from
-     SimpleTypeVisitor6 remove redundant text that was previous moved to an implSpec tag.

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

PR Comment: https://git.openjdk.org/jdk/pull/14477#issuecomment-1593798332

From darcy at openjdk.org  Thu Jun 15 22:31:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 15 Jun 2023 22:31:58 GMT
Subject: RFR: JDK-8309964: Use directed inheritDoc for javax.lang.model API
In-Reply-To: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
References: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
Message-ID: <RU_tEwth6VdNSyxRipCxTZIUG0VFuL0qS-89wJQ4XcA=.7a81b043-e042-449c-8fa8-02c1fd6f0f51@github.com>

On Wed, 14 Jun 2023 20:05:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update javax.lang.model and javax.annotation.processing to use directed inhertitDoc.

Possible follow-up work includes reviewing the `@return` tags in the visitor hierarchy to be less implSpec and more spec and, if I understand the functionality correctly, replacing the repeated paragraphs in the class-level docs in the visitor hierarchy with directed inheritance of implSpec/implNote, etc. to result in DRY-er documentation when reading the sources.

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

PR Comment: https://git.openjdk.org/jdk/pull/14477#issuecomment-1593803310

From darcy at openjdk.org  Thu Jun 15 22:44:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 15 Jun 2023 22:44:21 GMT
Subject: RFR: JDK-8309747: Update --release 21 symbol information for JDK 21
 build 27
Message-ID: <enbZszuJQJD7Y5CDAksWBq0AHDuin4-2mW7lqGo0oEE=.06f905fc-ea5b-45ec-b1fe-f0320b5f2be4@github.com>

Usual symbol file update in JDK 22 for the newest JDK 21 build.

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

Commit messages:
 - JDK-8309747: Update --release 21 symbol information for JDK 21 build 27

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

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

From iris at openjdk.org  Thu Jun 15 22:50:58 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 15 Jun 2023 22:50:58 GMT
Subject: RFR: JDK-8309747: Update --release 21 symbol information for JDK
 21 build 27
In-Reply-To: <enbZszuJQJD7Y5CDAksWBq0AHDuin4-2mW7lqGo0oEE=.06f905fc-ea5b-45ec-b1fe-f0320b5f2be4@github.com>
References: <enbZszuJQJD7Y5CDAksWBq0AHDuin4-2mW7lqGo0oEE=.06f905fc-ea5b-45ec-b1fe-f0320b5f2be4@github.com>
Message-ID: <xsEG-RyU7vLQenkaOEISZWvP9_sonoz0AswXeSSfKCs=.2698582b-dedc-429b-b9e4-805c4bb56abe@github.com>

On Thu, 15 Jun 2023 22:37:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual symbol file update in JDK 22 for the newest JDK 21 build.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14503#pullrequestreview-1482488685

From prappo at openjdk.org  Thu Jun 15 23:34:02 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Jun 2023 23:34:02 GMT
Subject: RFR: JDK-8309964: Use directed inheritDoc for javax.lang.model API
In-Reply-To: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
References: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
Message-ID: <FKKuPtupFmTVKcbO7KkDc-zcTV7cOhPoWowdf2imsKc=.c52715cb-32ea-4542-acb6-a4676bdb2411@github.com>

On Wed, 14 Jun 2023 20:05:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update javax.lang.model and javax.annotation.processing to use directed inheritDoc.

src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java line 121:

> 119:      * @return  {@inheritDoc ElementVisitor}
> 120:      * @throws UnknownElementException
> 121:      *          a visitor implementation may optionally throw this exception

If documenting that exception is intentional, I'd suggest DRY-ing that comment even more: 

@throws UnknownElementException {@inheritDoc ElementVisitor}

src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java line 152:

> 150:      * @param p  {@inheritDoc TypeVisitor}
> 151:      * @return a visitor-specified result
> 152:      * @throws UnknownTypeException

Similar comment about inheriting exception info.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14477#discussion_r1231621200
PR Review Comment: https://git.openjdk.org/jdk/pull/14477#discussion_r1231621876

From darcy at openjdk.org  Thu Jun 15 23:39:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 15 Jun 2023 23:39:06 GMT
Subject: Integrated: JDK-8309747: Update --release 21 symbol information for
 JDK 21 build 27
In-Reply-To: <enbZszuJQJD7Y5CDAksWBq0AHDuin4-2mW7lqGo0oEE=.06f905fc-ea5b-45ec-b1fe-f0320b5f2be4@github.com>
References: <enbZszuJQJD7Y5CDAksWBq0AHDuin4-2mW7lqGo0oEE=.06f905fc-ea5b-45ec-b1fe-f0320b5f2be4@github.com>
Message-ID: <GQXHXeacpl802uB3MKOHPx7hDu3pzWc1WeOGgKPfIIQ=.c3370fbf-c2fd-4d18-81eb-9d6a9f692dde@github.com>

On Thu, 15 Jun 2023 22:37:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual symbol file update in JDK 22 for the newest JDK 21 build.

This pull request has now been integrated.

Changeset: 353e581a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/353e581a53c5c16a8d8b824464d7ca4854d3422f
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8309747: Update --release 21 symbol information for JDK 21 build 27

Reviewed-by: iris

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

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

From darcy at openjdk.org  Thu Jun 15 23:48:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 15 Jun 2023 23:48:20 GMT
Subject: RFR: JDK-8309964: Use directed inheritDoc for javax.lang.model API
 [v2]
In-Reply-To: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
References: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
Message-ID: <xv8u1x9GytnEVNy2LCRUQC9brLDYoqi4DpgLAC7KSiM=.a633a4ea-19b9-4b80-9573-196e5fc4374a@github.com>

> Update javax.lang.model and javax.annotation.processing to use directed inheritDoc.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Implement review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14477/files
  - new: https://git.openjdk.org/jdk/pull/14477/files/c2377290..bde2d72b

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

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

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

From darcy at openjdk.org  Thu Jun 15 23:48:22 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 15 Jun 2023 23:48:22 GMT
Subject: RFR: JDK-8309964: Use directed inheritDoc for javax.lang.model API
 [v2]
In-Reply-To: <FKKuPtupFmTVKcbO7KkDc-zcTV7cOhPoWowdf2imsKc=.c52715cb-32ea-4542-acb6-a4676bdb2411@github.com>
References: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
 <FKKuPtupFmTVKcbO7KkDc-zcTV7cOhPoWowdf2imsKc=.c52715cb-32ea-4542-acb6-a4676bdb2411@github.com>
Message-ID: <z9P-EQHV_RVaLMhosYqnmb0nP-tEXOgJx9U_MNaT__s=.d8bde1f7-f2b4-4efb-9d34-441ea10fe07b@github.com>

On Thu, 15 Jun 2023 23:23:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement review feedback.
>
> src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java line 152:
> 
>> 150:      * @param p  {@inheritDoc TypeVisitor}
>> 151:      * @return a visitor-specified result
>> 152:      * @throws UnknownTypeException
> 
> Similar comment about inheriting exception info.

Good idea; I included the annotation value variant too -- I'll update the CSR for the change in annotation value visitor class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14477#discussion_r1231631419

From martin at openjdk.org  Fri Jun 16 04:39:17 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 16 Jun 2023 04:39:17 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <wvgrrZUkfRMQ3rNy7Uphe5-57WTk0A10EdPKbeGWOko=.f35bd62f-c094-4ec5-91f8-ae1ecff726ca@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
 <wvgrrZUkfRMQ3rNy7Uphe5-57WTk0A10EdPKbeGWOko=.f35bd62f-c094-4ec5-91f8-ae1ecff726ca@github.com>
Message-ID: <sxYo3C8Lkg2RLbg-NyOwCGOfqtA4Mud4i4ImQ8GNf1I=.a22a4573-4e06-4472-8e5b-3161bcb49d32@github.com>

On Wed, 14 Jun 2023 10:07:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1534:
>> 
>>> 1532: 
>>> 1533:     /**
>>> 1534:      * {@inheritDoc ConcurrentMap}
>> 
>> This clarifies the authors' intent, so is clear progress. 
>> 
>> Semantic difficulties remain:
>> - it would be nice to somehow declare that we never ever want to inherit doc from AbstractMap (or even at the module level, declare that AbstractFoo classes are specified only for subclass writers, not users).  Private inheritance?
>> - we never want to inherit AbstractFoo @implNotes
>> - ConcurrentMap does *not* have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should *not* be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.
>
>> * we never want to inherit AbstractFoo @implNotes
> 
> `@implNote`, `@apiNote` and `@implSpec` can only be inherited via explicit `{@inheritDoc}`:
> 
>     @implSpec {@inheritDoc}
> 
>> * ConcurrentMap does _not_ have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should _not_ be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.
> 
> That state of affairs predates this PR and is merely highlighted by it. Sadly, I'm not sure how JavaDoc can help here. Annotations, contracts, inspections, and doc tests come to mind; but none of these are supported by JavaDoc at the moment.

(There's nothing wrong with this PR)

Back in the 1980s there was a lot of optimism that OOP would be a big leap forward in software engineering.
But especially the "inheritance" part of OOP has been disappointing - unexpectedly brittle!
javadoc inheritance in collection classes was particularly interesting to me from this perspective.
Especially with the multiple inheritance that java was mostly reluctant to adopt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1231765877

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 abimpoudis at openjdk.org  Fri Jun 16 07:08:08 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 16 Jun 2023 07:08:08 GMT
Subject: Integrated: 8310128: Switch with unnamed patterns erroneously
 non-exhaustive
In-Reply-To: <H7f846SIbX5mTdJc3eTrd1TQWZt5Aot3AaMgXXfZ0R8=.36186255-a9e7-478a-b709-6363e30f6c99@github.com>
References: <H7f846SIbX5mTdJc3eTrd1TQWZt5Aot3AaMgXXfZ0R8=.36186255-a9e7-478a-b709-6363e30f6c99@github.com>
Message-ID: <FzW-5W6mIGZnSjCHzfAzavsemhGF6tLfKvXfYxngfSk=.7fbb01d1-f213-48a8-bf14-4767461a6ee6@github.com>

On Thu, 15 Jun 2023 10:23:42 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> When a record pattern has an unnamed pattern with the type of the corresponding record component being primitive, the switch is erroneously deemed as non-exhaustive. This PR addresses this issue by introducing the correct type for unnamed patterns during exhaustivity check.

This pull request has now been integrated.

Changeset: 32243ef4
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32243ef47df75241302e243b4fd9627d686437fe
Stats:     28 lines in 2 files changed: 25 ins; 2 del; 1 mod

8310128: Switch with unnamed patterns erroneously non-exhaustive

Reviewed-by: vromero, jlahoda

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

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

From abimpoudis at openjdk.org  Fri Jun 16 08:16:19 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 16 Jun 2023 08:16:19 GMT
Subject: RFR: 8310128: Switch with unnamed patterns erroneously non-exhaustive
Message-ID: <LPNUH9xnDppPiqNhSc_O0hARFZBwVnYgLiZAa5yAGac=.9f0069da-0782-4d60-ba9f-4a557474c106@github.com>

Hi all,

This pull request contains a backport of commit [32243ef4](https://github.com/openjdk/jdk/commit/32243ef47df75241302e243b4fd9627d686437fe) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Aggelos Biboudis on 16 Jun 2023 and was reviewed by Vicente Romero and Jan Lahoda.

Thanks!

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

Commit messages:
 - Backport 32243ef47df75241302e243b4fd9627d686437fe

Changes: https://git.openjdk.org/jdk21/pull/23/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=23&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310128
  Stats: 28 lines in 2 files changed: 25 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/23.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/23/head:pull/23

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

From jlahoda at openjdk.org  Fri Jun 16 08:36:58 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 Jun 2023 08:36:58 GMT
Subject: RFR: 8310128: Switch with unnamed patterns erroneously
 non-exhaustive
In-Reply-To: <LPNUH9xnDppPiqNhSc_O0hARFZBwVnYgLiZAa5yAGac=.9f0069da-0782-4d60-ba9f-4a557474c106@github.com>
References: <LPNUH9xnDppPiqNhSc_O0hARFZBwVnYgLiZAa5yAGac=.9f0069da-0782-4d60-ba9f-4a557474c106@github.com>
Message-ID: <VEVzk_vUXD4ZIucuNRSrQoUUU8GSnU5k2O945pI6mmQ=.d273f09f-d323-4501-9390-3eceab279e91@github.com>

On Fri, 16 Jun 2023 08:08:10 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [32243ef4](https://github.com/openjdk/jdk/commit/32243ef47df75241302e243b4fd9627d686437fe) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Aggelos Biboudis on 16 Jun 2023 and was reviewed by Vicente Romero and Jan Lahoda.
> 
> Thanks!

Marked as reviewed by jlahoda (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/23#pullrequestreview-1483000392

From abimpoudis at openjdk.org  Fri Jun 16 10:13:08 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 16 Jun 2023 10:13:08 GMT
Subject: Integrated: 8310128: Switch with unnamed patterns erroneously
 non-exhaustive
In-Reply-To: <LPNUH9xnDppPiqNhSc_O0hARFZBwVnYgLiZAa5yAGac=.9f0069da-0782-4d60-ba9f-4a557474c106@github.com>
References: <LPNUH9xnDppPiqNhSc_O0hARFZBwVnYgLiZAa5yAGac=.9f0069da-0782-4d60-ba9f-4a557474c106@github.com>
Message-ID: <x5VHd8kLL6tATGSXfR5QUec2lXTxCwbOxPjOh__Icbs=.a6b8fc31-8409-40ac-a6b7-f8ebf7c47d07@github.com>

On Fri, 16 Jun 2023 08:08:10 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [32243ef4](https://github.com/openjdk/jdk/commit/32243ef47df75241302e243b4fd9627d686437fe) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Aggelos Biboudis on 16 Jun 2023 and was reviewed by Vicente Romero and Jan Lahoda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: aced1144
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/aced11446ea0b80568bb1139a257927cc57af376
Stats:     28 lines in 2 files changed: 25 ins; 2 del; 1 mod

8310128: Switch with unnamed patterns erroneously non-exhaustive

Reviewed-by: jlahoda
Backport-of: 32243ef47df75241302e243b4fd9627d686437fe

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

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

From jlahoda at openjdk.org  Fri Jun 16 13:13:06 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 Jun 2023 13:13:06 GMT
Subject: RFR: 8302865: Illegal bytecode for break from if with instanceof
 pattern matching condition
Message-ID: <igomErQjESyBvaBcsL9-GdNaqZAGwzH5kTs9qk-fhHI=.70d43df1-00a6-41d8-a684-1178648d7e24@github.com>

Please see the CSR for the exact wording of the specification change:
https://bugs.openjdk.org/browse/JDK-8310016

There are two changes to flow scoping under this PR:

a) for code like:


X: if (!(o instanceof String s)) {
    break X;
}
System.err.println(s);


`s` won't be in the scope for `System.err.println` anymore (as that leads to an invalid bytecode anyway). I was experimenting with several possibilities to fix this, and the final proposal is (when we are about to add some bindings to the scope), look for an immediately enclosing labelled statement(s), and there's some, look for a break to this statement(s).

b) for code like:


X: {
         while (!(o instanceof String s)) {
             break X;
         }
         System.err.println(s);
}


javac implements a strict interpretation of the specification, which does not include `s` in the scope for the `System.err.println` (due to the `break` out of the `while`). The specification is clarified, so that only breaks to the loop are considered (together with breaks to the enclosing labelled statements), so flow scoping handling for loops is adjusted to only consider breaks to the loop.

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

Commit messages:
 - Fixing search for immediately enclosing labelled statements.
 - Fixing whitespaces.
 - 8302865: Illegal bytecode for break from if with instanceof pattern matching condition

Changes: https://git.openjdk.org/jdk/pull/14517/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14517&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302865
  Stats: 244 lines in 6 files changed: 176 ins; 49 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/14517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14517/head:pull/14517

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

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 vromero at openjdk.org  Fri Jun 16 15:25:02 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 16 Jun 2023 15:25:02 GMT
Subject: RFR: JDK-8309964: Use directed inheritDoc for javax.lang.model API
 [v2]
In-Reply-To: <xv8u1x9GytnEVNy2LCRUQC9brLDYoqi4DpgLAC7KSiM=.a633a4ea-19b9-4b80-9573-196e5fc4374a@github.com>
References: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
 <xv8u1x9GytnEVNy2LCRUQC9brLDYoqi4DpgLAC7KSiM=.a633a4ea-19b9-4b80-9573-196e5fc4374a@github.com>
Message-ID: <Kj52tEGHPSazpJFaXEQHCnneEqDO6zc2ojTTmroUlFk=.011f570d-f41f-46ca-90ee-8ee48f8a1ff6@github.com>

On Thu, 15 Jun 2023 23:48:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Update javax.lang.model and javax.annotation.processing to use directed inheritDoc.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14477#pullrequestreview-1483753837

From vromero at openjdk.org  Fri Jun 16 16:39:57 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 16 Jun 2023 16:39:57 GMT
Subject: RFR: 8302865: Illegal bytecode for break from if with instanceof
 pattern matching condition
In-Reply-To: <igomErQjESyBvaBcsL9-GdNaqZAGwzH5kTs9qk-fhHI=.70d43df1-00a6-41d8-a684-1178648d7e24@github.com>
References: <igomErQjESyBvaBcsL9-GdNaqZAGwzH5kTs9qk-fhHI=.70d43df1-00a6-41d8-a684-1178648d7e24@github.com>
Message-ID: <d8cB-Tbr-O5CCUcZOL3RnzaO1DwDxNLZfOtHvAWqsxQ=.92a81f7f-167e-4aaf-8303-eb7ea70c16ed@github.com>

On Fri, 16 Jun 2023 11:52:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Please see the CSR for the exact wording of the specification change:
> https://bugs.openjdk.org/browse/JDK-8310016
> 
> There are two changes to flow scoping under this PR:
> 
> a) for code like:
> 
> 
> X: if (!(o instanceof String s)) {
>     break X;
> }
> System.err.println(s);
> 
> 
> `s` won't be in the scope for `System.err.println` anymore (as that leads to an invalid bytecode anyway). I was experimenting with several possibilities to fix this, and the final proposal is (when we are about to add some bindings to the scope), look for an immediately enclosing labelled statement(s), and there's some, look for a break to this statement(s).
> 
> b) for code like:
> 
> 
> X: {
>          while (!(o instanceof String s)) {
>              break X;
>          }
>          System.err.println(s);
> }
> 
> 
> javac implements a strict interpretation of the specification, which does not include `s` in the scope for the `System.err.println` (due to the `break` out of the `while`). The specification is clarified, so that only breaks to the loop are considered (together with breaks to the enclosing labelled statements), so flow scoping handling for loops is adjusted to only consider breaks to the loop.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14517#pullrequestreview-1483926857

From darcy at openjdk.org  Fri Jun 16 16:46:12 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 16 Jun 2023 16:46:12 GMT
Subject: Integrated: JDK-8309964: Use directed inheritDoc for javax.lang.model
 API
In-Reply-To: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
References: <KwV_nE3GQt2NRuVu9pgk45s9vV4vWfShItbu7lXXWLA=.aa957850-aef1-494d-91fa-265cc95056aa@github.com>
Message-ID: <1dnzUKLu80_22BXmFNQAGDJ-8TmAAlgCYZeTfl0z1Ag=.980fec5e-12fe-4432-9887-1dc91e1f390d@github.com>

On Wed, 14 Jun 2023 20:05:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update javax.lang.model and javax.annotation.processing to use directed inheritDoc.

This pull request has now been integrated.

Changeset: cf8d0b05
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf8d0b05372838db345ff373950e71b7b3b76de7
Stats:     357 lines in 30 files changed: 74 ins; 7 del; 276 mod

8309964: Use directed inheritDoc for javax.lang.model API

Reviewed-by: vromero

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

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

From cushon at openjdk.org  Fri Jun 16 16:46:12 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 16 Jun 2023 16:46:12 GMT
Subject: Integrated: 8309499: javac fails to report compiler.err.no.java.lang
 with annotation processing enabled
In-Reply-To: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
References: <KrTimhuqRqnYCEwoAGXZpBdq0AZ-hXHHWqvCZIU2aR0=.b860f596-2513-4d7a-aa15-4f7c65a7ca24@github.com>
Message-ID: <hH7sM6htVQpuN0QW5pJ9ysRkwZum8IZdpbpWho34Pko=.fd895ae4-6f91-4b22-8fbf-54b8d19154d5@github.com>

On Wed, 7 Jun 2023 21:03:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi,
> 
> Please consider this fix for an error handling bug in javac, which causes a deferred diagnostic to be lost when an `Abort` is thrown with annotation processing enabled. See https://bugs.openjdk.org/browse/JDK-8309499 for more details.
> 
> This fix is contributed by my colleague Paula Toth paulatoth at google.com.

This pull request has now been integrated.

Changeset: 53abba3a
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53abba3a5acee3e4d776fe8a42a307b827fda54d
Stats:     131 lines in 2 files changed: 131 ins; 0 del; 0 mod

8309499: javac fails to report compiler.err.no.java.lang with annotation processing enabled

Co-authored-by: Paula Toth <paulatoth at google.com>
Reviewed-by: vromero

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

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

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 darcy at openjdk.org  Fri Jun 16 18:41:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 16 Jun 2023 18:41:36 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being used
Message-ID: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>

Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

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

Commit messages:
 - Copyright update.
 - Update tests and implementation.
 - Merge branch 'master' into JDK-8310061
 - JDK-8310061: Note if implicit annotation processing is being used

Changes: https://git.openjdk.org/jdk/pull/14499/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14499&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310061
  Stats: 35 lines in 7 files changed: 27 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14499/head:pull/14499

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

From briangoetz at openjdk.org  Fri Jun 16 18:41:36 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Fri, 16 Jun 2023 18:41:36 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used
In-Reply-To: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
Message-ID: <7PQLDpXqlDHPADZ-tRfco87q4x95iv8Q9zYObcj_o9I=.eb8ccc7d-82bf-48a5-a163-cb884a59aa59@github.com>

On Thu, 15 Jun 2023 18:16:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

New diagnostic messages look reasonable

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

PR Review: https://git.openjdk.org/jdk/pull/14499#pullrequestreview-1484093072

From darcy at openjdk.org  Fri Jun 16 18:48:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 16 Jun 2023 18:48:16 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used
In-Reply-To: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
Message-ID: <-OeHM41NKGGOoISIGiZfCFbzKEQLU5WAxt20PkFCm_Y=.3fc97ca8-5312-4a17-a8a7-2a1134fb27bc@github.com>

On Thu, 15 Jun 2023 18:16:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

The goal of the change in this PR is to emit a message to users who may be unknowingly relying on default implicit annotation processing that the long-standing default may be changing in a future release. The message is a Note rather than a Warning to avoid running afoul of build setups using configurations like "-Xlint:all -Werror".

Semantically, the note about implicit processors is treated as on by default. The note is *not* emitted if there are explicit configuration options related to annotation processing, including the new-in-JDK-21 "-proc:full". and not emitted if the "options" lint check is explicitly disabled, either through "-Xlint:-options" or "-Xlint:none".

A targeted regression test for the change to follow.

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

PR Comment: https://git.openjdk.org/jdk/pull/14499#issuecomment-1595135616

From alex.buckley at oracle.com  Fri Jun 16 19:20:21 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 16 Jun 2023 12:20:21 -0700
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used
In-Reply-To: <-OeHM41NKGGOoISIGiZfCFbzKEQLU5WAxt20PkFCm_Y=.3fc97ca8-5312-4a17-a8a7-2a1134fb27bc@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <-OeHM41NKGGOoISIGiZfCFbzKEQLU5WAxt20PkFCm_Y=.3fc97ca8-5312-4a17-a8a7-2a1134fb27bc@github.com>
Message-ID: <0c2b3dc7-f38e-669a-5e7e-cd3fa91e66c7@oracle.com>

On 6/16/2023 11:48 AM, Joe Darcy wrote:
> On Thu, 15 Jun 2023 18:16:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:
> 
>> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.
> 
> The goal of the change in this PR is to emit a message to users who may be unknowingly relying on default implicit annotation processing that the long-standing default may be changing in a future release. The message is a Note rather than a Warning to avoid running afoul of build setups using configurations like "-Xlint:all -Werror".

I looked at the man page -- 
https://download.java.net/java/early_access/jdk21/docs/specs/man/javac.html#how-annotation-processing-works 
-- to learn about javac's default search path for processors.

(`-proc:full` isn't mentioned, but maybe it's coming soon?)

The title of this mail is about "implicit annotation processing", that 
is, the fact that annotation processing is enabled by default ... but 
the focus of the new message is about a different kind of default, 
namely the default search path for locating annotation processors. I read:

   One or more annotation processors found under the default policy of
   searching the class path or module path for processors.

as saying:

   Let's try to be more specific about where javac should search for
   processors -- look at --processor-path or --processor-module-path

(The man page doesn't mention searching the module path for processors. 
It only searches the "user class path".)


Consider this text, which sidesteps "implicit" in favor of 
"enabled"/"disabled" to align with how the man page starts: "Unless 
annotation processing is disabled with the -proc:none option ..."

   Annotation processing is enabled, and one or more annotation
   processors were found. [Maybe -processorpath was specified, maybe it
   wasn't, but either way, something was found.]

   They will be called [the word from the man page] in this compilation,
   but a future release of javac may choose to disable annotation
   processing by default. It will then be necessary to enable annotation
   processing with `-proc:only` or `-proc:full`.

   Use -Xlint:-options to suppress this message.

Alex

From darcy at openjdk.org  Fri Jun 16 19:50:08 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 16 Jun 2023 19:50:08 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used
In-Reply-To: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
Message-ID: <jdJIRzeT17S5SujWGNszWA0N8r9Yni0Rop3feaUWnsg=.09538ff2-1cd1-4105-8943-9d0df6eb3f9e@github.com>

On Thu, 15 Jun 2023 18:16:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

PS To be clear, the goal is to get this change into JDK 22 and then backport it into JDK 21.

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

PR Comment: https://git.openjdk.org/jdk/pull/14499#issuecomment-1595206790

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 acobbs at openjdk.org  Fri Jun 16 22:52:13 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 16 Jun 2023 22:52:13 GMT
Subject: Integrated: 8309511: Regression test ExtraImportSemicolon.java refers
 to the wrong bug
In-Reply-To: <q0klSK94ZawvuTwY9MyS7q4eFTnpY81zcF66yFFFDBo=.4e4ee534-24ce-421f-a706-22e64c247213@github.com>
References: <q0klSK94ZawvuTwY9MyS7q4eFTnpY81zcF66yFFFDBo=.4e4ee534-24ce-421f-a706-22e64c247213@github.com>
Message-ID: <anaYTiro57zQFk-B2lonbCQ8CgPHzza6JQkEPthFxR4=.3eed648d-81a0-4329-953b-772297b6ac3a@github.com>

On Tue, 6 Jun 2023 01:52:34 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this trivial fix for an incorrect `@bug` reference in `ExtraImportSemicolon.java`.

This pull request has now been integrated.

Changeset: bcc4d368
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bcc4d36857b0907e865d0afc4447f9b0780f8101
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8309511: Regression test ExtraImportSemicolon.java refers to the wrong bug

Reviewed-by: vromero

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

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

From joe.darcy at oracle.com  Sat Jun 17 01:49:12 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 16 Jun 2023 18:49:12 -0700
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used
In-Reply-To: <0c2b3dc7-f38e-669a-5e7e-cd3fa91e66c7@oracle.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <-OeHM41NKGGOoISIGiZfCFbzKEQLU5WAxt20PkFCm_Y=.3fc97ca8-5312-4a17-a8a7-2a1134fb27bc@github.com>
 <0c2b3dc7-f38e-669a-5e7e-cd3fa91e66c7@oracle.com>
Message-ID: <d175b041-2206-d581-f554-1000d89869be@oracle.com>

On 6/16/2023 12:20 PM, Alex Buckley wrote:
> On 6/16/2023 11:48 AM, Joe Darcy wrote:
>> On Thu, 15 Jun 2023 18:16:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>>
>>> Emit a note warning of the possibility of changing the implicit 
>>> running of annotation processors in a future release.
>>
>> The goal of the change in this PR is to emit a message to users who 
>> may be unknowingly relying on default implicit annotation processing 
>> that the long-standing default may be changing in a future release. 
>> The message is a Note rather than a Warning to avoid running afoul of 
>> build setups using configurations like "-Xlint:all -Werror".
>
> I looked at the man page -- 
> https://download.java.net/java/early_access/jdk21/docs/specs/man/javac.html#how-annotation-processing-works 
> -- to learn about javac's default search path for processors.
>
> (`-proc:full` isn't mentioned, but maybe it's coming soon?)


Getting -proc:full in the man page is being addressed under JDK-8308456.


>
> The title of this mail is about "implicit annotation processing", that 
> is, the fact that annotation processing is enabled by default ... but 
> the focus of the new message is about a different kind of default, 
> namely the default search path for locating annotation processors. I 
> read:
>
> ? One or more annotation processors found under the default policy of
> ? searching the class path or module path for processors.
>
> as saying:
>
> ? Let's try to be more specific about where javac should search for
> ? processors -- look at --processor-path or --processor-module-path
>
> (The man page doesn't mention searching the module path for 
> processors. It only searches the "user class path".)


My mistake; I verified the implementation does not look for annotation 
processors on the --module-path, just on --processor-module-path. I'll 
update the note accordingly.


>
>
> Consider this text, which sidesteps "implicit" in favor of 
> "enabled"/"disabled" to align with how the man page starts: "Unless 
> annotation processing is disabled with the -proc:none option ..."
>
> ? Annotation processing is enabled, and one or more annotation
> ? processors were found. [Maybe -processorpath was specified, maybe it
> ? wasn't, but either way, something was found.]


To give more context around the situations where the note appears and 
the motivation behind it. Using a command line like

 ??? $ javac --class-path JarFileWithAnnotationProcessor.java Foo.java

will look for and find the annotation processor inside 
JarFileWithAnnotationProcessor and run it per the process outlined in 
the man page, etc. There are no strictly annotation processing related 
configuration options in this situation; these are the sort of implicit 
cases where the warning note will be reported under this PR.

In contrast, none of these other command lines would generate a note:

 ??? $ javac --processor-path JarFileWithAnnotationProcessor.java Foo.java
 ??? $ javac --class-path???? JarFileWithAnnotationProcessor.java 
-processor NameOfProcessorInJarFile Foo.java
 ??? $ javac --class-path???? JarFileWithAnnotationProcessor.java 
-proc:full????????????????????????? Foo.java

 ??? $ javac --class-path JarFileWithAnnotationProcessor.java 
-Xlint:-options Foo.java
 ??? $ javac --class-path JarFileWithAnnotationProcessor.java 
-Xlint:none???? Foo.java

The first three have explicit annotation processor related configuration 
optoins, hence opting-in to annotation processing, and the last two 
explicitly disable warnings related to option handling.

Thanks,

-Joe


>
> ? They will be called [the word from the man page] in this compilation,
> ? but a future release of javac may choose to disable annotation
> ? processing by default. It will then be necessary to enable annotation
> ? processing with `-proc:only` or `-proc:full`.
>
> ? Use -Xlint:-options to suppress this message.
>
> Alex

From alex.buckley at oracle.com  Sat Jun 17 02:32:44 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 16 Jun 2023 19:32:44 -0700
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used
In-Reply-To: <d175b041-2206-d581-f554-1000d89869be@oracle.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <-OeHM41NKGGOoISIGiZfCFbzKEQLU5WAxt20PkFCm_Y=.3fc97ca8-5312-4a17-a8a7-2a1134fb27bc@github.com>
 <0c2b3dc7-f38e-669a-5e7e-cd3fa91e66c7@oracle.com>
 <d175b041-2206-d581-f554-1000d89869be@oracle.com>
Message-ID: <0ace961f-c9c9-3afe-5eb4-40c3064e6633@oracle.com>

On 6/16/2023 6:49 PM, Joseph D. Darcy wrote:
> To give more context around the situations where the note appears and 
> the motivation behind it. Using a command line like
> 
>  ??? $ javac --class-path JarFileWithAnnotationProcessor.java Foo.java
> 
> will look for and find the annotation processor inside 
> JarFileWithAnnotationProcessor and run it per the process outlined in 
> the man page, etc. There are no strictly annotation processing related 
> configuration options in this situation; these are the sort of implicit 
> cases where the warning note will be reported under this PR.
> 
> In contrast, none of these other command lines would generate a note:
> 
>  ??? $ javac --processor-path JarFileWithAnnotationProcessor.java Foo.java
>  ??? $ javac --class-path???? JarFileWithAnnotationProcessor.java 
> -processor NameOfProcessorInJarFile Foo.java
>  ??? $ javac --class-path???? JarFileWithAnnotationProcessor.java 
> -proc:full????????????????????????? Foo.jav
A new suggestion:

   Annotation processing is enabled because one or more processors
   were found on the class path. A future release of javac may disable
   annotation processing unless at least one processor is specified by
   name (`-processor`), or a search path is specified
   (`--processor-path`, `--processor-module-path`), or annotation
   processing is enabled explicitly (`-proc:only`, `-proc:full`).
   Use -Xlint:-options to suppress this message.

Alex

From jwaters at openjdk.org  Sat Jun 17 04:25:20 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 17 Jun 2023 04:25:20 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <Kqarur3gMF803Fju6IqgblO9C8BlpED-wXRwHtN-ew0=.9355bde6-c320-4c55-914f-19dcc541c5d3@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Bumping again...

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1595613231

From jlahoda at openjdk.org  Mon Jun 19 15:59:27 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 Jun 2023 15:59:27 GMT
Subject: RFR: 8310314: Misplaced
 "unnamed classes are a preview feature and are disabled by default" error
Message-ID: <9ORpte5XzOtkw6ECOqm3dFvdYAA2Bh5ZSaqC30WkBwg=.25d240d6-f392-4df2-bb7e-9947b6a0ab20@github.com>

Consider code like:

$ cat Test.java
void main() {
    System.err.println("Hello!");
}


Currently, the "unnamed classes are a preview feature and are disabled by default" error is put at the end of the file:

$ java Test.java
Test.java:4: error: unnamed classes are a preview feature and are disabled by default.

  (use --enable-preview to enable unnamed classes)
1 error
error: compilation failed


This does not seem to be user friendly. It seems to me that putting the error on the first method/variable in the file would be better:

$ java Test.java
Test.java:1: error: unnamed classes are a preview feature and are disabled by default.
void main() {
^
  (use --enable-preview to enable unnamed classes)
1 error
error: compilation failed


The proposed patch is to simply move the source level check to the place where the top-level method or field is parsed. Calling the method multiple times for a single file should not be a problem - `Log` itself will prevent printing the error multiple times for the same file.

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

Commit messages:
 - Improving test metadata
 - Enhancing test.
 - 8310314: Misplaces "unnamed classes are a preview feature and are disabled by default" error

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

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

From jlaskey at openjdk.org  Mon Jun 19 16:12:47 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 19 Jun 2023 16:12:47 GMT
Subject: RFR: 8310314: Misplaced
 "unnamed classes are a preview feature and are disabled by default" error
In-Reply-To: <9ORpte5XzOtkw6ECOqm3dFvdYAA2Bh5ZSaqC30WkBwg=.25d240d6-f392-4df2-bb7e-9947b6a0ab20@github.com>
References: <9ORpte5XzOtkw6ECOqm3dFvdYAA2Bh5ZSaqC30WkBwg=.25d240d6-f392-4df2-bb7e-9947b6a0ab20@github.com>
Message-ID: <RJ5VFbSYrcvzfFWkGvbQsjq2AD5HMQ748KR9n4HMQ7Q=.5d4a25cd-b8ae-43bd-ba5d-5b5e622a29b4@github.com>

On Mon, 19 Jun 2023 15:51:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> $ cat Test.java
> void main() {
>     System.err.println("Hello!");
> }
> 
> 
> Currently, the "unnamed classes are a preview feature and are disabled by default" error is put at the end of the file:
> 
> $ java Test.java
> Test.java:4: error: unnamed classes are a preview feature and are disabled by default.
> 
>   (use --enable-preview to enable unnamed classes)
> 1 error
> error: compilation failed
> 
> 
> This does not seem to be user friendly. It seems to me that putting the error on the first method/variable in the file would be better:
> 
> $ java Test.java
> Test.java:1: error: unnamed classes are a preview feature and are disabled by default.
> void main() {
> ^
>   (use --enable-preview to enable unnamed classes)
> 1 error
> error: compilation failed
> 
> 
> The proposed patch is to simply move the source level check to the place where the top-level method or field is parsed. Calling the method multiple times for a single file should not be a problem - `Log` itself will prevent printing the error multiple times for the same file.

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14544#pullrequestreview-1486532652

From maurizio.cimadamore at oracle.com  Mon Jun 19 17:49:27 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 19 Jun 2023 18:49:27 +0100
Subject: javac's allparams(): returns type arguments, yes?
In-Reply-To: <CAHNdxukxm7bLngUTjrDcC-niP3kj98ag2gbY4X4aQkuBuYvRWg@mail.gmail.com>
References: <CAHNdxukxm7bLngUTjrDcC-niP3kj98ag2gbY4X4aQkuBuYvRWg@mail.gmail.com>
Message-ID: <5ff40d2d-71b6-640b-f04b-8a42567e7382@oracle.com>

Hi,
the naming of these methods is unfortunate, and has been like that for a 
very long time (historical reasons lost in time). Remember that the core 
of the javac implementation is based on a compiler that was written 
before JLS 5.0 was finalized, so some of the terminology was still in 
flux, which resulted in some of the methods not having the "correct" 
name (as per JLS).

You are correct in pointing out that both `allparams` and 
`getTypeArguments` are really about "type arguments" (use site).

The only difference is that the former only returns the type arguments 
of the generic class type (or generic method) it is called on, whereas 
the latter will recurse up to the outermost generic type (and return 
_all_ the type arguments - this is useful e.g. when performing type 
susbtitution).

In this vein, the "typarams_field" name is also obviously wrong, and it 
is really a "type argument cache".

P.S.
We will gladly accept PRs which rectify the status quo (given we just 
forked 22 from 21, now it would be a good time for such sweeping changes 
too) :-)

Cheers
Maurizio


On 13/06/2023 18:01, Laird Nelson wrote:
> I am reading some javac code to satisfy some curiosity and wanted to 
> quickly confirm something.
>
> I noticed that the com.sun.tools.javac.code.Type#allparams() method 
> actually operates on type *arguments*, correct, despite its name 
> implying (to me, used to the Java language model terminology) otherwise?
>
> So in the case of a type representing Outer<String>.Inner<Number>, 
> allparams(innerType) would presumably return the String and Number 
> type *arguments*, and not the formal type parameter elements (S and N 
> or whatever) corresponding to them?
>
> Related: the getTypeArguments() method works on a field called 
> typarams_field; I'm assuming again that the typarams_field field 
> stores type *arguments*, not formal type parameter elements?
>
> L

From jlahoda at openjdk.org  Mon Jun 19 19:08:43 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 Jun 2023 19:08:43 GMT
Subject: RFR: 8310326: Incorrect position of the synthetic unnamed class
Message-ID: <UkVNgVr5xBsmyvHoCA1zOsVtvd2zkQA0gsVJEa52z28=.d43d3806-02bc-4ff1-bff4-7d27c47739fb@github.com>

Considering code like:

void main() {
}


The method is wrapped in a synthetic class. But, for, this class:
 - `SourcePositions.getStartPosition` returns `5`, while `0` would be better (the reason is the the "name"/"preferred" position from the first member is used, not the starting position for the first member)
 - has (synthetic) empty modifiers with starting position `5`, while normally empty modifiers have starting pos `-1`, e.g.:
https://github.com/openjdk/jdk/blob/33c6ec9d4eb36649a94125aa005dc6b961dcd2c1/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L3525

This patch proposes to:
 - use the starting position of the first member as the position of the class
 - use `-1` as the position for the empty synthetic modifiers of the class

End positions for neither of these is not set, and continues not to be set, and hence `getEndPosition` returns `-1`. That is (AFAIK) the common behavior for synthetic trees.

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

Commit messages:
 - 8310326: Incorrect position of the synthetic unnamed class

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

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

From jlaskey at openjdk.org  Mon Jun 19 19:43:02 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 19 Jun 2023 19:43:02 GMT
Subject: RFR: 8310326: Incorrect position of the synthetic unnamed class
In-Reply-To: <UkVNgVr5xBsmyvHoCA1zOsVtvd2zkQA0gsVJEa52z28=.d43d3806-02bc-4ff1-bff4-7d27c47739fb@github.com>
References: <UkVNgVr5xBsmyvHoCA1zOsVtvd2zkQA0gsVJEa52z28=.d43d3806-02bc-4ff1-bff4-7d27c47739fb@github.com>
Message-ID: <Tsh_a2hkOPmgG7h2B1PDo0Hqu5dYCRIxBQ18HPCTUjU=.ae3836e5-101c-4853-a73c-30e17ecbfb6d@github.com>

On Mon, 19 Jun 2023 19:01:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> void main() {
> }
> 
> 
> The method is wrapped in a synthetic class. But, for, this class:
>  - `SourcePositions.getStartPosition` returns `5`, while `0` would be better (the reason is the the "name"/"preferred" position from the first member is used, not the starting position for the first member)
>  - has (synthetic) empty modifiers with starting position `5`, while normally empty modifiers have starting pos `-1`, e.g.:
> https://github.com/openjdk/jdk/blob/33c6ec9d4eb36649a94125aa005dc6b961dcd2c1/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L3525
> 
> This patch proposes to:
>  - use the starting position of the first member as the position of the class
>  - use `-1` as the position for the empty synthetic modifiers of the class
> 
> End positions for neither of these is not set, and continues not to be set, and hence `getEndPosition` returns `-1`. That is (AFAIK) the common behavior for synthetic trees.

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14548#pullrequestreview-1486827167

From ljnelson at gmail.com  Mon Jun 19 21:51:00 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Mon, 19 Jun 2023 14:51:00 -0700
Subject: javac's allparams(): returns type arguments, yes?
In-Reply-To: <5ff40d2d-71b6-640b-f04b-8a42567e7382@oracle.com>
References: <CAHNdxukxm7bLngUTjrDcC-niP3kj98ag2gbY4X4aQkuBuYvRWg@mail.gmail.com>
 <5ff40d2d-71b6-640b-f04b-8a42567e7382@oracle.com>
Message-ID: <CAHNdxun7R4wGTFbUPGSVWhRoP4_Y446JSRhUmHQ2SATN8t=-Ng@mail.gmail.com>

On Mon, Jun 19, 2023 at 10:49?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> the naming of these methods is unfortunate
>

Sure; no judgment on my part. Just seeking clarification.


> You are correct in pointing out that both `allparams` and
> `getTypeArguments` are really about "type arguments" (use site).
>
> The only difference is that the former only returns the type arguments
> of the generic class type (or generic method) it is called on, whereas
> the latter will recurse up to the outermost generic type (and return
> _all_ the type arguments - this is useful e.g. when performing type
> susbtitution).
>

(I think you have "former" and "latter" confused here? allparams "will
recurse up to the outermost generic type?", yes? And "getTypeArguments"
"returns the type arguments of the generic class type?it is called on"?
Anyway, thank you for the clarification.)

L
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230619/33ef4297/attachment.htm>

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 maurizio.cimadamore at oracle.com  Mon Jun 19 22:47:15 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 19 Jun 2023 23:47:15 +0100
Subject: javac's allparams(): returns type arguments, yes?
In-Reply-To: <CAHNdxun7R4wGTFbUPGSVWhRoP4_Y446JSRhUmHQ2SATN8t=-Ng@mail.gmail.com>
References: <CAHNdxukxm7bLngUTjrDcC-niP3kj98ag2gbY4X4aQkuBuYvRWg@mail.gmail.com>
 <5ff40d2d-71b6-640b-f04b-8a42567e7382@oracle.com>
 <CAHNdxun7R4wGTFbUPGSVWhRoP4_Y446JSRhUmHQ2SATN8t=-Ng@mail.gmail.com>
Message-ID: <b9dcc242-1ff4-a87d-63c0-c9afd3898254@oracle.com>


>
> (I think you have "former" and "latter" confused here? allparams "will 
> recurse up to the outermost generic type?", yes? And 
> "getTypeArguments" "returns the type arguments of the generic class 
> type?it is called on"?

Yes!

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230619/456774e4/attachment-0001.htm>

From jlahoda at openjdk.org  Tue Jun 20 07:06:34 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Jun 2023 07:06:34 GMT
Subject: Integrated: 8310314: Misplaced
 "unnamed classes are a preview feature and are disabled by default" error
In-Reply-To: <9ORpte5XzOtkw6ECOqm3dFvdYAA2Bh5ZSaqC30WkBwg=.25d240d6-f392-4df2-bb7e-9947b6a0ab20@github.com>
References: <9ORpte5XzOtkw6ECOqm3dFvdYAA2Bh5ZSaqC30WkBwg=.25d240d6-f392-4df2-bb7e-9947b6a0ab20@github.com>
Message-ID: <kDyEnD7X9t6Ct_UiNmX6PHx-VmHmIzag2dAeKfK8hNY=.f2f131ce-4568-49c1-85b6-92eeb73317b3@github.com>

On Mon, 19 Jun 2023 15:51:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> $ cat Test.java
> void main() {
>     System.err.println("Hello!");
> }
> 
> 
> Currently, the "unnamed classes are a preview feature and are disabled by default" error is put at the end of the file:
> 
> $ java Test.java
> Test.java:4: error: unnamed classes are a preview feature and are disabled by default.
> 
>   (use --enable-preview to enable unnamed classes)
> 1 error
> error: compilation failed
> 
> 
> This does not seem to be user friendly. It seems to me that putting the error on the first method/variable in the file would be better:
> 
> $ java Test.java
> Test.java:1: error: unnamed classes are a preview feature and are disabled by default.
> void main() {
> ^
>   (use --enable-preview to enable unnamed classes)
> 1 error
> error: compilation failed
> 
> 
> The proposed patch is to simply move the source level check to the place where the top-level method or field is parsed. Calling the method multiple times for a single file should not be a problem - `Log` itself will prevent printing the error multiple times for the same file.

This pull request has now been integrated.

Changeset: 79069c5e
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79069c5e748a274c45dec72aad082c31eff418d1
Stats:     18 lines in 3 files changed: 16 ins; 2 del; 0 mod

8310314: Misplaced "unnamed classes are a preview feature and are disabled by default" error

Reviewed-by: jlaskey

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

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

From jwaters at openjdk.org  Tue Jun 20 07:15:04 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Jun 2023 07:15:04 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <lIQVaH459GtVVtPncY-OfSZk15acodSpwnp_LlsIi2E=.651dd416-3f6a-4fb6-a573-2cfaebc8f4b2@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Bumping...

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1598234922

From jlahoda at openjdk.org  Tue Jun 20 09:35:17 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Jun 2023 09:35:17 GMT
Subject: [jdk21] RFR: 8310314: Misplaced
 "unnamed classes are a preview feature and are disabled by default" error
Message-ID: <_lB2z2UPWvHzb8mZGS1qJx_fkh7D9r_RKHzCAT2bWRA=.65abfba2-31ee-45e3-bbb8-fa5d13c30163@github.com>

Hi all,

This pull request contains a backport of commit [79069c5e](https://github.com/openjdk/jdk/commit/79069c5e748a274c45dec72aad082c31eff418d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 20 Jun 2023 and was reviewed by Jim Laskey.

Thanks!

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

Commit messages:
 - Backport 79069c5e748a274c45dec72aad082c31eff418d1

Changes: https://git.openjdk.org/jdk21/pull/36/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=36&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310314
  Stats: 18 lines in 3 files changed: 16 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/36.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/36/head:pull/36

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

From jlaskey at openjdk.org  Tue Jun 20 09:43:09 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 20 Jun 2023 09:43:09 GMT
Subject: [jdk21] RFR: 8310314: Misplaced
 "unnamed classes are a preview feature and are disabled by default" error
In-Reply-To: <_lB2z2UPWvHzb8mZGS1qJx_fkh7D9r_RKHzCAT2bWRA=.65abfba2-31ee-45e3-bbb8-fa5d13c30163@github.com>
References: <_lB2z2UPWvHzb8mZGS1qJx_fkh7D9r_RKHzCAT2bWRA=.65abfba2-31ee-45e3-bbb8-fa5d13c30163@github.com>
Message-ID: <TRj6vD3uHGRoE3u3AgYXy84ZFg93GVObaLMOHm8ahno=.3bbc231c-568a-45ee-8488-9c0b5368b133@github.com>

On Tue, 20 Jun 2023 09:29:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [79069c5e](https://github.com/openjdk/jdk/commit/79069c5e748a274c45dec72aad082c31eff418d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 20 Jun 2023 and was reviewed by Jim Laskey.
> 
> Thanks!

Marked as reviewed by jlaskey (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/36#pullrequestreview-1487739507

From jlahoda at openjdk.org  Tue Jun 20 10:37:12 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Jun 2023 10:37:12 GMT
Subject: [jdk21] Integrated: 8310314: Misplaced
 "unnamed classes are a preview feature and are disabled by default" error
In-Reply-To: <_lB2z2UPWvHzb8mZGS1qJx_fkh7D9r_RKHzCAT2bWRA=.65abfba2-31ee-45e3-bbb8-fa5d13c30163@github.com>
References: <_lB2z2UPWvHzb8mZGS1qJx_fkh7D9r_RKHzCAT2bWRA=.65abfba2-31ee-45e3-bbb8-fa5d13c30163@github.com>
Message-ID: <BScE9-mmva7pO58pxOKAjrdYg38aRBG_ei7QtuKZFuU=.d177928c-9b18-4f8d-9f32-70e69673661c@github.com>

On Tue, 20 Jun 2023 09:29:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [79069c5e](https://github.com/openjdk/jdk/commit/79069c5e748a274c45dec72aad082c31eff418d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 20 Jun 2023 and was reviewed by Jim Laskey.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ede16cd1
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/ede16cd19ece6e4fec9aaf4b1c7e39d14ff28b1d
Stats:     18 lines in 3 files changed: 16 ins; 2 del; 0 mod

8310314: Misplaced "unnamed classes are a preview feature and are disabled by default" error

Reviewed-by: jlaskey
Backport-of: 79069c5e748a274c45dec72aad082c31eff418d1

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

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

From jlahoda at openjdk.org  Tue Jun 20 10:38:11 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Jun 2023 10:38:11 GMT
Subject: Integrated: 8310326: Incorrect position of the synthetic unnamed class
In-Reply-To: <UkVNgVr5xBsmyvHoCA1zOsVtvd2zkQA0gsVJEa52z28=.d43d3806-02bc-4ff1-bff4-7d27c47739fb@github.com>
References: <UkVNgVr5xBsmyvHoCA1zOsVtvd2zkQA0gsVJEa52z28=.d43d3806-02bc-4ff1-bff4-7d27c47739fb@github.com>
Message-ID: <Va7fJeid9StNgtSL1-AYtUw3a5IeTrYJukkvGYF-JSI=.a6c052e2-f4b8-47da-bfac-66f226564871@github.com>

On Mon, 19 Jun 2023 19:01:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> void main() {
> }
> 
> 
> The method is wrapped in a synthetic class. But, for, this class:
>  - `SourcePositions.getStartPosition` returns `5`, while `0` would be better (the reason is the the "name"/"preferred" position from the first member is used, not the starting position for the first member)
>  - has (synthetic) empty modifiers with starting position `5`, while normally empty modifiers have starting pos `-1`, e.g.:
> https://github.com/openjdk/jdk/blob/33c6ec9d4eb36649a94125aa005dc6b961dcd2c1/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L3525
> 
> This patch proposes to:
>  - use the starting position of the first member as the position of the class
>  - use `-1` as the position for the empty synthetic modifiers of the class
> 
> End positions for neither of these is not set, and continues not to be set, and hence `getEndPosition` returns `-1`. That is (AFAIK) the common behavior for synthetic trees.

This pull request has now been integrated.

Changeset: 4ca548fe
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ca548fe74419dc9e110489e3d2d3adf695ef37f
Stats:     28 lines in 2 files changed: 25 ins; 0 del; 3 mod

8310326: Incorrect position of the synthetic unnamed class

Reviewed-by: jlaskey

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

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

From vromero at openjdk.org  Tue Jun 20 17:56:04 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 20 Jun 2023 17:56:04 GMT
Subject: RFR: 8310133: Effectivelly final condition not enforced in guards
 for binding variables from the same case
In-Reply-To: <vqB9pzieRa4_1mhYPP-xJTQeAS8E8XA3XUJgsZO6qis=.3fb5d9ca-d335-4a92-9e0b-69688f9e35c5@github.com>
References: <vqB9pzieRa4_1mhYPP-xJTQeAS8E8XA3XUJgsZO6qis=.3fb5d9ca-d335-4a92-9e0b-69688f9e35c5@github.com>
Message-ID: <RrCvtYJ7dDuVdgmqJD3PQHHPQrbj6Mk7SNG7cufrq3M=.b3861d5c-ed94-4007-93e1-ebd07a9b0ea5@github.com>

On Thu, 15 Jun 2023 16:21:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code containing snippet like:
> 
> ...
> case String s when s.isEmpty() -> {
> s = null;
> }
> ...
> 
> 
> The `s` binding variable is obviously not effectively final, but the specification currently requires variables used inside the guard to be effectively final or final.
> 
> The cause here is in a position check - for error reporting we need to sent a shared variable `currentTree` to the case, but the effectively final check will only check variables declared before the start of `currentTree` (to avoid reporting issues for variables inside a lambda, for example). The proposed fix is to keep the case inside `currentTree`, but ensure the guard's starting position is used, to allow a proper effectively final check.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14498#pullrequestreview-1488702242

From mchung at openjdk.org  Tue Jun 20 18:51:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Jun 2023 18:51:07 GMT
Subject: RFR: JDK-8310460: Remove jdeps -profile option
Message-ID: <-hGihw2JlEDwi4hTfaBKKkkZlJvWzMedJO9sKaFC1WE=.117cbc2d-fa8c-4f99-8e68-974854514c7d@github.com>

Compact profiles are defined in Java SE 8 and are legacy in Java SE 9. jdeps -profile option was deprecated for removal in JDK 21. This option can be removed in JDK 22. Customers can use jdeps to find the set of modules required by their applications instead.

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

Commit messages:
 - JDK-8310460: Remove jdeps -profile option

Changes: https://git.openjdk.org/jdk/pull/14570/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310460
  Stats: 376 lines in 9 files changed: 0 ins; 329 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/14570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14570/head:pull/14570

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

From jwaters at openjdk.org  Wed Jun 21 06:39:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 06:39:05 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <VsG9XGwrOEbiKEEGddWKF0fmxbG-NbV3vgmlm5zrow0=.b7accea5-3a50-47b9-9a45-93ebb0874bcf@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
 <VsG9XGwrOEbiKEEGddWKF0fmxbG-NbV3vgmlm5zrow0=.b7accea5-3a50-47b9-9a45-93ebb0874bcf@github.com>
Message-ID: <1cDaGU9yZaVB3pV154vRgWYxh8W40q9nIQVbVJRy2W0=.9c24e882-fba7-4045-a99a-949341e50b7b@github.com>

On Mon, 5 Jun 2023 17:14:45 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)
>
> A conservative solution would be to change the default but provide a mechanism like a hidden option to restore the old behavior in case anyone needs it.
> 
> The current behavior is not specified (but that's a different bug!) so a CSR should not be necessary, but in that case, I would advise a [Release Note](https://openjdk.org/guide/#release-notes).

@jonathan-gibbons ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1600264833

From jlahoda at openjdk.org  Wed Jun 21 09:19:15 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 Jun 2023 09:19:15 GMT
Subject: Integrated: 8310133: Effectivelly final condition not enforced in
 guards for binding variables from the same case
In-Reply-To: <vqB9pzieRa4_1mhYPP-xJTQeAS8E8XA3XUJgsZO6qis=.3fb5d9ca-d335-4a92-9e0b-69688f9e35c5@github.com>
References: <vqB9pzieRa4_1mhYPP-xJTQeAS8E8XA3XUJgsZO6qis=.3fb5d9ca-d335-4a92-9e0b-69688f9e35c5@github.com>
Message-ID: <RVB56KCZUyqX9F00fv8NUN0Cbsc6xK8KPZC4N8ywIy8=.c12e82e9-04e2-473d-9d1d-99c816d36dd5@github.com>

On Thu, 15 Jun 2023 16:21:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code containing snippet like:
> 
> ...
> case String s when s.isEmpty() -> {
> s = null;
> }
> ...
> 
> 
> The `s` binding variable is obviously not effectively final, but the specification currently requires variables used inside the guard to be effectively final or final.
> 
> The cause here is in a position check - for error reporting we need to sent a shared variable `currentTree` to the case, but the effectively final check will only check variables declared before the start of `currentTree` (to avoid reporting issues for variables inside a lambda, for example). The proposed fix is to keep the case inside `currentTree`, but ensure the guard's starting position is used, to allow a proper effectively final check.

This pull request has now been integrated.

Changeset: 01623f6a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01623f6a5724d3eb250c48656be0aaf28df11750
Stats:     13 lines in 3 files changed: 9 ins; 0 del; 4 mod

8310133: Effectivelly final condition not enforced in guards for binding variables from the same case

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Wed Jun 21 09:19:15 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 Jun 2023 09:19:15 GMT
Subject: Integrated: 8302865: Illegal bytecode for break from if with
 instanceof pattern matching condition
In-Reply-To: <igomErQjESyBvaBcsL9-GdNaqZAGwzH5kTs9qk-fhHI=.70d43df1-00a6-41d8-a684-1178648d7e24@github.com>
References: <igomErQjESyBvaBcsL9-GdNaqZAGwzH5kTs9qk-fhHI=.70d43df1-00a6-41d8-a684-1178648d7e24@github.com>
Message-ID: <SFDe8-QSAXKYDrSFzRT-IIOhtCQKko3aTRxYrB82hSc=.ec05b163-4ec6-4e95-bb91-b1e3c0d7ee17@github.com>

On Fri, 16 Jun 2023 11:52:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Please see the CSR for the exact wording of the specification change:
> https://bugs.openjdk.org/browse/JDK-8310016
> 
> There are two changes to flow scoping under this PR:
> 
> a) for code like:
> 
> 
> X: if (!(o instanceof String s)) {
>     break X;
> }
> System.err.println(s);
> 
> 
> `s` won't be in the scope for `System.err.println` anymore (as that leads to an invalid bytecode anyway). I was experimenting with several possibilities to fix this, and the final proposal is (when we are about to add some bindings to the scope), look for an immediately enclosing labelled statement(s), and there's some, look for a break to this statement(s).
> 
> b) for code like:
> 
> 
> X: {
>          while (!(o instanceof String s)) {
>              break X;
>          }
>          System.err.println(s);
> }
> 
> 
> javac implements a strict interpretation of the specification, which does not include `s` in the scope for the `System.err.println` (due to the `break` out of the `while`). The specification is clarified, so that only breaks to the loop are considered (together with breaks to the enclosing labelled statements), so flow scoping handling for loops is adjusted to only consider breaks to the loop.

This pull request has now been integrated.

Changeset: a15db1a5
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a15db1a56c560406eac0ac60c29a0ffd15984267
Stats:     244 lines in 6 files changed: 176 ins; 49 del; 19 mod

8302865: Illegal bytecode for break from if with instanceof pattern matching condition

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Wed Jun 21 09:26:17 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 Jun 2023 09:26:17 GMT
Subject: [jdk21] RFR: 8302865: Illegal bytecode for break from if with
 instanceof pattern matching condition
Message-ID: <V37Im4ty2MdDZtK4uqAV1ZrKCoGCBFKLKHprXWtpcjA=.dab349af-8ebf-42c0-900b-06dd2b4a2e17@github.com>

Hi all,

This pull request contains a backport of commit [a15db1a5](https://github.com/openjdk/jdk/commit/a15db1a56c560406eac0ac60c29a0ffd15984267) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 21 Jun 2023 and was reviewed by Vicente Romero.

Thanks!

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

Commit messages:
 - Backport a15db1a56c560406eac0ac60c29a0ffd15984267

Changes: https://git.openjdk.org/jdk21/pull/47/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=47&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302865
  Stats: 244 lines in 6 files changed: 176 ins; 49 del; 19 mod
  Patch: https://git.openjdk.org/jdk21/pull/47.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/47/head:pull/47

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

From jlahoda at openjdk.org  Wed Jun 21 09:27:23 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 Jun 2023 09:27:23 GMT
Subject: [jdk21] RFR: 8310133: Effectivelly final condition not enforced in
 guards for binding variables from the same case
Message-ID: <UM8WcMr11MJ7Dq9jpXYX_0PICCgItVpQTTQjppR66Z8=.6b7dfe85-d511-455f-9548-f92c5795ffed@github.com>

Hi all,

This pull request contains a backport of commit [01623f6a](https://github.com/openjdk/jdk/commit/01623f6a5724d3eb250c48656be0aaf28df11750) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 21 Jun 2023 and was reviewed by Vicente Romero.

Thanks!

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

Commit messages:
 - Backport 01623f6a5724d3eb250c48656be0aaf28df11750

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

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

From mbaesken at openjdk.org  Wed Jun 21 15:26:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 15:26:16 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
Message-ID: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>

There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

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

Commit messages:
 - JDK-8310550

Changes: https://git.openjdk.org/jdk/pull/14593/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310550
  Stats: 14 lines in 12 files changed: 0 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14593/head:pull/14593

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

From vromero at openjdk.org  Wed Jun 21 15:46:04 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 21 Jun 2023 15:46:04 GMT
Subject: [jdk21] RFR: 8310133: Effectivelly final condition not enforced in
 guards for binding variables from the same case
In-Reply-To: <UM8WcMr11MJ7Dq9jpXYX_0PICCgItVpQTTQjppR66Z8=.6b7dfe85-d511-455f-9548-f92c5795ffed@github.com>
References: <UM8WcMr11MJ7Dq9jpXYX_0PICCgItVpQTTQjppR66Z8=.6b7dfe85-d511-455f-9548-f92c5795ffed@github.com>
Message-ID: <wr9FhjNEtxA2qz6RR6kISrIqTU3enywbIfAyJg9mKlE=.42289a16-4807-4e33-926a-2a9c26d5ed47@github.com>

On Wed, 21 Jun 2023 09:17:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [01623f6a](https://github.com/openjdk/jdk/commit/01623f6a5724d3eb250c48656be0aaf28df11750) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 21 Jun 2023 and was reviewed by Vicente Romero.
> 
> Thanks!

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/46#pullrequestreview-1491108697

From vromero at openjdk.org  Wed Jun 21 15:58:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 21 Jun 2023 15:58:10 GMT
Subject: [jdk21] RFR: 8302865: Illegal bytecode for break from if with
 instanceof pattern matching condition
In-Reply-To: <V37Im4ty2MdDZtK4uqAV1ZrKCoGCBFKLKHprXWtpcjA=.dab349af-8ebf-42c0-900b-06dd2b4a2e17@github.com>
References: <V37Im4ty2MdDZtK4uqAV1ZrKCoGCBFKLKHprXWtpcjA=.dab349af-8ebf-42c0-900b-06dd2b4a2e17@github.com>
Message-ID: <oTv3HDMtMsBZjIgKbdoxxpi2p2Pa9109fSMBqZmJQIA=.b81cf355-41c4-474f-ad37-7c0fbdcc17f6@github.com>

On Wed, 21 Jun 2023 09:18:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a15db1a5](https://github.com/openjdk/jdk/commit/a15db1a56c560406eac0ac60c29a0ffd15984267) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 21 Jun 2023 and was reviewed by Vicente Romero.
> 
> Thanks!

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/47#pullrequestreview-1491136600

From erikj at openjdk.org  Wed Jun 21 17:01:04 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Jun 2023 17:01:04 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <wNaBmeQdT388fGPZljNxxG_k4sROzgMRPxAN90lq4_Q=.c3057546-4179-4745-b99b-73d740091d5b@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

The update to Java.gmk is good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1491263836

From jjg at openjdk.org  Wed Jun 21 17:57:03 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 21 Jun 2023 17:57:03 GMT
Subject: RFR: JDK-8309883: no `@since` info in com.sun.tools.javac
 package-info.java,Main.java
In-Reply-To: <Yq5vl2L2qgyKoQrb_0-7aBZd-5rQLlhedufy3J-VSnA=.ea9f3031-0f64-4e37-9134-c88530a05ded@github.com>
References: <m-y3bbiCne667UuTW0IvRpZO0mp-JRw7cKttjqxNlSk=.22a20912-a927-46c0-b5ad-b30c67a69470@github.com>
 <Yq5vl2L2qgyKoQrb_0-7aBZd-5rQLlhedufy3J-VSnA=.ea9f3031-0f64-4e37-9134-c88530a05ded@github.com>
Message-ID: <QbCz5gxc2S1ubSW66uSAWorYWdxUKOy5gjWlRdBLGRo=.afa159af-b3ae-4d84-ac54-b786f6b8a449@github.com>

On Mon, 12 Jun 2023 23:26:41 GMT, Iris Clark <iris at openjdk.org> wrote:

> Wow. Surprised to see that one escape for so long!

Nothing like this surprises me any more!

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

PR Comment: https://git.openjdk.org/jdk/pull/14431#issuecomment-1601320911

From jjg at openjdk.org  Wed Jun 21 18:04:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 21 Jun 2023 18:04:10 GMT
Subject: Integrated: JDK-8309883: no `@since` info in com.sun.tools.javac
 package-info.java, Main.java
In-Reply-To: <m-y3bbiCne667UuTW0IvRpZO0mp-JRw7cKttjqxNlSk=.22a20912-a927-46c0-b5ad-b30c67a69470@github.com>
References: <m-y3bbiCne667UuTW0IvRpZO0mp-JRw7cKttjqxNlSk=.22a20912-a927-46c0-b5ad-b30c67a69470@github.com>
Message-ID: <pUZtpKDTcQFmUSaJan_LO4Xc2275EmHdy7PCk4asSX0=.e2eb5051-8661-4cbf-9e8e-a37e3cc6e52f@github.com>

On Mon, 12 Jun 2023 23:17:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to add some long-overdue `@since` tags to public API in `com.sun.tools.javac`.

This pull request has now been integrated.

Changeset: 226c6a09
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/226c6a097d9ec2fb66a678546ccd56b513494693
Stats:     4 lines in 2 files changed: 4 ins; 0 del; 0 mod

8309883: no `@since` info in com.sun.tools.javac package-info.java, Main.java

Reviewed-by: iris, darcy

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

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

From dholmes at openjdk.org  Wed Jun 21 21:51:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Jun 2023 21:51:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Mostly seems okay - a couple of things need further adjusting I think.

Thanks.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196:

> 194: 
> 195:     /**
> 196:      * Set whether or not to use ct.sym as an alternate

As an alternate to what? This needs something else.

test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 1:

> 1: /*

The name of this test includes RTJar. It needs to be changed too I think. Does this test actually still test something?

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1491961660
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1237747922
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1237749197

From darcy at openjdk.org  Wed Jun 21 22:32:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 21 Jun 2023 22:32:13 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v2]
In-Reply-To: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
Message-ID: <FLM5l0MtLzK1hkQzzp8Fulgq9YDSxRcG7VRDlvjx6aE=.4818b29f-bb7b-4dbd-ab78-c918294a4a50@github.com>

> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

Joe Darcy 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 eight additional commits since the last revision:

 - Update test.
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8310061
 - Add a maintenance breadcrumb.
 - Copyright update.
 - Update tests and implementation.
 - Merge branch 'master' into JDK-8310061
 - JDK-8310061: Note if implicit annotation processing is being used

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14499/files
  - new: https://git.openjdk.org/jdk/pull/14499/files/1816c0d3..72e34bc4

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

  Stats: 9743 lines in 421 files changed: 5163 ins; 1898 del; 2682 mod
  Patch: https://git.openjdk.org/jdk/pull/14499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14499/head:pull/14499

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

From darcy at openjdk.org  Wed Jun 21 22:38:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 21 Jun 2023 22:38:09 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v3]
In-Reply-To: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
Message-ID: <iNH5A8wW_B0yv-LJGWdLiPKwt880ZSdmrT4YWEx3fkk=.367689d8-2266-460b-85e8-b48961f05497@github.com>

> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Appease jcheck.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14499/files
  - new: https://git.openjdk.org/jdk/pull/14499/files/72e34bc4..22cd7da9

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

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

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

From darcy at openjdk.org  Wed Jun 21 23:09:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 21 Jun 2023 23:09:14 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
Message-ID: <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>

> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Expand cases where an annotation processor path is detected.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14499/files
  - new: https://git.openjdk.org/jdk/pull/14499/files/22cd7da9..f3981ee7

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

  Stats: 21 lines in 3 files changed: 17 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14499/head:pull/14499

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

From jlahoda at openjdk.org  Thu Jun 22 04:27:09 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 Jun 2023 04:27:09 GMT
Subject: [jdk21] Integrated: 8310133: Effectivelly final condition not enforced
 in guards for binding variables from the same case
In-Reply-To: <UM8WcMr11MJ7Dq9jpXYX_0PICCgItVpQTTQjppR66Z8=.6b7dfe85-d511-455f-9548-f92c5795ffed@github.com>
References: <UM8WcMr11MJ7Dq9jpXYX_0PICCgItVpQTTQjppR66Z8=.6b7dfe85-d511-455f-9548-f92c5795ffed@github.com>
Message-ID: <hTkVd4Mb0mDRtRjVhTxYiVSCksKOZFkItMqklYDmWuo=.ad230dc5-e2e2-4928-9f69-15bb1e665e28@github.com>

On Wed, 21 Jun 2023 09:17:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [01623f6a](https://github.com/openjdk/jdk/commit/01623f6a5724d3eb250c48656be0aaf28df11750) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 21 Jun 2023 and was reviewed by Vicente Romero.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ceadaece
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/ceadaece94d458578a692bbe45d7a22136dc3064
Stats:     13 lines in 3 files changed: 9 ins; 0 del; 4 mod

8310133: Effectivelly final condition not enforced in guards for binding variables from the same case

Reviewed-by: vromero
Backport-of: 01623f6a5724d3eb250c48656be0aaf28df11750

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

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

From jlahoda at openjdk.org  Thu Jun 22 04:28:07 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 Jun 2023 04:28:07 GMT
Subject: [jdk21] Integrated: 8302865: Illegal bytecode for break from if with
 instanceof pattern matching condition
In-Reply-To: <V37Im4ty2MdDZtK4uqAV1ZrKCoGCBFKLKHprXWtpcjA=.dab349af-8ebf-42c0-900b-06dd2b4a2e17@github.com>
References: <V37Im4ty2MdDZtK4uqAV1ZrKCoGCBFKLKHprXWtpcjA=.dab349af-8ebf-42c0-900b-06dd2b4a2e17@github.com>
Message-ID: <2TRkkZHp-976xXlkde41HrntA9z4ZLia2nNJOA5BdnA=.1d9c1f69-604c-4fa1-95cc-8b6d1291f78d@github.com>

On Wed, 21 Jun 2023 09:18:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a15db1a5](https://github.com/openjdk/jdk/commit/a15db1a56c560406eac0ac60c29a0ffd15984267) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 21 Jun 2023 and was reviewed by Vicente Romero.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 789b2fc4
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/789b2fc4f2a1375f1fca8f8a5dec6fde55af2eb6
Stats:     244 lines in 6 files changed: 176 ins; 49 del; 19 mod

8302865: Illegal bytecode for break from if with instanceof pattern matching condition

Reviewed-by: vromero
Backport-of: a15db1a56c560406eac0ac60c29a0ffd15984267

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

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

From mbaesken at openjdk.org  Thu Jun 22 09:26:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:26:06 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
Message-ID: <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>

On Wed, 21 Jun 2023 21:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196:
> 
>> 194: 
>> 195:     /**
>> 196:      * Set whether or not to use ct.sym as an alternate
> 
> As an alternate to what? This needs something else.

should "to the image modules files"  be used instead ?

> test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 1:
> 
>> 1: /*
> 
> The name of this test includes RTJar. It needs to be changed too I think. Does this test actually still test something?

It seems to start a javap. So I think it tests something, how important this is and what other tests might cover similar stuff, I do not know unfortunately .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238252196
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238254149

From alanb at openjdk.org  Thu Jun 22 14:23:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 14:23:04 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

src/java.sql/share/classes/java/sql/DriverManager.java line 658:

> 656:          * (which is invoking this class indirectly)
> 657:          * classloader, so that the JDBC driver class outside the image
> 658:          * can be loaded from here.

This code should probably be changed to use VM.isSystemDomainLoader(callerCL).

I think the comment should be replaced because it doesn't match what it actually does and it's nothing to do with the whether the JDBC driver is in the run-time image or not. How about:

"If the caller is defined to the bootstrap or platform class loader then use the Thread CCL as the initiating class loader so that a JDBC on the class path, or bundled with an application, is found."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238604300

From jwaters at openjdk.org  Fri Jun 23 02:45:25 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 02:45:25 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac [v2]
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

Julian Waters 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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-2
 - Remove Visual C++ specific workaround in javac

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13457/files
  - new: https://git.openjdk.org/jdk/pull/13457/files/105c332d..1db3082b

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

  Stats: 560116 lines in 6608 files changed: 455075 ins; 57368 del; 47673 mod
  Patch: https://git.openjdk.org/jdk/pull/13457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13457/head:pull/13457

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

From jwaters at openjdk.org  Fri Jun 23 05:50:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 05:50:02 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <YXR91kzp1JqAvi7z8_yXBHV_hO4h5eYRQzysZu7MZUQ=.42299d34-b10f-4ed0-a370-684c61e97be7@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
 <4atS6_AQCdSp76e4kyyUjAjV-X20m_a7KIkeS8KBgbk=.f9bea8a2-caaa-4d03-9031-560739068b2b@github.com>
 <YXR91kzp1JqAvi7z8_yXBHV_hO4h5eYRQzysZu7MZUQ=.42299d34-b10f-4ed0-a370-684c61e97be7@github.com>
Message-ID: <J2WTIqNg_l8mNOa3ZLf9MRqbl2TvEU8h0RyoORxSI5M=.46064924-636e-4d58-9bf7-7db70193991b@github.com>

On Mon, 5 Jun 2023 16:43:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Ah, that's good to know, now we'll just have to wait for the CSR review
>
>> Ah, that's good to know, now we'll just have to wait for the CSR review
> 
> Note that the CSR for this issue is in "Draft" state, which means it is not on the list of CSRs being considered for review. See https://wiki.openjdk.org/display/csr/Main for details.
> 
> To request a review, move the CSR to either Proposed or Finalized; HTH.

@jddarcy @lahodaj Anyone..?

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1603712557

From darcy at openjdk.org  Fri Jun 23 20:19:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 20:19:09 GMT
Subject: RFR: JDK-8310676: add note about unnamed module to
 Elements.getAllModuleElements
Message-ID: <UG_huAVgNylfLv7M1oFr1uquRMXc-wyQkycr48iQMpU=.f48b206c-e831-4723-80d0-a54e3069db29@github.com>

Simple doc clarification, also intended to backport to JDK 21.

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

Commit messages:
 - JDK-8310676: add note about unnamed module to Elements.getAllModuleElements

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

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

From jjg at openjdk.org  Fri Jun 23 21:20:01 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Jun 2023 21:20:01 GMT
Subject: RFR: JDK-8310676: add note about unnamed module to
 Elements.getAllModuleElements
In-Reply-To: <UG_huAVgNylfLv7M1oFr1uquRMXc-wyQkycr48iQMpU=.f48b206c-e831-4723-80d0-a54e3069db29@github.com>
References: <UG_huAVgNylfLv7M1oFr1uquRMXc-wyQkycr48iQMpU=.f48b206c-e831-4723-80d0-a54e3069db29@github.com>
Message-ID: <LlaZgDhuvszZQ61VjZZGhD5JD2iBqpnhDOvCjpo5_3s=.72dfaf5d-97fe-4b6d-8312-0b3e42627e20@github.com>

On Fri, 23 Jun 2023 20:12:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple doc clarification, also intended to backport to JDK 21.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14633#pullrequestreview-1496044756

From darcy at openjdk.org  Fri Jun 23 21:25:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 21:25:14 GMT
Subject: Integrated: JDK-8310676: add note about unnamed module to
 Elements.getAllModuleElements
In-Reply-To: <UG_huAVgNylfLv7M1oFr1uquRMXc-wyQkycr48iQMpU=.f48b206c-e831-4723-80d0-a54e3069db29@github.com>
References: <UG_huAVgNylfLv7M1oFr1uquRMXc-wyQkycr48iQMpU=.f48b206c-e831-4723-80d0-a54e3069db29@github.com>
Message-ID: <yb1QZuAnBHLhrABCQXOo8Uh1CwglKjRXcR4dDJPeQ1g=.ddb99363-a747-4aeb-858d-cae9828de833@github.com>

On Fri, 23 Jun 2023 20:12:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple doc clarification, also intended to backport to JDK 21.

This pull request has now been integrated.

Changeset: 69f3114c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/69f3114c4119d66a8c16cf95c35ea1adc488bdee
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8310676: add note about unnamed module to Elements.getAllModuleElements

Reviewed-by: jjg

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

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

From darcy at openjdk.org  Fri Jun 23 21:36:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 21:36:18 GMT
Subject: [jdk21] RFR: 8310676: add note about unnamed module to
 Elements.getAllModuleElements
Message-ID: <awT-TY9US6wtJOus5lDiZlMEhKB5RnEmprIIunnCWqk=.91300818-73b6-4295-b451-87c3ee24103a@github.com>

Doc-only backport.

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

Commit messages:
 - Backport 69f3114c4119d66a8c16cf95c35ea1adc488bdee

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

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

From jjg at openjdk.org  Fri Jun 23 23:04:01 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Jun 2023 23:04:01 GMT
Subject: [jdk21] RFR: 8310676: add note about unnamed module to
 Elements.getAllModuleElements
In-Reply-To: <awT-TY9US6wtJOus5lDiZlMEhKB5RnEmprIIunnCWqk=.91300818-73b6-4295-b451-87c3ee24103a@github.com>
References: <awT-TY9US6wtJOus5lDiZlMEhKB5RnEmprIIunnCWqk=.91300818-73b6-4295-b451-87c3ee24103a@github.com>
Message-ID: <Y6AVUpOf181ZbVWu4NzZzmdDKey-svcQYpCVYDTZQ1A=.48799205-8619-44c0-8f20-512b9f168880@github.com>

On Fri, 23 Jun 2023 21:28:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Doc-only backport.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/61#pullrequestreview-1496165172

From darcy at openjdk.org  Fri Jun 23 23:08:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 23:08:04 GMT
Subject: [jdk21] Integrated: 8310676: add note about unnamed module to
 Elements.getAllModuleElements
In-Reply-To: <awT-TY9US6wtJOus5lDiZlMEhKB5RnEmprIIunnCWqk=.91300818-73b6-4295-b451-87c3ee24103a@github.com>
References: <awT-TY9US6wtJOus5lDiZlMEhKB5RnEmprIIunnCWqk=.91300818-73b6-4295-b451-87c3ee24103a@github.com>
Message-ID: <zkKpRpOmV85hKxIGmqc8xpxABNmW3U_vvpvMQLMvkO0=.179abef4-150f-4bf0-9645-e876ea435e60@github.com>

On Fri, 23 Jun 2023 21:28:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Doc-only backport.

This pull request has now been integrated.

Changeset: 7489967d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/7489967d6a88458cef4a7887ba2d6a881b4eab4f
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8310676: add note about unnamed module to Elements.getAllModuleElements

Reviewed-by: jjg
Backport-of: 69f3114c4119d66a8c16cf95c35ea1adc488bdee

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

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

From jwaters at openjdk.org  Sun Jun 25 16:03:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Jun 2023 16:03:09 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac [v2]
In-Reply-To: <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
 <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
Message-ID: <zr5YBiiRXTWMXNOVzTifX6oOSJk2t3RLLEjlnfMQW2M=.8a3c594d-2124-450c-a82b-2ac215ac4bcb@github.com>

On Fri, 23 Jun 2023 02:45:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)
>
> Julian Waters 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-2
>  - Remove Visual C++ specific workaround in javac

...

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1606143135

From darcy at openjdk.org  Mon Jun 26 01:01:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 01:01:39 GMT
Subject: RFR: JDK-8310861: Improve location reporting for javac serial lint
 warnings
Message-ID: <KtD4v8dbDkSeUsG5LKfNjelu4xPwrPR1uAWASvQmE3o=.1b8a98b0-1211-42d9-b237-61cdf8e1fedc@github.com>

For a subset of the expanded serial lint warnings ([JDK-8202056](https://bugs.openjdk.org/browse/JDK-8202056), [JDK-8160675](https://bugs.openjdk.org/browse/JDK-8160675)), javac uses the location of the enclosing type rather than the method or field in question.

This PR addresses this by using the idiom of finding the method/field's tree within the type tree being checked.

All langtools regression tests pass when run locally; the intention is to backport this fix to JDK 21 as well.

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

Commit messages:
 - JDK-8310861: Improve location reporting for javac serial lint warnings

Changes: https://git.openjdk.org/jdk/pull/14644/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14644&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310861
  Stats: 46 lines in 9 files changed: 21 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/14644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14644/head:pull/14644

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

From darcy at openjdk.org  Mon Jun 26 01:30:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 01:30:15 GMT
Subject: RFR: JDK-8310861: Improve location reporting for javac serial lint
 warnings [v2]
In-Reply-To: <KtD4v8dbDkSeUsG5LKfNjelu4xPwrPR1uAWASvQmE3o=.1b8a98b0-1211-42d9-b237-61cdf8e1fedc@github.com>
References: <KtD4v8dbDkSeUsG5LKfNjelu4xPwrPR1uAWASvQmE3o=.1b8a98b0-1211-42d9-b237-61cdf8e1fedc@github.com>
Message-ID: <5pXaECqUpKe0x3Cp2ZNd7awd6vlBN8NAldo2ndVW68c=.861a3333-17c9-4880-9a82-ebbb725155ad@github.com>

> For a subset of the expanded serial lint warnings ([JDK-8202056](https://bugs.openjdk.org/browse/JDK-8202056), [JDK-8160675](https://bugs.openjdk.org/browse/JDK-8160675)), javac uses the location of the enclosing type rather than the method or field in question.
> 
> This PR addresses this by using the idiom of finding the method/field's tree within the type tree being checked.
> 
> All langtools regression tests pass when run locally; the intention is to backport this fix to JDK 21 as well.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Cover additional case.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14644/files
  - new: https://git.openjdk.org/jdk/pull/14644/files/0f0c3c1f..f9d4b8a2

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

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

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

From darcy at openjdk.org  Mon Jun 26 01:32:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 01:32:03 GMT
Subject: RFR: JDK-8310861: Improve location reporting for javac serial lint
 warnings
In-Reply-To: <KtD4v8dbDkSeUsG5LKfNjelu4xPwrPR1uAWASvQmE3o=.1b8a98b0-1211-42d9-b237-61cdf8e1fedc@github.com>
References: <KtD4v8dbDkSeUsG5LKfNjelu4xPwrPR1uAWASvQmE3o=.1b8a98b0-1211-42d9-b237-61cdf8e1fedc@github.com>
Message-ID: <IQkipTzb3nna0VUTr9LayHv7Brp2XkWfFnQQG46hLVQ=.54f72a73-c9f5-4a80-9745-a7117cc56bb0@github.com>

On Mon, 26 Jun 2023 00:54:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> For a subset of the expanded serial lint warnings ([JDK-8202056](https://bugs.openjdk.org/browse/JDK-8202056), [JDK-8160675](https://bugs.openjdk.org/browse/JDK-8160675)), javac uses the location of the enclosing type rather than the method or field in question.
> 
> This PR addresses this by using the idiom of finding the method/field's tree within the type tree being checked.
> 
> All langtools regression tests pass when run locally; the intention is to backport this fix to JDK 21 as well.

PS To expand "negative" testing, I could add more `@compile` lines to verify no warnings are generated without serial warnings being enabled -- or revert the few such changes like that already added.

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

PR Comment: https://git.openjdk.org/jdk/pull/14644#issuecomment-1606399894

From jlahoda at openjdk.org  Mon Jun 26 13:32:07 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 26 Jun 2023 13:32:07 GMT
Subject: RFR: JDK-8310861: Improve location reporting for javac serial lint
 warnings [v2]
In-Reply-To: <5pXaECqUpKe0x3Cp2ZNd7awd6vlBN8NAldo2ndVW68c=.861a3333-17c9-4880-9a82-ebbb725155ad@github.com>
References: <KtD4v8dbDkSeUsG5LKfNjelu4xPwrPR1uAWASvQmE3o=.1b8a98b0-1211-42d9-b237-61cdf8e1fedc@github.com>
 <5pXaECqUpKe0x3Cp2ZNd7awd6vlBN8NAldo2ndVW68c=.861a3333-17c9-4880-9a82-ebbb725155ad@github.com>
Message-ID: <HeAx0QolQCWhpH4CP7riN8nUBN8hKBzVG0lhz2pLwk8=.6b6f25bd-f7f7-4086-8beb-4e17fe7dea6f@github.com>

On Mon, 26 Jun 2023 01:30:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> For a subset of the expanded serial lint warnings ([JDK-8202056](https://bugs.openjdk.org/browse/JDK-8202056), [JDK-8160675](https://bugs.openjdk.org/browse/JDK-8160675)), javac uses the location of the enclosing type rather than the method or field in question.
>> 
>> This PR addresses this by using the idiom of finding the method/field's tree within the type tree being checked.
>> 
>> All langtools regression tests pass when run locally; the intention is to backport this fix to JDK 21 as well.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cover additional case.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14644#pullrequestreview-1498531655

From darcy at openjdk.org  Mon Jun 26 17:00:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 17:00:11 GMT
Subject: Integrated: JDK-8310861: Improve location reporting for javac serial
 lint warnings
In-Reply-To: <KtD4v8dbDkSeUsG5LKfNjelu4xPwrPR1uAWASvQmE3o=.1b8a98b0-1211-42d9-b237-61cdf8e1fedc@github.com>
References: <KtD4v8dbDkSeUsG5LKfNjelu4xPwrPR1uAWASvQmE3o=.1b8a98b0-1211-42d9-b237-61cdf8e1fedc@github.com>
Message-ID: <nFOMaOdoD_l7UntTT_DXeGgH9CBE4qmClYqJQ6hAtzY=.0de47cf4-98e0-46f3-a672-2f7a6e9a0ef2@github.com>

On Mon, 26 Jun 2023 00:54:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> For a subset of the expanded serial lint warnings ([JDK-8202056](https://bugs.openjdk.org/browse/JDK-8202056), [JDK-8160675](https://bugs.openjdk.org/browse/JDK-8160675)), javac uses the location of the enclosing type rather than the method or field in question.
> 
> This PR addresses this by using the idiom of finding the method/field's tree within the type tree being checked.
> 
> All langtools regression tests pass when run locally; the intention is to backport this fix to JDK 21 as well.

This pull request has now been integrated.

Changeset: 289f218a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/289f218a32558bbbf7e6c589b4618757bd6d043f
Stats:     52 lines in 9 files changed: 24 ins; 0 del; 28 mod

8310861: Improve location reporting for javac serial lint warnings

Reviewed-by: jlahoda

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

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

From darcy at openjdk.org  Mon Jun 26 17:12:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 17:12:13 GMT
Subject: [jdk21] RFR: 8310861: Improve location reporting for javac serial lint
 warnings
Message-ID: <ejxmEZEvhW5OlGSjuBHd8WIoSEaROOJvF1tYoED1SjE=.0a39fff1-4e60-4f72-9bb5-262b8d7916b2@github.com>

Backport to JDK 21.

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

Commit messages:
 - Backport 289f218a32558bbbf7e6c589b4618757bd6d043f

Changes: https://git.openjdk.org/jdk21/pull/63/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=63&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310861
  Stats: 52 lines in 9 files changed: 24 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk21/pull/63.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/63/head:pull/63

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

From jlahoda at openjdk.org  Mon Jun 26 17:28:02 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 26 Jun 2023 17:28:02 GMT
Subject: [jdk21] RFR: 8310861: Improve location reporting for javac serial
 lint warnings
In-Reply-To: <ejxmEZEvhW5OlGSjuBHd8WIoSEaROOJvF1tYoED1SjE=.0a39fff1-4e60-4f72-9bb5-262b8d7916b2@github.com>
References: <ejxmEZEvhW5OlGSjuBHd8WIoSEaROOJvF1tYoED1SjE=.0a39fff1-4e60-4f72-9bb5-262b8d7916b2@github.com>
Message-ID: <YWPJmx9lVQtF-usTylLVk6rJ26wquhZXH_r0-K_C-oE=.b0556b33-0c60-4d97-8654-ae51e49de63d@github.com>

On Mon, 26 Jun 2023 17:04:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Backport to JDK 21.

LGTM

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/63#pullrequestreview-1499041600

From vromero at openjdk.org  Mon Jun 26 17:34:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 26 Jun 2023 17:34:10 GMT
Subject: RFR: 8305671: javac rejects semicolons in compilation units with
 no imports [v5]
In-Reply-To: <OhEcqhwMH2DnsTy0_jGmTIOWfAEfzwCU9LF-xY33arI=.879835b7-66a5-4107-92b1-1df5a9651e6b@github.com>
References: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
 <OhEcqhwMH2DnsTy0_jGmTIOWfAEfzwCU9LF-xY33arI=.879835b7-66a5-4107-92b1-1df5a9651e6b@github.com>
Message-ID: <S_kuapmploryuU_ViP02gop2G5J9Dgvoa_QQHNv3bLc=.3f06bb73-cbc1-4959-8d36-554f5dcde69b@github.com>

On Tue, 6 Jun 2023 01:52:58 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The fix for [JDK-8027682](https://bugs.openjdk.org/browse/JDK-8027682) created a new bug in which a program like this:
>> 
>> package p;;
>> 
>> would be rejected.
>> 
>> This is due to the previous fix swallowing all the semicolons. Instead, in the case of semicolons followed by EOF, it needs to swallow all but the last one.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8305671
>  - Merge branch 'master' into JDK-8305671
>  - Consume extra semicolons in a more straightforward way.
>  - Merge branch 'master' into JDK-8305671
>  - Use ToolBox and add more tests per review suggestion.
>  - Allow a package declaration followed (only) by multiple commas.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13361#pullrequestreview-1499050142

From darcy at openjdk.org  Mon Jun 26 18:19:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 18:19:21 GMT
Subject: Integrated: JDK-8310907: Add missing file
Message-ID: <Qnjy6UcO7fxChK-mAp8inKM8OulGETm2bYFXP-q4JIM=.b8942525-4295-46a3-a808-30ee323633fe@github.com>

Accidentally omitted from recent PR.

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

Commit messages:
 - JDK-8310907: Add missing file

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

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

From jjg at openjdk.org  Mon Jun 26 18:19:22 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 26 Jun 2023 18:19:22 GMT
Subject: Integrated: JDK-8310907: Add missing file
In-Reply-To: <Qnjy6UcO7fxChK-mAp8inKM8OulGETm2bYFXP-q4JIM=.b8942525-4295-46a3-a808-30ee323633fe@github.com>
References: <Qnjy6UcO7fxChK-mAp8inKM8OulGETm2bYFXP-q4JIM=.b8942525-4295-46a3-a808-30ee323633fe@github.com>
Message-ID: <IQBp10ZxwSbaLEKJPIMlwL25yzCT1asFwvyVb2nH55w=.aab47094-b1c2-4431-b419-86d2e26fb847@github.com>

On Mon, 26 Jun 2023 18:11:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Accidentally omitted from recent PR.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14661#pullrequestreview-1499124619

From darcy at openjdk.org  Mon Jun 26 18:19:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 18:19:23 GMT
Subject: Integrated: JDK-8310907: Add missing file
In-Reply-To: <Qnjy6UcO7fxChK-mAp8inKM8OulGETm2bYFXP-q4JIM=.b8942525-4295-46a3-a808-30ee323633fe@github.com>
References: <Qnjy6UcO7fxChK-mAp8inKM8OulGETm2bYFXP-q4JIM=.b8942525-4295-46a3-a808-30ee323633fe@github.com>
Message-ID: <gAXfvNkT1_S1T0_9N8amysycwLg8OuArXF2-a694Ag8=.d2faee3e-e666-414c-b464-359142862a50@github.com>

On Mon, 26 Jun 2023 18:11:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Accidentally omitted from recent PR.

This pull request has now been integrated.

Changeset: 815ac6ee
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/815ac6eeb3017ea1969219f38fb3e0d003629760
Stats:     0 lines in 1 file changed: 0 ins; 0 del; 0 mod

8310907: Add missing file

Reviewed-by: jjg

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

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

From acobbs at openjdk.org  Mon Jun 26 19:08:17 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 26 Jun 2023 19:08:17 GMT
Subject: Integrated: 8305671: javac rejects semicolons in compilation units
 with no imports
In-Reply-To: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
References: <vNvIEk3fuqSza9JQOUCq31LFcbTGRuuMn4BdngS9VG4=.ce1c080c-bd8a-452c-80be-7029bfb2543e@github.com>
Message-ID: <3Gv-L69W-lPbSlNCPTnB7KCbDD2HH3JOZ1wyXuM6zJE=.15980361-424e-4e1a-9b38-f5ac5239d73e@github.com>

On Wed, 5 Apr 2023 18:37:05 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The fix for [JDK-8027682](https://bugs.openjdk.org/browse/JDK-8027682) created a new bug in which a program like this:
> 
> package p;;
> 
> would be rejected.
> 
> This is due to the previous fix swallowing all the semicolons. Instead, in the case of semicolons followed by EOF, it needs to swallow all but the last one.

This pull request has now been integrated.

Changeset: a08352f6
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a08352f62181d7ae010851959b35d1e11a184f40
Stats:     92 lines in 2 files changed: 89 ins; 2 del; 1 mod

8305671: javac rejects semicolons in compilation units with no imports

Reviewed-by: vromero

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

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

From acobbs at openjdk.org  Mon Jun 26 19:17:29 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 26 Jun 2023 19:17:29 GMT
Subject: [jdk21] RFR: 8305671: javac rejects semicolons in compilation units
 with no imports
Message-ID: <aRRHTy8OMZ9JOqBPSR73gdgmZwUCoZ_ZYzketXWsHu4=.2fd3ad61-70c2-494c-857e-6ee67aba92be@github.com>

This pull request contains a backport of commit [a08352f6](https://github.com/openjdk/jdk/commit/a08352f62181d7ae010851959b35d1e11a184f40) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

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

Commit messages:
 - Backport a08352f62181d7ae010851959b35d1e11a184f40

Changes: https://git.openjdk.org/jdk21/pull/64/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=64&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305671
  Stats: 92 lines in 2 files changed: 89 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/64.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/64/head:pull/64

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

From darcy at openjdk.org  Mon Jun 26 19:33:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 19:33:07 GMT
Subject: [jdk21] RFR: 8305671: javac rejects semicolons in compilation
 units with no imports
In-Reply-To: <aRRHTy8OMZ9JOqBPSR73gdgmZwUCoZ_ZYzketXWsHu4=.2fd3ad61-70c2-494c-857e-6ee67aba92be@github.com>
References: <aRRHTy8OMZ9JOqBPSR73gdgmZwUCoZ_ZYzketXWsHu4=.2fd3ad61-70c2-494c-857e-6ee67aba92be@github.com>
Message-ID: <-YbR7gBRaXQFqYz1vLfaPqDFt6HHBEtFj7KkM01whWU=.e34acfd4-953b-4470-97a8-03ac22256db4@github.com>

On Mon, 26 Jun 2023 19:11:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This pull request contains a backport of commit [a08352f6](https://github.com/openjdk/jdk/commit/a08352f62181d7ae010851959b35d1e11a184f40) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

Is this change expanding or reducing the set of programs accepted by javac? Should it have a CSR review?

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

PR Comment: https://git.openjdk.org/jdk21/pull/64#issuecomment-1608107968

From acobbs at openjdk.org  Mon Jun 26 19:52:01 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 26 Jun 2023 19:52:01 GMT
Subject: [jdk21] RFR: 8305671: javac rejects semicolons in compilation
 units with no imports
In-Reply-To: <-YbR7gBRaXQFqYz1vLfaPqDFt6HHBEtFj7KkM01whWU=.e34acfd4-953b-4470-97a8-03ac22256db4@github.com>
References: <aRRHTy8OMZ9JOqBPSR73gdgmZwUCoZ_ZYzketXWsHu4=.2fd3ad61-70c2-494c-857e-6ee67aba92be@github.com>
 <-YbR7gBRaXQFqYz1vLfaPqDFt6HHBEtFj7KkM01whWU=.e34acfd4-953b-4470-97a8-03ac22256db4@github.com>
Message-ID: <BsleVYrkQd7xIj6it8Us-t1MlPh6Qex1glA734RliG0=.f28966dc-4391-406a-af2b-1297b0c4cacb@github.com>

On Mon, 26 Jun 2023 19:30:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Is this change expanding or reducing the set of programs accepted by javac? Should it have a CSR review?

No - this bug was created during the 21 development cycle as a side effect of a different bug fix ([JDK-8027682](https://bugs.openjdk.org/browse/JDK-8027682)), so it's never seen the light of day.

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

PR Comment: https://git.openjdk.org/jdk21/pull/64#issuecomment-1608133792

From darcy at openjdk.org  Mon Jun 26 22:00:25 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 22:00:25 GMT
Subject: [jdk21] RFR: 8310861: Improve location reporting for javac serial
 lint warnings [v2]
In-Reply-To: <ejxmEZEvhW5OlGSjuBHd8WIoSEaROOJvF1tYoED1SjE=.0a39fff1-4e60-4f72-9bb5-262b8d7916b2@github.com>
References: <ejxmEZEvhW5OlGSjuBHd8WIoSEaROOJvF1tYoED1SjE=.0a39fff1-4e60-4f72-9bb5-262b8d7916b2@github.com>
Message-ID: <ri-5TKpocUW4FSicfaZdn_oTTeQjL--HjkLZaGF0Xcc=.55ec5d75-41e1-42b3-bd25-46a25e3a64bc@github.com>

> Backport to JDK 21.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add missing file.

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

Changes:
  - all: https://git.openjdk.org/jdk21/pull/63/files
  - new: https://git.openjdk.org/jdk21/pull/63/files/f151e9a9..ccc350f2

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

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

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

From darcy at openjdk.org  Mon Jun 26 22:39:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 22:39:15 GMT
Subject: [jdk21] Integrated: 8310861: Improve location reporting for javac
 serial lint warnings
In-Reply-To: <ejxmEZEvhW5OlGSjuBHd8WIoSEaROOJvF1tYoED1SjE=.0a39fff1-4e60-4f72-9bb5-262b8d7916b2@github.com>
References: <ejxmEZEvhW5OlGSjuBHd8WIoSEaROOJvF1tYoED1SjE=.0a39fff1-4e60-4f72-9bb5-262b8d7916b2@github.com>
Message-ID: <lrVixzGcHI2mVNXpN3jIAr2CUo32YCXMeJ8xDl4P1Zg=.55d981be-bf7d-4182-bfa3-be70982c5882@github.com>

On Mon, 26 Jun 2023 17:04:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Backport to JDK 21.

This pull request has now been integrated.

Changeset: 71a41f7e
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/71a41f7e7193fdca01601847e60d7fd92120e3b6
Stats:     52 lines in 10 files changed: 24 ins; 0 del; 28 mod

8310861: Improve location reporting for javac serial lint warnings
8310907: Add missing file

Reviewed-by: jlahoda
Backport-of: 289f218a32558bbbf7e6c589b4618757bd6d043f

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

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

From asotona at openjdk.org  Tue Jun 27 13:32:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 27 Jun 2023 13:32:47 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v5]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <BKbdk10xXBhnlMr4NrXPeOhY6yxkvhl3p_lEUcSHdTQ=.1071c09a-6654-47fa-bf64-205d3b1e9667@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> 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 220 commits:

 - fixed JavapTask
 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
 - fixed build
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - consolidated safeguarding of IAE in javap
 - ... and 210 more: https://git.openjdk.org/jdk/compare/05e9c41e...d5a65c49

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=04
  Stats: 3638 lines in 22 files changed: 835 ins; 1716 del; 1087 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From vromero at openjdk.org  Tue Jun 27 18:50:11 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 27 Jun 2023 18:50:11 GMT
Subject: [jdk21] RFR: 8305671: javac rejects semicolons in compilation
 units with no imports
In-Reply-To: <aRRHTy8OMZ9JOqBPSR73gdgmZwUCoZ_ZYzketXWsHu4=.2fd3ad61-70c2-494c-857e-6ee67aba92be@github.com>
References: <aRRHTy8OMZ9JOqBPSR73gdgmZwUCoZ_ZYzketXWsHu4=.2fd3ad61-70c2-494c-857e-6ee67aba92be@github.com>
Message-ID: <qJnSM0YVbPPZ2UAGGpgtcpPsL9OFckWOL2gtgyFRy9Y=.8cd4f9d5-419a-490b-afdc-509327df721f@github.com>

On Mon, 26 Jun 2023 19:11:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This pull request contains a backport of commit [a08352f6](https://github.com/openjdk/jdk/commit/a08352f62181d7ae010851959b35d1e11a184f40) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/64#pullrequestreview-1501632256

From prappo at openjdk.org  Wed Jun 28 11:40:09 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Jun 2023 11:40:09 GMT
Subject: RFR: 8311034: Fix typo in javac man page
Message-ID: <byd7td-mEqyr9AicjjwE9OhMqvKmAi7IY6xHa6KynVw=.3f8c7dcd-f149-4bdc-8697-c1a8c9577361@github.com>

Please review this trivial fix.

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

Commit messages:
 - Initial commit

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

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

From mbaesken at openjdk.org  Wed Jun 28 12:57:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 12:57:07 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
Message-ID: <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>

On Thu, 22 Jun 2023 14:20:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> src/java.sql/share/classes/java/sql/DriverManager.java line 658:
> 
>> 656:          * (which is invoking this class indirectly)
>> 657:          * classloader, so that the JDBC driver class outside the image
>> 658:          * can be loaded from here.
> 
> This code should probably be changed to use VM.isSystemDomainLoader(callerCL).
> 
> I think the comment should be replaced because it doesn't match what it actually does and it's nothing to do with the whether the JDBC driver is in the run-time image or not. How about:
> 
> "If the caller is defined to the bootstrap or platform class loader then use the Thread CCL as the initiating class loader so that a JDBC on the class path, or bundled with an application, is found."

Hi Alan, regarding usage of class VM I get 
'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql'
Is there any concern to export it as well to module java.sql  ?
And btw did you mean to use it like this, in the if  ?

`        if (callerCL == null || VM.isSystemDomainLoader(callerCL)) {
            callerCL = Thread.currentThread().getContextClassLoader();
        }`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245164604

From alanb at openjdk.org  Wed Jun 28 13:19:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Jun 2023 13:19:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
Message-ID: <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>

On Wed, 28 Jun 2023 12:54:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
> 
> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`

It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245197137

From mbaesken at openjdk.org  Wed Jun 28 13:25:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 13:25:07 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
 <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
Message-ID: <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>

On Wed, 28 Jun 2023 13:16:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Alan, regarding usage of class VM I get 
>> 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql'
>> Is there any concern to export it as well to module java.sql  ?
>> And btw did you mean to use it like this, in the if  ?
>> 
>> `
>>  if (callerCL == null || VM.isSystemDomainLoader(callerCL)) {
>>             callerCL = Thread.currentThread().getContextClassLoader();
>> }
>> `
>
>> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
>> 
>> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`
> 
> It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.

Hi Alan, thanks for clarifying.  So I should only adjust the comment, correct ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245204791

From hannesw at openjdk.org  Wed Jun 28 13:35:03 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 Jun 2023 13:35:03 GMT
Subject: RFR: 8311034: Fix typo in javac man page
In-Reply-To: <byd7td-mEqyr9AicjjwE9OhMqvKmAi7IY6xHa6KynVw=.3f8c7dcd-f149-4bdc-8697-c1a8c9577361@github.com>
References: <byd7td-mEqyr9AicjjwE9OhMqvKmAi7IY6xHa6KynVw=.3f8c7dcd-f149-4bdc-8697-c1a8c9577361@github.com>
Message-ID: <ADinllfG_J2_n2xfQ1Ls4KUBNsf1COc-niTtKcLhqcU=.4781010a-b66e-4e4b-b47f-79eb30cc690d@github.com>

On Wed, 28 Jun 2023 11:34:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix.

Looks good.

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14694#pullrequestreview-1503104275

From prappo at openjdk.org  Wed Jun 28 13:51:10 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Jun 2023 13:51:10 GMT
Subject: Integrated: 8311034: Fix typo in javac man page
In-Reply-To: <byd7td-mEqyr9AicjjwE9OhMqvKmAi7IY6xHa6KynVw=.3f8c7dcd-f149-4bdc-8697-c1a8c9577361@github.com>
References: <byd7td-mEqyr9AicjjwE9OhMqvKmAi7IY6xHa6KynVw=.3f8c7dcd-f149-4bdc-8697-c1a8c9577361@github.com>
Message-ID: <CDdBpCIFaUr2zYUcMZc9brW6Tl79OuRJKV5AGeVlOMg=.4523a2a0-5571-45a4-8fdb-1cda1a3834de@github.com>

On Wed, 28 Jun 2023 11:34:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix.

This pull request has now been integrated.

Changeset: f17bfeec
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f17bfeec61b753eb0eb8a48df9bf5ccc3bcd9eb3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8311034: Fix typo in javac man page

Reviewed-by: hannesw

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

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

From briangoetz at openjdk.org  Wed Jun 28 14:06:05 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Wed, 28 Jun 2023 14:06:05 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
Message-ID: <OX67KwWGe37Owdbv-WwklB5Yl1CqBI8gMC3enNWFqMw=.5f4cdabe-7803-48ef-b67b-b27758d75c14@github.com>

On Wed, 21 Jun 2023 23:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand cases where an annotation processor path is detected.

Marked as reviewed by briangoetz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14499#pullrequestreview-1503183934

From prappo at openjdk.org  Wed Jun 28 14:06:24 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Jun 2023 14:06:24 GMT
Subject: [jdk21] RFR: 8311034: Fix typo in javac man page
Message-ID: <QUh3AVEqZ2qrdK1D_j8VAgWKvgvnOG_1VsdcPenv5Fo=.e86483f4-da99-4190-8665-f6bb4f995d5c@github.com>

Hi all,

This pull request contains a backport of commit [f17bfeec](https://github.com/openjdk/jdk/commit/f17bfeec61b753eb0eb8a48df9bf5ccc3bcd9eb3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Pavel Rappo on 28 Jun 2023 and was reviewed by Hannes Walln?fer.

Thanks!

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

Commit messages:
 - Backport f17bfeec61b753eb0eb8a48df9bf5ccc3bcd9eb3

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

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

From rriggs at openjdk.org  Wed Jun 28 14:18:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 Jun 2023 14:18:11 GMT
Subject: [jdk21] RFR: 8311034: Fix typo in javac man page
In-Reply-To: <QUh3AVEqZ2qrdK1D_j8VAgWKvgvnOG_1VsdcPenv5Fo=.e86483f4-da99-4190-8665-f6bb4f995d5c@github.com>
References: <QUh3AVEqZ2qrdK1D_j8VAgWKvgvnOG_1VsdcPenv5Fo=.e86483f4-da99-4190-8665-f6bb4f995d5c@github.com>
Message-ID: <I35oa5nmWL7Zu55FodEa9ZonkRzDPw0ipGJLDl4qkrU=.ef424d0a-f30e-4e80-a84e-075cf97f68da@github.com>

On Wed, 28 Jun 2023 14:00:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f17bfeec](https://github.com/openjdk/jdk/commit/f17bfeec61b753eb0eb8a48df9bf5ccc3bcd9eb3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Pavel Rappo on 28 Jun 2023 and was reviewed by Hannes Walln?fer.
> 
> Thanks!

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/76#pullrequestreview-1503214387

From prappo at openjdk.org  Wed Jun 28 14:25:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Jun 2023 14:25:07 GMT
Subject: [jdk21] Integrated: 8311034: Fix typo in javac man page
In-Reply-To: <QUh3AVEqZ2qrdK1D_j8VAgWKvgvnOG_1VsdcPenv5Fo=.e86483f4-da99-4190-8665-f6bb4f995d5c@github.com>
References: <QUh3AVEqZ2qrdK1D_j8VAgWKvgvnOG_1VsdcPenv5Fo=.e86483f4-da99-4190-8665-f6bb4f995d5c@github.com>
Message-ID: <5Xc7OE-JnHeZ2S3OT4xnLa9tH_ht_lwpMxDotIeIDjM=.82a00bf2-fca2-4148-987b-8cad82cfee31@github.com>

On Wed, 28 Jun 2023 14:00:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f17bfeec](https://github.com/openjdk/jdk/commit/f17bfeec61b753eb0eb8a48df9bf5ccc3bcd9eb3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Pavel Rappo on 28 Jun 2023 and was reviewed by Hannes Walln?fer.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ccacc2b4
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/ccacc2b4da01916d675d220880c89208bf335cd6
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8311034: Fix typo in javac man page

Reviewed-by: rriggs
Backport-of: f17bfeec61b753eb0eb8a48df9bf5ccc3bcd9eb3

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

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

From vromero at openjdk.org  Wed Jun 28 15:25:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Jun 2023 15:25:31 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
Message-ID: <BNwqRIcL8fggM2MSyB-s0NLscuF0UpojbpRU-ol9zr0=.28d761f6-932e-4c3a-96f2-5702cca9f111@github.com>

On Wed, 21 Jun 2023 23:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand cases where an annotation processor path is detected.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14499#pullrequestreview-1503388114

From acobbs at openjdk.org  Wed Jun 28 15:51:15 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 28 Jun 2023 15:51:15 GMT
Subject: [jdk21] Integrated: 8305671: javac rejects semicolons in compilation
 units with no imports
In-Reply-To: <aRRHTy8OMZ9JOqBPSR73gdgmZwUCoZ_ZYzketXWsHu4=.2fd3ad61-70c2-494c-857e-6ee67aba92be@github.com>
References: <aRRHTy8OMZ9JOqBPSR73gdgmZwUCoZ_ZYzketXWsHu4=.2fd3ad61-70c2-494c-857e-6ee67aba92be@github.com>
Message-ID: <82FglAkkaSuuSphl7tfMr2IVRxjhdxBetjetRreJkHg=.7763b60e-55c8-4a5d-aa6a-23b60b40ce9c@github.com>

On Mon, 26 Jun 2023 19:11:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This pull request contains a backport of commit [a08352f6](https://github.com/openjdk/jdk/commit/a08352f62181d7ae010851959b35d1e11a184f40) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This pull request has now been integrated.

Changeset: 359bd63b
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/359bd63b15fc256df19cc7f1b0b2b4c399b4adc0
Stats:     92 lines in 2 files changed: 89 ins; 2 del; 1 mod

8305671: javac rejects semicolons in compilation units with no imports

Reviewed-by: vromero
Backport-of: a08352f62181d7ae010851959b35d1e11a184f40

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

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

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 jjg at openjdk.org  Wed Jun 28 17:12:58 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 28 Jun 2023 17:12:58 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
Message-ID: <jzcCIQHaN_Xbdsx6muZAyCgbHLH5Wh7JwtxSwb9nHoc=.00d08443-d878-43d8-98b1-87fbe1001ce6@github.com>

On Wed, 21 Jun 2023 23:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand cases where an annotation processor path is detected.

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 239:

> 237:     public Log log;
> 238: 
> 239:     /** Whether or not the options lint category was initially disabled

You've copied my pattern of misuse.  "Whether or not" is not recommended use, whether or not you like it.
The consensus is to use just `whether`;  `whether or not` means `regardless`

FWIW, I still like the `whether or not` form!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245528247

From jjg at openjdk.org  Wed Jun 28 17:15:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 28 Jun 2023 17:15:55 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
Message-ID: <w8sF1EkRgejxujKdhZP-txArxi3aB2QhBZp-T2UuUdk=.c53829e1-c891-420a-a1d6-1deb7190fdf9@github.com>

On Wed, 21 Jun 2023 23:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand cases where an annotation processor path is detected.

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 437:

> 435:         optionsCheckingInitiallyDisabled =
> 436:             options.isSet(Option.XLINT_CUSTOM, "-options") ||
> 437:             options.isSet(Option.XLINT_CUSTOM, "none");

You have a `context`, so you can use get a `Lint` object with `Lint.instance(context)` and then use `isEnabled(LintCategory)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245531666

From jjg at openjdk.org  Wed Jun 28 17:27:02 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 28 Jun 2023 17:27:02 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
Message-ID: <RAjrUbG2ImKy8Qsxm1HdJPSJkt9PI89q-Lc76A8XyhI=.eccb1b60-87a9-4a9c-b8c8-c1a33271d426@github.com>

On Wed, 21 Jun 2023 23:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand cases where an annotation processor path is detected.

Approved, with some optional suggestions for stylistic improvement

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

> 1776:     path is specified (--processor-path, --processor-module-path), or annotation\n\
> 1777:     processing is enabled explicitly (-proc:only, -proc:full).\n\
> 1778:     Use -Xlint:-options to suppress this message.

You ought to be able to suppress the message by addressing the underlying cause, not just by disabling the check.
For example, I would expect `-proc:none` to disable the message as well.

test/langtools/tools/javac/diags/examples.not-yet.txt line 217:

> 215: 
> 216: # this one needs a forged class file to be reproduced
> 217: compiler.err.annotation.unrecognized.attribute.name

Is it just me? I cannot see any difference in these lines...  Is there a difference in trailing whitespace?

test/langtools/tools/javac/processing/options/TestNoteOnImplicitProcessing.java line 106:

> 104: 
> 105:         // write out processor source file
> 106:         tb.writeFile(processorName + ".java",

If you use `writeJavaFiles`, it will infer the filename from the source code.

test/langtools/tools/javac/processing/options/TestNoteOnImplicitProcessing.java line 135:

> 133:         // Compile the processor
> 134:         new JavacTask(tb)
> 135:             .files(processorName + ".java")

there's a utility method `ToolBox.findJavaFiles` which is generally useful in this sort of context

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14499#pullrequestreview-1503625527
PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245535349
PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245537258
PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245540576
PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245541629

From darcy at openjdk.org  Wed Jun 28 17:27:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 28 Jun 2023 17:27:04 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <w8sF1EkRgejxujKdhZP-txArxi3aB2QhBZp-T2UuUdk=.c53829e1-c891-420a-a1d6-1deb7190fdf9@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
 <w8sF1EkRgejxujKdhZP-txArxi3aB2QhBZp-T2UuUdk=.c53829e1-c891-420a-a1d6-1deb7190fdf9@github.com>
Message-ID: <U5xSM3JIfb4HDgHbRow8yN9NZbQbAuUfT-VQubWzHyQ=.f05b975e-e038-42f9-9ab6-78b1fa97deaf@github.com>

On Wed, 28 Jun 2023 17:12:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Expand cases where an annotation processor path is detected.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 437:
> 
>> 435:         optionsCheckingInitiallyDisabled =
>> 436:             options.isSet(Option.XLINT_CUSTOM, "-options") ||
>> 437:             options.isSet(Option.XLINT_CUSTOM, "none");
> 
> You have a `context`, so you can use get a `Lint` object with `Lint.instance(context)` and then use `isEnabled(LintCategory)`

I'm slightly abusing the existing lint options category here. I want to have the effect that a new options-related link check is on by default. There are lint categories that are enabled by default, but options isn't one of them.

I'm implementing that policy by treating the implicit annotation processing check as enabled unless options checking has been explicitly disabled, which is what the code above does and is different than the standard is-options-lint-category enabled check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245538677

From darcy at openjdk.org  Wed Jun 28 17:37:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 28 Jun 2023 17:37:56 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <RAjrUbG2ImKy8Qsxm1HdJPSJkt9PI89q-Lc76A8XyhI=.eccb1b60-87a9-4a9c-b8c8-c1a33271d426@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
 <RAjrUbG2ImKy8Qsxm1HdJPSJkt9PI89q-Lc76A8XyhI=.eccb1b60-87a9-4a9c-b8c8-c1a33271d426@github.com>
Message-ID: <H-XxSHdLaTDr5M3yzZvdfCGjPn8LrXdGXrjgRaLN8T4=.08e2882b-704a-4c08-89e3-28e9580c6517@github.com>

On Wed, 28 Jun 2023 17:18:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Expand cases where an annotation processor path is detected.
>
> test/langtools/tools/javac/diags/examples.not-yet.txt line 217:
> 
>> 215: 
>> 216: # this one needs a forged class file to be reproduced
>> 217: compiler.err.annotation.unrecognized.attribute.name
> 
> Is it just me? I cannot see any difference in these lines...  Is there a difference in trailing whitespace?

IIRC, it was an end-of-file difference, but it isn't being reflected in the webrev either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245553451

From darcy at openjdk.org  Wed Jun 28 19:37:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 28 Jun 2023 19:37:14 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v5]
In-Reply-To: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
Message-ID: <VM1qnSR-pc0AboQjR9H0BUMwLnjqbZmZ1MTKJO2jsE0=.2b12f7e4-683a-4cda-bb8a-e9093c9eaef3@github.com>

> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

Joe Darcy 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 11 additional commits since the last revision:

 - Merge branch 'master' into JDK-8310061
 - Expand cases where an annotation processor path is detected.
 - Appease jcheck.
 - Update test.
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8310061
 - Add a maintenance breadcrumb.
 - Copyright update.
 - Update tests and implementation.
 - Merge branch 'master' into JDK-8310061
 - ... and 1 more: https://git.openjdk.org/jdk/compare/0132b89b...6cbeec6c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14499/files
  - new: https://git.openjdk.org/jdk/pull/14499/files/f3981ee7..6cbeec6c

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

  Stats: 12731 lines in 626 files changed: 5313 ins; 3694 del; 3724 mod
  Patch: https://git.openjdk.org/jdk/pull/14499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14499/head:pull/14499

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

From darcy at openjdk.org  Wed Jun 28 19:39:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 28 Jun 2023 19:39:58 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <U5xSM3JIfb4HDgHbRow8yN9NZbQbAuUfT-VQubWzHyQ=.f05b975e-e038-42f9-9ab6-78b1fa97deaf@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
 <w8sF1EkRgejxujKdhZP-txArxi3aB2QhBZp-T2UuUdk=.c53829e1-c891-420a-a1d6-1deb7190fdf9@github.com>
 <U5xSM3JIfb4HDgHbRow8yN9NZbQbAuUfT-VQubWzHyQ=.f05b975e-e038-42f9-9ab6-78b1fa97deaf@github.com>
Message-ID: <pPThmCKGHH_mP9xdZcaYb7ziFe-C74Fg66YBW7CSIXk=.85047f76-798c-4f11-ba9b-36de1d96f2ba@github.com>

On Wed, 28 Jun 2023 17:20:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 437:
>> 
>>> 435:         optionsCheckingInitiallyDisabled =
>>> 436:             options.isSet(Option.XLINT_CUSTOM, "-options") ||
>>> 437:             options.isSet(Option.XLINT_CUSTOM, "none");
>> 
>> You have a `context`, so you can use get a `Lint` object with `Lint.instance(context)` and then use `isEnabled(LintCategory)`
>
> I'm slightly abusing the existing lint options category here. I want to have the effect that a new options-related link check is on by default. There are lint categories that are enabled by default, but options isn't one of them.
> 
> I'm implementing that policy by treating the implicit annotation processing check as enabled unless options checking has been explicitly disabled, which is what the code above does and is different than the standard is-options-lint-category enabled check.

PS Will add a clarifying comment that the idiom in question is intentional.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245677485

From darcy at openjdk.org  Wed Jun 28 20:09:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 28 Jun 2023 20:09:56 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v4]
In-Reply-To: <RAjrUbG2ImKy8Qsxm1HdJPSJkt9PI89q-Lc76A8XyhI=.eccb1b60-87a9-4a9c-b8c8-c1a33271d426@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <gyrLOXn88nc77LkPQpqZQWoB9SrZczpZWCvkF9D2DjE=.e83a48b5-0104-4c08-8a7f-9fbbd08a1c32@github.com>
 <RAjrUbG2ImKy8Qsxm1HdJPSJkt9PI89q-Lc76A8XyhI=.eccb1b60-87a9-4a9c-b8c8-c1a33271d426@github.com>
Message-ID: <QD0yraL8cwzJS73jOVJYpkjBKZhd6bCM9mwaIDZcJyM=.4b569786-6ede-4f09-a674-5cc080388deb@github.com>

On Wed, 28 Jun 2023 17:16:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Expand cases where an annotation processor path is detected.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1778:
> 
>> 1776:     path is specified (--processor-path, --processor-module-path), or annotation\n\
>> 1777:     processing is enabled explicitly (-proc:only, -proc:full).\n\
>> 1778:     Use -Xlint:-options to suppress this message.
> 
> You ought to be able to suppress the message by addressing the underlying cause, not just by disabling the check.
> For example, I would expect `-proc:none` to disable the message as well.

That observation is true and I'll add -proc:none to the test case.

I'll add a sentence that -proc:none will disable processing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14499#discussion_r1245703410

From darcy at openjdk.org  Wed Jun 28 20:29:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 28 Jun 2023 20:29:06 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v6]
In-Reply-To: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
Message-ID: <00Ts7VkwlVn2MkO2hcvM0TQUWwvwCWZj_H3H3dOdGv8=.c5cf7d1a-4262-42dc-bc36-820b84929bed@github.com>

> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Resond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14499/files
  - new: https://git.openjdk.org/jdk/pull/14499/files/6cbeec6c..948a3212

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

  Stats: 64 lines in 3 files changed: 25 ins; 2 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/14499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14499/head:pull/14499

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

From jjg at openjdk.org  Wed Jun 28 20:56:56 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 28 Jun 2023 20:56:56 GMT
Subject: RFR: JDK-8310061: Note if implicit annotation processing is being
 used [v6]
In-Reply-To: <00Ts7VkwlVn2MkO2hcvM0TQUWwvwCWZj_H3H3dOdGv8=.c5cf7d1a-4262-42dc-bc36-820b84929bed@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
 <00Ts7VkwlVn2MkO2hcvM0TQUWwvwCWZj_H3H3dOdGv8=.c5cf7d1a-4262-42dc-bc36-820b84929bed@github.com>
Message-ID: <7Jd7AFpSzeWReyQ-QR0G2TvGRa2NxYdxnS7wdVQuaaA=.ed287d09-296d-48d1-a4c9-031a50326ce6@github.com>

On Wed, 28 Jun 2023 20:29:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resond to review feedback.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14499#pullrequestreview-1504045155

From darcy at openjdk.org  Wed Jun 28 21:03:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 28 Jun 2023 21:03:09 GMT
Subject: Integrated: JDK-8310061: Note if implicit annotation processing is
 being used
In-Reply-To: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
References: <BoRgDS8UKGm5NKC-s60V_b7UQ4FsTqZzfJR3hl_JaTk=.8019bb22-1e72-4e30-ac1e-c718789c181b@github.com>
Message-ID: <TXeA5EBe62RN8i04DejqlTEbgBZjuRopiBeGGTCrxeQ=.ed35c221-b48b-4295-b226-e15875a08bdd@github.com>

On Thu, 15 Jun 2023 18:16:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Emit a note warning of the possibility of changing the implicit running of annotation processors in a future release.

This pull request has now been integrated.

Changeset: 3df36c4f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3df36c4f101e094d6f6beccadc004742b47d045a
Stats:     340 lines in 10 files changed: 328 ins; 0 del; 12 mod

8310061: Note if implicit annotation processing is being used

Reviewed-by: briangoetz, vromero, jjg

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

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

From darcy at openjdk.org  Wed Jun 28 21:49:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 28 Jun 2023 21:49:17 GMT
Subject: [jdk21] RFR: 8310061: Note if implicit annotation processing is being
 used
Message-ID: <f8k8mwO8OvgQulWHMj6UvhUwhxK8i_EPosLhLW-fwck=.f13ac300-1517-4b78-abdc-1878ddc52be6@github.com>

Backport.

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

Commit messages:
 - Backport 3df36c4f101e094d6f6beccadc004742b47d045a

Changes: https://git.openjdk.org/jdk21/pull/80/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=80&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310061
  Stats: 340 lines in 10 files changed: 328 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk21/pull/80.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/80/head:pull/80

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

From vromero at openjdk.org  Thu Jun 29 00:07:54 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 29 Jun 2023 00:07:54 GMT
Subject: [jdk21] RFR: 8310061: Note if implicit annotation processing is
 being used
In-Reply-To: <f8k8mwO8OvgQulWHMj6UvhUwhxK8i_EPosLhLW-fwck=.f13ac300-1517-4b78-abdc-1878ddc52be6@github.com>
References: <f8k8mwO8OvgQulWHMj6UvhUwhxK8i_EPosLhLW-fwck=.f13ac300-1517-4b78-abdc-1878ddc52be6@github.com>
Message-ID: <uOCq5kxryJYVb5-5r3557hy4k_2kRXM8yiRI60Z8zzo=.27cd26d5-826d-4d88-b04f-f8c1f4580cef@github.com>

On Wed, 28 Jun 2023 21:43:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Backport.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/80#pullrequestreview-1504390171

From darcy at openjdk.org  Thu Jun 29 00:13:00 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 29 Jun 2023 00:13:00 GMT
Subject: [jdk21] Integrated: 8310061: Note if implicit annotation processing is
 being used
In-Reply-To: <f8k8mwO8OvgQulWHMj6UvhUwhxK8i_EPosLhLW-fwck=.f13ac300-1517-4b78-abdc-1878ddc52be6@github.com>
References: <f8k8mwO8OvgQulWHMj6UvhUwhxK8i_EPosLhLW-fwck=.f13ac300-1517-4b78-abdc-1878ddc52be6@github.com>
Message-ID: <CmnJIg7BIJ7Tji29o5yu9G45uLwe6cNxM5UQ-bpBY6c=.c5ebc1fe-8a50-4e4c-815b-3becbeb9f217@github.com>

On Wed, 28 Jun 2023 21:43:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Backport.

This pull request has now been integrated.

Changeset: e67393fd
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/e67393fd302686584eaaea2e5eef42336b71cf67
Stats:     340 lines in 10 files changed: 328 ins; 0 del; 12 mod

8310061: Note if implicit annotation processing is being used

Reviewed-by: vromero
Backport-of: 3df36c4f101e094d6f6beccadc004742b47d045a

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

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

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 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 jlahoda at openjdk.org  Thu Jun 29 13:30:03 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 29 Jun 2023 13:30:03 GMT
Subject: RFR: 8311038: Incorrect exhaustivity computation
Message-ID: <O0ux_r2SFBkYplgo6tHml1fgdgluKhE-QbE_u542TNc=.249c86c4-a181-4dd7-9b85-87b47608071b@github.com>

Consider this code:

public class Test {

    record Rec(Object t) {}

    private void test2() {
        Rec r = new Rec("test");
        int res = switch (r) {
            case Rec(String x): {
                yield x.length();
            }
            case Rec(Object x): {
                yield -3;
            }
        };
    }

}


It is obviously exhaustive (there's `Rec(Object x)`, which is unconditional on `Rec`), but javac fails to compile this code:

/tmp/Test.java:7: error: the switch expression does not cover all possible input values
        int res = switch (r) {
                  ^
1 error


The cause seems to be that when binding patterns for the (nested) `String` and `Object` are reduced, they are reduced to `String` and `ConstantDesc`, which is no longer exhaustive for `Object`.

This is a result of this code:
https://github.com/openjdk/jdk/blob/07734f6dde2b29574b6ef98eeb9e007d8801a3ea/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java#L886
which is intended to help with patterns that don't stand directly in the selector's hierarchy, like:
https://github.com/openjdk/jdk/blob/07734f6dde2b29574b6ef98eeb9e007d8801a3ea/test/langtools/tools/javac/patterns/Exhaustiveness.java#L1494
where `I3` is only related to the selector (`I`) via a permitted subtype.

Part of the problem is that `Object` is removed from the pattern set - adding `ConstantDesc` is not a problem. The proposal in this patch is to keep supertypes of the type that is being added in the pattern set. This will lead to pattern set `ConstantDesc`, `Object` and `String`, which should be OK for correctness, although generally enhancing the pattern set might slow down the processing.

There are two complicating factors, which make the observed bug surprising and difficult to diagnose:
 - if (in this example) `ConstantDesc` has not been completed yet, `.isSealed()` will return `false` for it, and the code will compile. This may happen when `x.length()` is removed/replaced in the example. This patch proposes to complete the Symbols before checking for sealedness.
 - it appears to be difficult to reproduce with a synthetic testcase, due to variations in ordering in maps. Hence this patch is using `String` in the testcase, as opposed to a test-only class.

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

Commit messages:
 - 8311038: Incorrect exhaustivity computation

Changes: https://git.openjdk.org/jdk/pull/14711/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14711&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311038
  Stats: 28 lines in 2 files changed: 26 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14711.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14711/head:pull/14711

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

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 vromero at openjdk.org  Thu Jun 29 15:05:55 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 29 Jun 2023 15:05:55 GMT
Subject: RFR: 8311038: Incorrect exhaustivity computation
In-Reply-To: <O0ux_r2SFBkYplgo6tHml1fgdgluKhE-QbE_u542TNc=.249c86c4-a181-4dd7-9b85-87b47608071b@github.com>
References: <O0ux_r2SFBkYplgo6tHml1fgdgluKhE-QbE_u542TNc=.249c86c4-a181-4dd7-9b85-87b47608071b@github.com>
Message-ID: <njxOcccwmih7GmeaMfJFSSsGBxpIyG4rp3kr-R7ceMM=.7c6e17b5-6ce3-4e11-830f-47ef74159d06@github.com>

On Thu, 29 Jun 2023 13:24:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this code:
> 
> public class Test {
> 
>     record Rec(Object t) {}
> 
>     private void test2() {
>         Rec r = new Rec("test");
>         int res = switch (r) {
>             case Rec(String x): {
>                 yield x.length();
>             }
>             case Rec(Object x): {
>                 yield -3;
>             }
>         };
>     }
> 
> }
> 
> 
> It is obviously exhaustive (there's `Rec(Object x)`, which is unconditional on `Rec`), but javac fails to compile this code:
> 
> /tmp/Test.java:7: error: the switch expression does not cover all possible input values
>         int res = switch (r) {
>                   ^
> 1 error
> 
> 
> The cause seems to be that when binding patterns for the (nested) `String` and `Object` are reduced, they are reduced to `String` and `ConstantDesc`, which is no longer exhaustive for `Object`.
> 
> This is a result of this code:
> https://github.com/openjdk/jdk/blob/07734f6dde2b29574b6ef98eeb9e007d8801a3ea/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java#L886
> which is intended to help with patterns that don't stand directly in the selector's hierarchy, like:
> https://github.com/openjdk/jdk/blob/07734f6dde2b29574b6ef98eeb9e007d8801a3ea/test/langtools/tools/javac/patterns/Exhaustiveness.java#L1494
> where `I3` is only related to the selector (`I`) via a permitted subtype.
> 
> Part of the problem is that `Object` is removed from the pattern set - adding `ConstantDesc` is not a problem. The proposal in this patch is to keep supertypes of the type that is being added in the pattern set. This will lead to pattern set `ConstantDesc`, `Object` and `String`, which should be OK for correctness, although generally enhancing the pattern set might slow down the processing.
> 
> There are two complicating factors, which make the observed bug surprising and difficult to diagnose:
>  - if (in this example) `ConstantDesc` has not been completed yet, `.isSealed()` will return `false` for it, and the code will compile. This may happen when `x.length()` is removed/replaced in the example. This patch proposes to complete the Symbols before checking for sealedness.
>  - it appears to be difficult to reproduce with a synthetic testcase, due to variations in ordering in maps. Hence this patch is using `String` in the testcase, as opposed to a test-only class.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14711#pullrequestreview-1505500822

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 asotona at openjdk.org  Thu Jun 29 16:34:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 29 Jun 2023 16:34:29 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v6]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <nGXlPVyTSblsi739gd_20d8wWS_SDroAygGJ1qv84iE=.f2955e08-c830-4865-9eea-01731cc48a1a@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> 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 222 commits:

 - throwing ConstantPoolException for invalid BSM entry index
 - Merge branch 'master' into JDK-8294969-javap
 - fixed JavapTask
 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
 - fixed build
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - ... and 212 more: https://git.openjdk.org/jdk/compare/07734f6d...adf79feb

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=05
  Stats: 3643 lines in 23 files changed: 839 ins; 1716 del; 1088 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

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 asotona at openjdk.org  Fri Jun 30 09:57:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 30 Jun 2023 09:57:26 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v7]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <agnWMhYDLijFGdeEO-Ez_eOcHz64220vPlozmqcOZlk=.b9691db0-ad82-4aad-9cc9-b5b3c3c8521a@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

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

  extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/adf79feb..28ee5f35

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

  Stats: 176 lines in 5 files changed: 162 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From mbaesken at openjdk.org  Fri Jun 30 10:02:01 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 10:02:01 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v2]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <Ykg6Amp7406I2u7bTQig2FG2o_g4ebNwgmWCgPOR_Ow=.2394846a-4734-4faf-8d38-77f05d98b95b@github.com>

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust comment in src/java.sql/share/classes/java/sql/DriverManager.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/5d52b4cb..6665f60b

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

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

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

From mbaesken at openjdk.org  Fri Jun 30 10:02:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 10:02:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v2]
In-Reply-To: <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
 <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
 <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>
Message-ID: <o1kCrnJzTAiEKF84HDgMZQltwIDLeTBOBXouGC5S_0E=.4087cdc2-b4db-4e35-80ed-72241aee7120@github.com>

On Wed, 28 Jun 2023 13:22:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
>>> 
>>> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`
>> 
>> It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.
>
> Hi Alan, thanks for clarifying.  So I should only adjust the comment, correct ?

Hi Alan, I adjusted the comment in DriverManager.java  .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1247686721

From mbaesken at openjdk.org  Fri Jun 30 11:37:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:37:10 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/6665f60b..9b2232a7

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

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

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

From asotona at openjdk.org  Fri Jun 30 13:17:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 30 Jun 2023 13:17:26 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v8]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <EC4fgvIj5RbHdRs7dWE-dNsh4IKxulMBgrZrsu3UctU=.30d64530-f510-4b31-a766-881c568e6567@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

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

  added DydnamicConstantPoolEntry::bootstrapMethodIndex
  fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/28ee5f35..834de482

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

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

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

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

From darcy at openjdk.org  Fri Jun 30 17:23:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Jun 2023 17:23:56 GMT
Subject: RFR: JDK-8310173: Update --release 21 symbol information for JDK 21
 build 29
Message-ID: <Zd7BbgvRokGwS7AJcDnXwsYn8iFUwy_h3JMOD9TSqYg=.ac3d1c19-0ac8-43c4-a79f-d279c1e3c412@github.com>

Looks like JDK-8310459 involved some updates to the vector API.

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

Commit messages:
 - JDK-8310173: Update --release 21 symbol information for JDK 21 build 29

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

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

From iris at openjdk.org  Fri Jun 30 17:34:55 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 30 Jun 2023 17:34:55 GMT
Subject: RFR: JDK-8310173: Update --release 21 symbol information for JDK
 21 build 29
In-Reply-To: <Zd7BbgvRokGwS7AJcDnXwsYn8iFUwy_h3JMOD9TSqYg=.ac3d1c19-0ac8-43c4-a79f-d279c1e3c412@github.com>
References: <Zd7BbgvRokGwS7AJcDnXwsYn8iFUwy_h3JMOD9TSqYg=.ac3d1c19-0ac8-43c4-a79f-d279c1e3c412@github.com>
Message-ID: <Dz4fJIZpIzlBcaINbKdAJ-UWFP4-fjYbu7GdpcqrfEw=.b4fb20aa-d74c-4765-a0e1-5c8961ac24d1@github.com>

On Fri, 30 Jun 2023 17:18:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Looks like JDK-8310459 involved some updates to the vector API.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14740#pullrequestreview-1507605501

From darcy at openjdk.org  Fri Jun 30 19:15:00 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Jun 2023 19:15:00 GMT
Subject: Integrated: JDK-8310173: Update --release 21 symbol information for
 JDK 21 build 29
In-Reply-To: <Zd7BbgvRokGwS7AJcDnXwsYn8iFUwy_h3JMOD9TSqYg=.ac3d1c19-0ac8-43c4-a79f-d279c1e3c412@github.com>
References: <Zd7BbgvRokGwS7AJcDnXwsYn8iFUwy_h3JMOD9TSqYg=.ac3d1c19-0ac8-43c4-a79f-d279c1e3c412@github.com>
Message-ID: <UZFhrnUVSB6SlmW9QlWmZBfWn2WaFMQc1bM2J5nmw9s=.32424c2e-56f4-49f5-83d7-ed5a196440be@github.com>

On Fri, 30 Jun 2023 17:18:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Looks like JDK-8310459 involved some updates to the vector API.

This pull request has now been integrated.

Changeset: 456bf115
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/456bf115aa6d8d2291790d01f54eb71b2e42eb77
Stats:     32 lines in 2 files changed: 0 ins; 31 del; 1 mod

8310173: Update --release 21 symbol information for JDK 21 build 29

Reviewed-by: iris

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

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