From darcy at openjdk.java.net  Wed Jun  1 03:18:44 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Jun 2022 03:18:44 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v4]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com>

> Time to start getting ready for JDK 20...

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

 - Adjust deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Respond to review feedback.
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - ... and 28 more: https://git.openjdk.java.net/jdk/compare/2ffc9a25...54e872b5

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/eedd36bd..54e872b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=02-03

  Stats: 1101 lines in 21 files changed: 708 ins; 170 del; 223 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From jjg at openjdk.java.net  Wed Jun  1 03:27:40 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 1 Jun 2022 03:27:40 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3]
In-Reply-To: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
Message-ID: <GmyrRLk_MX9e34aqLobfdvQjpkjXU5kY0t2JSikbE9Y=.07123259-b005-4395-b546-bf105c719ba6@github.com>

On Tue, 31 May 2022 20:32:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> 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 36 additional commits since the last revision:
> 
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbol information for JDK 19 b23.
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/44ff5c88...eedd36bd

langtools files look OK, although I did skim through the auto-generated new data/symbols files.

There are possibilities in the langtools file to simplify naming and default initialization of member fields in various places, in a separate PR, separate from these changes.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8236

From dholmes at openjdk.java.net  Wed Jun  1 04:44:39 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Jun 2022 04:44:39 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v4]
In-Reply-To: <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com>
Message-ID: <p6o4WrONmMn3MP2XfJ7lN8SCQEe3QJk03gt_i5R7K04=.9c343d94-dc8b-48c5-9756-6552a7cb16f9@github.com>

On Wed, 1 Jun 2022 03:18:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> 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 38 additional commits since the last revision:
> 
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 28 more: https://git.openjdk.java.net/jdk/compare/c1abb195...54e872b5

Updates look good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8236

From shade at openjdk.java.net  Wed Jun  1 06:05:39 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 06:05:39 GMT
Subject: Integrated: 8287520: Shrink x86_32 problemlists after JDK-8287437
In-Reply-To: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
Message-ID: <jIFGi8wjZIj-EwfNs7gLylJoHNocD_UjZEKWdMaZYPg=.cdc07e0e-b911-484f-a307-e27c97d8272f@github.com>

On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
> 
> Additional testing:
>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [x] GHA run

This pull request has now been integrated.

Changeset: 71599763
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/71599763359055c81afbe5e04d6034b7bb3f3606
Stats:     143 lines in 3 files changed: 0 ins; 142 del; 1 mod

8287520: Shrink x86_32 problemlists after JDK-8287437

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8946

From shade at openjdk.java.net  Wed Jun  1 06:36:55 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 06:36:55 GMT
Subject: RFR: 8287625: ProblemList jdk/jshell/HighlightUITest.java on all
 platforms
Message-ID: <y0qQZNmqAKzatIb4HW61mfVUX9ZEGNPLNnpPMtM3AcU=.db1410fd-8abf-4a32-992c-395bf7522d74@github.com>

There is now sighting on Windows x64 in GHA as well. I think it is time to problemlist the test on all platforms.

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/8965

From jlahoda at openjdk.java.net  Wed Jun  1 07:39:36 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 1 Jun 2022 07:39:36 GMT
Subject: RFR: 8287625: ProblemList jdk/jshell/HighlightUITest.java on all
 platforms
In-Reply-To: <y0qQZNmqAKzatIb4HW61mfVUX9ZEGNPLNnpPMtM3AcU=.db1410fd-8abf-4a32-992c-395bf7522d74@github.com>
References: <y0qQZNmqAKzatIb4HW61mfVUX9ZEGNPLNnpPMtM3AcU=.db1410fd-8abf-4a32-992c-395bf7522d74@github.com>
Message-ID: <AqL0XEzWy8mzQabd47IRM_zuQJqsyQqJ_jC7RPGQSfc=.5e8b406e-f25c-4d72-b50f-b799a9832725@github.com>

On Wed, 1 Jun 2022 06:29:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is now sighting on Windows x64 in GHA as well. I think it is time to problemlist the test on all platforms.

+1

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

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8965

From shade at openjdk.java.net  Wed Jun  1 15:00:39 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 15:00:39 GMT
Subject: Integrated: 8287625: ProblemList jdk/jshell/HighlightUITest.java on
 all platforms
In-Reply-To: <y0qQZNmqAKzatIb4HW61mfVUX9ZEGNPLNnpPMtM3AcU=.db1410fd-8abf-4a32-992c-395bf7522d74@github.com>
References: <y0qQZNmqAKzatIb4HW61mfVUX9ZEGNPLNnpPMtM3AcU=.db1410fd-8abf-4a32-992c-395bf7522d74@github.com>
Message-ID: <bhnNyPSDf7hW3ZtFTipi4lSsFbV7ZpxUjLEGy0ETDnc=.bbf630b0-8e6c-41a9-957a-d6dad5fe6f6d@github.com>

On Wed, 1 Jun 2022 06:29:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is now sighting on Windows x64 in GHA as well. I think it is time to problemlist the test on all platforms.

This pull request has now been integrated.

Changeset: 774928f9
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/774928f9447e961ec26a76e03dbf2143ffdcc05d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8287625: ProblemList jdk/jshell/HighlightUITest.java on all platforms

Reviewed-by: jlahoda

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

PR: https://git.openjdk.java.net/jdk/pull/8965

From shade at openjdk.java.net  Wed Jun  1 15:00:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 15:00:38 GMT
Subject: RFR: 8287625: ProblemList jdk/jshell/HighlightUITest.java on all
 platforms
In-Reply-To: <y0qQZNmqAKzatIb4HW61mfVUX9ZEGNPLNnpPMtM3AcU=.db1410fd-8abf-4a32-992c-395bf7522d74@github.com>
References: <y0qQZNmqAKzatIb4HW61mfVUX9ZEGNPLNnpPMtM3AcU=.db1410fd-8abf-4a32-992c-395bf7522d74@github.com>
Message-ID: <R5rq_a5eZW7uoPVNMScsDJT8rXcepBQl5Tt6dP8Cf34=.1c20d758-3e9f-49dd-9175-1dffa8e3ba06@github.com>

On Wed, 1 Jun 2022 06:29:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is now sighting on Windows x64 in GHA as well. I think it is time to problemlist the test on all platforms.

I am integrating to get cleaner GHA runs for everyone.

I am integrating to get cleaner GHA runs for everyone.

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

PR: https://git.openjdk.java.net/jdk/pull/8965

From mcimadamore at openjdk.java.net  Wed Jun  1 21:03:41 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 1 Jun 2022 21:03:41 GMT
Subject: RFR: 8287236: Reorganize AST related to pattern matching for
 switch [v2]
In-Reply-To: <qtLf3X0bR06ngl9cg9AeJGRjAoQ0xFq6swfVssTnyIQ=.283f2282-6edc-4783-80ce-d07cb21cf847@github.com>
References: <wPMQTWs7GB--mzTFHCTF-Ie8M-ps-tOfPZ5WsJ209vM=.8a3fde5b-c385-42cb-bb74-df6989a9f07c@github.com>
 <qtLf3X0bR06ngl9cg9AeJGRjAoQ0xFq6swfVssTnyIQ=.283f2282-6edc-4783-80ce-d07cb21cf847@github.com>
Message-ID: <0dl8SSLU9tLMnk5ycupgD7VN2gvZZsBOl60P15dz_UY=.7a3a8256-96c9-4063-8581-843b53a7ce1a@github.com>

On Tue, 31 May 2022 17:08:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Under JEP 427, case label elements may be: a) expressions; b) patterns; c) the default. Currently, this is modeled in the Trees API in a way where all expressions and patterns extend `CaseLabelTree`.
>> 
>> When guarded patterns were removed in favor of guards on pattern case label element, it was necessary to augment all patterns with a guard, which is only used when the pattern is used as a case label element. This is somewhat inconsistent for the Trees API.
>> 
>> A use a layer of indirection is proposed here: - the `CaseLabelTree` has three subtypes: `ConstantCaseLabelTree`, which contains `ExpressionTree` as a subnode; `PatternCaseLabelTree`, which contains `PatternTree` and a guard (`ExpressionTree`) as subnodes; and the `DefaultCaseLabelTree` for the default clause.
>> 
>> This patch also fixes `TreeScanner.visitCase`, which currently iterates only over `CaseTree.getExpressions()`, ignoring patterns. It is changed to iterate over `CaseTree.getLabels()`, to get all labels.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test.

Overall looks an improvement modelling-wise. Unfortunately the code seem to have gotten a bit more verbose, with all the `hasTag` check which sometimes are followed by casts. I added some suggestions to use pattern match, but if now, perhaps some helper methods in TreeInfo might help.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1719:

> 1717:                 boolean wasUnconditionalPattern = hasUnconditionalPattern;
> 1718:                 for (JCCaseLabel label : c.labels) {
> 1719:                     if (label.hasTag(CONSTANTCASELABEL)) {

Note here how we could use sealed types do do tests and cast with instanceof patterns. I know we have not used sealed types elsewhere, but in this particular case it seems particularly worthy, since you have a relatively small number of options, all of which need to be looked at. But even w/o sealing, pattern + instanceof could be useful. Not necessarily something to act on now - but I think methods like `hasTag` are starting to get a bit stale :-)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 741:

> 739:         private Set<Symbol> coveredSymbolsForCases(DiagnosticPosition pos,
> 740:                                                    JCExpression selector, List<JCCase> cases) {
> 741:             HashSet<JCTree> labels = cases.stream()

Is the name `labels` correct to identify the set of things returned by the stream? Aren't these either patterns or constant expressions? We probably miss a term for that entity. But it's confusing in the current code to just call them lables, because you can see in the stream expression that you go deeper inside the labels.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 756:

> 754:             Map<Symbol, List<JCRecordPattern>> deconstructionPatternsBySymbol = new HashMap<>();
> 755: 
> 756:             for (JCTree label : labels) {

Similar naming problem with `label` here.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2587:

> 2585:                     l.tail.head.labels.size() == 1 &&
> 2586:                     l.tail.head.labels.head.hasTag(CONSTANTCASELABEL) &&
> 2587:                     TreeInfo.isNull(((JCConstantCaseLabel) l.tail.head.labels.head).expr)) {

Patterns can help quite a bit here too


l.tail.head.labels.head instanceof JCConstantCaseLabel constantLabel &&
TreeInfo.isNull(constantLabel.expr)

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1302:

> 1300:             List<JCCase> l = cases;
> 1301:             for (int i = 0; i < labels.length; i++) {
> 1302:                 if (l.head.labels.head.hasTag(CONSTANTCASELABEL)) {

Another good one for patterns

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1304:

> 1302:                 if (l.head.labels.head.hasTag(CONSTANTCASELABEL)) {
> 1303:                     Assert.check(l.head.labels.size() == 1);
> 1304:                     int val = ((Number)((JCConstantCaseLabel) l.head.labels.head).expr.type.constValue()).intValue();

And here

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

PR: https://git.openjdk.java.net/jdk/pull/8959

From darcy at openjdk.java.net  Thu Jun  2 01:16:52 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Jun 2022 01:16:52 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
Message-ID: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>

Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.

The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

Commit messages:
 - JDK-8042981: Strip type annotations in Types' utility methods

Changes: https://git.openjdk.java.net/jdk/pull/8984/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8984&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8042981
  Stats: 193 lines in 4 files changed: 189 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8984.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8984/head:pull/8984

PR: https://git.openjdk.java.net/jdk/pull/8984

From jlahoda at openjdk.java.net  Thu Jun  2 10:55:44 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 2 Jun 2022 10:55:44 GMT
Subject: RFR: 8287236: Reorganize AST related to pattern matching for
 switch [v3]
In-Reply-To: <wPMQTWs7GB--mzTFHCTF-Ie8M-ps-tOfPZ5WsJ209vM=.8a3fde5b-c385-42cb-bb74-df6989a9f07c@github.com>
References: <wPMQTWs7GB--mzTFHCTF-Ie8M-ps-tOfPZ5WsJ209vM=.8a3fde5b-c385-42cb-bb74-df6989a9f07c@github.com>
Message-ID: <iDDVAzK3P4OfRiLR39jUyv0giDJX9J5sPYvPJkwl8ns=.1effd05f-63d4-424c-95d2-985104aa3806@github.com>

> Under JEP 427, case label elements may be: a) expressions; b) patterns; c) the default. Currently, this is modeled in the Trees API in a way where all expressions and patterns extend `CaseLabelTree`.
> 
> When guarded patterns were removed in favor of guards on pattern case label element, it was necessary to augment all patterns with a guard, which is only used when the pattern is used as a case label element. This is somewhat inconsistent for the Trees API.
> 
> A use a layer of indirection is proposed here: - the `CaseLabelTree` has three subtypes: `ConstantCaseLabelTree`, which contains `ExpressionTree` as a subnode; `PatternCaseLabelTree`, which contains `PatternTree` and a guard (`ExpressionTree`) as subnodes; and the `DefaultCaseLabelTree` for the default clause.
> 
> This patch also fixes `TreeScanner.visitCase`, which currently iterates only over `CaseTree.getExpressions()`, ignoring patterns. It is changed to iterate over `CaseTree.getLabels()`, to get all labels.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8959/files
  - new: https://git.openjdk.java.net/jdk/pull/8959/files/7a147c2f..a952c48d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8959&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8959&range=01-02

  Stats: 26 lines in 3 files changed: 2 ins; 1 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8959/head:pull/8959

PR: https://git.openjdk.java.net/jdk/pull/8959

From mcimadamore at openjdk.java.net  Thu Jun  2 14:08:14 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Jun 2022 14:08:14 GMT
Subject: RFR: 8287236: Reorganize AST related to pattern matching for
 switch [v3]
In-Reply-To: <iDDVAzK3P4OfRiLR39jUyv0giDJX9J5sPYvPJkwl8ns=.1effd05f-63d4-424c-95d2-985104aa3806@github.com>
References: <wPMQTWs7GB--mzTFHCTF-Ie8M-ps-tOfPZ5WsJ209vM=.8a3fde5b-c385-42cb-bb74-df6989a9f07c@github.com>
 <iDDVAzK3P4OfRiLR39jUyv0giDJX9J5sPYvPJkwl8ns=.1effd05f-63d4-424c-95d2-985104aa3806@github.com>
Message-ID: <b0E1wQOY20EJ1tkVmubqYmIwyb5q1vLPW1_GKEwLJAU=.603342f9-05d2-46b5-967e-6ba8192cfc80@github.com>

On Thu, 2 Jun 2022 10:55:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Under JEP 427, case label elements may be: a) expressions; b) patterns; c) the default. Currently, this is modeled in the Trees API in a way where all expressions and patterns extend `CaseLabelTree`.
>> 
>> When guarded patterns were removed in favor of guards on pattern case label element, it was necessary to augment all patterns with a guard, which is only used when the pattern is used as a case label element. This is somewhat inconsistent for the Trees API.
>> 
>> A use a layer of indirection is proposed here: - the `CaseLabelTree` has three subtypes: `ConstantCaseLabelTree`, which contains `ExpressionTree` as a subnode; `PatternCaseLabelTree`, which contains `PatternTree` and a guard (`ExpressionTree`) as subnodes; and the `DefaultCaseLabelTree` for the default clause.
>> 
>> This patch also fixes `TreeScanner.visitCase`, which currently iterates only over `CaseTree.getExpressions()`, ignoring patterns. It is changed to iterate over `CaseTree.getLabels()`, to get all labels.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments.

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8959

From shade at openjdk.java.net  Thu Jun  2 14:59:46 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Jun 2022 14:59:46 GMT
Subject: RFR: 8287732: jdk/jshell/ToolEnablePreviewTest.java fails on x86_32
 after JDK-8287496
Message-ID: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>

Manifests right now in x86_32 tier1 tests and GHA. The test tries to launch the tool via JDI/JVMTI, which does not fully work without continuations after [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496):


FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
  Exception: java.lang.InternalError: Failed remote launch: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679 @ com.sun.jdi.CommandLineLaunch (defaults: home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=, main=, suspend=true, quote=", vmexec=java, enumeratevthreads=n) -- {home=home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=options=--enable-preview, main=main=jdk.jshell.execution.RemoteExecutionControl 43679, suspend=suspend=true, quote=quote=", vmexec=vmexec=java, enumeratevthreads=enumeratevthreads=n}
                  jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
                  jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
                  jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:110)
                  jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
                  jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
      cause: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679
FailOverExecutionControlProvider: FAILED: 2:jdi --
  Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3

                  jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
                  jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:111)
                  jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
                  jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
                  jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)


I think test needs `@requires vm.continuations` as well.

Additional testing:
 - [x] Linux x86_32 `fastdebug`, affected test now skipped
 - [x] Linux x86_64 `fastdebug`, affected test still runs

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/8995

From hannesw at openjdk.java.net  Thu Jun  2 15:56:31 2022
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 2 Jun 2022 15:56:31 GMT
Subject: RFR: JDK-8287337: SnippetUtils should throw exceptions if snippets
 not found [v2]
In-Reply-To: <DUmSuSqVS7zzX9yn10gDa4c5avpX2saIYnk33u63t6s=.286975b3-0a1d-4adc-8369-d01a4b02ab04@github.com>
References: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>
 <DUmSuSqVS7zzX9yn10gDa4c5avpX2saIYnk33u63t6s=.286975b3-0a1d-4adc-8369-d01a4b02ab04@github.com>
Message-ID: <b8YWGj5iMYmZpQ7nvQwk6lyMuyxlw2p8QMXmsUa4HZ8=.22e5aafd-81fd-4592-b7f1-698135afbb92@github.com>

On Tue, 31 May 2022 23:43:34 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a simple change for `SnippetUtils` to throw a checked exception if a snippet cannot be found.
>
> Jonathan Gibbons 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 review feedback
>  - Merge remote-tracking branch 'upstream/master' into 8287337.snippetutils
>  - JDK-8287337: SnippetUtils should throw exceptions if snippets not found

The new version looks good to me. I hadn't even thought about the case of the missing comment, I like that it's handled explicitly now.

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

Marked as reviewed by hannesw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8892

From darcy at openjdk.java.net  Thu Jun  2 17:00:35 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Jun 2022 17:00:35 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>

> Time to start getting ready for JDK 20...

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

 - Update symbols for JDK 19 b25.
 - Merge branch 'master' into JDK-8284858
 - Adjust deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Respond to review feedback.
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7a25d65...e495a579

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/54e872b5..e495a579

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=03-04

  Stats: 7203 lines in 242 files changed: 5859 ins; 868 del; 476 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From alanb at openjdk.java.net  Thu Jun  2 19:01:33 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 19:01:33 GMT
Subject: RFR: 8287732: jdk/jshell/ToolEnablePreviewTest.java fails on
 x86_32 after JDK-8287496
In-Reply-To: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
References: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
Message-ID: <uu5RNt-xlkwLjqCy0jpSdSEAMi9GwHDpkne2xOsYfD0=.bc945402-efad-4b26-8809-97d774ec6190@github.com>

On Thu, 2 Jun 2022 14:50:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Manifests right now in x86_32 tier1 tests and GHA. The test tries to launch the tool via JDI/JVMTI, which does not fully work without continuations after [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496):
> 
> 
> FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
>   Exception: java.lang.InternalError: Failed remote launch: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679 @ com.sun.jdi.CommandLineLaunch (defaults: home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=, main=, suspend=true, quote=", vmexec=java, enumeratevthreads=n) -- {home=home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=options=--enable-preview, main=main=jdk.jshell.execution.RemoteExecutionControl 43679, suspend=suspend=true, quote=quote=", vmexec=vmexec=java, enumeratevthreads=enumeratevthreads=n}
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:110)
>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>       cause: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679
> FailOverExecutionControlProvider: FAILED: 2:jdi --
>   Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3
> 
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:111)
>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>                   jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)
> 
> 
> I think test needs `@requires vm.continuations` as well.
> 
> Additional testing:
>  - [x] Linux x86_32 `fastdebug`, affected test now skipped
>  - [x] Linux x86_64 `fastdebug`, affected test still runs

test/langtools/jdk/jshell/ToolEnablePreviewTest.java line 28:

> 26:  * @bug 8199193
> 27:  * @summary Tests for the --enable-preview option
> 28:  * @requires vm.continuations

This seems to be only jshell tests that uses --enable-preview so I think this is okay, just need to update the copyright year.

The update to TEST.ROOT looks okay, just surprised that tests in the langtools tree have never needed to specify requires properties before now.

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

PR: https://git.openjdk.java.net/jdk/pull/8995

From iris at openjdk.java.net  Thu Jun  2 21:29:37 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 2 Jun 2022 21:29:37 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
In-Reply-To: <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
Message-ID: <JHtXFR9mN8psVmhAOvRFenF52uKdoxjuVefqcVw1M4s=.39da768e-4da9-4dc4-aad5-4b7460bef47b@github.com>

On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> 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 40 additional commits since the last revision:
> 
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/5a6d202d...e495a579

Changes still look good.

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8236

From prappo at openjdk.java.net  Thu Jun  2 22:56:50 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 2 Jun 2022 22:56:50 GMT
Subject: RFR: 8287753: [spelling] close well-established compounds
Message-ID: <fsbCD-gMgzUChkasRfpB3svHu7h60ONJXi8527T2lzo=.e0a241d4-b099-4830-bf34-8d8341ff7d1f@github.com>

This is a spelling and terminology PR, not a code PR. Rationale for some of the changes are as follows:

* "Subsignature" is mentioned in JLS 8.4.2 Method Signature.
* lower- and upper- bounded wrt `super` and `extends` are mentioned in JLS 4.10.5 Type Projections.
* For "super super class" I used a great-grandparent analogy as I'm unaware of any rules on repeated prefixes in English.
* "subkind" is used on two more occasions a few lines above that change

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/9007/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9007&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287753
  Stats: 40 lines in 18 files changed: 0 ins; 0 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9007.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9007/head:pull/9007

PR: https://git.openjdk.java.net/jdk/pull/9007

From jjg at openjdk.java.net  Thu Jun  2 23:57:24 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 2 Jun 2022 23:57:24 GMT
Subject: Integrated: JDK-8287337: SnippetUtils should throw exceptions if
 snippets not found
In-Reply-To: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>
References: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>
Message-ID: <T24D-XiTalnIN3mhZBuYD9TQMVIwrdaolf6R06aNRNI=.cbf0d1cd-58ce-4482-8f8d-65e6529e7756@github.com>

On Wed, 25 May 2022 19:38:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple change for `SnippetUtils` to throw a checked exception if a snippet cannot be found.

This pull request has now been integrated.

Changeset: deb06539
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/deb06539b00e5fd5c29795277b2f90da0c9ff5d5
Stats:     45 lines in 2 files changed: 34 ins; 6 del; 5 mod

8287337: SnippetUtils should throw exceptions if snippets not found

Reviewed-by: hannesw

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

PR: https://git.openjdk.java.net/jdk/pull/8892

From shade at openjdk.java.net  Fri Jun  3 05:54:21 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 05:54:21 GMT
Subject: RFR: 8287732: jdk/jshell/ToolEnablePreviewTest.java fails on
 x86_32 after JDK-8287496 [v2]
In-Reply-To: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
References: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
Message-ID: <fRMvu8VpjEsCG4p8psL9cP9PWAYIydlxqX_QjJj3344=.a9bc4d3e-d669-4c6c-a18b-842ca7dbff00@github.com>

> Manifests right now in x86_32 tier1 tests and GHA. The test tries to launch the tool via JDI/JVMTI, which does not fully work without continuations after [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496):
> 
> 
> FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
>   Exception: java.lang.InternalError: Failed remote launch: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679 @ com.sun.jdi.CommandLineLaunch (defaults: home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=, main=, suspend=true, quote=", vmexec=java, enumeratevthreads=n) -- {home=home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=options=--enable-preview, main=main=jdk.jshell.execution.RemoteExecutionControl 43679, suspend=suspend=true, quote=quote=", vmexec=vmexec=java, enumeratevthreads=enumeratevthreads=n}
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:110)
>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>       cause: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679
> FailOverExecutionControlProvider: FAILED: 2:jdi --
>   Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3
> 
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:111)
>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>                   jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)
> 
> 
> I think test needs `@requires vm.continuations` as well.
> 
> Additional testing:
>  - [x] Linux x86_32 `fastdebug`, affected test now skipped
>  - [x] Linux x86_64 `fastdebug`, affected test still runs

Aleksey Shipilev 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:

 - Copyright updates
 - Merge branch 'master' into JDK-8287732-loom-tool-enable-preview
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8995/files
  - new: https://git.openjdk.java.net/jdk/pull/8995/files/71b54a5b..de2b8036

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8995&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8995&range=00-01

  Stats: 294 lines in 88 files changed: 165 ins; 84 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8995.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8995/head:pull/8995

PR: https://git.openjdk.java.net/jdk/pull/8995

From shade at openjdk.java.net  Fri Jun  3 05:54:22 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 05:54:22 GMT
Subject: RFR: 8287732: jdk/jshell/ToolEnablePreviewTest.java fails on
 x86_32 after JDK-8287496 [v2]
In-Reply-To: <uu5RNt-xlkwLjqCy0jpSdSEAMi9GwHDpkne2xOsYfD0=.bc945402-efad-4b26-8809-97d774ec6190@github.com>
References: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
 <uu5RNt-xlkwLjqCy0jpSdSEAMi9GwHDpkne2xOsYfD0=.bc945402-efad-4b26-8809-97d774ec6190@github.com>
Message-ID: <jHVcPZ8GNmRlteH_oxDpmti_p3OJbCzV_eb7XbSz8rw=.ecf96fa0-f6a0-4069-a424-ea59162d666f@github.com>

On Thu, 2 Jun 2022 18:58:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev 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:
>> 
>>  - Copyright updates
>>  - Merge branch 'master' into JDK-8287732-loom-tool-enable-preview
>>  - Fix
>
> test/langtools/jdk/jshell/ToolEnablePreviewTest.java line 28:
> 
>> 26:  * @bug 8199193
>> 27:  * @summary Tests for the --enable-preview option
>> 28:  * @requires vm.continuations
> 
> This seems to be only jshell teststhat uses --enable-preview so I think this is okay, just need to update the copyright year.
> 
> The update to TEST.ROOT looks okay, just surprised that tests in the langtools tree have never needed to specify requires properties before now.

Updated.

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

PR: https://git.openjdk.java.net/jdk/pull/8995

From alanb at openjdk.java.net  Fri Jun  3 06:16:24 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Jun 2022 06:16:24 GMT
Subject: RFR: 8287732: jdk/jshell/ToolEnablePreviewTest.java fails on
 x86_32 after JDK-8287496 [v2]
In-Reply-To: <fRMvu8VpjEsCG4p8psL9cP9PWAYIydlxqX_QjJj3344=.a9bc4d3e-d669-4c6c-a18b-842ca7dbff00@github.com>
References: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
 <fRMvu8VpjEsCG4p8psL9cP9PWAYIydlxqX_QjJj3344=.a9bc4d3e-d669-4c6c-a18b-842ca7dbff00@github.com>
Message-ID: <I0Nkg8ZgNqPmNKhq0u33lKZA4pMjrzxOVM7s6osR0Ys=.22a22782-8a37-4390-91d5-6ec682d3be2f@github.com>

On Fri, 3 Jun 2022 05:54:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Manifests right now in x86_32 tier1 tests and GHA. The test tries to launch the tool via JDI/JVMTI, which does not fully work without continuations after [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496):
>> 
>> 
>> FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
>>   Exception: java.lang.InternalError: Failed remote launch: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679 @ com.sun.jdi.CommandLineLaunch (defaults: home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=, main=, suspend=true, quote=", vmexec=java, enumeratevthreads=n) -- {home=home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=options=--enable-preview, main=main=jdk.jshell.execution.RemoteExecutionControl 43679, suspend=suspend=true, quote=quote=", vmexec=vmexec=java, enumeratevthreads=enumeratevthreads=n}
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:110)
>>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>>       cause: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679
>> FailOverExecutionControlProvider: FAILED: 2:jdi --
>>   Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3
>> 
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:111)
>>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>>                   jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)
>> 
>> 
>> I think test needs `@requires vm.continuations` as well.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 `fastdebug`, affected test now skipped
>>  - [x] Linux x86_64 `fastdebug`, affected test still runs
>
> Aleksey Shipilev 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:
> 
>  - Copyright updates
>  - Merge branch 'master' into JDK-8287732-loom-tool-enable-preview
>  - Fix

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8995

From jlahoda at openjdk.java.net  Fri Jun  3 10:22:15 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Jun 2022 10:22:15 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v3]
In-Reply-To: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
Message-ID: <76agXbVWiCtcXkp1a8cD9UoTEXj1pSdWWiqVVXIs2R0=.6301c93e-de95-451f-81cc-c9988de50469@github.com>

> [This is a GitHub copy of: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014389.html ]
> 
> Currently, (com.sun.tools.javac.code.)Symbol/s have a long field "flags_field", which holds various one-bit information ("Flags") about the given Symbol.
> 
> We currently have around 64 such Flags, which means we are out of bits in the long field, and adding new flags is not easy.
> 
> We could change the "flags_field" to be a Set over enums, but this would increase the memory footprint notably, and would also slow-down access to flags. Currently, flags operations in javac are very fast and very common, so this is probably too much burden. There are also flags to which we need to access as bit masks, e.g. due to writing to classfile.
> 
> My proposal here is to use an intermediate solution, until we find a better solution, or until a better solution is possible (like due to Valhalla). The idea is as follows:
> -the current long-based Flags are split into 4 groups:
> --"flat" Flags, long based, work exactly as before.
> --enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, respectively, and are checked using methods like Symbol.isFlagSet and set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these flags are mostly encapsulated, even though physically they are currently stored in the flags_field as well.
> 
> There are ~~37~~ 40 "flat" flags and ~~16~~ 17 TypeSymbolFlags (methods and vars have less flags), 57 in total. This gives us at least 7 new flags before we run out of long bits in flags_field again - but even if we do, there are several easy mitigation strategies we could use, like:
> -create a new int/long field on TypeSymbols for the TypeSymbolFlags (probably preferable)
> -split TypeSymbolFlags into Class/Package/MethodSymbolFlags
> 
> The positives of this solution include:
> -safe(r) access to the flags - the access to the extra/symbol-kind-specific flags is mostly encapsulated, and hence mostly safe
> -improves the abstractions at least for some flags
> -reasonably complex patch (attempts to encapsulate all the flags were troublesome in previous experiments)
> -the performances appears to be acceptable.
> 
> The negative that I see is that the code includes several incompatible types of flags now. These cannot be easily confused by accident (as the type system will complain), but still we need to be aware of them when writing code.
> 
> Some more alternatives:
> -add a new field to Symbol, like long extraFlags, and continue with bit masks as we did so far using this new field. The drawback is that it is more error prone (it would be difficult to ensure only the new/extra flags would be stored and read from extraFlags).
> -have a new field, and "flat" and non-"flat" enum-based encapsulated Flags, but don't separate Type/Method/Var flags. Probably something to consider, even though I am a bit reluctant to add new fields without trying to avoid it .
> 
> Any feedback is welcome!

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Cleanup.
 - Merge branch 'master' into JDK-8241356
 - Removing merge tags are noted on the review - thanks!
 - Whitespaces.
 - Cleanup.
 - Merging master into JDK-8241356
 - 8241356: Use a more reliable way to encode Symbol flags

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

Changes: https://git.openjdk.java.net/jdk/pull/2316/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2316&range=02
  Stats: 800 lines in 31 files changed: 341 ins; 211 del; 248 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2316.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2316/head:pull/2316

PR: https://git.openjdk.java.net/jdk/pull/2316

From shade at openjdk.java.net  Fri Jun  3 10:38:26 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 10:38:26 GMT
Subject: RFR: 8287732: jdk/jshell/ToolEnablePreviewTest.java fails on
 x86_32 after JDK-8287496 [v2]
In-Reply-To: <fRMvu8VpjEsCG4p8psL9cP9PWAYIydlxqX_QjJj3344=.a9bc4d3e-d669-4c6c-a18b-842ca7dbff00@github.com>
References: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
 <fRMvu8VpjEsCG4p8psL9cP9PWAYIydlxqX_QjJj3344=.a9bc4d3e-d669-4c6c-a18b-842ca7dbff00@github.com>
Message-ID: <lOc5BqPyTxbTMwcLrh9WRDxtC6IPKYehT82iv98RZJo=.26097964-700c-4bbe-8261-19b21327bfcc@github.com>

On Fri, 3 Jun 2022 05:54:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Manifests right now in x86_32 tier1 tests and GHA. The test tries to launch the tool via JDI/JVMTI, which does not fully work without continuations after [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496):
>> 
>> 
>> FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
>>   Exception: java.lang.InternalError: Failed remote launch: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679 @ com.sun.jdi.CommandLineLaunch (defaults: home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=, main=, suspend=true, quote=", vmexec=java, enumeratevthreads=n) -- {home=home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=options=--enable-preview, main=main=jdk.jshell.execution.RemoteExecutionControl 43679, suspend=suspend=true, quote=quote=", vmexec=vmexec=java, enumeratevthreads=enumeratevthreads=n}
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:110)
>>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>>       cause: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679
>> FailOverExecutionControlProvider: FAILED: 2:jdi --
>>   Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3
>> 
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:111)
>>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>>                   jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)
>> 
>> 
>> I think test needs `@requires vm.continuations` as well.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 `fastdebug`, affected test now skipped
>>  - [x] Linux x86_64 `fastdebug`, affected test still runs
>
> Aleksey Shipilev 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:
> 
>  - Copyright updates
>  - Merge branch 'master' into JDK-8287732-loom-tool-enable-preview
>  - Fix

Thank you, any more reviews?

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

PR: https://git.openjdk.java.net/jdk/pull/8995

From jjg at openjdk.java.net  Fri Jun  3 15:31:35 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Jun 2022 15:31:35 GMT
Subject: RFR: 8287753: [spelling] close well-established compounds
In-Reply-To: <fsbCD-gMgzUChkasRfpB3svHu7h60ONJXi8527T2lzo=.e0a241d4-b099-4830-bf34-8d8341ff7d1f@github.com>
References: <fsbCD-gMgzUChkasRfpB3svHu7h60ONJXi8527T2lzo=.e0a241d4-b099-4830-bf34-8d8341ff7d1f@github.com>
Message-ID: <LKomA0PhxJab0t5xIu5kDQ_NovN82036hMrNg53JWjI=.a3b76e89-eb29-430b-8a91-211c75db1d50@github.com>

On Thu, 2 Jun 2022 22:48:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This is a spelling and terminology PR, not a code PR. Rationale for some of the changes are as follows:
> 
> * "Subsignature" is mentioned in JLS 8.4.2 Method Signature.
> * lower- and upper- bounded wrt `super` and `extends` are mentioned in JLS 4.10.5 Type Projections.
> * For "super super class" I used a great-grandparent analogy as I'm unaware of any rules on repeated prefixes in English.
> * "subkind" is used on two more occasions a few lines above that change

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9007

From prappo at openjdk.java.net  Sat Jun  4 15:59:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 4 Jun 2022 15:59:34 GMT
Subject: Integrated: 8287753: [spelling] close well-established compounds
In-Reply-To: <fsbCD-gMgzUChkasRfpB3svHu7h60ONJXi8527T2lzo=.e0a241d4-b099-4830-bf34-8d8341ff7d1f@github.com>
References: <fsbCD-gMgzUChkasRfpB3svHu7h60ONJXi8527T2lzo=.e0a241d4-b099-4830-bf34-8d8341ff7d1f@github.com>
Message-ID: <owYSjd09VuU3hugbaUchkAjKFLGgiRrnThdmfvg9jdI=.eabaf549-1ccf-4b1e-b4d5-4342a7657daa@github.com>

On Thu, 2 Jun 2022 22:48:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This is a spelling and terminology PR, not a code PR. Rationale for some of the changes are as follows:
> 
> * "Subsignature" is mentioned in JLS 8.4.2 Method Signature.
> * lower- and upper- bounded wrt `super` and `extends` are mentioned in JLS 4.10.5 Type Projections.
> * For "super super class" I used a great-grandparent analogy as I'm unaware of any rules on repeated prefixes in English.
> * "subkind" is used on two more occasions a few lines above that change

This pull request has now been integrated.

Changeset: a6fc485a
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6fc485a22484b70daf170e981432c0856b9d93d
Stats:     40 lines in 18 files changed: 0 ins; 0 del; 40 mod

8287753: [spelling] close well-established compounds

Reviewed-by: jjg

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

PR: https://git.openjdk.java.net/jdk/pull/9007

From kvn at openjdk.java.net  Sat Jun  4 16:10:25 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 4 Jun 2022 16:10:25 GMT
Subject: RFR: 8287732: jdk/jshell/ToolEnablePreviewTest.java fails on
 x86_32 after JDK-8287496 [v2]
In-Reply-To: <fRMvu8VpjEsCG4p8psL9cP9PWAYIydlxqX_QjJj3344=.a9bc4d3e-d669-4c6c-a18b-842ca7dbff00@github.com>
References: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
 <fRMvu8VpjEsCG4p8psL9cP9PWAYIydlxqX_QjJj3344=.a9bc4d3e-d669-4c6c-a18b-842ca7dbff00@github.com>
Message-ID: <tuVYqFTpxVNOvUqN4HQfyGNkIoEhNMecWOSJxdbl81Q=.40e3ccce-83af-4c77-971f-7690191fd5f9@github.com>

On Fri, 3 Jun 2022 05:54:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Manifests right now in x86_32 tier1 tests and GHA. The test tries to launch the tool via JDI/JVMTI, which does not fully work without continuations after [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496):
>> 
>> 
>> FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
>>   Exception: java.lang.InternalError: Failed remote launch: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679 @ com.sun.jdi.CommandLineLaunch (defaults: home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=, main=, suspend=true, quote=", vmexec=java, enumeratevthreads=n) -- {home=home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=options=--enable-preview, main=main=jdk.jshell.execution.RemoteExecutionControl 43679, suspend=suspend=true, quote=quote=", vmexec=vmexec=java, enumeratevthreads=enumeratevthreads=n}
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:110)
>>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>>       cause: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679
>> FailOverExecutionControlProvider: FAILED: 2:jdi --
>>   Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3
>> 
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:111)
>>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>>                   jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)
>> 
>> 
>> I think test needs `@requires vm.continuations` as well.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 `fastdebug`, affected test now skipped
>>  - [x] Linux x86_64 `fastdebug`, affected test still runs
>
> Aleksey Shipilev 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:
> 
>  - Copyright updates
>  - Merge branch 'master' into JDK-8287732-loom-tool-enable-preview
>  - Fix

Looks good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8995

From shade at openjdk.java.net  Mon Jun  6 05:32:48 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Jun 2022 05:32:48 GMT
Subject: RFR: 8287732: jdk/jshell/ToolEnablePreviewTest.java fails on
 x86_32 after JDK-8287496 [v2]
In-Reply-To: <fRMvu8VpjEsCG4p8psL9cP9PWAYIydlxqX_QjJj3344=.a9bc4d3e-d669-4c6c-a18b-842ca7dbff00@github.com>
References: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
 <fRMvu8VpjEsCG4p8psL9cP9PWAYIydlxqX_QjJj3344=.a9bc4d3e-d669-4c6c-a18b-842ca7dbff00@github.com>
Message-ID: <mw0eRBcTYqM9vlVDYWrnslDI9QqLqvsmIVVrQ8l3hOQ=.34bcf9bf-011f-4676-833a-75e2d5accb90@github.com>

On Fri, 3 Jun 2022 05:54:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Manifests right now in x86_32 tier1 tests and GHA. The test tries to launch the tool via JDI/JVMTI, which does not fully work without continuations after [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496):
>> 
>> 
>> FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
>>   Exception: java.lang.InternalError: Failed remote launch: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679 @ com.sun.jdi.CommandLineLaunch (defaults: home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=, main=, suspend=true, quote=", vmexec=java, enumeratevthreads=n) -- {home=home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=options=--enable-preview, main=main=jdk.jshell.execution.RemoteExecutionControl 43679, suspend=suspend=true, quote=quote=", vmexec=vmexec=java, enumeratevthreads=enumeratevthreads=n}
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:110)
>>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>>       cause: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679
>> FailOverExecutionControlProvider: FAILED: 2:jdi --
>>   Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3
>> 
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
>>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:111)
>>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>>                   jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)
>> 
>> 
>> I think test needs `@requires vm.continuations` as well.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 `fastdebug`, affected test now skipped
>>  - [x] Linux x86_64 `fastdebug`, affected test still runs
>
> Aleksey Shipilev 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:
> 
>  - Copyright updates
>  - Merge branch 'master' into JDK-8287732-loom-tool-enable-preview
>  - Fix

Thank you!

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

PR: https://git.openjdk.java.net/jdk/pull/8995

From shade at openjdk.java.net  Mon Jun  6 05:32:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Jun 2022 05:32:49 GMT
Subject: Integrated: 8287732: jdk/jshell/ToolEnablePreviewTest.java fails on
 x86_32 after JDK-8287496
In-Reply-To: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
References: <-J2L9ETLN2yM9Edov2A6mJQ6QO5sbSwWsstzbFlxgEE=.185ac61a-8b81-4cdd-b560-84d1a129ab27@github.com>
Message-ID: <jt5YXaP7zYpDFPrcWJlM2-cMIbqEjRtwjKfOiYWG5n0=.5103de72-da09-4933-ae1c-9ea2e3bcf0df@github.com>

On Thu, 2 Jun 2022 14:50:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Manifests right now in x86_32 tier1 tests and GHA. The test tries to launch the tool via JDI/JVMTI, which does not fully work without continuations after [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496):
> 
> 
> FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
>   Exception: java.lang.InternalError: Failed remote launch: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679 @ com.sun.jdi.CommandLineLaunch (defaults: home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=, main=, suspend=true, quote=", vmexec=java, enumeratevthreads=n) -- {home=home=/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk, options=options=--enable-preview, main=main=jdk.jshell.execution.RemoteExecutionControl 43679, suspend=suspend=true, quote=quote=", vmexec=vmexec=java, enumeratevthreads=enumeratevthreads=n}
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:110)
>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>       cause: java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/images/jdk/bin/java --enable-preview -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:51453,suspend=y,enumeratevthreads=n jdk.jshell.execution.RemoteExecutionControl 43679
> FailOverExecutionControlProvider: FAILED: 2:jdi --
>   Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3
> 
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
>                   jdk.jshell/jdk.jshell.execution.JdiInitiator.<init>(JdiInitiator.java:111)
>                   jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
>                   jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
>                   jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)
> 
> 
> I think test needs `@requires vm.continuations` as well.
> 
> Additional testing:
>  - [x] Linux x86_32 `fastdebug`, affected test now skipped
>  - [x] Linux x86_64 `fastdebug`, affected test still runs

This pull request has now been integrated.

Changeset: 0d1a3053
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0d1a3053cd25dc666981c5aedfa5efc2dc95bd0e
Stats:     16 lines in 2 files changed: 15 ins; 0 del; 1 mod

8287732: jdk/jshell/ToolEnablePreviewTest.java fails on x86_32 after JDK-8287496

Reviewed-by: alanb, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/8995

From jlahoda at openjdk.java.net  Mon Jun  6 10:46:07 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 6 Jun 2022 10:46:07 GMT
Subject: RFR: 8287808: javac generates illegal class file for pattern matching
 switch with records
Message-ID: <sA_Fn8LdP9_mi4y1jFUJ3t-adLy0Y2YWgcehgqBO1_I=.7c6e3c2c-b82a-414b-b580-e4446cda4001@github.com>

For record patterns, javac generates proxy methods for accessors, to properly wrap exceptions. These proxies are currently generated as package private, which is not valid for interfaces. Using private methods should be better.

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

Commit messages:
 - 8287808: javac generates illegal class file for pattern matching switch with records

Changes: https://git.openjdk.java.net/jdk/pull/9039/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9039&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287808
  Stats: 12 lines in 4 files changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9039/head:pull/9039

PR: https://git.openjdk.java.net/jdk/pull/9039

From jlahoda at openjdk.java.net  Mon Jun  6 14:49:05 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 6 Jun 2022 14:49:05 GMT
Subject: RFR: 8286206: Missing cases for RECORD
Message-ID: <ZYWClWU13X886-pVUQg1Nnhz5poSSmDRhULECJQQZFM=.4d2d0bee-566f-41f6-80b1-b28bfb67a646@github.com>

Adds handling of `ElementKind.RECORD` to JShell's code completion.

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

Commit messages:
 - 8286206: Missing cases for RECORD

Changes: https://git.openjdk.java.net/jdk/pull/9042/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9042&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286206
  Stats: 40 lines in 3 files changed: 31 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9042.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9042/head:pull/9042

PR: https://git.openjdk.java.net/jdk/pull/9042

From vromero at openjdk.java.net  Mon Jun  6 20:35:47 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 6 Jun 2022 20:35:47 GMT
Subject: RFR: 8286206: Missing cases for RECORD
In-Reply-To: <ZYWClWU13X886-pVUQg1Nnhz5poSSmDRhULECJQQZFM=.4d2d0bee-566f-41f6-80b1-b28bfb67a646@github.com>
References: <ZYWClWU13X886-pVUQg1Nnhz5poSSmDRhULECJQQZFM=.4d2d0bee-566f-41f6-80b1-b28bfb67a646@github.com>
Message-ID: <AqZavwrt1Z07b94Pl4PSidLwwVLkUYF-8elEZ9Pn0q4=.5156a238-4d97-45f7-821b-3231ae1790c7@github.com>

On Mon, 6 Jun 2022 14:40:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adds handling of `ElementKind.RECORD` to JShell's code completion.

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9042

From jjg at openjdk.java.net  Mon Jun  6 20:35:51 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 6 Jun 2022 20:35:51 GMT
Subject: RFR: 8286206: Missing cases for RECORD
In-Reply-To: <ZYWClWU13X886-pVUQg1Nnhz5poSSmDRhULECJQQZFM=.4d2d0bee-566f-41f6-80b1-b28bfb67a646@github.com>
References: <ZYWClWU13X886-pVUQg1Nnhz5poSSmDRhULECJQQZFM=.4d2d0bee-566f-41f6-80b1-b28bfb67a646@github.com>
Message-ID: <YInk6Byr2I_wXd1ZfIthV26tL-q_DR-PvHYohvGaT9w=.28798c04-9c6e-4b94-aa34-8bd85dee8be5@github.com>

On Mon, 6 Jun 2022 14:40:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adds handling of `ElementKind.RECORD` to JShell's code completion.

I can't easily verify whether you have found all the necessary places to update, but I do understand/approve what I see here.

On switch statements, like at JavadocHelper:701, would it help to list the cases now covered by default, and use `default` as an "error" to catch unhandled new cases in future?

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9042

From duke at openjdk.java.net  Tue Jun  7 00:54:27 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Tue, 7 Jun 2022 00:54:27 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used
Message-ID: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>

8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

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

Commit messages:
 - 8287760: Keep do-not-resolve-by-default flag

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

PR: https://git.openjdk.java.net/jdk/pull/9049

From joe.darcy at oracle.com  Tue Jun  7 01:54:09 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 6 Jun 2022 18:54:09 -0700
Subject: Mandated/implicit parameters
In-Reply-To: <bf8d0723-91f5-b9b3-14d0-84d54a49ed04@oracle.com>
References: <AM0PR03MB4577A0135FC226906946623FAFD79@AM0PR03MB4577.eurprd03.prod.outlook.com>
 <bf8d0723-91f5-b9b3-14d0-84d54a49ed04@oracle.com>
Message-ID: <c7f37d4b-606b-905f-e517-d13d58e2218e@oracle.com>


On 5/24/2022 8:52 AM, Alex Buckley wrote:
> On 5/23/2022 11:27 PM, Hannes Greule wrote:
>> I came across an oddity when using the Parameter#isImplicit()[1] method.
>> According to its documentation, it returns true if the parameter is 
>> implicitly
>> declared in source code. ...
>> However, it seems like the information is only embedded when compiling
>> with the -parameters flag.
>>
>> From my understanding of the given section in the JLS, the mandated flag
>> should *always* be emitted. Is this a bug, or am I missing something?
>
> In principle, the isImplicit() status of a parameter at run time 
> should not depend on whether -parameters was given at compile time. 
> Unfortunately, the class file bit that records "implicitly declared", 
> for use by isImplicit(), is located in the MethodParameters attribute 
> (JVMS 4.7.24) that is only emitted when -parameters is given.
>
> It would be legitimate to emit MethodParameters without -parameters, 
> so as to record `final` and "implicitly declared" but not the 
> parameter name, but at some cost to implementation complexity in 
> java.lang.reflect.
>
>> Looking into it a bit deeper, it also seems like the parameters of a 
>> compact
>> constructor for records are never marked as mandated, even when 
>> compiling with
>> the -parameters flag (but the MethodParameters attribute is always 
>> written
>> or record constructors).
>
> That is weird, and sounds like a javac bug.
>

JDK-8234908: consider if the MANDATED flag should be applied to record 
members added by the compiler
https://bugs.openjdk.org/browse/JDK-8234908

-Joe


From darcy at openjdk.java.net  Tue Jun  7 05:11:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 7 Jun 2022 05:11:45 GMT
Subject: RFR: JDK-8287886: Further terminology updates to match JLS
Message-ID: <nm2wDZHpCXIsZ_vGDiuG0-M7pLisZ8kI7_qYQ0rNk_4=.8506b5d8-8021-4c8b-bf1e-8ad4d23e3f77@github.com>

Work previously done under [JDK-8257638](https://bugs.openjdk.org/browse/JDK-8257638) missed some cases.

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

Commit messages:
 - JDK-8287886: Further terminology updates to match JLS

Changes: https://git.openjdk.java.net/jdk/pull/9052/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9052&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287886
  Stats: 63 lines in 6 files changed: 3 ins; 0 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9052.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9052/head:pull/9052

PR: https://git.openjdk.java.net/jdk/pull/9052

From alanb at openjdk.java.net  Tue Jun  7 07:15:12 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Jun 2022 07:15:12 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <7FbQ0t2ZDkLR2vH7Jju8sG7EsY9-kTwVnP_epkxESb0=.f69a5c18-bf10-4e27-a998-857927f40edc@github.com>

On Tue, 7 Jun 2022 00:45:17 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

The change looks okay but I think we should add a test. You'll have to check the test tree to see if there are existing tests for incubator modules packages as JAR files, there may not be as it's an unusual setup.

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

PR: https://git.openjdk.java.net/jdk/pull/9049

From sundar at openjdk.java.net  Tue Jun  7 08:14:04 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Tue, 7 Jun 2022 08:14:04 GMT
Subject: RFR: 8287808: javac generates illegal class file for pattern
 matching switch with records
In-Reply-To: <sA_Fn8LdP9_mi4y1jFUJ3t-adLy0Y2YWgcehgqBO1_I=.7c6e3c2c-b82a-414b-b580-e4446cda4001@github.com>
References: <sA_Fn8LdP9_mi4y1jFUJ3t-adLy0Y2YWgcehgqBO1_I=.7c6e3c2c-b82a-414b-b580-e4446cda4001@github.com>
Message-ID: <kXgxGtMs7f44nkiE0rCMxEVbAKc1qpNtMsucMsO9oLc=.25cd1d55-c5b6-40ef-bb20-5e3bb8f656a9@github.com>

On Mon, 6 Jun 2022 10:39:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For record patterns, javac generates proxy methods for accessors, to properly wrap exceptions. These proxies are currently generated as package private, which is not valid for interfaces. Using private methods should be better.

LGTM

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

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9039

From jlahoda at openjdk.java.net  Tue Jun  7 09:33:06 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 7 Jun 2022 09:33:06 GMT
Subject: RFR: 8286206: Missing cases for RECORD [v2]
In-Reply-To: <ZYWClWU13X886-pVUQg1Nnhz5poSSmDRhULECJQQZFM=.4d2d0bee-566f-41f6-80b1-b28bfb67a646@github.com>
References: <ZYWClWU13X886-pVUQg1Nnhz5poSSmDRhULECJQQZFM=.4d2d0bee-566f-41f6-80b1-b28bfb67a646@github.com>
Message-ID: <fzKaqEkJDr4oVvWnUtT_XL1XwkrV5ucjN-tk_wMeD98=.5ad3b5bf-75b7-4fa6-929d-4862d92d1eac@github.com>

> Adds handling of `ElementKind.RECORD` to JShell's code completion.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Listing all possible elements as suggested.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9042/files
  - new: https://git.openjdk.java.net/jdk/pull/9042/files/9067d979..6a7e8bd3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9042&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9042&range=00-01

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9042.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9042/head:pull/9042

PR: https://git.openjdk.java.net/jdk/pull/9042

From ihse at openjdk.java.net  Tue Jun  7 10:17:33 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 7 Jun 2022 10:17:33 GMT
Subject: RFR: 8287895: Some langtools tests fail on msys2
Message-ID: <lw0jfruseupJnx6SQfT8zyt4JYqqaZQ_yQMB9pU9xLM=.c1498702-ea14-4230-af50-21fd81e31c9c@github.com>

A bunch of langtools tests, which all rely on `test/langtools/tools/javac/Paths/Util.sh`, fails when run on Windows with msys2, since this environment is not properly detected.

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

Commit messages:
 - 8287895: Some langtools tests fail on msys2

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

PR: https://git.openjdk.java.net/jdk/pull/9056

From ihse at openjdk.java.net  Tue Jun  7 10:21:48 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 7 Jun 2022 10:21:48 GMT
Subject: RFR: 8287895: Some langtools tests fail on msys2 [v2]
In-Reply-To: <lw0jfruseupJnx6SQfT8zyt4JYqqaZQ_yQMB9pU9xLM=.c1498702-ea14-4230-af50-21fd81e31c9c@github.com>
References: <lw0jfruseupJnx6SQfT8zyt4JYqqaZQ_yQMB9pU9xLM=.c1498702-ea14-4230-af50-21fd81e31c9c@github.com>
Message-ID: <qYg55CBOt1zrGcLBnzA2aRKouaEOtoyEhk28y5JMVoU=.2879a796-12d1-40db-9ee5-0438b547873c@github.com>

> A bunch of langtools tests, which all rely on `test/langtools/tools/javac/Paths/Util.sh`, fails when run on Windows with msys2, since this environment is not properly detected.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9056/files
  - new: https://git.openjdk.java.net/jdk/pull/9056/files/5d19cbf6..2633f9d1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9056&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9056&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/9056

From jlahoda at openjdk.java.net  Tue Jun  7 10:35:09 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 7 Jun 2022 10:35:09 GMT
Subject: Integrated: 8287236: Reorganize AST related to pattern matching for
 switch
In-Reply-To: <wPMQTWs7GB--mzTFHCTF-Ie8M-ps-tOfPZ5WsJ209vM=.8a3fde5b-c385-42cb-bb74-df6989a9f07c@github.com>
References: <wPMQTWs7GB--mzTFHCTF-Ie8M-ps-tOfPZ5WsJ209vM=.8a3fde5b-c385-42cb-bb74-df6989a9f07c@github.com>
Message-ID: <7AFSQ6bSd5OMOImV12d4oWPYqrOWepj7N7D98cQ2Lfo=.3c0fc5d7-8a55-4671-96c0-4bccf66a9fb9@github.com>

On Tue, 31 May 2022 16:13:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Under JEP 427, case label elements may be: a) expressions; b) patterns; c) the default. Currently, this is modeled in the Trees API in a way where all expressions and patterns extend `CaseLabelTree`.
> 
> When guarded patterns were removed in favor of guards on pattern case label element, it was necessary to augment all patterns with a guard, which is only used when the pattern is used as a case label element. This is somewhat inconsistent for the Trees API.
> 
> A use a layer of indirection is proposed here: - the `CaseLabelTree` has three subtypes: `ConstantCaseLabelTree`, which contains `ExpressionTree` as a subnode; `PatternCaseLabelTree`, which contains `PatternTree` and a guard (`ExpressionTree`) as subnodes; and the `DefaultCaseLabelTree` for the default clause.
> 
> This patch also fixes `TreeScanner.visitCase`, which currently iterates only over `CaseTree.getExpressions()`, ignoring patterns. It is changed to iterate over `CaseTree.getLabels()`, to get all labels.

This pull request has now been integrated.

Changeset: bde7a7ae
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bde7a7ae03f51360227c9757b2ab3ddbff4df908
Stats:     651 lines in 27 files changed: 423 ins; 101 del; 127 mod

8287236: Reorganize AST related to pattern matching for switch

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.java.net/jdk/pull/8959

From duke at openjdk.java.net  Tue Jun  7 13:16:04 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Tue, 7 Jun 2022 13:16:04 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v2]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <nx072PA7iMz2mi6k8BQxuA-ls_XCnCzxMOCV31MIId4=.5e5d584c-1c46-4057-8762-883bef588df5@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/cd25d8ad..544ee0f7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/9049

From duke at openjdk.java.net  Tue Jun  7 13:30:50 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Tue, 7 Jun 2022 13:30:50 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v3]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <A6Jv-1uGhDEGi-hHqFjkxK2lbkckMP5xjr9RtQAaswY=.f1dc641f-4ba7-490a-909e-548742761512@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Fix copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/544ee0f7..2acbedb1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.java.net/jdk/pull/9049

From duke at openjdk.java.net  Tue Jun  7 13:35:06 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Tue, 7 Jun 2022 13:35:06 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v3]
In-Reply-To: <A6Jv-1uGhDEGi-hHqFjkxK2lbkckMP5xjr9RtQAaswY=.f1dc641f-4ba7-490a-909e-548742761512@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <A6Jv-1uGhDEGi-hHqFjkxK2lbkckMP5xjr9RtQAaswY=.f1dc641f-4ba7-490a-909e-548742761512@github.com>
Message-ID: <xeeIg9KgJE073zxqHpVNhjPEUTZa8E93UyKTbVi551g=.0e69be65-6c73-406e-8b70-0bad6ca3c20e@github.com>

On Tue, 7 Jun 2022 13:30:50 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Fix copyright year

@Thihup Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more information.

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

PR: https://git.openjdk.java.net/jdk/pull/9049

From jlahoda at openjdk.java.net  Tue Jun  7 13:36:07 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 7 Jun 2022 13:36:07 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <yYgK7XFgOkNtqPtMNG8aMIbFEmKiunZ5Dtf0MWPa17I=.c561ff0a-2a9c-451a-a810-f2282f411e55@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

Looks like a reasonable compromise to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8747

From asotona at openjdk.java.net  Tue Jun  7 13:43:07 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 7 Jun 2022 13:43:07 GMT
Subject: Integrated: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option
In-Reply-To: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
Message-ID: <XIBv73swJLhV6unhWIpCxdwKBnyNnl4edElggHH4fm0=.c0f4b6d3-3cee-430a-9775-370247944777@github.com>

On Tue, 17 May 2022 12:47:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ### Problem description
> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
> fails to run java source launcher correctly (for example when --source N is specified).
> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
> 
> ### Root cause
> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
> 
> ### Alternative patch
> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
> 
> ### Proposed fix
> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
> Plus added specific test case.
> 
> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 905bcbe3
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/905bcbe34eb9750f6f7f12a577733c71a31d7972
Stats:     76 lines in 3 files changed: 29 ins; 37 del; 10 mod

8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option

Reviewed-by: jlahoda

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From jlahoda at openjdk.java.net  Tue Jun  7 13:45:55 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 7 Jun 2022 13:45:55 GMT
Subject: Integrated: 8287808: javac generates illegal class file for pattern
 matching switch with records
In-Reply-To: <sA_Fn8LdP9_mi4y1jFUJ3t-adLy0Y2YWgcehgqBO1_I=.7c6e3c2c-b82a-414b-b580-e4446cda4001@github.com>
References: <sA_Fn8LdP9_mi4y1jFUJ3t-adLy0Y2YWgcehgqBO1_I=.7c6e3c2c-b82a-414b-b580-e4446cda4001@github.com>
Message-ID: <hhtFc0YEyQE21cJlwfCnvr6j735mkqHS9JHhnMMzqbI=.41d27de2-7fe8-461a-b2d1-6065101bb729@github.com>

On Mon, 6 Jun 2022 10:39:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For record patterns, javac generates proxy methods for accessors, to properly wrap exceptions. These proxies are currently generated as package private, which is not valid for interfaces. Using private methods should be better.

This pull request has now been integrated.

Changeset: 2f62f15b
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2f62f15b09dcfa4bed556dc7778cb1a6bb31d9ba
Stats:     12 lines in 4 files changed: 8 ins; 0 del; 4 mod

8287808: javac generates illegal class file for pattern matching switch with records

Reviewed-by: sundar

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

PR: https://git.openjdk.java.net/jdk/pull/9039

From hannesgreule at outlook.de  Tue Jun  7 15:00:06 2022
From: hannesgreule at outlook.de (Hannes Greule)
Date: Tue, 7 Jun 2022 17:00:06 +0200
Subject: Fwd: Mandated/implicit parameters
In-Reply-To: <CABe8uE0LFFFmR9hqYLsaahAeOeaO-MVSjY8C6Q5zF2-qS_EVAQ@mail.gmail.com>
References: <AM0PR03MB457746B3A0FE7D594A26E452AFD69@AM0PR03MB4577.eurprd03.prod.outlook.com>
 <CABe8uE2gMRi8AjSEjJ0dARo0VFmOfVsZgKPJCWNVdvSN=i5B-Q@mail.gmail.com>
 <CABe8uE0LFFFmR9hqYLsaahAeOeaO-MVSjY8C6Q5zF2-qS_EVAQ@mail.gmail.com>
Message-ID: <AM0PR03MB4577F94DC0D765573242D1DDAFA59@AM0PR03MB4577.eurprd03.prod.outlook.com>

 > So, your approach would fix all these issues reported.

That's interesting, I didn't think? of other related issues before.

However, this would only fix the issue for newly compiled class files 
and only for compile targets >= Java 8 from my understanding.

How should we go forward from here? I think I got a working fix for it 
on this branch[1] and I already ran the langtools_javac tests.
There are two failing tests, one of them[2] was assuming a wrong 
constant pool index (as the MethodParameter attribute wasn't written 
before). I updated the test accordingly.

The other one[3] seems to be an issue with the ClassReader here[4].

[1] 
https://github.com/SirYwell/jdk/tree/fix/enforce-methodparam_attr-if-mandated
[2] 
https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnnotatedExtendsTest.java#L62
[3] 
https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/6889255/T6889255.java
[4] 
https://github.com/openjdk/jdk/blob/062db59eeb8ba6389aaa3c622dbc109a92d580ca/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1069-L1071


From jlahoda at openjdk.java.net  Tue Jun  7 15:25:55 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 7 Jun 2022 15:25:55 GMT
Subject: Integrated: 8286206: Missing cases for RECORD
In-Reply-To: <ZYWClWU13X886-pVUQg1Nnhz5poSSmDRhULECJQQZFM=.4d2d0bee-566f-41f6-80b1-b28bfb67a646@github.com>
References: <ZYWClWU13X886-pVUQg1Nnhz5poSSmDRhULECJQQZFM=.4d2d0bee-566f-41f6-80b1-b28bfb67a646@github.com>
Message-ID: <2xqJ445B9I5p6AQgH4bCJtMyqyLBS-x7KbY3Fm4Nfyk=.25d283b3-0d95-4281-a6f3-cb53a291fb9d@github.com>

On Mon, 6 Jun 2022 14:40:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adds handling of `ElementKind.RECORD` to JShell's code completion.

This pull request has now been integrated.

Changeset: 062db59e
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/062db59eeb8ba6389aaa3c622dbc109a92d580ca
Stats:     45 lines in 3 files changed: 35 ins; 0 del; 10 mod

8286206: Missing cases for RECORD

Reviewed-by: vromero, jjg

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

PR: https://git.openjdk.java.net/jdk/pull/9042

From jjg at openjdk.java.net  Tue Jun  7 22:43:35 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Jun 2022 22:43:35 GMT
Subject: RFR: 8287895: Some langtools tests fail on msys2 [v2]
In-Reply-To: <qYg55CBOt1zrGcLBnzA2aRKouaEOtoyEhk28y5JMVoU=.2879a796-12d1-40db-9ee5-0438b547873c@github.com>
References: <lw0jfruseupJnx6SQfT8zyt4JYqqaZQ_yQMB9pU9xLM=.c1498702-ea14-4230-af50-21fd81e31c9c@github.com>
 <qYg55CBOt1zrGcLBnzA2aRKouaEOtoyEhk28y5JMVoU=.2879a796-12d1-40db-9ee5-0438b547873c@github.com>
Message-ID: <R2Q3R6CbOKLV75FuXL03BxsQyW8PnJGKYSNRevCXVsY=.7592732e-0c62-4626-b9c9-6fd0cf455428@github.com>

On Tue, 7 Jun 2022 10:21:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A bunch of langtools tests, which all rely on `test/langtools/tools/javac/Paths/Util.sh`, fails when run on Windows with msys2, since this environment is not properly detected.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9056

From jjg at openjdk.java.net  Tue Jun  7 23:59:32 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Jun 2022 23:59:32 GMT
Subject: RFR: JDK-8287886: Further terminology updates to match JLS
In-Reply-To: <nm2wDZHpCXIsZ_vGDiuG0-M7pLisZ8kI7_qYQ0rNk_4=.8506b5d8-8021-4c8b-bf1e-8ad4d23e3f77@github.com>
References: <nm2wDZHpCXIsZ_vGDiuG0-M7pLisZ8kI7_qYQ0rNk_4=.8506b5d8-8021-4c8b-bf1e-8ad4d23e3f77@github.com>
Message-ID: <LSfOEG_l8PEmtVlXt3dV5tpLjwcx6GhwO1fWwz1YWUM=.119a7df7-b709-4965-a84a-62774cda6686@github.com>

On Tue, 7 Jun 2022 05:04:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Work previously done under [JDK-8257638](https://bugs.openjdk.org/browse/JDK-8257638) missed some cases.

Marked as reviewed by jjg (Reviewer).

src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 78:

> 76:  * members. Propagation of the annotations to mandated members is
> 77:  * governed by rules given in the <cite>The Java Language
> 78:  * Specification</cite>.

Future? could be a `@jls` reference

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

PR: https://git.openjdk.java.net/jdk/pull/9052

From darcy at openjdk.java.net  Wed Jun  8 01:00:56 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 8 Jun 2022 01:00:56 GMT
Subject: RFR: JDK-8287886: Further terminology updates to match JLS [v2]
In-Reply-To: <nm2wDZHpCXIsZ_vGDiuG0-M7pLisZ8kI7_qYQ0rNk_4=.8506b5d8-8021-4c8b-bf1e-8ad4d23e3f77@github.com>
References: <nm2wDZHpCXIsZ_vGDiuG0-M7pLisZ8kI7_qYQ0rNk_4=.8506b5d8-8021-4c8b-bf1e-8ad4d23e3f77@github.com>
Message-ID: <oD6bm9eG5gcyTZg90oSzoLNZcRdgbejNDpouJ35DK60=.7d43a6f6-9b42-4736-8767-41f508e814c3@github.com>

> Work previously done under [JDK-8257638](https://bugs.openjdk.org/browse/JDK-8257638) missed some cases.

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

 - Respond to review feedback.
 - Merge branch 'master' into JDK-8287886
 - JDK-8287886: Further terminology updates to match JLS

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9052/files
  - new: https://git.openjdk.java.net/jdk/pull/9052/files/d39870eb..265e2575

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9052&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9052&range=00-01

  Stats: 4184 lines in 264 files changed: 2831 ins; 571 del; 782 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9052.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9052/head:pull/9052

PR: https://git.openjdk.java.net/jdk/pull/9052

From darcy at openjdk.java.net  Wed Jun  8 01:00:57 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 8 Jun 2022 01:00:57 GMT
Subject: Integrated: JDK-8287886: Further terminology updates to match JLS
In-Reply-To: <nm2wDZHpCXIsZ_vGDiuG0-M7pLisZ8kI7_qYQ0rNk_4=.8506b5d8-8021-4c8b-bf1e-8ad4d23e3f77@github.com>
References: <nm2wDZHpCXIsZ_vGDiuG0-M7pLisZ8kI7_qYQ0rNk_4=.8506b5d8-8021-4c8b-bf1e-8ad4d23e3f77@github.com>
Message-ID: <1AUm5Zs-hhbOO95HuxLqRUt2wz8kurJaZVok2117bYg=.fc7fc2ec-8ee0-4e6f-a164-fd262ca5eb24@github.com>

On Tue, 7 Jun 2022 05:04:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Work previously done under [JDK-8257638](https://bugs.openjdk.org/browse/JDK-8257638) missed some cases.

This pull request has now been integrated.

Changeset: 39ec58b6
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/39ec58b63cff640734b5fd9454441bb93c467e5b
Stats:     64 lines in 6 files changed: 3 ins; 0 del; 61 mod

8287886: Further terminology updates to match JLS

Reviewed-by: jjg

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

PR: https://git.openjdk.java.net/jdk/pull/9052

From darcy at openjdk.java.net  Wed Jun  8 01:42:50 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 8 Jun 2022 01:42:50 GMT
Subject: RFR: JDK-8287967: Update golden test files after JDK-8287886
Message-ID: <A233g3zMExnrq51DmNo8ybCTt9PTFKcZEv8J0LQYEgE=.eb02c747-2264-42a5-bfa3-c8c585009c87@github.com>

The terminology changes made to an exception message in [JDK-8287886](https://bugs.openjdk.org/browse/JDK-8287886) require updates to two golden files.

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

Commit messages:
 - JDK-8287967: Update golden test files after JDK-8287886

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

PR: https://git.openjdk.java.net/jdk/pull/9076

From dholmes at openjdk.java.net  Wed Jun  8 01:58:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Jun 2022 01:58:36 GMT
Subject: RFR: JDK-8287967: Update golden test files after JDK-8287886
In-Reply-To: <A233g3zMExnrq51DmNo8ybCTt9PTFKcZEv8J0LQYEgE=.eb02c747-2264-42a5-bfa3-c8c585009c87@github.com>
References: <A233g3zMExnrq51DmNo8ybCTt9PTFKcZEv8J0LQYEgE=.eb02c747-2264-42a5-bfa3-c8c585009c87@github.com>
Message-ID: <_OFQcah97QLoeMroGYcw10SB427W24uIlVS2oVRiIsA=.6dd85baf-bc01-4c7f-8167-271e6fd69601@github.com>

On Wed, 8 Jun 2022 01:33:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The terminology changes made to an exception message in [JDK-8287886](https://bugs.openjdk.org/browse/JDK-8287886) require updates to two golden files.

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9076

From darcy at openjdk.java.net  Wed Jun  8 02:03:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 8 Jun 2022 02:03:33 GMT
Subject: Integrated: JDK-8287967: Update golden test files after JDK-8287886
In-Reply-To: <A233g3zMExnrq51DmNo8ybCTt9PTFKcZEv8J0LQYEgE=.eb02c747-2264-42a5-bfa3-c8c585009c87@github.com>
References: <A233g3zMExnrq51DmNo8ybCTt9PTFKcZEv8J0LQYEgE=.eb02c747-2264-42a5-bfa3-c8c585009c87@github.com>
Message-ID: <8Q_Oo3iDBxl_7_yqFFOzRjBKJ_6Ezz4gwSDVejGrrkQ=.c0abba1d-21af-4408-907a-77823803e89e@github.com>

On Wed, 8 Jun 2022 01:33:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The terminology changes made to an exception message in [JDK-8287886](https://bugs.openjdk.org/browse/JDK-8287886) require updates to two golden files.

This pull request has now been integrated.

Changeset: 32dd1eef
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/32dd1eef8859231bfb298a7b86f808d8188aec69
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8287967: Update golden test files after JDK-8287886

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/9076

From duke at openjdk.java.net  Wed Jun  8 07:56:53 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Wed, 8 Jun 2022 07:56:53 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
Message-ID: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>

At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.

This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

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

Commit messages:
 - 8288001: SOURCE_DATE_EPOCH should not be set by default
 - 8288001: SOURCE_DATE_EPOCH should not be set by default

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

PR: https://git.openjdk.java.net/jdk/pull/9081

From sgehwolf at openjdk.java.net  Wed Jun  8 09:38:32 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 8 Jun 2022 09:38:32 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <U-R3vVopclgOiL09AZ9Z9wPG9oBtNQQ1JnVhTmDeLDU=.979f33c8-6e94-4943-a05f-fe428b0bd961@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

It's not clear **why** you don't want `SOURCE_DATE_EPOCH` set by default. Could you explain? It would be good to make the OpenJDK build reproducible by default. The way it works currently, is a first step towards that goal.

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

PR: https://git.openjdk.java.net/jdk/pull/9081

From ihse at openjdk.java.net  Wed Jun  8 09:53:27 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Jun 2022 09:53:27 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <HzifBIxA8d6cIiza9tCi2HpLQwXgivv8oCuQPJOWS00=.783b86e2-9419-4474-b717-c8f5dc06520c@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

No no no. The current design is very much intentional. We must export `SOURCE_DATE_EPOCH` for gcc to be able to see it.

I wonder just like Severin: *why* do you think this is a problem?

Also, the long term goal is to *only* make reproducible builds. The sole reason it is possible to do `--disable-reproducible-builds` is out of an abundance of caution, if the changes needed for full reproducibility had unintended negative consequences.

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

PR: https://git.openjdk.java.net/jdk/pull/9081

From ihse at openjdk.java.net  Wed Jun  8 10:10:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Jun 2022 10:10:38 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
In-Reply-To: <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
Message-ID: <K3UtWQx-QAzR5uRkyvaJvzkgJFFMuJ2Rx8xSSgxDxFs=.c4e57ba0-3320-480c-9dd2-1d00bb5d08d3@github.com>

On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> 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 40 additional commits since the last revision:
> 
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/6a77da51...e495a579

Build changes look good. Thanks for fixing the bug in `generate-symbol-data.sh`.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8236

From ihse at openjdk.java.net  Wed Jun  8 14:08:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Jun 2022 14:08:38 GMT
Subject: Integrated: 8287895: Some langtools tests fail on msys2
In-Reply-To: <lw0jfruseupJnx6SQfT8zyt4JYqqaZQ_yQMB9pU9xLM=.c1498702-ea14-4230-af50-21fd81e31c9c@github.com>
References: <lw0jfruseupJnx6SQfT8zyt4JYqqaZQ_yQMB9pU9xLM=.c1498702-ea14-4230-af50-21fd81e31c9c@github.com>
Message-ID: <ANfoLcgCGrYln1h7-OikTzbikFCJqY6SHGWzNvXBmBo=.60807fe4-d486-46c9-a90a-939c86dfe167@github.com>

On Tue, 7 Jun 2022 10:09:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A bunch of langtools tests, which all rely on `test/langtools/tools/javac/Paths/Util.sh`, fails when run on Windows with msys2, since this environment is not properly detected.

This pull request has now been integrated.

Changeset: f7791ad0
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f7791ad0ea984d49ff26e6f30233d8dcee4305b8
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8287895: Some langtools tests fail on msys2

Reviewed-by: jjg

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

PR: https://git.openjdk.java.net/jdk/pull/9056

From liangchenblue at gmail.com  Wed Jun  8 14:43:52 2022
From: liangchenblue at gmail.com (-)
Date: Wed, 8 Jun 2022 09:43:52 -0500
Subject: Fwd: Mandated/implicit parameters
In-Reply-To: <AM0PR03MB4577F94DC0D765573242D1DDAFA59@AM0PR03MB4577.eurprd03.prod.outlook.com>
References: <AM0PR03MB457746B3A0FE7D594A26E452AFD69@AM0PR03MB4577.eurprd03.prod.outlook.com>
 <CABe8uE2gMRi8AjSEjJ0dARo0VFmOfVsZgKPJCWNVdvSN=i5B-Q@mail.gmail.com>
 <CABe8uE0LFFFmR9hqYLsaahAeOeaO-MVSjY8C6Q5zF2-qS_EVAQ@mail.gmail.com>
 <AM0PR03MB4577F94DC0D765573242D1DDAFA59@AM0PR03MB4577.eurprd03.prod.outlook.com>
Message-ID: <CABe8uE1BWkoG0iKMH3Aw-p=XNc1jF_Zz3E3HRs9BcbDJwPNOPA@mail.gmail.com>

Your patch looks nice. I suggest, in addition, to write the attribute
when any synthetic parameter is present as well (such as the first two
String and int of enum constructors). In addition, I would recommend a
test for core reflection to ensure the newly emitted attributes allow
core reflection to correctly describe the parameterized types of inner
class constructors, etc.

Once you can find a related issue on the bug tracker (or report one at
https://bugs.java.com/ if you can't find a fitting one), you can
submit this patch for that bug tracker issue.

For class files compiled by older Javac, unfortunately, they indeed do
not have necessary data for core reflection to correctly interpret if
an argument is synthetic or mandated. However, any javac beyond 8
should have the -parameters attribute, which they could turn on for a
workaround.

For the ClassReader, I think you may need a `index++;` before the
`continue;`, as that would better match the behavior of
LocalVariableTable register-based index assigning.


On Tue, Jun 7, 2022 at 10:00 AM Hannes Greule <hannesgreule at outlook.de> wrote:
>
>  > So, your approach would fix all these issues reported.
>
> That's interesting, I didn't think  of other related issues before.
>
> However, this would only fix the issue for newly compiled class files
> and only for compile targets >= Java 8 from my understanding.
>
> How should we go forward from here? I think I got a working fix for it
> on this branch[1] and I already ran the langtools_javac tests.
> There are two failing tests, one of them[2] was assuming a wrong
> constant pool index (as the MethodParameter attribute wasn't written
> before). I updated the test accordingly.
>
> The other one[3] seems to be an issue with the ClassReader here[4].
>
> [1]
> https://github.com/SirYwell/jdk/tree/fix/enforce-methodparam_attr-if-mandated
> [2]
> https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnnotatedExtendsTest.java#L62
> [3]
> https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/6889255/T6889255.java
> [4]
> https://github.com/openjdk/jdk/blob/062db59eeb8ba6389aaa3c622dbc109a92d580ca/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1069-L1071
>

From duke at openjdk.java.net  Wed Jun  8 14:48:36 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Wed, 8 Jun 2022 14:48:36 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v4]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <bKDy4tvzC2xuyqZGGtRJy4rvuOHtejFuQWvGAGXlU1M=.7fdd47c1-a068-4132-a705-c05bfd48aeb9@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Add tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/2acbedb1..c4a719e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=02-03

  Stats: 129 lines in 1 file changed: 129 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.java.net/jdk/pull/9049

From duke at openjdk.java.net  Wed Jun  8 14:51:59 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Wed, 8 Jun 2022 14:51:59 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v5]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Fix test message

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/c4a719e3..c88bc754

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.java.net/jdk/pull/9049

From alanb at openjdk.java.net  Wed Jun  8 15:01:36 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 8 Jun 2022 15:01:36 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v5]
In-Reply-To: <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>
Message-ID: <7uelBMnhTcrFYlWR5QJwEsVI99wtnr_CQ2jYsvcrzbs=.474db124-8328-4c95-8996-0ffb17a25583@github.com>

On Wed, 8 Jun 2022 14:51:59 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test message

test/jdk/tools/jar/modularJar/Basic.java line 1050:

> 1048:      */
> 1049:     @Test(dataProvider = "resolutionNames")
> 1050:     public void updateFooModuleResolutionDoNotResolveByDefaultAndWarnIfResolved(String resolutionName, Predicate<ModuleResolution> hasWarning) throws IOException {

Update the existing tests is good but overly long lines make it too hard to read (it will make future side-by-side view impossible). Can you trim all these lines down to something closer to the existing tests in this file?

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

PR: https://git.openjdk.java.net/jdk/pull/9049

From psandoz at openjdk.java.net  Wed Jun  8 15:55:02 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 8 Jun 2022 15:55:02 GMT
Subject: RFR: 8287186: JDK modules participating in preview
Message-ID: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>

Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.

It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.

Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.

The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

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

Commit messages:
 - Unused import.
 - Generalize the pariticipating in preview APIs.

Changes: https://git.openjdk.java.net/jdk/pull/9087/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287186
  Stats: 98 lines in 7 files changed: 62 ins; 28 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9087.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9087/head:pull/9087

PR: https://git.openjdk.java.net/jdk/pull/9087

From duke at openjdk.java.net  Wed Jun  8 17:00:27 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Wed, 8 Jun 2022 17:00:27 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v6]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <rLUa0b0Un3Q4Z10SAp1NRIGAy9HJKi4BGrBrBc2JD64=.ac3b642d-9ee1-463e-a5d1-f435ab9df367@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Simplify test names

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/c88bc754..7362da92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=04-05

  Stats: 30 lines in 1 file changed: 10 ins; 3 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.java.net/jdk/pull/9049

From alanb at openjdk.java.net  Wed Jun  8 17:24:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 8 Jun 2022 17:24:32 GMT
Subject: RFR: 8287186: JDK modules participating in preview
In-Reply-To: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
Message-ID: <o7B-cdTDeabcvHanobQukiwPRFmQoEkIL11YV8dSGaw=.130f4b1d-3a92-4630-9e63-40a321178bbe@github.com>

On Wed, 8 Jun 2022 15:46:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

Can java.management participate too? It would allow sun.management.Util.isVirtual(Thread) to go away (lots of methods in sun.management.ThreadImpl need to test if a thread is virtual).

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

PR: https://git.openjdk.java.net/jdk/pull/9087

From alex.buckley at oracle.com  Wed Jun  8 17:43:59 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 8 Jun 2022 10:43:59 -0700
Subject: Mandated/implicit parameters
In-Reply-To: <c7f37d4b-606b-905f-e517-d13d58e2218e@oracle.com>
References: <AM0PR03MB4577A0135FC226906946623FAFD79@AM0PR03MB4577.eurprd03.prod.outlook.com>
 <bf8d0723-91f5-b9b3-14d0-84d54a49ed04@oracle.com>
 <c7f37d4b-606b-905f-e517-d13d58e2218e@oracle.com>
Message-ID: <063db7d2-1a58-9b80-f880-9989556fd938@oracle.com>

On 6/6/2022 6:54 PM, Joseph D. Darcy wrote:> On 5/24/2022 8:52 AM, Alex 
Buckley wrote:
>> On 5/23/2022 11:27 PM, Hannes Greule wrote:
>>> Looking into it a bit deeper, it also seems like the parameters
>>> of a compact constructor for records are never marked as
>>> mandated, even when compiling with the -parameters flag (but the
>>> MethodParameters attribute is always written or record
>>> constructors).
>>
>> That is weird, and sounds like a javac bug.
> 
> JDK-8234908: consider if the MANDATED flag should be applied to record 
> members added by the compiler
> https://bugs.openjdk.org/browse/JDK-8234908

The bug in javac is that when MethodParameters is emitted for a record 
ctor (which is apparently "always"), the ACC_MANDATED flag is not set 
for the ctor's parameters even in cases when it should be set. When 
should it be set? When the ctor is implicitly declared according to JLS 
8.10.4.

JDK-8234908 is talking about something different: being able to mark the 
ctor itself (and other methods) as mandated, not just parameters. That's 
a fine goal, but it's not responsive to the observation by Hannes Greule 
about missing mandated parameters.

(I linked to this thread in the Description of JDK-8234908, without 
changing its original text: "the MANDATED flag has been used so far for 
parameters added by the compiler. Now the compiler is adding more 
members that are not parameters only, like accessors and constructors in 
records. We should consider if the flag should be applied to those too. 
This flag would only be visible by source reflection")

Alex

From psandoz at openjdk.java.net  Wed Jun  8 18:24:35 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 8 Jun 2022 18:24:35 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
Message-ID: <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>

> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  Let java.management participate in preview features.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9087/files
  - new: https://git.openjdk.java.net/jdk/pull/9087/files/5e7ca855..9defdf23

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=00-01

  Stats: 44 lines in 5 files changed: 4 ins; 29 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9087.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9087/head:pull/9087

PR: https://git.openjdk.java.net/jdk/pull/9087

From psandoz at openjdk.java.net  Wed Jun  8 18:24:38 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 8 Jun 2022 18:24:38 GMT
Subject: RFR: 8287186: JDK modules participating in preview
In-Reply-To: <o7B-cdTDeabcvHanobQukiwPRFmQoEkIL11YV8dSGaw=.130f4b1d-3a92-4630-9e63-40a321178bbe@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <o7B-cdTDeabcvHanobQukiwPRFmQoEkIL11YV8dSGaw=.130f4b1d-3a92-4630-9e63-40a321178bbe@github.com>
Message-ID: <K60MqsJDCyyc2JvgDuVerhdbUSbeYZl32dliaxekGiA=.334a0f1c-f6ae-4fc1-a7d8-c85713f4d286@github.com>

On Wed, 8 Jun 2022 17:21:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can java.management participate too? It would allow sun.management.Util.isVirtual(Thread) to go away (lots of methods in sun.management.ThreadImpl need to test if a thread is virtual).

Pushed update.

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

PR: https://git.openjdk.java.net/jdk/pull/9087

From alanb at openjdk.java.net  Wed Jun  8 18:30:35 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 8 Jun 2022 18:30:35 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
Message-ID: <R_joxppBdMx0zy4QJnMHA8c_4g1U_SWJMlDiztQ4iGg=.33e28a8b-2926-4fe9-9b9d-dbf78fe4647c@github.com>

On Wed, 8 Jun 2022 18:24:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
>> 
>> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
>> 
>> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
>> 
>> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Let java.management participate in preview features.

The updates to java.base, java.management, and jdk.incubator.* looks fine, it's good to have the reflection code go away.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9087

From jlahoda at openjdk.java.net  Wed Jun  8 19:29:34 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 8 Jun 2022 19:29:34 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
Message-ID: <WLNko_NnPuWjR7pR-K3-DwHE0AqPQpCXb_2gUyMQQGc=.8e873804-84b3-4b3b-88e5-1ec4cebe1348@github.com>

On Wed, 8 Jun 2022 18:24:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
>> 
>> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
>> 
>> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
>> 
>> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Let java.management participate in preview features.

javac + `jdk.internal.javac` changes look good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9087

From dawid.weiss at gmail.com  Wed Jun  8 20:08:14 2022
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 8 Jun 2022 22:08:14 +0200
Subject: Generic type information for classes within closures not emitted by
 javac 11.0.15
Message-ID: <CAM21Rt-0+Wsef5s=+JVgfBvBu8ge4X6O=LkPMaRug9fA+2uRRw@mail.gmail.com>

Good evening,

I've spent an interesting day debugging a very awkward error in Google
Guice: a binding would work in JDK17 but would result in an odd (and
misleading) error information under JDK11. This turns out to be a problem
with generic signatures emitted by the corresponding compilers.

I narrowed it down to essentially something like this [full source at 1]:

Callable<Void> r =
        () -> {
          class Foo1 {
            public Map<String, Integer> field;
          }

          System.out.println("Foo1.field type: " +
Foo1.class.getField("field").getGenericType());
          return null;
        };
    r.call();

When I compile and run this snippet under java 11.0.15, I get only the
following signatures for generic types:

Foo1.field type: interface java.util.Map

if you move the inner class declaration outside of the closure, proper
generic info is stored and then loaded/ printed:

Foo2.field type: java.util.Map<java.lang.String, java.lang.Integer>

In Java 17.0.3, this compiles and works fine and I can't find any issue
where this was fixed. Is this a class bytecode constraint somewhere? My
reading of the JLS [2] would suggest the signature is mandatory, even if
emitted from within that nested class Foo1?

Any pointers would be appreciated!
Dawid

[1] https://gist.github.com/dweiss/d77452c52daa178e041adce145c2e86a
[2]
https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.7.9.1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220608/5bc6e637/attachment.htm>

From lancea at openjdk.java.net  Wed Jun  8 20:17:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 8 Jun 2022 20:17:27 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v5]
In-Reply-To: <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>
Message-ID: <dLzZWF1bWNj28VQFSIx6jx_DXdLCRb3R9OcMSJBJwEw=.4cd3436c-cd45-4b4b-8963-744097f7b691@github.com>

On Wed, 8 Jun 2022 14:51:59 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test message

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9049

From duke at openjdk.java.net  Wed Jun  8 22:09:48 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 8 Jun 2022 22:09:48 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
Message-ID: <3U2G2s2rU3i848aC3PNZUkBVxZKhVNM3uZPWnA_AObc=.2f5a668f-a0ac-4fa5-9160-e98e7399bb33@github.com>

On Wed, 8 Jun 2022 18:24:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
>> 
>> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
>> 
>> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
>> 
>> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Let java.management participate in preview features.

Just curious, is it still up to incubator modules' discretion to avoid accidental user access to preview content via the modules without enabling preview, like the `PreviewFeatures.ensureEnabled()` in `StructuredTaskScope`?

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

PR: https://git.openjdk.java.net/jdk/pull/9087

From darcy at openjdk.java.net  Thu Jun  9 01:03:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Jun 2022 01:03:47 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <n1d8Iv4qjk-lznK-UveaBbbb-EAfIGyDOwkoQ935WAQ=.483638ae-69ba-4731-ad21-f47299ca8ca2@github.com>

> Time to start getting ready for JDK 20...

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

 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Update symbols for JDK 19 b25.
 - Merge branch 'master' into JDK-8284858
 - Adjust deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - ... and 34 more: https://git.openjdk.java.net/jdk/compare/530d16c1...1b29a17c

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/e495a579..1b29a17c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=04-05

  Stats: 16423 lines in 539 files changed: 12382 ins; 2143 del; 1898 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From iris at openjdk.java.net  Thu Jun  9 04:23:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 9 Jun 2022 04:23:40 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]
In-Reply-To: <n1d8Iv4qjk-lznK-UveaBbbb-EAfIGyDOwkoQ935WAQ=.483638ae-69ba-4731-ad21-f47299ca8ca2@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <n1d8Iv4qjk-lznK-UveaBbbb-EAfIGyDOwkoQ935WAQ=.483638ae-69ba-4731-ad21-f47299ca8ca2@github.com>
Message-ID: <GM1p-fYjWEfrt5pYM5rZjVuRnY2fr_nKe_hpB_iTk1w=.3c99866a-5384-41be-bbc9-15dd1affffc1@github.com>

On Thu, 9 Jun 2022 01:03:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> 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 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - ... and 34 more: https://git.openjdk.java.net/jdk/compare/705cfa36...1b29a17c

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From duke at openjdk.java.net  Thu Jun  9 12:19:35 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 9 Jun 2022 12:19:35 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v7]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <2RGbeMoqCpLOmePC72LlrtxJqqSUQZiLgDQPlStFJmk=.1db7273f-406b-4079-a8da-179b03f4378a@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Update author

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/7362da92..8544abd9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=05-06

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.java.net/jdk/pull/9049

From arnoldnunag12 at gmail.com  Thu Jun  9 15:46:45 2022
From: arnoldnunag12 at gmail.com (Arnold Alejo Nunag)
Date: Thu, 9 Jun 2022 23:46:45 +0800
Subject: Compile failure with AP and explicit record accessor for type
 parameter
Message-ID: <527f4d26-4f8b-46c8-0133-4f0e798dedf3@gmail.com>

Hello,

Our team at Minecraft Forge (a modding platform for Minecraft: Java 
Edition) recently found a compiler bug regarding records, type 
parameters, and explicit types while trying to implement a new feature. 
I'm led to believe that this is the appropriate place to at least 
publicize and discuss this compiler-related issue. If not, please point 
me in the appropriate place to report this, thank you.

In summary, an explicitly declared accessor method for a record 
component whose type is a type parameter of the record fails to compile 
/only/ when an annotation processor is present during compilation. 
Removal of the explicit accessor or the annotation processor(s) makes 
the class compile as expected.

We've assembled a small reproducible case for this issue:

import javax.annotation.processing.AbstractProcessor;
import javax.annotation.processing.RoundEnvironment;
import javax.lang.model.element.TypeElement;
import java.util.Set;

public class EmptyProcessor extends AbstractProcessor {
 ??? @Override
 ??? public boolean process(Set<? extends TypeElement> annotations, 
RoundEnvironment roundEnv) {
 ??????? return false;
 ??? }
}

public record TestRecord<T>(T someValue) {
 ??? public T someValue() {
 ??????? return this.someValue;
 ??? }
}

Put each snippet into the source files `EmptyProcessor.java` and 
`TestRecord.java` respectively, compile the AP class using `javac 
EmptyProcessor.java`, and try to compile the record class with the AP 
present using `javac -processor EmptyProcessor TestRecord.java`. The 
warnings about the processor's lack of source version and supported 
annotations can be safely ignored (we used them to confirm that the 
annotation processor is present). Here is the output from running the 
above on Java 17:

D:\Dev\Sandbox\javacbug> javac -processor EmptyProcessor TestRecord.java
warning: No SupportedSourceVersion annotation found on EmptyProcessor, 
returning RELEASE_6.
warning: Supported source version 'RELEASE_6' from annotation processor 
'EmptyProcessor' less than -source '17'
warning: No SupportedAnnotationTypes annotation found on EmptyProcessor, 
returning an empty set.
TestRecord.java:3: error: invalid accessor method in record TestRecord
 ??? public T someValue() {
 ???????????? ^
 ? (return type of accessor method someValue() must match the type of 
record component someValue)
 ? where T is a type-variable:
 ??? T extends Object declared in record TestRecord
1 error
3 warnings

We've tested this on Windows against Java 16, 17, 18, as well as the 19 
EA (build 25, 2022/6/2), all reference implementations from 
jdk.java.net, as well as the latest Java 17 for Eclipse Temurin 
(17.0.3_7) and the test case fails on all those versions. We've also 
tested this against the Eclipse Compiler for Java, and it compiles 
successfully both with and without the presence of the AP.

Regards,
Arnold (@sciwhiz12)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220609/b5c30259/attachment.htm>

From hannesgreule at outlook.de  Thu Jun  9 16:09:04 2022
From: hannesgreule at outlook.de (Hannes Greule)
Date: Thu, 9 Jun 2022 18:09:04 +0200
Subject: Fwd: Mandated/implicit parameters
In-Reply-To: <CABe8uE1BWkoG0iKMH3Aw-p=XNc1jF_Zz3E3HRs9BcbDJwPNOPA@mail.gmail.com>
References: <AM0PR03MB457746B3A0FE7D594A26E452AFD69@AM0PR03MB4577.eurprd03.prod.outlook.com>
 <CABe8uE2gMRi8AjSEjJ0dARo0VFmOfVsZgKPJCWNVdvSN=i5B-Q@mail.gmail.com>
 <CABe8uE0LFFFmR9hqYLsaahAeOeaO-MVSjY8C6Q5zF2-qS_EVAQ@mail.gmail.com>
 <AM0PR03MB4577F94DC0D765573242D1DDAFA59@AM0PR03MB4577.eurprd03.prod.outlook.com>
 <CABe8uE1BWkoG0iKMH3Aw-p=XNc1jF_Zz3E3HRs9BcbDJwPNOPA@mail.gmail.com>
Message-ID: <AM0PR03MB4577C7150B97F6DB14849729AFA79@AM0PR03MB4577.eurprd03.prod.outlook.com>

 > Your patch looks nice. I suggest, in addition, to write the attribute
 > when any synthetic parameter is present as well (such as the first two
 > String and int of enum constructors).

Thank you. I'll look into synthetic parameters too.

 > In addition, I would recommend a
 > test for core reflection to ensure the newly emitted attributes allow
 > core reflection to correctly describe the parameterized types of inner
 > class constructors, etc.

I think I also need a test for the compiler output. I'll start working 
on that.

 > Once you can find a related issue on the bug tracker (or report one at
 > https://bugs.java.com/ if you can't find a fitting one), you can
 > submit this patch for that bug tracker issue.

I found JDK-8213329: Normalize inclusion of non-explicit parameters in 
JVM attributes[1] but that doesn't really fit the issue. I'll report a 
new one.

 > For the ClassReader, I think you may need a `index++;` before the
 > `continue;`, as that would better match the behavior of
 > LocalVariableTable register-based index assigning.

I looked into that a bit more. It seems more complicated as the 
ClassReader reads names from both the LocalVariableTable and the 
MethodParameters attribute if both are present. However, if the 
MethodParameters attribute is read after the LocalVariableTable, it will 
replace names from the LocalVariableTable. This causes issues if no 
names are written to the MethodParameters attribute.
I'm not sure what the best approach would be here, especially as 
indexing is different (due to the slot for `this` in non-static 
methods/ctors).

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

From darcy at openjdk.java.net  Thu Jun  9 16:21:25 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Jun 2022 16:21:25 GMT
Subject: Integrated: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <b1Cu-1h4TvuAVVuAlcZi4SoVs0KQOh8UxvL9CUKz3IE=.3792f081-f3fe-444c-981a-af47a3d6f123@github.com>

On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start getting ready for JDK 20...

This pull request has now been integrated.

Changeset: edff51e5
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edff51e5fdb5282830ecfb3792a88c7b28ca6557
Stats:     6453 lines in 69 files changed: 6403 ins; 5 del; 45 mod

8284858: Start of release updates for JDK 20
8286035: Add source 20 and target 20 to javac
8286034: Add SourceVersion.RELEASE_20

Reviewed-by: dholmes, kcr, iris, erikj, jjg, ihse

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

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

From vicente.romero at oracle.com  Thu Jun  9 16:23:36 2022
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 9 Jun 2022 12:23:36 -0400
Subject: Compile failure with AP and explicit record accessor for type
 parameter
In-Reply-To: <527f4d26-4f8b-46c8-0133-4f0e798dedf3@gmail.com>
References: <527f4d26-4f8b-46c8-0133-4f0e798dedf3@gmail.com>
Message-ID: <2b5fc064-6d8b-d964-a317-e4acc9b6d6d5@oracle.com>

Hi Arnold,

Thanks a lot for the detailed bug report. I have created [1] to track it,

Vicente

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

On 6/9/22 11:46, Arnold Alejo Nunag wrote:
>
> Hello,
>
> Our team at Minecraft Forge (a modding platform for Minecraft: Java 
> Edition) recently found a compiler bug regarding records, type 
> parameters, and explicit types while trying to implement a new 
> feature. I'm led to believe that this is the appropriate place to at 
> least publicize and discuss this compiler-related issue. If not, 
> please point me in the appropriate place to report this, thank you.
>
> In summary, an explicitly declared accessor method for a record 
> component whose type is a type parameter of the record fails to 
> compile /only/ when an annotation processor is present during 
> compilation. Removal of the explicit accessor or the annotation 
> processor(s) makes the class compile as expected.
>
> We've assembled a small reproducible case for this issue:
>
> import javax.annotation.processing.AbstractProcessor;
> import javax.annotation.processing.RoundEnvironment;
> import javax.lang.model.element.TypeElement;
> import java.util.Set;
>
> public class EmptyProcessor extends AbstractProcessor {
> ??? @Override
> ??? public boolean process(Set<? extends TypeElement> annotations, 
> RoundEnvironment roundEnv) {
> ??????? return false;
> ??? }
> }
>
> public record TestRecord<T>(T someValue) {
> ??? public T someValue() {
> ??????? return this.someValue;
> ??? }
> }
>
> Put each snippet into the source files `EmptyProcessor.java` and 
> `TestRecord.java` respectively, compile the AP class using `javac 
> EmptyProcessor.java`, and try to compile the record class with the AP 
> present using `javac -processor EmptyProcessor TestRecord.java`. The 
> warnings about the processor's lack of source version and supported 
> annotations can be safely ignored (we used them to confirm that the 
> annotation processor is present). Here is the output from running the 
> above on Java 17:
>
> D:\Dev\Sandbox\javacbug> javac -processor EmptyProcessor TestRecord.java
> warning: No SupportedSourceVersion annotation found on EmptyProcessor, 
> returning RELEASE_6.
> warning: Supported source version 'RELEASE_6' from annotation 
> processor 'EmptyProcessor' less than -source '17'
> warning: No SupportedAnnotationTypes annotation found on 
> EmptyProcessor, returning an empty set.
> TestRecord.java:3: error: invalid accessor method in record TestRecord
> ??? public T someValue() {
> ???????????? ^
> ? (return type of accessor method someValue() must match the type of 
> record component someValue)
> ? where T is a type-variable:
> ??? T extends Object declared in record TestRecord
> 1 error
> 3 warnings
>
> We've tested this on Windows against Java 16, 17, 18, as well as the 
> 19 EA (build 25, 2022/6/2), all reference implementations from 
> jdk.java.net, as well as the latest Java 17 for Eclipse Temurin 
> (17.0.3_7) and the test case fails on all those versions. We've also 
> tested this against the Eclipse Compiler for Java, and it compiles 
> successfully both with and without the presence of the AP.
>
> Regards,
> Arnold (@sciwhiz12)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220609/243f76ed/attachment.htm>

From dawid.weiss at gmail.com  Fri Jun 10 12:48:02 2022
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Fri, 10 Jun 2022 14:48:02 +0200
Subject: Generic type information for classes within closures not emitted
 by javac 11.0.15
In-Reply-To: <CAM21Rt-0+Wsef5s=+JVgfBvBu8ge4X6O=LkPMaRug9fA+2uRRw@mail.gmail.com>
References: <CAM21Rt-0+Wsef5s=+JVgfBvBu8ge4X6O=LkPMaRug9fA+2uRRw@mail.gmail.com>
Message-ID: <CAM21Rt8PfOAr=ZtViLJ8koaxq3vWiTHfL4hPaQrSwUz8JKVvEw@mail.gmail.com>

Just FYI - I did a little bisecting archeology and it's this issue:
https://bugs.openjdk.org/browse/JDK-8215470

The signatures from the nested class are fine after that commit and erased/
missing before. So the bug is present in anything up to jdk-13-ga.

Dawid

On Wed, Jun 8, 2022 at 10:08 PM Dawid Weiss <dawid.weiss at gmail.com> wrote:

>
> Good evening,
>
> I've spent an interesting day debugging a very awkward error in Google
> Guice: a binding would work in JDK17 but would result in an odd (and
> misleading) error information under JDK11. This turns out to be a problem
> with generic signatures emitted by the corresponding compilers.
>
> I narrowed it down to essentially something like this [full source at 1]:
>
> Callable<Void> r =
>         () -> {
>           class Foo1 {
>             public Map<String, Integer> field;
>           }
>
>           System.out.println("Foo1.field type: " +
> Foo1.class.getField("field").getGenericType());
>           return null;
>         };
>     r.call();
>
> When I compile and run this snippet under java 11.0.15, I get only the
> following signatures for generic types:
>
> Foo1.field type: interface java.util.Map
>
> if you move the inner class declaration outside of the closure, proper
> generic info is stored and then loaded/ printed:
>
> Foo2.field type: java.util.Map<java.lang.String, java.lang.Integer>
>
> In Java 17.0.3, this compiles and works fine and I can't find any issue
> where this was fixed. Is this a class bytecode constraint somewhere? My
> reading of the JLS [2] would suggest the signature is mandatory, even if
> emitted from within that nested class Foo1?
>
> Any pointers would be appreciated!
> Dawid
>
> [1] https://gist.github.com/dweiss/d77452c52daa178e041adce145c2e86a
> [2]
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.7.9.1
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220610/61b46b03/attachment.htm>

From duke at openjdk.java.net  Fri Jun 10 16:30:57 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 10 Jun 2022 16:30:57 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v8]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9049/files
  - new: https://git.openjdk.org/jdk/pull/9049/files/8544abd9..962f0ec1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=06-07

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

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

From darcy at openjdk.java.net  Fri Jun 10 17:34:17 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 10 Jun 2022 17:34:17 GMT
Subject: RFR: JDK-8286038: Update --release 19 symbol information for JDK 19
 build 26
Message-ID: <BBJvpY7TTxFIApKj6VcQ3QIxpmHNs3v12nyj7W0Z6RY=.e18f3cba-1cb6-430d-a03e-b404bb62e592@github.com>

Typical update of symbol files in JDK 20 for the latest build of JDK 19.

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

Commit messages:
 - JDK-8286038: Update --release 19 symbol information for JDK 19 build 26

Changes: https://git.openjdk.org/jdk/pull/9132/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286038
  Stats: 46 lines in 4 files changed: 39 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9132.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9132/head:pull/9132

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

From iris at openjdk.java.net  Fri Jun 10 17:47:01 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 10 Jun 2022 17:47:01 GMT
Subject: RFR: JDK-8286038: Update --release 19 symbol information for JDK
 19 build 26
In-Reply-To: <BBJvpY7TTxFIApKj6VcQ3QIxpmHNs3v12nyj7W0Z6RY=.e18f3cba-1cb6-430d-a03e-b404bb62e592@github.com>
References: <BBJvpY7TTxFIApKj6VcQ3QIxpmHNs3v12nyj7W0Z6RY=.e18f3cba-1cb6-430d-a03e-b404bb62e592@github.com>
Message-ID: <H-OEntgM38rFhy5lCNJSKDk4MQAmiUvXQzsanV3aUdY=.a0c8666f-eca6-4f31-a610-2994424e367f@github.com>

On Fri, 10 Jun 2022 17:23:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typical update of symbol files in JDK 20 for the latest build of JDK 19.

Marked as reviewed by iris (Reviewer).

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

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

From alanb at openjdk.java.net  Fri Jun 10 18:05:06 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 18:05:06 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v8]
In-Reply-To: <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>
Message-ID: <Q3jfKrJ_wm3mvDjf-RxOf5Qed20eF3t0tzb0C7nuTvU=.e46c68c6-1f82-47b8-93dd-34c562c333ec@github.com>

On Fri, 10 Jun 2022 16:30:57 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

test/jdk/tools/jar/modularJar/Basic.java line 44:

> 42: 
> 43: import jdk.internal.module.ModuleReferenceImpl;
> 44: import jdk.internal.module.ModuleResolution;

At some point we need to put in test infrastructure to avoid this and a few other tests from depending on JDK internals.

test/jdk/tools/jar/modularJar/Basic.java line 951:

> 949: 
> 950:     @DataProvider(name = "resolutionNames")
> 951:     public Object[][] resolutionNames() {

This is a data provider for resolution warnings, maybe it should be renamed.

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

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

From duke at openjdk.java.net  Fri Jun 10 18:28:46 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 10 Jun 2022 18:28:46 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v9]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Rename dataprovider

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9049/files
  - new: https://git.openjdk.org/jdk/pull/9049/files/962f0ec1..d566ebca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=07-08

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

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

From alanb at openjdk.java.net  Fri Jun 10 18:28:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 18:28:47 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v9]
In-Reply-To: <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>
Message-ID: <BdPM3hdNCRYygVZ9n0_H7n7h5_vTPL9pKqnSoIKYoXw=.9c1c6da0-5086-4435-be37-8322b3ba588d@github.com>

On Fri, 10 Jun 2022 18:25:09 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename dataprovider

Marked as reviewed by alanb (Reviewer).

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

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

From duke at openjdk.java.net  Fri Jun 10 18:28:47 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 10 Jun 2022 18:28:47 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v8]
In-Reply-To: <Q3jfKrJ_wm3mvDjf-RxOf5Qed20eF3t0tzb0C7nuTvU=.e46c68c6-1f82-47b8-93dd-34c562c333ec@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>
 <Q3jfKrJ_wm3mvDjf-RxOf5Qed20eF3t0tzb0C7nuTvU=.e46c68c6-1f82-47b8-93dd-34c562c333ec@github.com>
Message-ID: <Vcih8o167PlfmQ4QVEBCEdta9X2N1JbEI_qy6BiBjL4=.ac88540f-307c-40ba-b560-923f941a397e@github.com>

On Fri, 10 Jun 2022 18:01:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright year
>
> test/jdk/tools/jar/modularJar/Basic.java line 44:
> 
>> 42: 
>> 43: import jdk.internal.module.ModuleReferenceImpl;
>> 44: import jdk.internal.module.ModuleResolution;
> 
> At some point we need to put in test infrastructure to avoid this and a few other tests from depending on JDK internals.

Do you think it is better to parse the output of `javap` instead of using the internals to detect if it worked?

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

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

From alanb at openjdk.java.net  Fri Jun 10 18:28:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 18:28:48 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v8]
In-Reply-To: <Vcih8o167PlfmQ4QVEBCEdta9X2N1JbEI_qy6BiBjL4=.ac88540f-307c-40ba-b560-923f941a397e@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>
 <Q3jfKrJ_wm3mvDjf-RxOf5Qed20eF3t0tzb0C7nuTvU=.e46c68c6-1f82-47b8-93dd-34c562c333ec@github.com>
 <Vcih8o167PlfmQ4QVEBCEdta9X2N1JbEI_qy6BiBjL4=.ac88540f-307c-40ba-b560-923f941a397e@github.com>
Message-ID: <dtPTNvSCFezqq6hyGDNNgM3hbILXTg5QgYDYcsGf4wU=.9df8e214-b088-440b-b26d-105b7ab684a4@github.com>

On Fri, 10 Jun 2022 18:19:42 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> test/jdk/tools/jar/modularJar/Basic.java line 44:
>> 
>>> 42: 
>>> 43: import jdk.internal.module.ModuleReferenceImpl;
>>> 44: import jdk.internal.module.ModuleResolution;
>> 
>> At some point we need to put in test infrastructure to avoid this and a few other tests from depending on JDK internals.
>
> Do you think it is better to parse the output of `javap` instead of using the internals to detect if it worked?

Parsing the output of javap would be fragile. Instead, I think we'll just add some test infrastructure at some point, maybe when this class file attribute is documented somewhere.

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

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

From darcy at openjdk.java.net  Fri Jun 10 19:03:59 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 10 Jun 2022 19:03:59 GMT
Subject: Integrated: JDK-8286038: Update --release 19 symbol information for
 JDK 19 build 26
In-Reply-To: <BBJvpY7TTxFIApKj6VcQ3QIxpmHNs3v12nyj7W0Z6RY=.e18f3cba-1cb6-430d-a03e-b404bb62e592@github.com>
References: <BBJvpY7TTxFIApKj6VcQ3QIxpmHNs3v12nyj7W0Z6RY=.e18f3cba-1cb6-430d-a03e-b404bb62e592@github.com>
Message-ID: <hr86v-UxpfzRDTrM1jiHB7cv54USxvMo-kDl2CJpJbY=.6d21be2c-b00f-4d24-90ad-9fd74bc3597a@github.com>

On Fri, 10 Jun 2022 17:23:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typical update of symbol files in JDK 20 for the latest build of JDK 19.

This pull request has now been integrated.

Changeset: 7e940efc
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e940efcbc13a941f749cc6aff3ccf2f0640b438
Stats:     46 lines in 4 files changed: 39 ins; 1 del; 6 mod

8286038: Update --release 19 symbol information for JDK 19 build 26

Reviewed-by: iris

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

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

From darcy at openjdk.java.net  Fri Jun 10 19:57:17 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 10 Jun 2022 19:57:17 GMT
Subject: RFR: JDK-8288238: Add missing file jdk.incubator.concurrent-J.sym.txt
Message-ID: <DhzXdRD0OqHN4ZPC6MVTDCilo8Rr_-AYnAanWhhbhqo=.afbb832d-7ff0-4992-9bae-de8584c0f474@github.com>

The fix for [JDK-8286038](https://bugs.openjdk.org/browse/JDK-8286038) accidentally omitted one of the new files.

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

Commit messages:
 - JDK-8288238: Add missing file jdk.incubator.concurrent-J.sym.txt

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

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

From mikael at openjdk.java.net  Fri Jun 10 20:03:10 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Fri, 10 Jun 2022 20:03:10 GMT
Subject: RFR: JDK-8288238: Add missing file
 jdk.incubator.concurrent-J.sym.txt
In-Reply-To: <DhzXdRD0OqHN4ZPC6MVTDCilo8Rr_-AYnAanWhhbhqo=.afbb832d-7ff0-4992-9bae-de8584c0f474@github.com>
References: <DhzXdRD0OqHN4ZPC6MVTDCilo8Rr_-AYnAanWhhbhqo=.afbb832d-7ff0-4992-9bae-de8584c0f474@github.com>
Message-ID: <WN6fHPOXSmwE10iAm1SX7jIdf1kmtQe_J2CNTK9LwAY=.31a417fb-3bdf-441b-9b14-53e8e845a390@github.com>

On Fri, 10 Jun 2022 19:50:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The fix for [JDK-8286038](https://bugs.openjdk.org/browse/JDK-8286038) accidentally omitted one of the new files.

Marked as reviewed by mikael (Reviewer).

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

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

From dcubed at openjdk.java.net  Fri Jun 10 20:03:11 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 10 Jun 2022 20:03:11 GMT
Subject: RFR: JDK-8288238: Add missing file
 jdk.incubator.concurrent-J.sym.txt
In-Reply-To: <DhzXdRD0OqHN4ZPC6MVTDCilo8Rr_-AYnAanWhhbhqo=.afbb832d-7ff0-4992-9bae-de8584c0f474@github.com>
References: <DhzXdRD0OqHN4ZPC6MVTDCilo8Rr_-AYnAanWhhbhqo=.afbb832d-7ff0-4992-9bae-de8584c0f474@github.com>
Message-ID: <fgYTx4se5k0bBUefBpVFejAAxUCE2CSZ6rw8lqb-Z_Y=.19c1703b-d1fc-45d9-a124-bf9a1140a1d1@github.com>

On Fri, 10 Jun 2022 19:50:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The fix for [JDK-8286038](https://bugs.openjdk.org/browse/JDK-8286038) accidentally omitted one of the new files.

Thumbs up. This is an urgent build fix.

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

Marked as reviewed by dcubed (Reviewer).

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

From darcy at openjdk.java.net  Fri Jun 10 20:03:12 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 10 Jun 2022 20:03:12 GMT
Subject: Integrated: JDK-8288238: Add missing file
 jdk.incubator.concurrent-J.sym.txt
In-Reply-To: <DhzXdRD0OqHN4ZPC6MVTDCilo8Rr_-AYnAanWhhbhqo=.afbb832d-7ff0-4992-9bae-de8584c0f474@github.com>
References: <DhzXdRD0OqHN4ZPC6MVTDCilo8Rr_-AYnAanWhhbhqo=.afbb832d-7ff0-4992-9bae-de8584c0f474@github.com>
Message-ID: <uxH_9EVTVu8fsOMlfOdwbiHJqYnVpvsBC7EHtG8l4yE=.9acfefa3-570c-43cd-8882-7e93356b6a2d@github.com>

On Fri, 10 Jun 2022 19:50:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The fix for [JDK-8286038](https://bugs.openjdk.org/browse/JDK-8286038) accidentally omitted one of the new files.

This pull request has now been integrated.

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

8288238: Add missing file jdk.incubator.concurrent-J.sym.txt

Reviewed-by: mikael, dcubed

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

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

From duke at openjdk.java.net  Mon Jun 13 06:54:06 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Mon, 13 Jun 2022 06:54:06 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

Thank you for your comments.
I understood the goal of reproducible build. But now, ENABLE_REPRODUCIBLE_BUILD is set to false in default configuration.
Then I think minimize the effort of SOURCE_DATE_EPOCH when reproducible build is disabled. I wonder why build time information is different from Windows and Linux.

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

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

From ihse at openjdk.java.net  Mon Jun 13 07:17:53 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 13 Jun 2022 07:17:53 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <faW2AaIxj_dpfar5Aah90IehCsdATzePzFWUvZMdc78=.0c1716f0-7f65-41e1-9ff5-f8df99dd45a4@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

What do you mean by "build time information"?

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

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

From sgehwolf at openjdk.java.net  Mon Jun 13 09:51:00 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 13 Jun 2022 09:51:00 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <faW2AaIxj_dpfar5Aah90IehCsdATzePzFWUvZMdc78=.0c1716f0-7f65-41e1-9ff5-f8df99dd45a4@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <faW2AaIxj_dpfar5Aah90IehCsdATzePzFWUvZMdc78=.0c1716f0-7f65-41e1-9ff5-f8df99dd45a4@github.com>
Message-ID: <IrrVrkrSEoNCqWxzCdp1r1i4x-lZtxfkUpedxysLUdw=.35b62496-24e2-4450-8eec-26d68234d1a9@github.com>

On Mon, 13 Jun 2022 07:14:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
>> 
>> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?
>
> What do you mean by "build time information"?

@magicus I think it's `-Xinternalversion` which has different output between Windows and Linux of the same build. But to me that's a feature not a bug. From the PR description:

> With default configuration shows `-Xinternalversion` output same as Windows, [...]

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

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

From psandoz at openjdk.java.net  Mon Jun 13 15:12:11 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 13 Jun 2022 15:12:11 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v3]
In-Reply-To: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
Message-ID: <nquBNDj0inCwi2aDQWXgbPsf_pI4Yt0_B01SHKSPMGo=.4698a394-7479-4651-bd0e-7bf2f3020f34@github.com>

> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

Paul Sandoz 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:

 - Merge remote-tracking branch 'upstream/master' into JDK-8287186-preview-participating
 - Let java.management participate in preview features.
 - Unused import.
 - Generalize the pariticipating in preview APIs.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9087/files
  - new: https://git.openjdk.org/jdk/pull/9087/files/9defdf23..abd1fbf6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=01-02

  Stats: 17219 lines in 554 files changed: 13408 ins; 1651 del; 2160 mod
  Patch: https://git.openjdk.org/jdk/pull/9087.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9087/head:pull/9087

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

From ihse at openjdk.java.net  Tue Jun 14 07:45:00 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 07:45:00 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <IrrVrkrSEoNCqWxzCdp1r1i4x-lZtxfkUpedxysLUdw=.35b62496-24e2-4450-8eec-26d68234d1a9@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <faW2AaIxj_dpfar5Aah90IehCsdATzePzFWUvZMdc78=.0c1716f0-7f65-41e1-9ff5-f8df99dd45a4@github.com>
 <IrrVrkrSEoNCqWxzCdp1r1i4x-lZtxfkUpedxysLUdw=.35b62496-24e2-4450-8eec-26d68234d1a9@github.com>
Message-ID: <AkG3jzrCOMcPm5_CFyvGU1LKJETUtKl4bOY1erWpSuI=.ea4b3a09-14cc-4dfc-a1e9-c371d5d04681@github.com>

On Mon, 13 Jun 2022 09:47:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> What do you mean by "build time information"?
>
> @magicus I think it's `-Xinternalversion` which has different output between Windows and Linux of the same build. But to me that's a feature not a bug. From the PR description:
> 
>> With default configuration shows `-Xinternalversion` output same as Windows, [...]

@jerboaa I agree. If anything, this PR makes me want to remove the option to *not* build reproducible. That way, there will be no discrepancies between platforms.

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

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

From erikj at openjdk.java.net  Tue Jun 14 09:00:51 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 14 Jun 2022 09:00:51 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <p6ULnQnrZW_CElUlCe3m2TvI5f4UJjZUpD5m-bLNsx0=.7194efbe-827b-44e5-ba14-4b98c719ba82@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

Is the problem that on Windows we get -Xinternalversion in local timezone but on Linux we get UTC? That's a difference that may warrant fixing, but I don't think this is the way to do it. 

I don't think it makes a practical difference if the timestamp is taken at the start of the build or when a certain src file is compiled.

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

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

From ihse at openjdk.java.net  Tue Jun 14 09:54:44 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 09:54:44 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>
Message-ID: <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>

On Mon, 13 Jun 2022 06:50:54 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

>> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
>> 
>> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?
>
> Thank you for your comments.
> I understood the goal of reproducible build. But now, ENABLE_REPRODUCIBLE_BUILD is set to false in default configuration.
> Then I think minimize the effort of SOURCE_DATE_EPOCH when reproducible build is disabled. I wonder why build time information is different from Windows and Linux.

@tkiriyama I have created https://bugs.openjdk.org/browse/JDK-8288396 for the approach I championed above, i.e. to always build reproducible instead. As part of this, the `-Xinternalversion` time stamp should be of the same format for all platforms, given the same set of options to `configure`.

The associated PR is https://github.com/openjdk/jdk/pull/9152. Can you verify if this solves your issues, and if so, close this bug?

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

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

From psandoz at openjdk.java.net  Tue Jun 14 16:26:04 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 14 Jun 2022 16:26:04 GMT
Subject: Integrated: 8287186: JDK modules participating in preview
In-Reply-To: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
Message-ID: <6CzW4Uip3pPr8mDrfl2Edu4ZQm9PWKHvjOjw6kwtv8c=.a388fde1-a6c1-4bce-bedd-09dedc110976@github.com>

On Wed, 8 Jun 2022 15:46:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

This pull request has now been integrated.

Changeset: fb297705
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb297705f6dc668bea0257efb9c46b90b5eab2e9
Stats:     140 lines in 12 files changed: 65 ins; 57 del; 18 mod

8287186: JDK modules participating in preview

Reviewed-by: alanb, jlahoda

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

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

From psandoz at openjdk.java.net  Tue Jun 14 16:45:14 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 14 Jun 2022 16:45:14 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <3U2G2s2rU3i848aC3PNZUkBVxZKhVNM3uZPWnA_AObc=.2f5a668f-a0ac-4fa5-9160-e98e7399bb33@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
 <3U2G2s2rU3i848aC3PNZUkBVxZKhVNM3uZPWnA_AObc=.2f5a668f-a0ac-4fa5-9160-e98e7399bb33@github.com>
Message-ID: <OX8A52p2wTWLhHz9ukLgZmO6-p69VOIgDbuUqzNfuxc=.08a4c09e-2436-41a9-ae49-740f9cb71dc9@github.com>

On Wed, 8 Jun 2022 22:07:38 GMT, liach <duke at openjdk.java.net> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Let java.management participate in preview features.
>
> Just curious, is it still up to incubator modules' discretion to avoid accidental user access to preview content via the modules without enabling preview, like the `PreviewFeatures.ensureEnabled()` in `StructuredTaskScope`?

@liach it depends on the API and its scope. A constructor of `StructuredTaskScope` specifies that it implicitly uses a virtual thread factory, so it performs a preview runtime check. 

The same check is also performed by `Thread.ofVirtual`, ensuring developers cannot reflectively work around 
`--enable-preview` when creating virtual threads. This approach is feasible since the API surface is so small.

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

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

From vromero at openjdk.java.net  Wed Jun 15 00:11:12 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 15 Jun 2022 00:11:12 GMT
Subject: RFR: 8288130: compiler error with AP and explicit record accessor
Message-ID: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>

Please review this PR which is fixing a tricky bug in records. Right now this code is trivial to compile by javac:

record TestRecord<T>(T someValue) {
    public T someValue() {
        return this.someValue;
    }
}

but in the presence of an annotation processor this code is entered at least two times. Every one of those times a new type variable is created. Now for records this have some implications. Record components are created once, in most cases unless there is an error for example, meaning that the type of the record component in this case was not in sync with the type of the accessor, and this is a mismatch reported as an error by the compiler. Note that if the accessor was not explicitly declared but generated this wouldn't happen as the accessor is generated from the info in the record component so a generated accessor is always in sync with its corresponding record component.

A possible solution to this issue could be to recreate the record component if there is at least a type variable in its type. But I decided to go for an all in solution recreating the record component always so if there are annotation processor rounds, a new record component would be created for each of them. This way we can future-proof this area of records which has seen bugs in the past and be sure that we are always dealing with a fresh instance of the record components.

TIA

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

Commit messages:
 - adding accompanying regression test
 - 8288130: compiler error with AP and explicit record accessor

Changes: https://git.openjdk.org/jdk/pull/9160/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288130
  Stats: 283 lines in 4 files changed: 104 ins; 79 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/9160.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9160/head:pull/9160

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

From vromero at openjdk.java.net  Wed Jun 15 03:56:40 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 15 Jun 2022 03:56:40 GMT
Subject: RFR: 8288130: compiler error with AP and explicit record accessor
 [v2]
In-Reply-To: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
References: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
Message-ID: <F4r3RPKtmkYk-gg2bhB-FFw3IUVE7WwM_eJsKo4z-T0=.009a397f-5f4f-4947-b68a-abe6089414be@github.com>

> Please review this PR which is fixing a tricky bug in records. Right now this code is trivial to compile by javac:
> 
> record TestRecord<T>(T someValue) {
>     public T someValue() {
>         return this.someValue;
>     }
> }
> 
> but in the presence of an annotation processor this code is entered at least two times. Every one of those times a new type variable is created. Now for records this have some implications. Record components are created once, in most cases unless there is an error for example, meaning that the type of the record component in this case was not in sync with the type of the accessor, and this is a mismatch reported as an error by the compiler. Note that if the accessor was not explicitly declared but generated this wouldn't happen as the accessor is generated from the info in the record component so a generated accessor is always in sync with its corresponding record component.
> 
> A possible solution to this issue could be to recreate the record component if there is at least a type variable in its type. But I decided to go for an all in solution recreating the record component always so if there are annotation processor rounds, a new record component would be created for each of them. This way we can future-proof this area of records which has seen bugs in the past and be sure that we are always dealing with a fresh instance of the record components.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  adding some documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9160/files
  - new: https://git.openjdk.org/jdk/pull/9160/files/fac1f320..af03c68d

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

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

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

From vicente.romero at oracle.com  Wed Jun 15 14:36:26 2022
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 15 Jun 2022 10:36:26 -0400
Subject: Generic type information for classes within closures not emitted
 by javac 11.0.15
In-Reply-To: <CAM21Rt8PfOAr=ZtViLJ8koaxq3vWiTHfL4hPaQrSwUz8JKVvEw@mail.gmail.com>
References: <CAM21Rt-0+Wsef5s=+JVgfBvBu8ge4X6O=LkPMaRug9fA+2uRRw@mail.gmail.com>
 <CAM21Rt8PfOAr=ZtViLJ8koaxq3vWiTHfL4hPaQrSwUz8JKVvEw@mail.gmail.com>
Message-ID: <ce6f6c7c-b41a-43a9-9fc9-f1e21b8878da@oracle.com>

Hi Dawid,

Thanks for the additional information, but from your findings it seems 
like the issue has been fixed in recent releases. Fixing it in previous 
releases seems to me like a sustaining / support job,

Thanks,
Vicente

On 6/10/22 08:48, Dawid Weiss wrote:
>
> Just FYI - I did a little bisecting archeology and it's this issue:
> https://bugs.openjdk.org/browse/JDK-8215470
>
> The signatures from the nested class are fine after that commit and 
> erased/ missing before. So the?bug is present in anything up to jdk-13-ga.
>
> Dawid
>
> On Wed, Jun 8, 2022 at 10:08 PM Dawid Weiss <dawid.weiss at gmail.com> wrote:
>
>
>     Good evening,
>
>     I've spent an interesting day debugging a very awkward error in
>     Google Guice: a binding would work in JDK17 but would result in an
>     odd (and misleading) error information under JDK11. This turns out
>     to be a problem with generic signatures emitted by the
>     corresponding compilers.
>
>     I narrowed it down to essentially something like this [full source
>     at 1]:
>
>     Callable<Void> r =
>     ? ? ? ? () -> {
>     ? ? ? ? ? class Foo1 {
>     ? ? ? ? ? ? public Map<String, Integer> field;
>     ? ? ? ? ? }
>
>     ? ? ? ? ? System.out.println("Foo1.field type: " +
>     Foo1.class.getField("field").getGenericType());
>     ? ? ? ? ? return null;
>     ? ? ? ? };
>     ? ? r.call();
>
>     When I compile and run this snippet under java 11.0.15, I get only
>     the following signatures for generic types:
>
>     Foo1.field type: interface java.util.Map
>
>     if you move the inner class declaration outside of the closure,
>     proper generic info is stored and then loaded/ printed:
>
>     Foo2.field type: java.util.Map<java.lang.String, java.lang.Integer>
>
>     In Java 17.0.3, this compiles and works fine and I can't find any
>     issue where this was fixed. Is this a class bytecode constraint
>     somewhere? My reading of the JLS [2] would suggest the signature
>     is mandatory, even if emitted from within that nested class Foo1?
>
>     Any pointers would be appreciated!
>     Dawid
>
>     [1] https://gist.github.com/dweiss/d77452c52daa178e041adce145c2e86a
>     [2]
>     https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.7.9.1
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220615/9aace31c/attachment.htm>

From sasidhar6998 at gmail.com  Sat Jun 11 16:53:23 2022
From: sasidhar6998 at gmail.com (sasi)
Date: Sat, 11 Jun 2022 22:23:23 +0530
Subject: How to Start
Message-ID: <CABnuzW+je=ebTHoo=EA-GFUe_9xS+7LJb6N=kfVTXgV9x4N2UQ@mail.gmail.com>

Hi,

I am a java developer and enthusiast.
I have been using java since 2017.

I am interested in contributing to the community and want to be involved in
contributing to the jdk compiler development.
Kindly point the way on how to start.

Are there any resources to learn?



Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220611/33dacfca/attachment.htm>

From jjg at openjdk.java.net  Wed Jun 15 21:53:42 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 15 Jun 2022 21:53:42 GMT
Subject: RFR: JDK-8288533: Missing @param tags in com.sun.source classes
Message-ID: <Jej520lK0pVKbh6idzArUZhNNXOp8xpjcdzzi8I_FoY=.5d51593d-e7bd-4d06-a898-85d401e56a8a@github.com>

Please review a noreg-doc fix to add some missing `@param` tags in the `com.sun.source` API. The added text is boilerplate taken from similar classes.

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

Commit messages:
 - JDK-8288533: Missing @param tags in com.sun.source classes

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

PR: https://git.openjdk.org/jdk19/pull/25

From darcy at openjdk.java.net  Wed Jun 15 21:53:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 15 Jun 2022 21:53:42 GMT
Subject: RFR: JDK-8288533: Missing @param tags in com.sun.source classes
In-Reply-To: <Jej520lK0pVKbh6idzArUZhNNXOp8xpjcdzzi8I_FoY=.5d51593d-e7bd-4d06-a898-85d401e56a8a@github.com>
References: <Jej520lK0pVKbh6idzArUZhNNXOp8xpjcdzzi8I_FoY=.5d51593d-e7bd-4d06-a898-85d401e56a8a@github.com>
Message-ID: <jWAAwiAbUJo1Rbqp3RQfT8m6L15QykPB6d7IQ6WfS60=.9bee30ed-23c4-4abd-b1db-746c3d420874@github.com>

On Wed, 15 Jun 2022 21:42:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a noreg-doc fix to add some missing `@param` tags in the `com.sun.source` API. The added text is boilerplate taken from similar classes.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/25

From iris at openjdk.java.net  Wed Jun 15 22:15:00 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 15 Jun 2022 22:15:00 GMT
Subject: RFR: JDK-8288533: Missing @param tags in com.sun.source classes
In-Reply-To: <Jej520lK0pVKbh6idzArUZhNNXOp8xpjcdzzi8I_FoY=.5d51593d-e7bd-4d06-a898-85d401e56a8a@github.com>
References: <Jej520lK0pVKbh6idzArUZhNNXOp8xpjcdzzi8I_FoY=.5d51593d-e7bd-4d06-a898-85d401e56a8a@github.com>
Message-ID: <Yg98OWHXGHtYZhHk0fdc8yJ2KVOGEr42vySJjOWi2IQ=.9adc9584-8c74-4af2-a091-dca441a7acc7@github.com>

On Wed, 15 Jun 2022 21:42:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a noreg-doc fix to add some missing `@param` tags in the `com.sun.source` API. The added text is boilerplate taken from similar classes.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/25

From jjg at openjdk.java.net  Wed Jun 15 22:36:12 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 15 Jun 2022 22:36:12 GMT
Subject: Integrated: JDK-8288533: Missing @param tags in com.sun.source classes
In-Reply-To: <Jej520lK0pVKbh6idzArUZhNNXOp8xpjcdzzi8I_FoY=.5d51593d-e7bd-4d06-a898-85d401e56a8a@github.com>
References: <Jej520lK0pVKbh6idzArUZhNNXOp8xpjcdzzi8I_FoY=.5d51593d-e7bd-4d06-a898-85d401e56a8a@github.com>
Message-ID: <ETsyevSzgXFE4c5FmznvRH42SvR1vH6oiX2p4BiK0QQ=.5c170fd7-9da9-4d90-b6cb-20904e4d2ab9@github.com>

On Wed, 15 Jun 2022 21:42:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a noreg-doc fix to add some missing `@param` tags in the `com.sun.source` API. The added text is boilerplate taken from similar classes.

This pull request has now been integrated.

Changeset: 729164f5
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/729164f53499f146579a48ba1b466c687802f330
Stats:     18 lines in 3 files changed: 18 ins; 0 del; 0 mod

8288533: Missing @param tags in com.sun.source classes

Reviewed-by: darcy, iris

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

PR: https://git.openjdk.org/jdk19/pull/25

From duke at openjdk.java.net  Thu Jun 16 06:42:03 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Thu, 16 Jun 2022 06:42:03 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>
 <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>
Message-ID: <gnT9X1ZZU0XyviDF-mHP_m3YLSRBnHJYXZW_f-A7BXU=.cdb40d23-50a9-44cc-a79e-45b8c38efa4f@github.com>

On Tue, 14 Jun 2022 09:50:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thank you for your comments.
>> I understood the goal of reproducible build. But now, ENABLE_REPRODUCIBLE_BUILD is set to false in default configuration.
>> Then I think minimize the effort of SOURCE_DATE_EPOCH when reproducible build is disabled. I wonder why build time information is different from Windows and Linux.
>
> @tkiriyama I have created https://bugs.openjdk.org/browse/JDK-8288396 for the approach I championed above, i.e. to always build reproducible instead. As part of this, the `-Xinternalversion` time stamp should be of the same format for all platforms, given the same set of options to `configure`.
> 
> The associated PR is https://github.com/openjdk/jdk/pull/9152. Can you verify if this solves your issues, and if so, close this bug?

@magicus 
Thank you. I will check it.

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

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

From jwilhelm at openjdk.java.net  Thu Jun 16 07:09:00 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 16 Jun 2022 07:09:00 GMT
Subject: RFR: Merge jdk19
Message-ID: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8288533: Missing @param tags in com.sun.source classes
 - 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64
 - 8288414: Long::compress/expand samples are not correct
 - 8288289: Preview APIs in jdk.jdi, jdk.management, and jdk.jfr should be reflective preview APIs
 - 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
 - 8288360: CI: ciInstanceKlass::implementor() is not consistent for well-known classes
 - 8287889: (fs) Files.copy description of REPLACE_EXISTING is hard to read
 - 8288303: C1: Miscompilation due to broken Class.getModifiers intrinsic
 - 8288214: serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java test failed
 - ... and 1 more: https://git.openjdk.org/jdk/compare/39526e28...8b43a607

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9179&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9179&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9179/files
  Stats: 254 lines in 17 files changed: 193 ins; 13 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/9179.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9179/head:pull/9179

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

From jwilhelm at openjdk.org  Thu Jun 16 12:05:20 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 16 Jun 2022 12:05:20 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>
References: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>
Message-ID: <jE5ZH0NidXVkm_bPpXtl0UPI_FXUl9NK5fQyfDq6Cvg=.57654ad5-3d0b-4019-a178-2777c19d9611@github.com>

On Thu, 16 Jun 2022 07:00:53 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 3d12c022
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d12c0225b31bb359bec70aac6befd879cd0c934
Stats:     254 lines in 17 files changed: 193 ins; 13 del; 48 mod

Merge

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

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

From asotona at openjdk.org  Thu Jun 16 13:59:07 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 13:59:07 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v11]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <E4j45zg2e_METAHDCb8VB7vBVN3OBZMV9r7kuSY_Ud0=.80634e26-7c57-40c3-b424-104af94c2591@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> 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 15 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 5 more: https://git.openjdk.org/jdk/compare/cf4a4966...3314423d

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

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=10
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

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

From asotona at openjdk.org  Thu Jun 16 17:05:17 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 17:05:17 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v12]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <3FVbsCyO8Uhv_P47AQJRdjzXy-Vrd3bD1-ReNIZ7jBI=.f4b29583-4211-4027-90b1-f7e133ff56ea@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> 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 16 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - ... and 6 more: https://git.openjdk.org/jdk/compare/e7d52e25...1b2d663d

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

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=11
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

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

From cstein at openjdk.org  Fri Jun 17 13:54:01 2022
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 17 Jun 2022 13:54:01 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v9]
In-Reply-To: <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>
Message-ID: <Y666DncZv5-PSis_udJwwCKKKsxPJ1o8SnwdTJWBQng=.957a5f1e-6df1-42b6-8e4e-cb25f537ddf4@github.com>

On Fri, 10 Jun 2022 18:28:46 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename dataprovider

LGTM

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

Marked as reviewed by cstein (Author).

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

From jlahoda at openjdk.org  Fri Jun 17 13:58:42 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 17 Jun 2022 13:58:42 GMT
Subject: RFR: 8288120: VerifyError with JEP 405 pattern match
Message-ID: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>

When pattern matching is looking up the accessor methods, it currently uses `Scope.findFirst`. This method may find a method with the same name from the record's supertype. The proposal is to use `Resolve.resolveInternalMethod` which should lookup the methods based on the ordinary rules, and should find the accessor from the record.

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

Commit messages:
 - 8288120: VerifyError with JEP 405 pattern match

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

PR: https://git.openjdk.org/jdk19/pull/34

From vromero at openjdk.org  Fri Jun 17 20:26:56 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 17 Jun 2022 20:26:56 GMT
Subject: RFR: 8288120: VerifyError with JEP 405 pattern match
In-Reply-To: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
References: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
Message-ID: <P16qkJVUuD47Zqb-DMWWFQ8Grapivu3Lcr-tTq7iakg=.8d0ae04f-d105-469f-bdad-2efbc4706cd8@github.com>

On Fri, 17 Jun 2022 13:50:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When pattern matching is looking up the accessor methods, it currently uses `Scope.findFirst`. This method may find a method with the same name from the record's supertype. The proposal is to use `Resolve.resolveInternalMethod` which should lookup the methods based on the ordinary rules, and should find the accessor from the record.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 351:

> 349:         return component2Proxy.computeIfAbsent(component, c -> {
> 350:             MethodSymbol realAccessor =
> 351:                     rs.resolveInternalMethod(pos, env, component.owner.type,

why not just reading the accessor field in the record component? it should point to the method symbol of the accessor

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

PR: https://git.openjdk.org/jdk19/pull/34

From jai.forums2013 at gmail.com  Sat Jun 18 08:44:15 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 18 Jun 2022 14:14:15 +0530
Subject: Invalid jar in classpath aborts the compilation and throws an
 exception
Message-ID: <c87fd7ef-8faa-8167-210a-55c9ecbed1a7@gmail.com>

An user of Ant has reported an issue where their project's build fails 
during compilation. The failure appears to be a result of a jar (in the 
classpath) having entries that the Java's java.util.zip/jar code doesn't 
allow. The issue reported in Ant is here 
https://bz.apache.org/bugzilla/show_bug.cgi?id=66110.

In cases like these, should the javac tool just ignore such jar files 
and continue with the compilation? At least for this specific issue that 
jar which is failing doesn't contribute any classes/resources for the 
compilation to succeed.

The specific exception that gets thrown comes from the ArchiveContainer 
which then propagates and ultimately results in a compilation error 
which looks like:


/foo/src/com/abc/Bz66110.java:1: error: cannot access com.abc
package com.abc;
^
ZipException opening "bz66110badJar.jar": ZIP file can't be opened as a 
file system because entry "/." has a '.' or '..' element in its name
1 error


-Jaikiran


From dawid.weiss at gmail.com  Sun Jun 19 20:22:38 2022
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Sun, 19 Jun 2022 22:22:38 +0200
Subject: Generic type information for classes within closures not emitted
 by javac 11.0.15
In-Reply-To: <ce6f6c7c-b41a-43a9-9fc9-f1e21b8878da@oracle.com>
References: <CAM21Rt-0+Wsef5s=+JVgfBvBu8ge4X6O=LkPMaRug9fA+2uRRw@mail.gmail.com>
 <CAM21Rt8PfOAr=ZtViLJ8koaxq3vWiTHfL4hPaQrSwUz8JKVvEw@mail.gmail.com>
 <ce6f6c7c-b41a-43a9-9fc9-f1e21b8878da@oracle.com>
Message-ID: <CAM21Rt_g9fmx9V3Y1C5K2CoBwHHhVpG3AvoHZd4koZpU+Sa2pA@mail.gmail.com>

Hi Vicente,

Apologies for the late reply - I missed your reply.

Thanks for the additional information, but from your findings it seems like
> the issue has been fixed in recent releases. Fixing it in previous releases
> seems to me like a sustaining / support job,
>

Right. It's been fixed in JDK 13+. I've been thinking about it - this is a
bug to me, since the spec in JDK11+ clearly says the compiler must emit
proper information about generic signatures present in source files (even
for this odd case of a class nested inside a closure). I'm not sure whether
the impact of this bug is significant enough to warrant a backport to
JDK11... but since it's an LTE release then perhaps it should be
backported? It's definitely a nasty surprise if you're using those
signatures anyhow because it will only manifest the problem if you use
JDK11 compiler (and will work just fine with a newer compiler combined with
--release 11).

Dawid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220619/0d652efa/attachment-0001.htm>

From jjg at openjdk.org  Mon Jun 20 00:06:13 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 20 Jun 2022 00:06:13 GMT
Subject: RFR: JDK-8288699: cleanup HTML tree in
 HtmlDocletWriter.commentTagsToContent
Message-ID: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>

Please review a particularly satisfying review of a cleanup for
`HtmlDocletWriter.commentTagsToContent`, and the use of `RawHtml`.

The background for this is a separate cleanup for `CommentHelper.getText`,
during which it was observed that the code could be eliminated, with some
uses being replaced by `HtmlDocletWriter.commentTagsToContent`. That led
to more tags being processed, which in turn led to the observation that
`Content.charCount` was often giving incorrect results.

The primary root cause of the problem with `Content.charCount` was the
handling of `StartElementTree` in the visitor in `commentTagsToContent`.
The problem is that code there creates a sequence of text nodes for the
attributes, preceded by a `RawHtml` object containing `<TAGNAME` and followed
by another separate `RawHtml` node containing just `>`.  The net result
is that `charCount` is mistaken into including the size of the intervening
text nodes in the total, because it does not recognize the "unbalanced" `<`
and `>` in the surrounding nodes.

The general system fix for `commentTagsToContent` is to change the _visit..._
methods to always append to the `Content` object supplied as a parameter, instead
of to a fixed local variable (`result`) in the enclosing scope. This allows
`visitStartElement` to accumulate the attributes in a temporary buffer,
and then create a single `RawHtml` node as the translation of the
`StartElementTree`.  Changing the methodology of the visitors also
required disentangling the processing of `{@docRoot}`, which generally
always appears inside the `href` attribute, typically followed by
the rest of the URL. The complication there is that since forever there
has been special handling of `{@docRoot}/..` which can be replaced by
the value of the `--docrootparent` option. In reviewing that part of the code,
it may help to just ignore the old code and just review the new replacement
code.

Starting with the code in `commentTagsToContent`, it became worthwhile to
use factory methods on `RawHtml` for stylized uses of the class, for _start
element_, _end element_, and _comment_. These all have a `charCount` of zero,
so it only becomes necessary to compute the character count when given
arbitrary text.

Related, the `Text` and `TextBuilder` classes are changed so that they 
contain unescaped content, and only escape the HTML characters when they
are written out. This allows their `charCount` to simply return the `length()`
of the string content, instead of having to parse the content to account
of any entities that may be present.  This also means that newline characters
will be counted; previously, they were not.

Another noteworthy change. Somewhat usually, some resource strings for the
description of mandated methods, such as for enum and record classes, contain
simple HTML (`<i>...</i>`), which is modelled in a single `TextTree` and
subsequently converted to a non-standard use of `RawHtml`. To avoid
significantly changing the resource strings, the solution is to parse the
resources into a suitable `List<DocTree>`, using a relatively simple regular
expression. The goal is to _not_ extend the support any further than that
provided.

Finally, one more change/bug fix. We do not claim to support HTML CDATA
sections, but there is one in the JDK API docs (in `coll-index.html`). 
It "mostly worked" by accident, but dropped the leading `<`, which "broke"
the section in the generated output. I've put code into `DocCommentParser`
to handle CDATA sections, representing them (for now) as a `Text` node
containing just the section itself. This is then handled specially up in
`commentTagsToContent`, where it is translated to a new `RawHtml` node.

For reviewing, I suggest starting with `RawHtml` and then `HtmlDocletWriter`.
Many of the other changes are derivative changes, such as changing
`new RawHtml(...)` to `RawHtml.of(...)` and similar other changes.

All tests continue to pass without change.

There are minor changes to the generated docs, in two flavors.

1. There is one instance, in `Collectors.html`, where the fixes to `charCount`
   are enough to change the separator after the type parameters in a 
   method summary table from `&nbsp;` to `<br>`. 
   See `AbstractMemberWriter` line 207. The current threshold is 10, and
   some of the methods in `Collectors.html` were less and are now more.

2. A number of files use an unescaped `>` in doc comments. These are now
   translated to `&gt;` in the output.  The change in behavior is because of
   changing to use `html.Text` nodes instead of `html.RawHtml` nodes to represent
   user-provided text in `TextTree` nodes.
   Previously, the generated output was inconsistent in this area: most
   instances used `&gt;`, but user-provided `>` was passed through.
   Now, the output is consistent. 
   FWIW, `tidy` prefers the use of `&gt;` as well.

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

Commit messages:
 - JDK-8288699: cleanup HTML tree in HtmlDocletWriter.commentTagsToContent

Changes: https://git.openjdk.org/jdk/pull/9210/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9210&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288699
  Stats: 353 lines in 14 files changed: 189 ins; 64 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/9210.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9210/head:pull/9210

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

From jonathan.gibbons at oracle.com  Mon Jun 20 00:14:17 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 19 Jun 2022 17:14:17 -0700
Subject: Invalid jar in classpath aborts the compilation and throws an
 exception
In-Reply-To: <c87fd7ef-8faa-8167-210a-55c9ecbed1a7@gmail.com>
References: <c87fd7ef-8faa-8167-210a-55c9ecbed1a7@gmail.com>
Message-ID: <07640433-675e-49c4-a739-bd8ac38d963b@oracle.com>

At a minimum, javac should report an error that it cannot open the file, 
and not simply ignore it.? I think an error is warranted over a warning, 
because the compilation cannot determine if it has been adversely 
affected by the bad jar file.? Eventually, I would expect the error to 
cause javac to exit with a non-zero exit code. Once an error has been 
reported, javac may continue "for a while" but will give up at the next 
point that it checks the error status.

-- Jon

On 6/18/22 1:44 AM, Jaikiran Pai wrote:
> An user of Ant has reported an issue where their project's build fails 
> during compilation. The failure appears to be a result of a jar (in 
> the classpath) having entries that the Java's java.util.zip/jar code 
> doesn't allow. The issue reported in Ant is here 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=66110.
>
> In cases like these, should the javac tool just ignore such jar files 
> and continue with the compilation? At least for this specific issue 
> that jar which is failing doesn't contribute any classes/resources for 
> the compilation to succeed.
>
> The specific exception that gets thrown comes from the 
> ArchiveContainer which then propagates and ultimately results in a 
> compilation error which looks like:
>
>
> /foo/src/com/abc/Bz66110.java:1: error: cannot access com.abc
> package com.abc;
> ^
> ZipException opening "bz66110badJar.jar": ZIP file can't be opened as 
> a file system because entry "/." has a '.' or '..' element in its name
> 1 error
>
>
> -Jaikiran
>

From jlahoda at openjdk.org  Mon Jun 20 12:00:49 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 20 Jun 2022 12:00:49 GMT
Subject: RFR: 8288120: VerifyError with JEP 405 pattern match [v2]
In-Reply-To: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
References: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
Message-ID: <-ozeXFqJ7bx0iGFfj3MvLARQZjZxtl97Q6BBZ4yN_V0=.0701b23a-fdcb-4b12-8e17-c25928edc9ec@github.com>

> When pattern matching is looking up the accessor methods, it currently uses `Scope.findFirst`. This method may find a method with the same name from the record's supertype. The proposal is to use `Resolve.resolveInternalMethod` which should lookup the methods based on the ordinary rules, and should find the accessor from the record.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Using component's accessor, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/34/files
  - new: https://git.openjdk.org/jdk19/pull/34/files/0dab927a..b013dc88

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

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk19/pull/34.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/34/head:pull/34

PR: https://git.openjdk.org/jdk19/pull/34

From jlahoda at openjdk.org  Mon Jun 20 12:00:51 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 20 Jun 2022 12:00:51 GMT
Subject: RFR: 8288120: VerifyError with JEP 405 pattern match [v2]
In-Reply-To: <P16qkJVUuD47Zqb-DMWWFQ8Grapivu3Lcr-tTq7iakg=.8d0ae04f-d105-469f-bdad-2efbc4706cd8@github.com>
References: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
 <P16qkJVUuD47Zqb-DMWWFQ8Grapivu3Lcr-tTq7iakg=.8d0ae04f-d105-469f-bdad-2efbc4706cd8@github.com>
Message-ID: <P6I5Kf7ECngl67V-SfJ53pMgUKu4jrJ6RO6nbfgIrcQ=.88f25768-9d58-47d0-b914-54e6a28063dd@github.com>

On Fri, 17 Jun 2022 20:24:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using component's accessor, as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 351:
> 
>> 349:         return component2Proxy.computeIfAbsent(component, c -> {
>> 350:             MethodSymbol realAccessor =
>> 351:                     rs.resolveInternalMethod(pos, env, component.owner.type,
> 
> suggestion: I think that you can just read the `accessor` field in the record component, it should point to the accessor's symbol which is what you want here

Thanks, I didn't realize that! Fixed now.

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

PR: https://git.openjdk.org/jdk19/pull/34

From jai.forums2013 at gmail.com  Mon Jun 20 15:18:00 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 20 Jun 2022 20:48:00 +0530
Subject: Invalid jar in classpath aborts the compilation and throws an
 exception
In-Reply-To: <07640433-675e-49c4-a739-bd8ac38d963b@oracle.com>
References: <c87fd7ef-8faa-8167-210a-55c9ecbed1a7@gmail.com>
 <07640433-675e-49c4-a739-bd8ac38d963b@oracle.com>
Message-ID: <03c20373-ced7-3a9e-ef0f-1895e6cc9a2d@gmail.com>

Hello Jon,

In its current form, javac does exit with a non-zero exit code and does 
report the root exception. However, based on what you say, I'm guessing 
javac could be enhanced to do this specific error reporting differently? 
Did I understand it right? If so, should I be creating a JBS enhancement 
request for it?

-Jaikiran

On 20/06/22 5:44 am, Jonathan Gibbons wrote:
> At a minimum, javac should report an error that it cannot open the 
> file, and not simply ignore it.? I think an error is warranted over a 
> warning, because the compilation cannot determine if it has been 
> adversely affected by the bad jar file.? Eventually, I would expect 
> the error to cause javac to exit with a non-zero exit code. Once an 
> error has been reported, javac may continue "for a while" but will 
> give up at the next point that it checks the error status.
>
> -- Jon
>
> On 6/18/22 1:44 AM, Jaikiran Pai wrote:
>> An user of Ant has reported an issue where their project's build 
>> fails during compilation. The failure appears to be a result of a jar 
>> (in the classpath) having entries that the Java's java.util.zip/jar 
>> code doesn't allow. The issue reported in Ant is here 
>> https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?id=66110__;!!ACWV5N9M2RV99hQ!J2GfDkI71NhF8OZiNgI3K0QoMrV5vNjJhkjYy8nMgEI-F-WhFvyViHBKsIavFhzZJH2DWEBa8Rgf0F7lVVwh02HcZI3Weg$ .
>>
>> In cases like these, should the javac tool just ignore such jar files 
>> and continue with the compilation? At least for this specific issue 
>> that jar which is failing doesn't contribute any classes/resources 
>> for the compilation to succeed.
>>
>> The specific exception that gets thrown comes from the 
>> ArchiveContainer which then propagates and ultimately results in a 
>> compilation error which looks like:
>>
>>
>> /foo/src/com/abc/Bz66110.java:1: error: cannot access com.abc
>> package com.abc;
>> ^
>> ZipException opening "bz66110badJar.jar": ZIP file can't be opened as 
>> a file system because entry "/." has a '.' or '..' element in its name
>> 1 error
>>
>>
>> -Jaikiran
>>

From jonathan.gibbons at oracle.com  Mon Jun 20 16:40:33 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 20 Jun 2022 09:40:33 -0700
Subject: [External] : Re: Invalid jar in classpath aborts the compilation
 and throws an exception
In-Reply-To: <03c20373-ced7-3a9e-ef0f-1895e6cc9a2d@gmail.com>
References: <c87fd7ef-8faa-8167-210a-55c9ecbed1a7@gmail.com>
 <07640433-675e-49c4-a739-bd8ac38d963b@oracle.com>
 <03c20373-ced7-3a9e-ef0f-1895e6cc9a2d@gmail.com>
Message-ID: <0dee974c-4080-9273-63c1-96520395c59d@oracle.com>

I was not suggesting that javac should handle this issue in any special 
way.? If it gives a coherent message and exits with an error code, that 
seems sufficient.

What are you guessing that javac could do differently/better?

-- Jon


On 6/20/22 8:18 AM, Jaikiran Pai wrote:
> Hello Jon,
>
> In its current form, javac does exit with a non-zero exit code and 
> does report the root exception. However, based on what you say, I'm 
> guessing javac could be enhanced to do this specific error reporting 
> differently? Did I understand it right? If so, should I be creating a 
> JBS enhancement request for it?
>
> -Jaikiran
>
> On 20/06/22 5:44 am, Jonathan Gibbons wrote:
>> At a minimum, javac should report an error that it cannot open the 
>> file, and not simply ignore it.? I think an error is warranted over a 
>> warning, because the compilation cannot determine if it has been 
>> adversely affected by the bad jar file.? Eventually, I would expect 
>> the error to cause javac to exit with a non-zero exit code. Once an 
>> error has been reported, javac may continue "for a while" but will 
>> give up at the next point that it checks the error status.
>>
>> -- Jon
>>
>> On 6/18/22 1:44 AM, Jaikiran Pai wrote:
>>> An user of Ant has reported an issue where their project's build 
>>> fails during compilation. The failure appears to be a result of a 
>>> jar (in the classpath) having entries that the Java's 
>>> java.util.zip/jar code doesn't allow. The issue reported in Ant is 
>>> here 
>>> https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?id=66110__;!!ACWV5N9M2RV99hQ!ICdtR3KvThiV0w3XCZPTzhhkC6Ki7ZHkeCP5wxQZWNO1mDbFBFu9oHwKY_PgoPaEriHC1-AkQp8x_ylu23tXHUhcylFm9Q$ 
>>> .
>>>
>>> In cases like these, should the javac tool just ignore such jar 
>>> files and continue with the compilation? At least for this specific 
>>> issue that jar which is failing doesn't contribute any 
>>> classes/resources for the compilation to succeed.
>>>
>>> The specific exception that gets thrown comes from the 
>>> ArchiveContainer which then propagates and ultimately results in a 
>>> compilation error which looks like:
>>>
>>>
>>> /foo/src/com/abc/Bz66110.java:1: error: cannot access com.abc
>>> package com.abc;
>>> ^
>>> ZipException opening "bz66110badJar.jar": ZIP file can't be opened 
>>> as a file system because entry "/." has a '.' or '..' element in its 
>>> name
>>> 1 error
>>>
>>>
>>> -Jaikiran
>>>

From jai.forums2013 at gmail.com  Tue Jun 21 05:56:43 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 21 Jun 2022 11:26:43 +0530
Subject: [External] : Re: Invalid jar in classpath aborts the compilation
 and throws an exception
In-Reply-To: <0dee974c-4080-9273-63c1-96520395c59d@oracle.com>
References: <c87fd7ef-8faa-8167-210a-55c9ecbed1a7@gmail.com>
 <07640433-675e-49c4-a739-bd8ac38d963b@oracle.com>
 <03c20373-ced7-3a9e-ef0f-1895e6cc9a2d@gmail.com>
 <0dee974c-4080-9273-63c1-96520395c59d@oracle.com>
Message-ID: <afb61545-b9f7-ac80-7d38-00f94eb056f1@gmail.com>

Hello Jon,

On 20/06/22 10:10 pm, Jonathan Gibbons wrote:
> I was not suggesting that javac should handle this issue in any 
> special way.? If it gives a coherent message and exits with an error 
> code, that seems sufficient.
>
> What are you guessing that javac could do differently/better?

I misunderstood your previous reply. Thank you for your inputs.

-Jaikiran


>
> -- Jon
>
>
> On 6/20/22 8:18 AM, Jaikiran Pai wrote:
>> Hello Jon,
>>
>> In its current form, javac does exit with a non-zero exit code and 
>> does report the root exception. However, based on what you say, I'm 
>> guessing javac could be enhanced to do this specific error reporting 
>> differently? Did I understand it right? If so, should I be creating a 
>> JBS enhancement request for it?
>>
>> -Jaikiran
>>
>> On 20/06/22 5:44 am, Jonathan Gibbons wrote:
>>> At a minimum, javac should report an error that it cannot open the 
>>> file, and not simply ignore it. I think an error is warranted over a 
>>> warning, because the compilation cannot determine if it has been 
>>> adversely affected by the bad jar file.? Eventually, I would expect 
>>> the error to cause javac to exit with a non-zero exit code. Once an 
>>> error has been reported, javac may continue "for a while" but will 
>>> give up at the next point that it checks the error status.
>>>
>>> -- Jon
>>>
>>> On 6/18/22 1:44 AM, Jaikiran Pai wrote:
>>>> An user of Ant has reported an issue where their project's build 
>>>> fails during compilation. The failure appears to be a result of a 
>>>> jar (in the classpath) having entries that the Java's 
>>>> java.util.zip/jar code doesn't allow. The issue reported in Ant is 
>>>> here 
>>>> https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?id=66110__;!!ACWV5N9M2RV99hQ!ICdtR3KvThiV0w3XCZPTzhhkC6Ki7ZHkeCP5wxQZWNO1mDbFBFu9oHwKY_PgoPaEriHC1-AkQp8x_ylu23tXHUhcylFm9Q$ 
>>>> .
>>>>
>>>> In cases like these, should the javac tool just ignore such jar 
>>>> files and continue with the compilation? At least for this specific 
>>>> issue that jar which is failing doesn't contribute any 
>>>> classes/resources for the compilation to succeed.
>>>>
>>>> The specific exception that gets thrown comes from the 
>>>> ArchiveContainer which then propagates and ultimately results in a 
>>>> compilation error which looks like:
>>>>
>>>>
>>>> /foo/src/com/abc/Bz66110.java:1: error: cannot access com.abc
>>>> package com.abc;
>>>> ^
>>>> ZipException opening "bz66110badJar.jar": ZIP file can't be opened 
>>>> as a file system because entry "/." has a '.' or '..' element in 
>>>> its name
>>>> 1 error
>>>>
>>>>
>>>> -Jaikiran
>>>>

From duke at openjdk.org  Tue Jun 21 06:29:44 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 21 Jun 2022 06:29:44 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>
 <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>
Message-ID: <0mVNgmpMBfN6cAe10CMInds_yHF3CCFSnSfFOJm1lus=.33d4e0e3-58f7-4d53-9feb-09282093e1c1@github.com>

On Tue, 14 Jun 2022 09:50:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thank you for your comments.
>> I understood the goal of reproducible build. But now, ENABLE_REPRODUCIBLE_BUILD is set to false in default configuration.
>> Then I think minimize the effort of SOURCE_DATE_EPOCH when reproducible build is disabled. I wonder why build time information is different from Windows and Linux.
>
> @tkiriyama I have created https://bugs.openjdk.org/browse/JDK-8288396 for the approach I championed above, i.e. to always build reproducible instead. As part of this, the `-Xinternalversion` time stamp should be of the same format for all platforms, given the same set of options to `configure`.
> 
> The associated PR is https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9152__;!!ACWV5N9M2RV99hQ!I-c1AHkIkg9lRzQ__LZUdtjPSllOILJRT7z0J-K1DZsFKAhqldVGYzUj1ZpqlSJoAW6So46_Q8TO6Xkrd7w$ . Can you verify if this solves your issues, and if so, close this bug?

@magicus Thank you for your action. I tried to build above PR branch, and I could get same build information between Windows and Linux
with ISO8601 format. I would close this PR.

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

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

From duke at openjdk.org  Tue Jun 21 06:29:44 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 21 Jun 2022 06:29:44 GMT
Subject: Withdrawn: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <OPPVg_LUW23L_qUwsgKtg4HdKFgJfi_HYmSikxBKAtQ=.ddb646e8-2fd1-4507-abc1-0022cb26fc1b@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

This pull request has been closed without being integrated.

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

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

From vromero at openjdk.org  Tue Jun 21 14:54:49 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 21 Jun 2022 14:54:49 GMT
Subject: RFR: 8288120: VerifyError with JEP 405 pattern match [v2]
In-Reply-To: <-ozeXFqJ7bx0iGFfj3MvLARQZjZxtl97Q6BBZ4yN_V0=.0701b23a-fdcb-4b12-8e17-c25928edc9ec@github.com>
References: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
 <-ozeXFqJ7bx0iGFfj3MvLARQZjZxtl97Q6BBZ4yN_V0=.0701b23a-fdcb-4b12-8e17-c25928edc9ec@github.com>
Message-ID: <ASTiSRnGCvHA2F_Wr7bnuG7k85woFUYt2KA_3LpYl58=.de2267ed-1660-4ada-8017-ef1e5a8b4597@github.com>

On Mon, 20 Jun 2022 12:00:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When pattern matching is looking up the accessor methods, it currently uses `Scope.findFirst`. This method may find a method with the same name from the record's supertype. The proposal is to use `Resolve.resolveInternalMethod` which should lookup the methods based on the ordinary rules, and should find the accessor from the record.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using component's accessor, as suggested.

Marked as reviewed by vromero (Reviewer).

lgtm

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 359:

> 357:                                                   currentClass);
> 358:             JCStatement accessorStatement =
> 359:                     make.Return(make.App(make.Select(make.Ident(proxy.params().head), c.accessor)));

I let this to your consideration: it could be worth as part of this patch to check if there are other places in the record patterns code that can benefit from this simplification.

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

PR: https://git.openjdk.org/jdk19/pull/34Marked as reviewed by vromero (Reviewer).

From duke at openjdk.org  Wed Jun 22 11:52:56 2022
From: duke at openjdk.org (ExE Boss)
Date: Wed, 22 Jun 2022 11:52:56 GMT
Subject: RFR: JDK-8286101: Support formatting in @value tag [v3]
In-Reply-To: <CWdwdv2SqEzApFSmzK-NUF81hrLkl3xuPtRY0s5lo_Q=.fec3fd71-a560-4817-b1bf-639ff62ca167@github.com>
References: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
 <CWdwdv2SqEzApFSmzK-NUF81hrLkl3xuPtRY0s5lo_Q=.fec3fd71-a560-4817-b1bf-639ff62ca167@github.com>
Message-ID: <ylEeTBv6F2RDGz6W31fLHY1hb9WEYCeLIs7i3xKHBxo=.2b3f2418-76d7-4c53-aa9f-c7ea0f6b9071@github.com>

On Tue, 17 May 2022 23:14:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This PR is for an update to the doc comment `{@value}` tag to permit an optional [format string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html#syntax) after the name of the tag.
>> 
>>     {@value optional-format-string optional-reference}
>> 
>> If given, the format string should either begin with `%` or the string should be quoted with `"`. For example, `%4x` or `"0x%4x"`.  The format string must contain exactly one `%` character.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - fix typo
>  - Merge remote-tracking branch 'upstream/master' into 8286101.format-at-value
>  - address review feedback
>  - address review feedback
>  - Merge remote-tracking branch 'upstream/master' into 8286101.format-at-value
>  - JDK-8286101: Support formatting in @value tag

src/jdk.compiler/share/classes/com/sun/source/doctree/ValueTree.java line 51:

> 49:      *
> 50:      * @implSpec This implementation returns {@code null}.
> 51:      * @since 19

This?`@since`?tag is?wrong (unless?this?will be?backported to?JDK?19)

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 423:

> 421:      *
> 422:      * @implSpec This implementation calls {@link #newValueTree(ReferenceTree) newValueTree(ref)}.
> 423:      * @since 19

[ditto](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8565*discussion_r903643787__;Iw!!ACWV5N9M2RV99hQ!Ir09a7Rmj7yiBDj-Yar_lqrXonjkCBWFil-QIF5odOVwiSmhjiaTF5nCl1SrFfshP7T0xDc2MpACM2uqjx0$ )

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

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

From prappo at openjdk.org  Wed Jun 22 12:09:45 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Jun 2022 12:09:45 GMT
Subject: RFR: JDK-8286101: Support formatting in @value tag [v3]
In-Reply-To: <ylEeTBv6F2RDGz6W31fLHY1hb9WEYCeLIs7i3xKHBxo=.2b3f2418-76d7-4c53-aa9f-c7ea0f6b9071@github.com>
References: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
 <CWdwdv2SqEzApFSmzK-NUF81hrLkl3xuPtRY0s5lo_Q=.fec3fd71-a560-4817-b1bf-639ff62ca167@github.com>
 <ylEeTBv6F2RDGz6W31fLHY1hb9WEYCeLIs7i3xKHBxo=.2b3f2418-76d7-4c53-aa9f-c7ea0f6b9071@github.com>
Message-ID: <SyWZzkpsVF09DPGiwnEdy5igBOBTjgQSf-HrgScoTSM=.69ca2903-a7a5-49df-934d-c523e0f6c76b@github.com>

On Wed, 22 Jun 2022 11:48:43 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - fix typo
>>  - Merge remote-tracking branch 'upstream/master' into 8286101.format-at-value
>>  - address review feedback
>>  - address review feedback
>>  - Merge remote-tracking branch 'upstream/master' into 8286101.format-at-value
>>  - JDK-8286101: Support formatting in @value tag
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 423:
> 
>> 421:      *
>> 422:      * @implSpec This implementation calls {@link #newValueTree(ReferenceTree) newValueTree(ref)}.
>> 423:      * @since 19
> 
> [ditto](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8565*discussion_r903643787__;Iw!!ACWV5N9M2RV99hQ!OefhDI1nJuK70xP_MU0qM4VUBW_5zEkCiO0YbZLH3mzVgAhuto2GpOXu44BQhWQZCNEMccVaVR5SAI_nmgk88A$ )

Those `@since` tags were correct when the PR was approved, but became outdated on the 9th of June. What can I say? A PR has a shelf life.

Those tags should be fixed. @jonathan-gibbons, please file a bug and I will review it. @ExE-Boss, thanks for noticing.

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

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

From jlahoda at openjdk.org  Wed Jun 22 13:17:58 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 22 Jun 2022 13:17:58 GMT
Subject: RFR: 8288120: VerifyError with JEP 405 pattern match [v2]
In-Reply-To: <ASTiSRnGCvHA2F_Wr7bnuG7k85woFUYt2KA_3LpYl58=.de2267ed-1660-4ada-8017-ef1e5a8b4597@github.com>
References: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
 <-ozeXFqJ7bx0iGFfj3MvLARQZjZxtl97Q6BBZ4yN_V0=.0701b23a-fdcb-4b12-8e17-c25928edc9ec@github.com>
 <ASTiSRnGCvHA2F_Wr7bnuG7k85woFUYt2KA_3LpYl58=.de2267ed-1660-4ada-8017-ef1e5a8b4597@github.com>
Message-ID: <khawYNAAomxXXB9Kq2s2Dbgww7tgJtSqX-2Zh1L77Gk=.40d86828-7514-4183-b350-1fd6550a6cea@github.com>

On Tue, 21 Jun 2022 14:50:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using component's accessor, as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 359:
> 
>> 357:                                                   currentClass);
>> 358:             JCStatement accessorStatement =
>> 359:                     make.Return(make.App(make.Select(make.Ident(proxy.params().head), c.accessor)));
> 
> I let this to your consideration: it could be worth as part of this patch to check if there are other places in the record patterns code that can benefit from this simplification.

Thanks, but I don't recall other places in the current pattern matching code that would be looking up the accessors.

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

PR: https://git.openjdk.org/jdk19/pull/34

From vromero at openjdk.org  Wed Jun 22 14:27:01 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 22 Jun 2022 14:27:01 GMT
Subject: RFR: 8288120: VerifyError with JEP 405 pattern match [v2]
In-Reply-To: <khawYNAAomxXXB9Kq2s2Dbgww7tgJtSqX-2Zh1L77Gk=.40d86828-7514-4183-b350-1fd6550a6cea@github.com>
References: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
 <-ozeXFqJ7bx0iGFfj3MvLARQZjZxtl97Q6BBZ4yN_V0=.0701b23a-fdcb-4b12-8e17-c25928edc9ec@github.com>
 <ASTiSRnGCvHA2F_Wr7bnuG7k85woFUYt2KA_3LpYl58=.de2267ed-1660-4ada-8017-ef1e5a8b4597@github.com>
 <khawYNAAomxXXB9Kq2s2Dbgww7tgJtSqX-2Zh1L77Gk=.40d86828-7514-4183-b350-1fd6550a6cea@github.com>
Message-ID: <IRVsSy28tQpTNKluT6EGTjtrkTCvED8vbuOIf9ovD3M=.dbf33ed7-f8bc-46c4-9429-a7b2cb57db1d@github.com>

On Wed, 22 Jun 2022 13:14:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 359:
>> 
>>> 357:                                                   currentClass);
>>> 358:             JCStatement accessorStatement =
>>> 359:                     make.Return(make.App(make.Select(make.Ident(proxy.params().head), c.accessor)));
>> 
>> I let this to your consideration: it could be worth as part of this patch to check if there are other places in the record patterns code that can benefit from this simplification.
>
> Thanks, but I don't recall other places in the current pattern matching code that would be looking up the accessors.

ok sounds good

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

PR: https://git.openjdk.org/jdk19/pull/34

From vromero at openjdk.org  Wed Jun 22 15:00:37 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 22 Jun 2022 15:00:37 GMT
Subject: RFR: 8288130: compiler error with AP and explicit record accessor
 [v3]
In-Reply-To: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
References: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
Message-ID: <cIk0T3fnyQbsuBAfWisUTBX1zBqLJqZ38s3vlNZbPpM=.3ede586c-eb91-48ac-8b3c-21163c58ccc4@github.com>

> Please review this PR which is fixing a tricky bug in records. Right now this code is trivial to compile by javac:
> 
> record TestRecord<T>(T someValue) {
>     public T someValue() {
>         return this.someValue;
>     }
> }
> 
> but in the presence of an annotation processor this code is entered at least two times. Every one of those times a new type variable is created. Now for records this have some implications. Record components are created once, in most cases unless there is an error for example, meaning that the type of the record component in this case was not in sync with the type of the accessor, and this is a mismatch reported as an error by the compiler. Note that if the accessor was not explicitly declared but generated this wouldn't happen as the accessor is generated from the info in the record component so a generated accessor is always in sync with its corresponding record component.
> 
> A possible solution to this issue could be to recreate the record component if there is at least a type variable in its type. But I decided to go for an all in solution recreating the record component always so if there are annotation processor rounds, a new record component would be created for each of them. This way we can future-proof this area of records which has seen bugs in the past and be sure that we are always dealing with a fresh instance of the record components.
> 
> TIA

Vicente Romero 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:

 - Merge branch 'master' into JDK-8288130
 - adding some documentation
 - adding accompanying regression test
 - 8288130: compiler error with AP and explicit record accessor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9160/files
  - new: https://git.openjdk.org/jdk/pull/9160/files/af03c68d..d0d86769

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

  Stats: 26450 lines in 921 files changed: 14299 ins; 9582 del; 2569 mod
  Patch: https://git.openjdk.org/jdk/pull/9160.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9160/head:pull/9160

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

From jjg at openjdk.org  Wed Jun 22 19:55:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 22 Jun 2022 19:55:16 GMT
Subject: RFR: JDK-8288994: Incorrect @since tags for @value update in
 JDK-8286101
Message-ID: <BXBvBfTvrJucDkfe5bT5UUTOlqLoqKKVgZPKvw0U2WI=.995b8b26-ee89-4108-9671-25a8a5933055@github.com>

Please review a trivial update to correct the values of the @since tags from a recent commit

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

Commit messages:
 - JDK-8288994: Incorrect @since tags for @value update in JDK-8286101

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

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

From jjg at openjdk.org  Wed Jun 22 20:00:24 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 22 Jun 2022 20:00:24 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v10]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <IV76zR3sLTS__JKwvy28eNUsdftvr9z_UEK2HZRJ2mo=.d5922cc6-a5e9-4092-afc2-c69aae1e89f9@github.com>

> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Updates for latest repo
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge with upstream/master
 - fix copyright dates
   remove archaic obsolete build flags
 - more URI -> URL
 - address review feedback
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - address review feedback
 - fix merge issues
 - ... and 4 more: https://git.openjdk.org/jdk/compare/58b6937b...26540818

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

Changes: https://git.openjdk.org/jdk/pull/8439/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=09
  Stats: 1501 lines in 41 files changed: 1473 ins; 6 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8439/head:pull/8439

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

From darcy at openjdk.org  Wed Jun 22 20:05:39 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 22 Jun 2022 20:05:39 GMT
Subject: RFR: JDK-8288994: Incorrect @since tags for @value update in
 JDK-8286101
In-Reply-To: <BXBvBfTvrJucDkfe5bT5UUTOlqLoqKKVgZPKvw0U2WI=.995b8b26-ee89-4108-9671-25a8a5933055@github.com>
References: <BXBvBfTvrJucDkfe5bT5UUTOlqLoqKKVgZPKvw0U2WI=.995b8b26-ee89-4108-9671-25a8a5933055@github.com>
Message-ID: <TzrBTy7yBmE8NK6O99pvyt_P7abkp7Kjzh3Zm1zvSNs=.8f515c3a-209c-44ba-a8b8-819bbee44189@github.com>

On Wed, 22 Jun 2022 19:47:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to correct the values of the @since tags from a recent commit

Marked as reviewed by darcy (Reviewer).

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

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

From prappo at openjdk.org  Wed Jun 22 20:19:42 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Jun 2022 20:19:42 GMT
Subject: RFR: JDK-8288994: Incorrect @since tags for @value update in
 JDK-8286101
In-Reply-To: <BXBvBfTvrJucDkfe5bT5UUTOlqLoqKKVgZPKvw0U2WI=.995b8b26-ee89-4108-9671-25a8a5933055@github.com>
References: <BXBvBfTvrJucDkfe5bT5UUTOlqLoqKKVgZPKvw0U2WI=.995b8b26-ee89-4108-9671-25a8a5933055@github.com>
Message-ID: <Kem3HB26pX1tQt1Vt7OgZ7X0W1hy7aRsZiYRQu3nEGY=.7b975330-fe01-4125-9928-f4ebbbe27e9e@github.com>

On Wed, 22 Jun 2022 19:47:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to correct the values of the @since tags from a recent commit

Marked as reviewed by prappo (Reviewer).

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

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

From jjg at openjdk.org  Wed Jun 22 20:53:37 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 22 Jun 2022 20:53:37 GMT
Subject: Integrated: JDK-8288994: Incorrect @since tags for @value update in
 JDK-8286101
In-Reply-To: <BXBvBfTvrJucDkfe5bT5UUTOlqLoqKKVgZPKvw0U2WI=.995b8b26-ee89-4108-9671-25a8a5933055@github.com>
References: <BXBvBfTvrJucDkfe5bT5UUTOlqLoqKKVgZPKvw0U2WI=.995b8b26-ee89-4108-9671-25a8a5933055@github.com>
Message-ID: <cz0e-QTZNSlkPzsQyP1aXgqX6LLUFWBUWDBD4rTkYgA=.b0a327b5-fbc7-4496-9a34-8325522d9d09@github.com>

On Wed, 22 Jun 2022 19:47:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to correct the values of the @since tags from a recent commit

This pull request has now been integrated.

Changeset: 3b1ec3e6
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b1ec3e660b9905f59373022b287de77196b407c
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8288994: Incorrect @since tags for @value update in JDK-8286101

Reviewed-by: darcy, prappo

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

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

From duke at openjdk.org  Thu Jun 23 09:44:55 2022
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 23 Jun 2022 09:44:55 GMT
Subject: Integrated: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <1oiFpWx4lrBNiCVme8mpQejB2dulWsgNu_mNyCJ_Lhs=.df893121-6a43-4701-afa5-ceb023388dd1@github.com>

On Tue, 7 Jun 2022 00:45:17 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

This pull request has now been integrated.

Changeset: a802b981
Author:    Thiago Henrique H?pner <thihup at gmail.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a802b9816ac5c0cb0fd236cc7f25ed4fdb1349ef
Stats:     139 lines in 2 files changed: 136 ins; 0 del; 3 mod

8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Reviewed-by: lancea, alanb, cstein

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

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

From darcy at openjdk.org  Fri Jun 24 05:00:18 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Jun 2022 05:00:18 GMT
Subject: RFR: JDK-8288609: Update --release 19 symbol information for JDK 19
 build 28
Message-ID: <404IOCHtV-W-fMxX9Fr699gC9qZqHXEvd3BL8CcfMCg=.eff0bd1a-102e-41e0-b6f7-8569161d3893@github.com>

Update symbol information in JDK 20 for the latest JDK 19 build.

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

Commit messages:
 - JDK-8288609: Update --release 19 symbol information for JDK 19 build 28

Changes: https://git.openjdk.org/jdk/pull/9270/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9270&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288609
  Stats: 32 lines in 4 files changed: 13 ins; 13 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9270.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9270/head:pull/9270

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

From iris at openjdk.org  Fri Jun 24 06:21:40 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 24 Jun 2022 06:21:40 GMT
Subject: RFR: JDK-8288609: Update --release 19 symbol information for JDK
 19 build 28
In-Reply-To: <404IOCHtV-W-fMxX9Fr699gC9qZqHXEvd3BL8CcfMCg=.eff0bd1a-102e-41e0-b6f7-8569161d3893@github.com>
References: <404IOCHtV-W-fMxX9Fr699gC9qZqHXEvd3BL8CcfMCg=.eff0bd1a-102e-41e0-b6f7-8569161d3893@github.com>
Message-ID: <ivndQblcR5ui3RnI1IlcBPLjhKOykgVxh3my4RmBJME=.e2952e88-ec67-40e8-b8da-42e9f2540279@github.com>

On Fri, 24 Jun 2022 04:52:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update symbol information in JDK 20 for the latest JDK 19 build.

Marked as reviewed by iris (Reviewer).

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

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

From sadayapalam at openjdk.org  Fri Jun 24 07:49:53 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Fri, 24 Jun 2022 07:49:53 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <JvwW8kJ1rn2Ds48TI76zHgCJ_pMH--TeYz9Hl1en73I=.18f32cb4-7286-43c8-9b02-a126db75da88@github.com>

On Thu, 2 Jun 2022 01:09:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

I think one point of view is to say com.sun.tools.javac.code.Type.Visitor is missing a method, say


R visitPrimtiveType(JCPrimitiveType t, S s);


but really the current method


R visitType(Type t, S s);


serves as the catch all clause, so to speak.

Is it a good enough catch all or does the current problem at hand calls for a discriminating/distinguishing special case method for primitive types is a question.

I think the real problem stems from (a) com.sun.tools.javac.code.Types.MapVisitor#visitType method being idempotent: 

``` 
public Type visitType(Type t, S s) { return t; }


AND

the visitor com.sun.tools.javac.code.Type#stripMetadata's failing to override that method thereby leaving it to the superclass's idempotent implementation to be the implementation.

If I add the following method to com.sun.tools.javac.code.Type#stripMetadata, the failing test passes:


            @Override
            public Type visitType(Type t, Void aVoid) {
                return super.visitType(t.typeNoMetadata(), aVoid);
            }

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

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

From sadayapalam at openjdk.org  Fri Jun 24 08:03:08 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Fri, 24 Jun 2022 08:03:08 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <7m8-SMK10Fs0YG-1sp-XF1vLyATNgwqIPZ8W_aNTTDo=.b97b1696-5ccc-493a-9a31-c4274c03af03@github.com>

On Thu, 2 Jun 2022 01:09:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

Also it occurs to me that there is inconsistency in com.sun.tools.javac.model.JavacTypes#erasure (implementing javax.lang.model.util.Types#erasure) stripping the type annotations 

(See https://mail.openjdk.org/pipermail/compiler-dev/2014-May/008792.html where Alex makes the comment:
For example, if I have a TypeMirror that 
represents '@Foo List<String\>', and I pass it to the erasure method, 
then I could reasonably expect to get back a TypeMirror that represents 
'@Foo List'. Similarly for getArrayType, getDeclaredType, etc."
)

while javax.lang.model.util.Types#getArrayType preserving the annotations.

But I think this behavior is too entrenched to do much about it - the new comments calling out the cases where the annotations are preserved, it would appear are documenting current behavior expressly and so OK.

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

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

From sadayapalam at openjdk.org  Fri Jun 24 08:13:54 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Fri, 24 Jun 2022 08:13:54 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <FK_tAeBmoMBzVFg6-rj1Ev767myWT03ybyxYOLGnACA=.83667f3b-ebaf-4997-a9ad-8be7dfb3c24f@github.com>

On Thu, 2 Jun 2022 01:09:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

Also worth observing is there already being several overrides of com.sun.tools.javac.code.Types.MapVisitor#visitType  where the idempotent return is unsuitable. So it seems the present problem also should simply override and handle suitably as opposed to introducing a new method.

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

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

From jlahoda at openjdk.org  Fri Jun 24 08:16:20 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 24 Jun 2022 08:16:20 GMT
Subject: Integrated: 8288120: VerifyError with JEP 405 pattern match
In-Reply-To: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
References: <xFJaBruVpsGuCvkPvsYL-NYWK0Wyj5v860q7Z_dPYhM=.ba014560-aefd-469a-835d-4f419f4e1dac@github.com>
Message-ID: <jlTnnM8iJXAqz2K9ww7BPIolKFa-_OwCgaFc30a8ofU=.c8dcab27-79cc-44d8-b2d2-b9dd0bbc17e5@github.com>

On Fri, 17 Jun 2022 13:50:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When pattern matching is looking up the accessor methods, it currently uses `Scope.findFirst`. This method may find a method with the same name from the record's supertype. The proposal is to use `Resolve.resolveInternalMethod` which should lookup the methods based on the ordinary rules, and should find the accessor from the record.

This pull request has now been integrated.

Changeset: bdf9902f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/bdf9902f753b71f30be8e1634fc361a5c7d8d8ec
Stats:     55 lines in 2 files changed: 48 ins; 4 del; 3 mod

8288120: VerifyError with JEP 405 pattern match

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk19/pull/34

From darcy at openjdk.org  Fri Jun 24 16:29:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Jun 2022 16:29:53 GMT
Subject: Integrated: JDK-8288609: Update --release 19 symbol information for
 JDK 19 build 28
In-Reply-To: <404IOCHtV-W-fMxX9Fr699gC9qZqHXEvd3BL8CcfMCg=.eff0bd1a-102e-41e0-b6f7-8569161d3893@github.com>
References: <404IOCHtV-W-fMxX9Fr699gC9qZqHXEvd3BL8CcfMCg=.eff0bd1a-102e-41e0-b6f7-8569161d3893@github.com>
Message-ID: <qsygtpgUc7pKVZTKI09wE5ciO3UfQRNY4-T2nCOqnNs=.6f212fc5-ae04-4bd4-ba73-2e4caf923972@github.com>

On Fri, 24 Jun 2022 04:52:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update symbol information in JDK 20 for the latest JDK 19 build.

This pull request has now been integrated.

Changeset: 9918b6d3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9918b6d384a2f7841fcbbbe5c5e7ef83d347c697
Stats:     32 lines in 4 files changed: 13 ins; 13 del; 6 mod

8288609: Update --release 19 symbol information for JDK 19 build 28

Reviewed-by: iris

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

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

From jlahoda at openjdk.org  Fri Jun 24 17:51:58 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 24 Jun 2022 17:51:58 GMT
Subject: RFR: 8288130: compiler error with AP and explicit record accessor
 [v3]
In-Reply-To: <cIk0T3fnyQbsuBAfWisUTBX1zBqLJqZ38s3vlNZbPpM=.3ede586c-eb91-48ac-8b3c-21163c58ccc4@github.com>
References: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
 <cIk0T3fnyQbsuBAfWisUTBX1zBqLJqZ38s3vlNZbPpM=.3ede586c-eb91-48ac-8b3c-21163c58ccc4@github.com>
Message-ID: <kqo5VgCDoE6vHNgvlT7UHn8CqrM-2tPfDODdFpuu2aQ=.510d5d41-5e2d-4118-ab67-e2c92e0a69f5@github.com>

On Wed, 22 Jun 2022 15:00:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR which is fixing a tricky bug in records. Right now this code is trivial to compile by javac:
>> 
>> record TestRecord<T>(T someValue) {
>>     public T someValue() {
>>         return this.someValue;
>>     }
>> }
>> 
>> but in the presence of an annotation processor this code is entered at least two times. Every one of those times a new type variable is created. Now for records this have some implications. Record components are created once, in most cases unless there is an error for example, meaning that the type of the record component in this case was not in sync with the type of the accessor, and this is a mismatch reported as an error by the compiler. Note that if the accessor was not explicitly declared but generated this wouldn't happen as the accessor is generated from the info in the record component so a generated accessor is always in sync with its corresponding record component.
>> 
>> A possible solution to this issue could be to recreate the record component if there is at least a type variable in its type. But I decided to go for an all in solution recreating the record component always so if there are annotation processor rounds, a new record component would be created for each of them. This way we can future-proof this area of records which has seen bugs in the past and be sure that we are always dealing with a fresh instance of the record components.
>> 
>> TIA
>
> Vicente Romero 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:
> 
>  - Merge branch 'master' into JDK-8288130
>  - adding some documentation
>  - adding accompanying regression test
>  - 8288130: compiler error with AP and explicit record accessor

Overall, the approach seems fine to me. Added some comments for consideration.

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

> 1508:             for (RecordComponent rc : recordComponents) {
> 1509:                 /* it could be that a record erroneously declares two record components with the same name, in that
> 1510:                  * case we need to use the position to disambiguate

I'd suggest to consider renaming this method. It does not "get" the record component, it (re-)creates it The `addIfMissing` parameter appears to be always `true`, and can be removed.

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

> 1516:             RecordComponent rc = null;
> 1517:             if (toRemove != null) {
> 1518:                 // Found a record component with an erroneous type: remove it and create a new one

Maybe update this comment?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 1254:

> 1252:                 RecordComponent rec = tree.sym.getRecordComponent(field.sym);
> 1253:                 TreeCopier<JCTree> tc = new TreeCopier<>(make.at(field.pos));
> 1254:                 List<JCAnnotation> originalAnnos = rec.getOriginalAnnos().isEmpty() ?

For you consideration:
-when instead of `rec.getOriginalAnnos().isEmpty() ...`, maybe just `tc.copy(rec.getOriginalAnnos())` (with a possible tweak to the copy method to not create the `ListBuffer` when the input is empty?)
-when setting the annotations, `fields.mods.annotations = originalAnnos` might be better, as it will keep other metadata of the modifiers (if needed/useful)

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

Marked as reviewed by jlahoda (Reviewer).

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

From vromero at openjdk.org  Fri Jun 24 20:04:57 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Jun 2022 20:04:57 GMT
Subject: RFR: 8288130: compiler error with AP and explicit record accessor
 [v3]
In-Reply-To: <kqo5VgCDoE6vHNgvlT7UHn8CqrM-2tPfDODdFpuu2aQ=.510d5d41-5e2d-4118-ab67-e2c92e0a69f5@github.com>
References: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
 <cIk0T3fnyQbsuBAfWisUTBX1zBqLJqZ38s3vlNZbPpM=.3ede586c-eb91-48ac-8b3c-21163c58ccc4@github.com>
 <kqo5VgCDoE6vHNgvlT7UHn8CqrM-2tPfDODdFpuu2aQ=.510d5d41-5e2d-4118-ab67-e2c92e0a69f5@github.com>
Message-ID: <lElQDbFCDj_G-0vf7Bc7kibEpe1V4FDbHAtXcxYz5q4=.b006c553-0f3d-4f88-b7d6-a3c568dfe194@github.com>

On Fri, 24 Jun 2022 17:48:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero 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:
>> 
>>  - Merge branch 'master' into JDK-8288130
>>  - adding some documentation
>>  - adding accompanying regression test
>>  - 8288130: compiler error with AP and explicit record accessor
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1510:
> 
>> 1508:             for (RecordComponent rc : recordComponents) {
>> 1509:                 /* it could be that a record erroneously declares two record components with the same name, in that
>> 1510:                  * case we need to use the position to disambiguate
> 
> I'd suggest to consider renaming this method. It does not "get" the record component, it (re-)creates it The `addIfMissing` parameter appears to be always `true`, and can be removed.

I agree

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

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

From jjg at openjdk.org  Fri Jun 24 21:00:43 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 24 Jun 2022 21:00:43 GMT
Subject: RFR: JDK-8275784: Bogus warning generated for record with compact
 constructor
Message-ID: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>

Please review a simple change to disable the check for missing `@param` tags in the case of a compact constructor for a record. In this case, there is no explicit argument list: it is inferred from the  list of record components, and so there is no need to check for `@param` tags.

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

Commit messages:
 - JDK-8275784: Bogus warning generated for record with compact constructor

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

PR: https://git.openjdk.org/jdk19/pull/70

From jjg at openjdk.org  Fri Jun 24 21:24:10 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 24 Jun 2022 21:24:10 GMT
Subject: RFR: JDK-8280826: Document set of strings javac recognizes for
 SuppressWarnings
Message-ID: <UFrPqvrx13EYa8NglVMRKk1jZhl7BkD33u3zv1J7ZV8=.16a3045a-3b23-4211-b8a4-5088f24e8342@github.com>

Please review a docs fix to document the set of strings recognized by javac support for `@SuppressWarnings`.

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

Commit messages:
 - update version info
 - JDK-8280826: Document set of strings javac recognizes for SuppressWarnings
 - JDK-8280826

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

PR: https://git.openjdk.org/jdk19/pull/71

From vromero at openjdk.org  Fri Jun 24 21:45:51 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Jun 2022 21:45:51 GMT
Subject: RFR: 8288130: compiler error with AP and explicit record accessor
 [v4]
In-Reply-To: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
References: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
Message-ID: <Lsx2Vu9SMsznhxeuC4XhPI4nLT-FhNvolrh7JE9vNtk=.d63fc6b0-b572-4cc7-967b-89149087b65c@github.com>

> Please review this PR which is fixing a tricky bug in records. Right now this code is trivial to compile by javac:
> 
> record TestRecord<T>(T someValue) {
>     public T someValue() {
>         return this.someValue;
>     }
> }
> 
> but in the presence of an annotation processor this code is entered at least two times. Every one of those times a new type variable is created. Now for records this have some implications. Record components are created once, in most cases unless there is an error for example, meaning that the type of the record component in this case was not in sync with the type of the accessor, and this is a mismatch reported as an error by the compiler. Note that if the accessor was not explicitly declared but generated this wouldn't happen as the accessor is generated from the info in the record component so a generated accessor is always in sync with its corresponding record component.
> 
> A possible solution to this issue could be to recreate the record component if there is at least a type variable in its type. But I decided to go for an all in solution recreating the record component always so if there are annotation processor rounds, a new record component would be created for each of them. This way we can future-proof this area of records which has seen bugs in the past and be sure that we are always dealing with a fresh instance of the record components.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9160/files
  - new: https://git.openjdk.org/jdk/pull/9160/files/d0d86769..0d4b4a64

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

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

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

From vromero at openjdk.org  Fri Jun 24 21:45:58 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Jun 2022 21:45:58 GMT
Subject: Integrated: 8288130: compiler error with AP and explicit record
 accessor
In-Reply-To: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
References: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
Message-ID: <LyzosV1aMMPXEIFTqYeyAN-yiT6AxJIdEcwLl_tXJ_w=.24d20aec-6c6d-489a-81a8-31ae3ce54149@github.com>

On Wed, 15 Jun 2022 00:01:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing a tricky bug in records. Right now this code is trivial to compile by javac:
> 
> record TestRecord<T>(T someValue) {
>     public T someValue() {
>         return this.someValue;
>     }
> }
> 
> but in the presence of an annotation processor this code is entered at least two times. Every one of those times a new type variable is created. Now for records this have some implications. Record components are created once, in most cases unless there is an error for example, meaning that the type of the record component in this case was not in sync with the type of the accessor, and this is a mismatch reported as an error by the compiler. Note that if the accessor was not explicitly declared but generated this wouldn't happen as the accessor is generated from the info in the record component so a generated accessor is always in sync with its corresponding record component.
> 
> A possible solution to this issue could be to recreate the record component if there is at least a type variable in its type. But I decided to go for an all in solution recreating the record component always so if there are annotation processor rounds, a new record component would be created for each of them. This way we can future-proof this area of records which has seen bugs in the past and be sure that we are always dealing with a fresh instance of the record components.
> 
> TIA

This pull request has now been integrated.

Changeset: 53b37fe1
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53b37fe1535388eb14e04c620a6b0118ed8884a0
Stats:     308 lines in 5 files changed: 124 ins; 79 del; 105 mod

8288130: compiler error with AP and explicit record accessor

Reviewed-by: jlahoda

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

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

From vromero at openjdk.org  Fri Jun 24 21:45:56 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Jun 2022 21:45:56 GMT
Subject: RFR: 8288130: compiler error with AP and explicit record accessor
 [v3]
In-Reply-To: <cIk0T3fnyQbsuBAfWisUTBX1zBqLJqZ38s3vlNZbPpM=.3ede586c-eb91-48ac-8b3c-21163c58ccc4@github.com>
References: <UoaOMjtcjIGtS-H6nrO1GjYSYK-Gui63FvVPrXxKZss=.b01561ac-6597-4337-9be6-8bee8f277b79@github.com>
 <cIk0T3fnyQbsuBAfWisUTBX1zBqLJqZ38s3vlNZbPpM=.3ede586c-eb91-48ac-8b3c-21163c58ccc4@github.com>
Message-ID: <Fhmxg02mZ1qTBpGNlnoOUgzPR-kAHJpitxmUHywOfUA=.99699e75-cbdb-4a26-b8a5-0e79cbfb4b20@github.com>

On Wed, 22 Jun 2022 15:00:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR which is fixing a tricky bug in records. Right now this code is trivial to compile by javac:
>> 
>> record TestRecord<T>(T someValue) {
>>     public T someValue() {
>>         return this.someValue;
>>     }
>> }
>> 
>> but in the presence of an annotation processor this code is entered at least two times. Every one of those times a new type variable is created. Now for records this have some implications. Record components are created once, in most cases unless there is an error for example, meaning that the type of the record component in this case was not in sync with the type of the accessor, and this is a mismatch reported as an error by the compiler. Note that if the accessor was not explicitly declared but generated this wouldn't happen as the accessor is generated from the info in the record component so a generated accessor is always in sync with its corresponding record component.
>> 
>> A possible solution to this issue could be to recreate the record component if there is at least a type variable in its type. But I decided to go for an all in solution recreating the record component always so if there are annotation processor rounds, a new record component would be created for each of them. This way we can future-proof this area of records which has seen bugs in the past and be sure that we are always dealing with a fresh instance of the record components.
>> 
>> TIA
>
> Vicente Romero 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:
> 
>  - Merge branch 'master' into JDK-8288130
>  - adding some documentation
>  - adding accompanying regression test
>  - 8288130: compiler error with AP and explicit record accessor

thanks for the review

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

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

From darcy at openjdk.org  Fri Jun 24 23:00:59 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Jun 2022 23:00:59 GMT
Subject: RFR: JDK-8280826: Document set of strings javac recognizes for
 SuppressWarnings
In-Reply-To: <UFrPqvrx13EYa8NglVMRKk1jZhl7BkD33u3zv1J7ZV8=.16a3045a-3b23-4211-b8a4-5088f24e8342@github.com>
References: <UFrPqvrx13EYa8NglVMRKk1jZhl7BkD33u3zv1J7ZV8=.16a3045a-3b23-4211-b8a4-5088f24e8342@github.com>
Message-ID: <mGFqfvf0OtoB7dhzi5HURFlCRq9riKHtc0RtPWR6bZ4=.fcb56090-59ff-4ab2-8e7a-6024084a8b2b@github.com>

On Fri, 24 Jun 2022 21:03:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a docs fix to document the set of strings recognized by javac support for `@SuppressWarnings`.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/71

From darcy at openjdk.org  Sun Jun 26 22:52:43 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 26 Jun 2022 22:52:43 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

 - Update visitor; all langtools regression tests pass.
 - Merge branch 'master' into JDK-8042981
 - JDK-8042981: Strip type annotations in Types' utility methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/8c0e1817..0dacb981

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

  Stats: 77527 lines in 1908 files changed: 44921 ins; 17904 del; 14702 mod
  Patch: https://git.openjdk.org/jdk/pull/8984.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8984/head:pull/8984

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

From darcy at openjdk.org  Sun Jun 26 22:55:35 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 26 Jun 2022 22:55:35 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
In-Reply-To: <FK_tAeBmoMBzVFg6-rj1Ev767myWT03ybyxYOLGnACA=.83667f3b-ebaf-4997-a9ad-8be7dfb3c24f@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <FK_tAeBmoMBzVFg6-rj1Ev767myWT03ybyxYOLGnACA=.83667f3b-ebaf-4997-a9ad-8be7dfb3c24f@github.com>
Message-ID: <n_7X3ebmS9hx2tlUXpSrcOk5x26OEc2HSeJNfwn8T8Y=.a20a9627-0ae6-44a7-9186-e1bc9fd301ef@github.com>

On Fri, 24 Jun 2022 08:10:07 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Also worth observing is there already being several overrides of com.sun.tools.javac.code.Types.MapVisitor#visitType where the idempotent return is unsuitable. So it seems the present problem also should simply override and handle suitably as opposed to introducing a new method.

Thanks @sadayapalam, adding the method you suggested resolved the issue and allows all the existing langtools regression tests to pass. 

I updated the  directSupertypes spec to have the annotations preserved, which was the (reasonable) behavior expected by an existing type annotations test.

I'll take another pass over refining the spec and tests.

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

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

From asotona at openjdk.org  Mon Jun 27 08:53:01 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Jun 2022 08:53:01 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v13]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <TYFZimuHBQWcdrZsDq3i-o6gLmjjC0Ca8R8BdDsGX3Y=.5bf9fe73-3a01-4b5c-ad3d-dc8d81093d0a@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> 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 17 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - ... and 7 more: https://git.openjdk.org/jdk/compare/7905788e...cab6ce59

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

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=12
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

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

From asotona at openjdk.org  Mon Jun 27 09:25:58 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Jun 2022 09:25:58 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v14]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

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

  re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8599/files
  - new: https://git.openjdk.org/jdk/pull/8599/files/cab6ce59..6f32938d

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

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

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

From prappo at openjdk.org  Mon Jun 27 10:38:44 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 27 Jun 2022 10:38:44 GMT
Subject: [jdk19] RFR: JDK-8275784: Bogus warning generated for record with
 compact constructor
In-Reply-To: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
References: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
Message-ID: <7QTAE3VK0uXkKu9IJxUzRomRwsMdDib9l6fXwieKXIQ=.40a9bea5-f6ea-4816-b83d-1940cc1d4ad1@github.com>

On Fri, 24 Jun 2022 20:53:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple change to disable the check for missing `@param` tags in the case of a compact constructor for a record. In this case, there is no explicit argument list: it is inferred from the  list of record components, and so there is no need to check for `@param` tags.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 270:

> 268:     }
> 269: 
> 270:     private  boolean isCanonicalRecordConstructor(ExecutableElement ee) {

Remove extra whitespace between `private` and `boolean`.

I would expect javax.lang.model to provide this functionality. Unfortunately, I couldn't find it. On the other hand, a very similar method exists in jdk.javadoc.internal.doclets.toolkit.util.Utils. It would be nice if we could avoid any duplication.

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

PR: https://git.openjdk.org/jdk19/pull/70

From jwilhelm at openjdk.org  Mon Jun 27 11:55:51 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 11:55:51 GMT
Subject: RFR: Merge jdk19
Message-ID: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8289079: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with "RuntimeException: Test failed"
 - 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing
 - 8288983: broken link in com.sun.net.httpserver.SimpleFileServer
 - 8289044: ARM32: missing LIR_Assembler::cmove metadata type support
 - 8288120: VerifyError with JEP 405 pattern match
 - 8288528: broken links in java.desktop
 - 8288080: (fc) FileChannel::map for MemorySegments should state it always throws UOE
 - 8287076: Document.normalizeDocument() produces different results
 - 8288589: Files.readString ignores encoding errors for UTF-16
 - ... and 2 more: https://git.openjdk.org/jdk/compare/7905788e...9579cc05

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9296/files
  Stats: 366 lines in 24 files changed: 274 ins; 41 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/9296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9296/head:pull/9296

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

From jjg at openjdk.org  Mon Jun 27 17:05:45 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Jun 2022 17:05:45 GMT
Subject: [jdk19] RFR: JDK-8275784: Bogus warning generated for record with
 compact constructor
In-Reply-To: <7QTAE3VK0uXkKu9IJxUzRomRwsMdDib9l6fXwieKXIQ=.40a9bea5-f6ea-4816-b83d-1940cc1d4ad1@github.com>
References: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
 <7QTAE3VK0uXkKu9IJxUzRomRwsMdDib9l6fXwieKXIQ=.40a9bea5-f6ea-4816-b83d-1940cc1d4ad1@github.com>
Message-ID: <dS8J4kXp5schrnRx8pf0rzSG2_BXeoMCnc_jxNlB6hU=.2a9eac26-74e6-4637-9cfd-605c4dda8ed0@github.com>

On Mon, 27 Jun 2022 10:11:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review a simple change to disable the check for missing `@param` tags in the case of a compact constructor for a record. In this case, there is no explicit argument list: it is inferred from the  list of record components, and so there is no need to check for `@param` tags.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 270:
> 
>> 268:     }
>> 269: 
>> 270:     private  boolean isCanonicalRecordConstructor(ExecutableElement ee) {
> 
> Remove extra whitespace between `private` and `boolean`.
> 
> I would expect javax.lang.model to provide this functionality. Unfortunately, I couldn't find it. On the other hand, a very similar method exists in jdk.javadoc.internal.doclets.toolkit.util.Utils. It would be nice if we could avoid any duplication.

I don't see how we can avoid duplication at this time.

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

PR: https://git.openjdk.org/jdk19/pull/70

From jjg at openjdk.org  Mon Jun 27 17:07:45 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Jun 2022 17:07:45 GMT
Subject: [jdk19] Integrated: JDK-8280826: Document set of strings javac
 recognizes for SuppressWarnings
In-Reply-To: <UFrPqvrx13EYa8NglVMRKk1jZhl7BkD33u3zv1J7ZV8=.16a3045a-3b23-4211-b8a4-5088f24e8342@github.com>
References: <UFrPqvrx13EYa8NglVMRKk1jZhl7BkD33u3zv1J7ZV8=.16a3045a-3b23-4211-b8a4-5088f24e8342@github.com>
Message-ID: <HRXcuehiYhekTVx8VF0B33BJix5iBhijC5P3h1GbKKQ=.055d0a97-b001-4ce4-ad9d-19413f8d9948@github.com>

On Fri, 24 Jun 2022 21:03:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a docs fix to document the set of strings recognized by javac support for `@SuppressWarnings`.

This pull request has now been integrated.

Changeset: 77466648
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/77466648193abda99f53b259a1ec9475b425b4d4
Stats:     72 lines in 2 files changed: 71 ins; 0 del; 1 mod

8280826: Document set of strings javac recognizes for SuppressWarnings

Reviewed-by: darcy

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

PR: https://git.openjdk.org/jdk19/pull/71

From jjg at openjdk.org  Mon Jun 27 17:11:39 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Jun 2022 17:11:39 GMT
Subject: [jdk19] RFR: JDK-8275784: Bogus warning generated for record with
 compact constructor [v2]
In-Reply-To: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
References: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
Message-ID: <dbZ1HOZBxy5Fp-5WL9OWEWNhqi4wwZK111YiSWQx69M=.43d51ab9-4511-414d-9833-92da1db2421f@github.com>

> Please review a simple change to disable the check for missing `@param` tags in the case of a compact constructor for a record. In this case, there is no explicit argument list: it is inferred from the  list of record components, and so there is no need to check for `@param` tags.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/70/files
  - new: https://git.openjdk.org/jdk19/pull/70/files/40444e97..efc85c3a

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

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

PR: https://git.openjdk.org/jdk19/pull/70

From jjg at openjdk.org  Mon Jun 27 17:17:40 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Jun 2022 17:17:40 GMT
Subject: [jdk19] RFR: JDK-8275784: Bogus warning generated for record with
 compact constructor [v2]
In-Reply-To: <dS8J4kXp5schrnRx8pf0rzSG2_BXeoMCnc_jxNlB6hU=.2a9eac26-74e6-4637-9cfd-605c4dda8ed0@github.com>
References: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
 <7QTAE3VK0uXkKu9IJxUzRomRwsMdDib9l6fXwieKXIQ=.40a9bea5-f6ea-4816-b83d-1940cc1d4ad1@github.com>
 <dS8J4kXp5schrnRx8pf0rzSG2_BXeoMCnc_jxNlB6hU=.2a9eac26-74e6-4637-9cfd-605c4dda8ed0@github.com>
Message-ID: <gFwpPUW3F_mOIkssaYEY754uGFjSSI65hYusTnl5VKE=.97c131f8-4c46-47f0-b90a-a9c359a15124@github.com>

On Mon, 27 Jun 2022 17:02:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 270:
>> 
>>> 268:     }
>>> 269: 
>>> 270:     private  boolean isCanonicalRecordConstructor(ExecutableElement ee) {
>> 
>> Remove extra whitespace between `private` and `boolean`.
>> 
>> I would expect javax.lang.model to provide this functionality. Unfortunately, I couldn't find it. On the other hand, a very similar method exists in jdk.javadoc.internal.doclets.toolkit.util.Utils. It would be nice if we could avoid any duplication.
>
> I don't see how we can avoid duplication at this time.

It's not actually clear that `java.lang.model` has the info to provide this method, since the compact constructor is a syntactic form, that has disappeared by the time we get to the `ExecutableElement` for the constructor.  Sure, we could provide the method, but it's not clear we can detect the difference between the compact form and the use of explicit parameters.  I guess we could maybe put it on `Trees` if there is enough info on the AST, if it hasn't already been desugared away.

At some level, it comes down to ... do we allow the `@param` tags to be only omitted on the compact constructor (no args provided), or on the canonical constructor where the param names match the component names.

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

PR: https://git.openjdk.org/jdk19/pull/70

From jjg at openjdk.org  Mon Jun 27 17:22:47 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Jun 2022 17:22:47 GMT
Subject: [jdk19] RFR: JDK-8275784: Bogus warning generated for record with
 compact constructor [v2]
In-Reply-To: <gFwpPUW3F_mOIkssaYEY754uGFjSSI65hYusTnl5VKE=.97c131f8-4c46-47f0-b90a-a9c359a15124@github.com>
References: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
 <7QTAE3VK0uXkKu9IJxUzRomRwsMdDib9l6fXwieKXIQ=.40a9bea5-f6ea-4816-b83d-1940cc1d4ad1@github.com>
 <dS8J4kXp5schrnRx8pf0rzSG2_BXeoMCnc_jxNlB6hU=.2a9eac26-74e6-4637-9cfd-605c4dda8ed0@github.com>
 <gFwpPUW3F_mOIkssaYEY754uGFjSSI65hYusTnl5VKE=.97c131f8-4c46-47f0-b90a-a9c359a15124@github.com>
Message-ID: <P1kLhR2fNhG_PlhWCZmtWRfHOa-ZsDAiTJBuA7GKqUU=.eb051892-554b-4e89-828c-809e1071d16e@github.com>

On Mon, 27 Jun 2022 17:11:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> I don't see how we can avoid duplication at this time.
>
> It's not actually clear that `java.lang.model` has the info to provide this method, since the compact constructor is a syntactic form, that has disappeared by the time we get to the `ExecutableElement` for the constructor.  Sure, we could provide the method, but it's not clear we can detect the difference between the compact form and the use of explicit parameters.  I guess we could maybe put it on `Trees` if there is enough info on the AST, if it hasn't already been desugared away.
> 
> At some level, it comes down to ... do we allow the `@param` tags to be only omitted on the compact constructor (no args provided), or on the canonical constructor where the param names match the component names.

Reading JLS [8.10.4](https://docs.oracle.com/javase/specs/jls/se18/html/jls-8.html#jls-8.10.4) we could suggest `isCanonicalConstructor` for `java.lang.model`, use that, and ignore whether it is a compact t constructor or an explicitly declared canonical constructor.

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

PR: https://git.openjdk.org/jdk19/pull/70

From jwilhelm at openjdk.org  Mon Jun 27 18:32:18 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 18:32:18 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
References: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
Message-ID: <QcElHQNvmhWdtuoJp8PQe_xbRrvU3U4EGBqA20EQnPw=.77ba96a7-3560-4cd8-b8ad-0aec9e1ac6ee@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 146 commits:

 - Merge
 - 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent
   
   Reviewed-by: ayang, cjplummer
 - 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN fields static in ProcessHandleImpl
   
   Reviewed-by: jpai, rriggs, bpb, naoto, iris
 - 8289147: unify os::infinite_sleep on posix platforms
   
   Reviewed-by: mdoerr, kbarrett, dholmes
 - 8266670: Better modeling of access flags in core reflection
   
   Reviewed-by: mchung, rriggs, asotona
 - 8286395: Address possibly lossy conversions in java.security.jgss
   
   Reviewed-by: chegar
 - 8286389: Address possibly lossy conversions in jdk.crypto.ec
   
   Reviewed-by: chegar, xuelei
 - 8288130: compiler error with AP and explicit record accessor
   
   Reviewed-by: jlahoda
 - 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java
   
   Reviewed-by: lmesnik, bpb
 - 8289098: clean up ported serviceability/jvmti tests
   
   Reviewed-by: kevinw, sspitsyn
 - ... and 136 more: https://git.openjdk.org/jdk/compare/7e13cdb7...9579cc05

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

Changes: https://git.openjdk.org/jdk/pull/9296/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=01
  Stats: 47784 lines in 1125 files changed: 22921 ins; 12915 del; 11948 mod
  Patch: https://git.openjdk.org/jdk/pull/9296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9296/head:pull/9296

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

From jwilhelm at openjdk.org  Mon Jun 27 18:32:18 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 18:32:18 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
References: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
Message-ID: <EOnXQGf1n2TS6psge4FEfSaSTM5kHMVXlCOMzBiffUw=.59ead9f8-4337-4c81-8b7b-55e735c78ac6@github.com>

On Mon, 27 Jun 2022 11:49:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: d4b040f4
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4b040f42dd0a9100ad1ffa55de4ae4f20e9f182
Stats:     366 lines in 24 files changed: 274 ins; 41 del; 51 mod

Merge

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

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

From jjg at openjdk.org  Mon Jun 27 19:56:44 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Jun 2022 19:56:44 GMT
Subject: [jdk19] RFR: JDK-8275784: Bogus warning generated for record with
 compact constructor [v2]
In-Reply-To: <P1kLhR2fNhG_PlhWCZmtWRfHOa-ZsDAiTJBuA7GKqUU=.eb051892-554b-4e89-828c-809e1071d16e@github.com>
References: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
 <7QTAE3VK0uXkKu9IJxUzRomRwsMdDib9l6fXwieKXIQ=.40a9bea5-f6ea-4816-b83d-1940cc1d4ad1@github.com>
 <dS8J4kXp5schrnRx8pf0rzSG2_BXeoMCnc_jxNlB6hU=.2a9eac26-74e6-4637-9cfd-605c4dda8ed0@github.com>
 <gFwpPUW3F_mOIkssaYEY754uGFjSSI65hYusTnl5VKE=.97c131f8-4c46-47f0-b90a-a9c359a15124@github.com>
 <P1kLhR2fNhG_PlhWCZmtWRfHOa-ZsDAiTJBuA7GKqUU=.eb051892-554b-4e89-828c-809e1071d16e@github.com>
Message-ID: <na1l5z3avfpmyI6UjFiCLxZcWVOO-kzfN9n62_GL_fk=.12c5c7f4-e97b-497b-b7cb-2e61271cfac2@github.com>

On Mon, 27 Jun 2022 17:20:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> It's not actually clear that `java.lang.model` has the info to provide this method, since the compact constructor is a syntactic form, that has disappeared by the time we get to the `ExecutableElement` for the constructor.  Sure, we could provide the method, but it's not clear we can detect the difference between the compact form and the use of explicit parameters.  I guess we could maybe put it on `Trees` if there is enough info on the AST, if it hasn't already been desugared away.
>> 
>> At some level, it comes down to ... do we allow the `@param` tags to be only omitted on the compact constructor (no args provided), or on the canonical constructor where the param names match the component names.
>
> Reading JLS [8.10.4](https://docs.oracle.com/javase/specs/jls/se18/html/jls-8.html#jls-8.10.4) we could suggest `isCanonicalConstructor` for `java.lang.model`, use that, and ignore whether it is a compact t constructor or an explicitly declared canonical constructor.

[JDK-8289249](https://bugs.openjdk.org/browse/JDK-8289249)

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

PR: https://git.openjdk.org/jdk19/pull/70

From prappo at openjdk.org  Tue Jun 28 11:28:43 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Jun 2022 11:28:43 GMT
Subject: [jdk19] RFR: JDK-8275784: Bogus warning generated for record with
 compact constructor [v2]
In-Reply-To: <dbZ1HOZBxy5Fp-5WL9OWEWNhqi4wwZK111YiSWQx69M=.43d51ab9-4511-414d-9833-92da1db2421f@github.com>
References: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
 <dbZ1HOZBxy5Fp-5WL9OWEWNhqi4wwZK111YiSWQx69M=.43d51ab9-4511-414d-9833-92da1db2421f@github.com>
Message-ID: <BQdaRo-Sab88v7UDtn38JMDPBPIr3p7vxvMXXByHHqs=.ab80b6d8-5c7d-4872-af22-88e0259b29a2@github.com>

On Mon, 27 Jun 2022 17:11:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a simple change to disable the check for missing `@param` tags in the case of a compact constructor for a record. In this case, there is no explicit argument list: it is inferred from the  list of record components, and so there is no need to check for `@param` tags.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix whitespace

Marked as reviewed by prappo (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/70

From jlahoda at openjdk.org  Tue Jun 28 13:19:15 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 28 Jun 2022 13:19:15 GMT
Subject: [jdk19] RFR: 8289196: Patttern domination not working property for
 record patterns
Message-ID: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>

When checking that a pattern in a switch case is not dominated by a preceding pattern, handling for record pattern is mostly missing. This patch is attempting to fix that, and as it requires a bit more code, it moves the check into `Check`.

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

Commit messages:
 - 8289196: Patttern domination not working property for record patterns

Changes: https://git.openjdk.org/jdk19/pull/84/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=84&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289196
  Stats: 179 lines in 5 files changed: 151 ins; 21 del; 7 mod
  Patch: https://git.openjdk.org/jdk19/pull/84.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/84/head:pull/84

PR: https://git.openjdk.org/jdk19/pull/84

From jjg at openjdk.org  Tue Jun 28 15:58:29 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 28 Jun 2022 15:58:29 GMT
Subject: [jdk19] Integrated: JDK-8275784: Bogus warning generated for record
 with compact constructor
In-Reply-To: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
References: <8jPkThfRav0hoJsOoFikrm-ZipyeL3zGGKDvPZbmzgE=.3cfb6691-2e40-4a8a-9bae-f04a124e776a@github.com>
Message-ID: <mAxknXeh4VgM1_xzT0tCiYJS3yoOeTjRGeUIG4HLKz4=.4243ab0e-63b7-4675-9bfd-506f0db0722d@github.com>

On Fri, 24 Jun 2022 20:53:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple change to disable the check for missing `@param` tags in the case of a compact constructor for a record. In this case, there is no explicit argument list: it is inferred from the  list of record components, and so there is no need to check for `@param` tags.

This pull request has now been integrated.

Changeset: a814293e
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/a814293e1fb724cb85e66501ed7a8185409642df
Stats:     73 lines in 2 files changed: 71 ins; 0 del; 2 mod

8275784: Bogus warning generated for record with compact constructor

Reviewed-by: prappo

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

PR: https://git.openjdk.org/jdk19/pull/70

From hannesw at openjdk.org  Tue Jun 28 17:02:45 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 28 Jun 2022 17:02:45 GMT
Subject: RFR: JDK-8288699: cleanup HTML tree in
 HtmlDocletWriter.commentTagsToContent
In-Reply-To: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
References: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
Message-ID: <TLBJueclKnaayXDUMftTLt7oa4QJvzfaeDBVukXWwnI=.518c69f4-05a6-475b-ab31-4af22a821d5f@github.com>

On Sun, 19 Jun 2022 23:58:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a particularly satisfying review of a cleanup for
> `HtmlDocletWriter.commentTagsToContent`, and the use of `RawHtml`.
> 
> The background for this is a separate cleanup for `CommentHelper.getText`,
> during which it was observed that the code could be eliminated, with some
> uses being replaced by `HtmlDocletWriter.commentTagsToContent`. That led
> to more tags being processed, which in turn led to the observation that
> `Content.charCount` was often giving incorrect results.
> 
> The primary root cause of the problem with `Content.charCount` was the
> handling of `StartElementTree` in the visitor in `commentTagsToContent`.
> The problem is that code there creates a sequence of text nodes for the
> attributes, preceded by a `RawHtml` object containing `<TAGNAME` and followed
> by another separate `RawHtml` node containing just `>`.  The net result
> is that `charCount` is mistaken into including the size of the intervening
> text nodes in the total, because it does not recognize the "unbalanced" `<`
> and `>` in the surrounding nodes.
> 
> The general system fix for `commentTagsToContent` is to change the _visit..._
> methods to always append to the `Content` object supplied as a parameter, instead
> of to a fixed local variable (`result`) in the enclosing scope. This allows
> `visitStartElement` to accumulate the attributes in a temporary buffer,
> and then create a single `RawHtml` node as the translation of the
> `StartElementTree`.  Changing the methodology of the visitors also
> required disentangling the processing of `{@docRoot}`, which generally
> always appears inside the `href` attribute, typically followed by
> the rest of the URL. The complication there is that since forever there
> has been special handling of `{@docRoot}/..` which can be replaced by
> the value of the `--docrootparent` option. In reviewing that part of the code,
> it may help to just ignore the old code and just review the new replacement
> code.
> 
> Starting with the code in `commentTagsToContent`, it became worthwhile to
> use factory methods on `RawHtml` for stylized uses of the class, for _start
> element_, _end element_, and _comment_. These all have a `charCount` of zero,
> so it only becomes necessary to compute the character count when given
> arbitrary text.
> 
> Related, the `Text` and `TextBuilder` classes are changed so that they 
> contain unescaped content, and only escape the HTML characters when they
> are written out. This allows their `charCount` to simply return the `length()`
> of the string content, instead of having to parse the content to account
> of any entities that may be present.  This also means that newline characters
> will be counted; previously, they were not.
> 
> Another noteworthy change. Somewhat usually, some resource strings for the
> description of mandated methods, such as for enum and record classes, contain
> simple HTML (`<i>...</i>`), which is modelled in a single `TextTree` and
> subsequently converted to a non-standard use of `RawHtml`. To avoid
> significantly changing the resource strings, the solution is to parse the
> resources into a suitable `List<DocTree>`, using a relatively simple regular
> expression. The goal is to _not_ extend the support any further than that
> provided.
> 
> Finally, one more change/bug fix. We do not claim to support HTML CDATA
> sections, but there is one in the JDK API docs (in `coll-index.html`). 
> It "mostly worked" by accident, but dropped the leading `<`, which "broke"
> the section in the generated output. I've put code into `DocCommentParser`
> to handle CDATA sections, representing them (for now) as a `Text` node
> containing just the section itself. This is then handled specially up in
> `commentTagsToContent`, where it is translated to a new `RawHtml` node.
> 
> For reviewing, I suggest starting with `RawHtml` and then `HtmlDocletWriter`.
> Many of the other changes are derivative changes, such as changing
> `new RawHtml(...)` to `RawHtml.of(...)` and similar other changes.
> 
> All tests continue to pass without change.
> 
> There are minor changes to the generated docs, in two flavors.
> 
> 1. There is one instance, in `Collectors.html`, where the fixes to `charCount`
>    are enough to change the separator after the type parameters in a 
>    method summary table from `&nbsp;` to `<br>`. 
>    See `AbstractMemberWriter` line 207. The current threshold is 10, and
>    some of the methods in `Collectors.html` were less and are now more.
> 
> 2. A number of files use an unescaped `>` in doc comments. These are now
>    translated to `&gt;` in the output.  The change in behavior is because of
>    changing to use `html.Text` nodes instead of `html.RawHtml` nodes to represent
>    user-provided text in `TextTree` nodes.
>    Previously, the generated output was inconsistent in this area: most
>    instances used `&gt;`, but user-provided `>` was passed through.
>    Now, the output is consistent. 
>    FWIW, `tidy` prefers the use of `&gt;` as well.

The changes look good, apart from a few minor nitpicks in the attribute handling code. 

The only remaining issue I have is that I don't (yet) fully convinced the old `{@docRoot}` handling code does the same thing as the new one, so I'm still working on that.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1555:

> 1553:                             pendingDocRoot.accept(this, content);
> 1554:                             pendingDocRoot = null;
> 1555:                             first = false;

first is already false here and a few lines above since pendingDocRoot assignment below is followed by a `first = false` assignment.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1558:

> 1556:                         }
> 1557: 
> 1558:                         if (dt instanceof TextTree tt){

Missing space before curly bracket.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1561:

> 1559:                             String text = tt.getBody();
> 1560:                             if (first && isHRef) {
> 1561:                                 text = redirectRelativeLinks(element, (TextTree) dt);

Could use tt instead of casting again.

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

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

From jwilhelm at openjdk.org  Tue Jun 28 21:21:12 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 21:21:12 GMT
Subject: RFR: Merge jdk19
Message-ID: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again
 - 8289069: Very slow C1 arraycopy jcstress tests after JDK-8279886
 - 8288058: Broken links on constant-values page
 - 8275784: Bogus warning generated for record with compact constructor
 - 8288836: (fs) Files.writeString spec for IOException has "specified charset" when no charset is provided
 - 8288425: Footprint regression due MH creation when initializing StringConcatFactory
 - 8289228: SegmentAllocator::allocateArray null handling is too lax
 - 8288445: AArch64: C2 compilation fails with guarantee(!true || (true && (shift != 0))) failed: impossible encoding
 - 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java
 - ... and 7 more: https://git.openjdk.org/jdk/compare/af008807...d57b485f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9315/files
  Stats: 821 lines in 29 files changed: 612 ins; 71 del; 138 mod
  Patch: https://git.openjdk.org/jdk/pull/9315.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9315/head:pull/9315

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

From darcy at openjdk.org  Tue Jun 28 21:39:54 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 28 Jun 2022 21:39:54 GMT
Subject: [jdk19] RFR: JDK-8289399: Update SourceVersion to use snippets
Message-ID: <BeExLf_DFJY0C4-NT_1fLGr4OPrVWJ6_gfPT_1N2cKM=.a6ebf73a-3a0e-427a-a28a-be111de0279e@github.com>

Please review this simple doc update.

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

Commit messages:
 - JDK-8289399: Update SourceVersion to use snippets

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

PR: https://git.openjdk.org/jdk19/pull/87

From jwilhelm at openjdk.org  Tue Jun 28 22:17:08 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 22:17:08 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
References: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
Message-ID: <cubHA4OFa8jwOIA-LZWGABo7MOx2vWK4HxANnyER4kM=.ebc33bd9-ee29-4dc6-8d77-98203c0ffcc4@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 166 commits:

 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8284640: CollectorImpl class could be a record class
   
   Reviewed-by: phh, rriggs
 - 8288961: jpackage: test MSI installation fix
   
   Reviewed-by: asemenyuk, almatvee
 - 8288013: jpackage: test utility Windows registry enhancement
   
   Reviewed-by: asemenyuk, almatvee
 - 8289071: Compute allocation sizes of stubs and nmethods outside of lock protection
   
   Reviewed-by: thartmann, phh
 - 8271252: os::reserve_memory should not use mtOther as default NMT flag
   
   Reviewed-by: zgu
 - 8287818: Shenandoah: adapt nmethod arming from Loom
   
   Reviewed-by: shade
 - 8289138: G1: Remove redundant is-marking-active checks in C1 barrier
   
   Reviewed-by: tschatzl, ehelin
 - 8288396: Always create reproducible builds
   
   Reviewed-by: amenkov, ehelin
 - 8289258: ProblemList some failing custom loader tests with ZGC
   
   Reviewed-by: dholmes
 - ... and 156 more: https://git.openjdk.org/jdk/compare/15048048...d57b485f

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

Changes: https://git.openjdk.org/jdk/pull/9315/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=01
  Stats: 68839 lines in 1210 files changed: 43242 ins; 13434 del; 12163 mod
  Patch: https://git.openjdk.org/jdk/pull/9315.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9315/head:pull/9315

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

From jwilhelm at openjdk.org  Tue Jun 28 22:17:09 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 22:17:09 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
References: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
Message-ID: <gtYlusBVnnkYR36SyDWKK3AhTK2FpOpGi5Wx7ZqufwI=.dcb880bf-bbbe-48c1-9985-75d302d4cf45@github.com>

On Tue, 28 Jun 2022 21:13:05 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 86dc760f
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86dc760f9ec0f403109bef7b06db82b9ed0739dd
Stats:     821 lines in 29 files changed: 612 ins; 71 del; 138 mod

Merge

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

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

From jjg at openjdk.org  Tue Jun 28 22:45:45 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 28 Jun 2022 22:45:45 GMT
Subject: [jdk19] RFR: JDK-8289399: Update SourceVersion to use snippets
In-Reply-To: <BeExLf_DFJY0C4-NT_1fLGr4OPrVWJ6_gfPT_1N2cKM=.a6ebf73a-3a0e-427a-a28a-be111de0279e@github.com>
References: <BeExLf_DFJY0C4-NT_1fLGr4OPrVWJ6_gfPT_1N2cKM=.a6ebf73a-3a0e-427a-a28a-be111de0279e@github.com>
Message-ID: <0QG0uhyEWJVycOq7PKPGn4lo0Uejr9C2aTbGUSSog7c=.26d78bb0-d06f-4b41-9473-ec4ba1cd7215@github.com>

On Tue, 28 Jun 2022 21:30:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this simple doc update.

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/87

From iris at openjdk.org  Tue Jun 28 22:54:39 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 28 Jun 2022 22:54:39 GMT
Subject: [jdk19] RFR: JDK-8289399: Update SourceVersion to use snippets
In-Reply-To: <BeExLf_DFJY0C4-NT_1fLGr4OPrVWJ6_gfPT_1N2cKM=.a6ebf73a-3a0e-427a-a28a-be111de0279e@github.com>
References: <BeExLf_DFJY0C4-NT_1fLGr4OPrVWJ6_gfPT_1N2cKM=.a6ebf73a-3a0e-427a-a28a-be111de0279e@github.com>
Message-ID: <N9QM7cFzLreZZRv4vmMMmuVI6k3ul8UzkW3o6hueP-c=.1a1b4844-e339-4633-8d1a-ed03ba384fd8@github.com>

On Tue, 28 Jun 2022 21:30:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this simple doc update.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/87

From darcy at openjdk.org  Wed Jun 29 00:19:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Jun 2022 00:19:30 GMT
Subject: [jdk19] Integrated: JDK-8289399: Update SourceVersion to use snippets
In-Reply-To: <BeExLf_DFJY0C4-NT_1fLGr4OPrVWJ6_gfPT_1N2cKM=.a6ebf73a-3a0e-427a-a28a-be111de0279e@github.com>
References: <BeExLf_DFJY0C4-NT_1fLGr4OPrVWJ6_gfPT_1N2cKM=.a6ebf73a-3a0e-427a-a28a-be111de0279e@github.com>
Message-ID: <I84iZDu3X_EZnSKL8pZLwz1c2fP2H8nt4YB64gJhohw=.a03e9f4a-c7cb-4fe3-a61a-5145024c38a4@github.com>

On Tue, 28 Jun 2022 21:30:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this simple doc update.

This pull request has now been integrated.

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

8289399: Update SourceVersion to use snippets

Reviewed-by: jjg, iris

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

PR: https://git.openjdk.org/jdk19/pull/87

From sundar at openjdk.org  Wed Jun 29 04:16:40 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 29 Jun 2022 04:16:40 GMT
Subject: [jdk19] RFR: JDK-8289399: Update SourceVersion to use snippets
In-Reply-To: <BeExLf_DFJY0C4-NT_1fLGr4OPrVWJ6_gfPT_1N2cKM=.a6ebf73a-3a0e-427a-a28a-be111de0279e@github.com>
References: <BeExLf_DFJY0C4-NT_1fLGr4OPrVWJ6_gfPT_1N2cKM=.a6ebf73a-3a0e-427a-a28a-be111de0279e@github.com>
Message-ID: <M357sOTdn2SkCIZblK_q7btIb7nczkclRi7jggx-x4w=.7393257c-9731-4233-bb1b-fb2327a41358@github.com>

On Tue, 28 Jun 2022 21:30:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this simple doc update.

LGTM

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

PR: https://git.openjdk.org/jdk19/pull/87

From darcy at openjdk.org  Wed Jun 29 04:34:36 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Jun 2022 04:34:36 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v10]
In-Reply-To: <IV76zR3sLTS__JKwvy28eNUsdftvr9z_UEK2HZRJ2mo=.d5922cc6-a5e9-4092-afc2-c69aae1e89f9@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <IV76zR3sLTS__JKwvy28eNUsdftvr9z_UEK2HZRJ2mo=.d5922cc6-a5e9-4092-afc2-c69aae1e89f9@github.com>
Message-ID: <N4iuIF7iZa3cHFUDs0W3bpgkHNMbnhRG6qZ5MyrDAfs=.01563980-381a-438c-90b3-1d028c40bb66@github.com>

On Wed, 22 Jun 2022 20:00:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Updates for latest repo
>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>  - Merge with upstream/master
>  - fix copyright dates
>    remove archaic obsolete build flags
>  - more URI -> URL
>  - address review feedback
>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>  - address review feedback
>  - fix merge issues
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/58b6937b...26540818

src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java line 225:

> 223:          * representing an {@code @spec} tag.
> 224:          *
> 225:          * @since 19

Please correct the `@since` tag.

src/jdk.compiler/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java line 476:

> 474:      * @return  the result of {@code defaultAction}
> 475:      *
> 476:      * @since 19

Please update the `@since` tag.

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

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

From jwilhelm at openjdk.org  Wed Jun 29 23:29:28 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 29 Jun 2022 23:29:28 GMT
Subject: RFR: Merge jdk19
Message-ID: <qbz6O1eYKsoroZdGs8jNszLJV6UryTXlA0o_O_83o5M=.855e3031-b34e-412e-ac2a-a17daad15323@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289252: Recommend Locale.of() method instead of the constructor
 - 8288596: Random:from() adapter does not delegate to supplied generator in all cases
 - 8289399: Update SourceVersion to use snippets

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9330&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9330&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9330/files
  Stats: 116 lines in 4 files changed: 102 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9330.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9330/head:pull/9330

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

From jwilhelm at openjdk.org  Wed Jun 29 23:37:38 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 29 Jun 2022 23:37:38 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <qbz6O1eYKsoroZdGs8jNszLJV6UryTXlA0o_O_83o5M=.855e3031-b34e-412e-ac2a-a17daad15323@github.com>
References: <qbz6O1eYKsoroZdGs8jNszLJV6UryTXlA0o_O_83o5M=.855e3031-b34e-412e-ac2a-a17daad15323@github.com>
Message-ID: <jxYKBVWkUN-a9BQuUJqxJJ3EWvqH5H3uOHBCFBkLe5w=.e801259a-1af5-4c80-a6cc-4e3a53379d53@github.com>

On Wed, 29 Jun 2022 19:38:59 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 048bffad
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/048bffad79b302890059ffc1bc559bfc601de92c
Stats:     116 lines in 4 files changed: 102 ins; 2 del; 12 mod

Merge

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

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

From hannesw at openjdk.org  Thu Jun 30 10:59:26 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 30 Jun 2022 10:59:26 GMT
Subject: RFR: JDK-8288699: cleanup HTML tree in
 HtmlDocletWriter.commentTagsToContent
In-Reply-To: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
References: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
Message-ID: <SyqCObXDga4QfBTf3vBR56OgBkZEO1qvY5F17Fk-Y2Q=.4aead7ac-007a-46bb-9a79-6c2c73fb4c71@github.com>

On Sun, 19 Jun 2022 23:58:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a particularly satisfying review of a cleanup for
> `HtmlDocletWriter.commentTagsToContent`, and the use of `RawHtml`.
> 
> The background for this is a separate cleanup for `CommentHelper.getText`,
> during which it was observed that the code could be eliminated, with some
> uses being replaced by `HtmlDocletWriter.commentTagsToContent`. That led
> to more tags being processed, which in turn led to the observation that
> `Content.charCount` was often giving incorrect results.
> 
> The primary root cause of the problem with `Content.charCount` was the
> handling of `StartElementTree` in the visitor in `commentTagsToContent`.
> The problem is that code there creates a sequence of text nodes for the
> attributes, preceded by a `RawHtml` object containing `<TAGNAME` and followed
> by another separate `RawHtml` node containing just `>`.  The net result
> is that `charCount` is mistaken into including the size of the intervening
> text nodes in the total, because it does not recognize the "unbalanced" `<`
> and `>` in the surrounding nodes.
> 
> The general system fix for `commentTagsToContent` is to change the _visit..._
> methods to always append to the `Content` object supplied as a parameter, instead
> of to a fixed local variable (`result`) in the enclosing scope. This allows
> `visitStartElement` to accumulate the attributes in a temporary buffer,
> and then create a single `RawHtml` node as the translation of the
> `StartElementTree`.  Changing the methodology of the visitors also
> required disentangling the processing of `{@docRoot}`, which generally
> always appears inside the `href` attribute, typically followed by
> the rest of the URL. The complication there is that since forever there
> has been special handling of `{@docRoot}/..` which can be replaced by
> the value of the `--docrootparent` option. In reviewing that part of the code,
> it may help to just ignore the old code and just review the new replacement
> code.
> 
> Starting with the code in `commentTagsToContent`, it became worthwhile to
> use factory methods on `RawHtml` for stylized uses of the class, for _start
> element_, _end element_, and _comment_. These all have a `charCount` of zero,
> so it only becomes necessary to compute the character count when given
> arbitrary text.
> 
> Related, the `Text` and `TextBuilder` classes are changed so that they 
> contain unescaped content, and only escape the HTML characters when they
> are written out. This allows their `charCount` to simply return the `length()`
> of the string content, instead of having to parse the content to account
> of any entities that may be present.  This also means that newline characters
> will be counted; previously, they were not.
> 
> Another noteworthy change. Somewhat usually, some resource strings for the
> description of mandated methods, such as for enum and record classes, contain
> simple HTML (`<i>...</i>`), which is modelled in a single `TextTree` and
> subsequently converted to a non-standard use of `RawHtml`. To avoid
> significantly changing the resource strings, the solution is to parse the
> resources into a suitable `List<DocTree>`, using a relatively simple regular
> expression. The goal is to _not_ extend the support any further than that
> provided.
> 
> Finally, one more change/bug fix. We do not claim to support HTML CDATA
> sections, but there is one in the JDK API docs (in `coll-index.html`). 
> It "mostly worked" by accident, but dropped the leading `<`, which "broke"
> the section in the generated output. I've put code into `DocCommentParser`
> to handle CDATA sections, representing them (for now) as a `Text` node
> containing just the section itself. This is then handled specially up in
> `commentTagsToContent`, where it is translated to a new `RawHtml` node.
> 
> For reviewing, I suggest starting with `RawHtml` and then `HtmlDocletWriter`.
> Many of the other changes are derivative changes, such as changing
> `new RawHtml(...)` to `RawHtml.of(...)` and similar other changes.
> 
> All tests continue to pass without change.
> 
> There are minor changes to the generated docs, in two flavors.
> 
> 1. There is one instance, in `Collectors.html`, where the fixes to `charCount`
>    are enough to change the separator after the type parameters in a 
>    method summary table from `&nbsp;` to `<br>`. 
>    See `AbstractMemberWriter` line 207. The current threshold is 10, and
>    some of the methods in `Collectors.html` were less and are now more.
> 
> 2. A number of files use an unescaped `>` in doc comments. These are now
>    translated to `&gt;` in the output.  The change in behavior is because of
>    changing to use `html.Text` nodes instead of `html.RawHtml` nodes to represent
>    user-provided text in `TextTree` nodes.
>    Previously, the generated output was inconsistent in this area: most
>    instances used `&gt;`, but user-provided `>` was passed through.
>    Now, the output is consistent. 
>    FWIW, `tidy` prefers the use of `&gt;` as well.

I've had another look at the old code. I think it's safe to say that the new code is much better and does the same thing as the old code.

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

Marked as reviewed by hannesw (Reviewer).

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