From jlahoda at openjdk.java.net  Wed Sep  1 06:09:52 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 1 Sep 2021 06:09:52 GMT
Subject: Integrated: 8272618: Unnecessary Attr.visitIdent.noOuterThisPath
In-Reply-To: <qAoyphrPdu9AaqryZdeA2vUmnMMI1NYpnTrM6yH2c4c=.aeb6ff68-e772-40c7-aed2-4241739228ee@github.com>
References: <qAoyphrPdu9AaqryZdeA2vUmnMMI1NYpnTrM6yH2c4c=.aeb6ff68-e772-40c7-aed2-4241739228ee@github.com>
Message-ID: <M08HtNbB-0_3-U9_HudhM_PkjLK1dcgeMVwy5G9ITL0=.952cb2ce-e5b8-45b9-b760-1de5bbb05a03@github.com>

On Wed, 18 Aug 2021 11:42:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch removes an unnecessary variable, which was not removed when `-source <= 5` was removed:
> https://bugs.openjdk.java.net/browse/JDK-8011044

This pull request has now been integrated.

Changeset: e600fe1a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e600fe1a1a57d7e4060b3a1b9a8ecdb65664a506
Stats:     11 lines in 1 file changed: 0 ins; 8 del; 3 mod

8272618: Unnecessary Attr.visitIdent.noOuterThisPath

Reviewed-by: vromero

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

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

From jjg at openjdk.java.net  Wed Sep  1 17:45:32 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 1 Sep 2021 17:45:32 GMT
Subject: RFR: 8273157: Add convenience methods to Messager
In-Reply-To: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com>
References: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com>
Message-ID: <4rLu1G68D_tTXtgvTXIvmyzy6VVmBsSKqM_Mov_quN0=.e4f577f8-b5a5-4cf5-9ebe-ff9da4d1c445@github.com>

On Tue, 31 Aug 2021 05:06:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Hello,
> 
> Please review the addition of a half dozen convenience methods to Messager to allow code like
> 
>     m.printError("Error message")
> 
> rather than
> 
>     m.printMessage(Kind.ERROR, "Error message")
> 
> For each of notes, warnings, and errors, two methods are added: one taking a message, the second taking a message and an element. There are other overloads of the printMessage method with additional arguments, but they are less commonly used and weren't judged to merit dedicated convenience methods.
> 
> The changeset also refactors ~125 of ~150 call sites of printMessage in the langtools regression tests to use the new methods. The updated tests (or tests using the updated files) all pass. I became more convinced of the utility of the new methods after using them in the refactoring.
> 
> I'll run a script to update the copyright years before any integration.
> 
> CSR for review: https://bugs.openjdk.java.net/browse/JDK-8273160

You might want to run an IDE inspection for now-unused imports, before you push.

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

Marked as reviewed by jjg (Reviewer).

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

From darcy at openjdk.java.net  Wed Sep  1 18:46:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Sep 2021 18:46:14 GMT
Subject: RFR: 8273157: Add convenience methods to Messager [v2]
In-Reply-To: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com>
References: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com>
Message-ID: <Ma11DIjgxYPx1IZBDdly-2wGD4arX7WZqmecPMzjhBw=.b5a267ef-52c6-4ce6-8324-a2a214ade927@github.com>

> Hello,
> 
> Please review the addition of a half dozen convenience methods to Messager to allow code like
> 
>     m.printError("Error message")
> 
> rather than
> 
>     m.printMessage(Kind.ERROR, "Error message")
> 
> For each of notes, warnings, and errors, two methods are added: one taking a message, the second taking a message and an element. There are other overloads of the printMessage method with additional arguments, but they are less commonly used and weren't judged to merit dedicated convenience methods.
> 
> The changeset also refactors ~125 of ~150 call sites of printMessage in the langtools regression tests to use the new methods. The updated tests (or tests using the updated files) all pass. I became more convinced of the utility of the new methods after using them in the refactoring.
> 
> I'll run a script to update the copyright years before any integration.
> 
> CSR for review: https://bugs.openjdk.java.net/browse/JDK-8273160

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Update copyrigth years.
 - Update a few more test files.
 - Merge branch 'master' into JDK-8273157
 - 8273157

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5309/files
  - new: https://git.openjdk.java.net/jdk/pull/5309/files/c7fbe977..af256daf

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

  Stats: 2520 lines in 178 files changed: 1644 ins; 316 del; 560 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5309/head:pull/5309

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

From darcy at openjdk.java.net  Wed Sep  1 20:27:55 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Sep 2021 20:27:55 GMT
Subject: RFR: 8273157: Add convenience methods to Messager [v3]
In-Reply-To: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com>
References: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com>
Message-ID: <3OpvLkMX92HeR8MA27Pz2CvG9acgc1mF7xwqWIuLaCg=.ef740210-fdc5-47c2-89f3-1da4c772167d@github.com>

> Hello,
> 
> Please review the addition of a half dozen convenience methods to Messager to allow code like
> 
>     m.printError("Error message")
> 
> rather than
> 
>     m.printMessage(Kind.ERROR, "Error message")
> 
> For each of notes, warnings, and errors, two methods are added: one taking a message, the second taking a message and an element. There are other overloads of the printMessage method with additional arguments, but they are less commonly used and weren't judged to merit dedicated convenience methods.
> 
> The changeset also refactors ~125 of ~150 call sites of printMessage in the langtools regression tests to use the new methods. The updated tests (or tests using the updated files) all pass. I became more convinced of the utility of the new methods after using them in the refactoring.
> 
> I'll run a script to update the copyright years before any integration.
> 
> CSR for review: https://bugs.openjdk.java.net/browse/JDK-8273160

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

  Fix imports.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5309/files
  - new: https://git.openjdk.java.net/jdk/pull/5309/files/af256daf..6238078f

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

  Stats: 65 lines in 37 files changed: 3 ins; 55 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5309/head:pull/5309

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

From darcy at openjdk.java.net  Wed Sep  1 20:31:36 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Sep 2021 20:31:36 GMT
Subject: Integrated: 8273157: Add convenience methods to Messager
In-Reply-To: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com>
References: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com>
Message-ID: <T6TKrmjBW2jHA-X6MveVAYaIKvhoBi0yWhasg4rLkvk=.273c3282-5039-4b09-94ef-3d09841ae1bf@github.com>

On Tue, 31 Aug 2021 05:06:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Hello,
> 
> Please review the addition of a half dozen convenience methods to Messager to allow code like
> 
>     m.printError("Error message")
> 
> rather than
> 
>     m.printMessage(Kind.ERROR, "Error message")
> 
> For each of notes, warnings, and errors, two methods are added: one taking a message, the second taking a message and an element. There are other overloads of the printMessage method with additional arguments, but they are less commonly used and weren't judged to merit dedicated convenience methods.
> 
> The changeset also refactors ~125 of ~150 call sites of printMessage in the langtools regression tests to use the new methods. The updated tests (or tests using the updated files) all pass. I became more convinced of the utility of the new methods after using them in the refactoring.
> 
> I'll run a script to update the copyright years before any integration.
> 
> CSR for review: https://bugs.openjdk.java.net/browse/JDK-8273160

This pull request has now been integrated.

Changeset: 2f01a6f8
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2f01a6f8b6c0bc08c6e3b7ea279d3826f451607f
Stats:     445 lines in 87 files changed: 91 ins; 86 del; 268 mod

8273157: Add convenience methods to Messager

Reviewed-by: jjg

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

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

From duke at openjdk.java.net  Wed Sep  1 22:56:31 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 1 Sep 2021 22:56:31 GMT
Subject: Withdrawn: 8269113: Javac throws when compiling switch (null)
In-Reply-To: <fWvC_4cpbo7D4YLAYzbJEPsq_6lW5ckiPLry_o5v8zI=.bc4a822a-1571-4567-9b3c-b36bc60219c9@github.com>
References: <fWvC_4cpbo7D4YLAYzbJEPsq_6lW5ckiPLry_o5v8zI=.bc4a822a-1571-4567-9b3c-b36bc60219c9@github.com>
Message-ID: <TuQdratDwHUMgveeK6fBNa6PZ7_PsoHMq9PA4oM_n50=.4a853020-b7ef-46b1-9dd9-e646325f177b@github.com>

On Sun, 4 Jul 2021 18:13:26 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When we use `switch(null)` in the source code, the type of the selector is `BottomType`.
> So the statement `Type seltype = selector.type;` of the method `TransPatterns::handleSwitch` will get a `BottomType`.
> Then compiler mistakenly uses this `BottomType` to construct a new `VarSymbol`.
> 
> 
>             VarSymbol temp = new VarSymbol(Flags.SYNTHETIC,
>                     names.fromString("selector" + tree.pos + target.syntheticNameChar() + "temp"),
>                     seltype,     // <--------here is a BottomType
>                     currentMethodSym);
> 
> 
> At last, when the compiler uses the new `VarSymbol temp` to construct a new `JCVariableDecl`(the code shown as below), it crashes at the method `TreeMaker::Type` because the method `TreeMaker::Type` can't handle the type `BottomType`.
> 
> 
> statements.append(make.at(tree.pos).VarDef(temp, !hasNullCase ? attr.makeNullCheck(selector)
>                                                                           : selector));
> 
> 
> This patch changes the type from `BottomType` to `syms.objectType` and adds the corresponding test.
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has been closed without being integrated.

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

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

From vicente.romero at oracle.com  Thu Sep  2 01:11:23 2021
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 1 Sep 2021 21:11:23 -0400
Subject: JShell does not recognize "non-sealed" as a keyword at top level
In-Reply-To: <625284020.968439.1630446403486.JavaMail.zimbra@u-pem.fr>
References: <625284020.968439.1630446403486.JavaMail.zimbra@u-pem.fr>
Message-ID: <f1b9ea48-423a-d97e-5a4f-aef1e52f6448@oracle.com>

Hi Remi,

Thanks for the report, I have created [1] to track this issue,

Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8273257

On 8/31/21 5:46 PM, Remi Forax wrote:
> sealed interface Component permits Label, Button, Canvas {}
> record Label(String name) implements Component {}
> final class Button implements Component {}
> non-sealed class Canvas implements Component {}


From vromero at openjdk.java.net  Thu Sep  2 04:25:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 2 Sep 2021 04:25:44 GMT
Subject: RFR: 8273234: extended 'for' with expression of type tvar causes the
 compiler to crash
Message-ID: <l-vAOsh_cm9ioktB-Xmz58Bf99udBn9SuYoEnO6OXm4=.a3362c38-e3d3-4acb-be1f-e46d33852a8d@github.com>

Please review this one liner patch that is fixing a crash in the compiler. Method `Attr::visitForeachLoop` is doing a lookup for method `iterator` without making sure that the `site` where the method is being looked for is not a type variable.

TIA

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

Commit messages:
 - 8273234: extended 'for' with expression of type tvar causes the compiler to crash

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

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

From jlahoda at openjdk.java.net  Thu Sep  2 10:42:41 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 2 Sep 2021 10:42:41 GMT
Subject: RFR: 8273257: jshell doesn't compile a sealed hierarchy with a sealed
 interface and a non-sealed leaf
Message-ID: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>

Considering code like:

non-sealed class C implements Undefined {}


javac will currently produce these compile-time errors:

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

Commit messages:
 - 8273257: jshell doesnt compile a sealed hierarchy with a sealed interface and a non-sealed leaf

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

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

From jlahoda at openjdk.java.net  Thu Sep  2 11:01:44 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 2 Sep 2021 11:01:44 GMT
Subject: RFR: 8273263: Incorrect recovery attribution of record component type
 when j.l.Record is unavailable
Message-ID: <VpZk4m7-HZCHw-vzZtyse4CdMXUMoqofFct6dULQ8bk=.7052efd8-6754-4dcd-aecf-3f739c2cd29b@github.com>

This is a little obscure case where `j.l.Record` is not available, yet the source code contains a record, the AST model is slightly broken - the first record's component has an erroneous type. The reason is that `syms.recordType` is used directly, and when it is completed (for the first time), the `CompletionFailure` thrown will break the component's type. It would be better to report the error on the proper place at a proper place. This is already done for enums, where the supertype is attributed from an AST, which reports any errors at an appropriate place. The proposal in this patch is to also create a temporary AST for `j.l.Record` and attribute it, so that the errors are reported at an appropriate time and place.

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

Commit messages:
 - 8273263: Incorrect recovery attribution of record component type when j.l.Record is unavailable

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

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

From duke at openjdk.java.net  Thu Sep  2 12:03:35 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 2 Sep 2021 12:03:35 GMT
Subject: Withdrawn: 8268869: java in source-file mode suggests javac-only
 Xlint flags
In-Reply-To: <qjY5eulWucRl0uOLn3SUAN5kNfssM9FIzu3Dd9wudsE=.87757a9c-b29a-4797-8fcf-a6fa2260f7b9@github.com>
References: <qjY5eulWucRl0uOLn3SUAN5kNfssM9FIzu3Dd9wudsE=.87757a9c-b29a-4797-8fcf-a6fa2260f7b9@github.com>
Message-ID: <vnmmusyFY04vlIZQj0GS4tndUK_2IaHR84egpcLENSo=.5296dd6d-b402-427e-a70d-abc47e5055af@github.com>

On Mon, 28 Jun 2021 13:33:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope.
> 
> This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details."   by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations.
> 
> Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode.
> 
> Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094
> 
> The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose

This pull request has been closed without being integrated.

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

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

From vromero at openjdk.java.net  Thu Sep  2 15:23:07 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 2 Sep 2021 15:23:07 GMT
Subject: RFR: 8272776: NullPointerException not reported
In-Reply-To: <4Fld7kLSi-ib_IkmeS04RUU7RFt-Trb9oZ2If5D3FJc=.2a82a5e1-d68e-4062-ad41-94e3ee5e4a74@github.com>
References: <4Fld7kLSi-ib_IkmeS04RUU7RFt-Trb9oZ2If5D3FJc=.2a82a5e1-d68e-4062-ad41-94e3ee5e4a74@github.com>
Message-ID: <3w9HRKYyD2XN9lVKGKkVXQ6jXLTfa4wcdrO-9ZSMyeI=.1478f0b3-64e0-41c3-b8d0-0163b65b0396@github.com>

On Tue, 31 Aug 2021 07:25:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Code like:
> 
> public void foo(Object o) {
>         switch (o) {
>           default: break;
>           case String s :System.out.println(s); break;
>         } 
> }
> public static void main(String[] args) {
>         (new X()).foo(null); // NPE expected, but prints null
> }
> 
> 
> Should lead to a NPE when executed, because `default` does not cover `null` and there is no total pattern in the switch, but the NPE is not thrown. The reason is that when generating the code, a `hasTotalPattern` flag is used, which means "has a total pattern or default". The code needs to check whether there is a real total pattern (which covers `null`) or not. That is done by looking for the `default` case label, but the code only checks the last case for `default`. It needs to check all cases to differentiate between a switch with a real total pattern and a switch with a `default`.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Thu Sep  2 17:09:02 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 2 Sep 2021 17:09:02 GMT
Subject: RFR: 8273257: jshell doesn't compile a sealed hierarchy with a
 sealed interface and a non-sealed leaf
In-Reply-To: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>
References: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>
Message-ID: <mVudR2g1Ecou_rd4jI8LrRyPF2WX9yDIIcYkbSbsCSk=.0b39fdd4-8c77-4397-8967-863780f6469b@github.com>

On Thu, 2 Sep 2021 10:34:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> non-sealed class C implements Undefined {}
> 
> 
> javac will currently produce these compile-time errors:

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Thu Sep  2 17:53:15 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 2 Sep 2021 17:53:15 GMT
Subject: RFR: 8273263: Incorrect recovery attribution of record component
 type when j.l.Record is unavailable
In-Reply-To: <VpZk4m7-HZCHw-vzZtyse4CdMXUMoqofFct6dULQ8bk=.7052efd8-6754-4dcd-aecf-3f739c2cd29b@github.com>
References: <VpZk4m7-HZCHw-vzZtyse4CdMXUMoqofFct6dULQ8bk=.7052efd8-6754-4dcd-aecf-3f739c2cd29b@github.com>
Message-ID: <Twu9xpOKKE0HKVL7wS7gt0ljabb7hLB2IekryqhhoRQ=.1fef4c8b-74a5-4cb9-bfab-47edde8e5f59@github.com>

On Thu, 2 Sep 2021 10:54:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a little obscure case where `j.l.Record` is not available, yet the source code contains a record, the AST model is slightly broken - the first record's component has an erroneous type. The reason is that `syms.recordType` is used directly, and when it is completed (for the first time), the `CompletionFailure` thrown will break the component's type. It would be better to report the error on the proper place at a proper place. This is already done for enums, where the supertype is attributed from an AST, which reports any errors at an appropriate place. The proposal in this patch is to also create a temporary AST for `j.l.Record` and attribute it, so that the errors are reported at an appropriate time and place.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From serb at openjdk.java.net  Thu Sep  2 22:59:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Sep 2021 22:59:31 GMT
Subject: Integrated: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <tin2l2VOVGWktdXefgDZIBJz2kpyYBxoc4d9Tq2Qzdk=.f818542a-aba3-400c-9127-74516d3d0905@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

This pull request has now been integrated.

Changeset: 7fff22af
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7fff22afe711c8c04dbf4cf5b4938d40632e4987
Stats:     364 lines in 53 files changed: 98 ins; 128 del; 138 mod

8272805: Avoid looking up standard charsets

Reviewed-by: weijun, naoto, dfuchs, azvegint, erikj

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

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

From vromero at openjdk.java.net  Thu Sep  2 23:50:32 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 2 Sep 2021 23:50:32 GMT
Subject: RFR: 8266239: Some duplicated javac command-line options have
 repeated effect
In-Reply-To: <UJabUDvvY1kArtsHt37QwftXns9v2rtOFCIw4TCIxuE=.42a6643e-5385-42ed-b4f7-f91e8880a914@github.com>
References: <UJabUDvvY1kArtsHt37QwftXns9v2rtOFCIw4TCIxuE=.42a6643e-5385-42ed-b4f7-f91e8880a914@github.com>
Message-ID: <dkuFNOkRdPoP3ujIdWnXPlEFmYXQ55eobPBFY3UKfF0=.2269a714-086b-406c-968c-797c80c3dccb@github.com>

On Fri, 28 May 2021 12:29:45 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Some duplicated info options (`--version`, `--help`, `--help-extra`, `--help-lint`, `--full-version`) have repeated effect. Please see the following example.
> 
> 
> $ javac -version -version
> javac 17-internal
> javac 17-internal
> 
> 
> The patch fixes it and adds a corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From ilyas.selimov at jetbrains.com  Fri Sep  3 04:21:51 2021
From: ilyas.selimov at jetbrains.com (Ilyas Selimov)
Date: Fri, 3 Sep 2021 11:21:51 +0700
Subject: Javac false-positive in patterns for switch
Message-ID: <CANbUyJeh7Kd+5hTFtZtyncmqC91w7GxM_6sFbuef65bura+yWg@mail.gmail.com>

Hello!

The code like

public class Test {
    String foo(int i) {
        return switch(i) {
            case Integer v -> "" + v;
            case default -> "";
        };
    }
}

seems shouldn't provide a compilation error,
but Javac (build 35) says "bad operand type int for unary operator
'<*nullchk*>'".
Could somebody take a look?

Thanks,
Ilyas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210903/5c6ee3b7/attachment.htm>

From ilyas.selimov at jetbrains.com  Fri Sep  3 05:27:42 2021
From: ilyas.selimov at jetbrains.com (Ilyas Selimov)
Date: Fri, 3 Sep 2021 12:27:42 +0700
Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency
Message-ID: <CANbUyJcbcmmrjSuk1oFvp-A1LtMjriEfeYZJyJv2AhXqHZzE2Q@mail.gmail.com>

Hello!

The next code compiles correctly, but it seems to contradict the dominance
rules:

void test(Integer i) {
  switch (i) {
    case Integer in && in != null:
      break;
    case 1:
      break;
    case default:
      break;
  }
}

> A switch label that has a pattern case label element p dominates another
switch label that has a constant case label element c if either of the
following is true:
> - the type of c is a primitive type and its wrapper class (5.1.7) is a
subtype of the erasure of the type of p.

Maybe the type of p should also be total for the type of selector
expression like in the rules for pattern-over-null dominance?

Thanks,
Ilyas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210903/b90cd2f3/attachment.htm>

From jlahoda at openjdk.java.net  Fri Sep  3 06:13:27 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Sep 2021 06:13:27 GMT
Subject: RFR: 8273234: extended 'for' with expression of type tvar causes
 the compiler to crash
In-Reply-To: <l-vAOsh_cm9ioktB-Xmz58Bf99udBn9SuYoEnO6OXm4=.a3362c38-e3d3-4acb-be1f-e46d33852a8d@github.com>
References: <l-vAOsh_cm9ioktB-Xmz58Bf99udBn9SuYoEnO6OXm4=.a3362c38-e3d3-4acb-be1f-e46d33852a8d@github.com>
Message-ID: <Ml7-ZqWgAcXCYCZLTCLqR8YCiNjNbYJyB3mH9CfbQTs=.48fec368-f9c9-4e4e-91b4-c5f9382caf8f@github.com>

On Thu, 2 Sep 2021 04:18:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this one liner patch that is fixing a crash in the compiler. Method `Attr::visitForeachLoop` is doing a lookup for method `iterator` without making sure that the `site` where the method is being looked for is not a type variable.
> 
> TIA

Looks reasonable.

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

Marked as reviewed by jlahoda (Reviewer).

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

From forax at univ-mlv.fr  Fri Sep  3 07:29:54 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 3 Sep 2021 09:29:54 +0200 (CEST)
Subject: Dominance in pattern matching for switch: Spec and Javac
 inconsistency
In-Reply-To: <CANbUyJcbcmmrjSuk1oFvp-A1LtMjriEfeYZJyJv2AhXqHZzE2Q@mail.gmail.com>
References: <CANbUyJcbcmmrjSuk1oFvp-A1LtMjriEfeYZJyJv2AhXqHZzE2Q@mail.gmail.com>
Message-ID: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr>

> From: "Ilyas Selimov" <ilyas.selimov at jetbrains.com>
> To: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Vendredi 3 Septembre 2021 07:27:42
> Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency

> Hello!

> The next code compiles correctly, but it seems to contradict the dominance
> rules:

> void test(Integer i) {
> switch (i) {
> case Integer in && in != null:
> break;
> case 1:
> break;
> case default:
> break;
> }
> }

>> A switch label that has a pattern case label element p dominates another switch
>> label that has a constant case label element c if either of the following is
> > true:
>> - the type of c is a primitive type and its wrapper class (5.1.7) is a subtype
> > of the erasure of the type of p.

> Maybe the type of p should also be total for the type of selector expression
> like in the rules for pattern-over-null dominance?

For me, the problem comes from the guard, if you write the same code without the guard, the compiler correctly emits an error 
void test(Integer i) { 
switch (i) { 
case Integer in: 
break; 
case 1: 
break; 
case default: 
break; 
} 
} 

for me, this rule should apply even if p is a guard, the type of p when p is a guard is the type of the type part (the left part) of a guard. 

So it's more a bug in the implementation than a spec issue. 
But given that Eclipse has the same issue, the spec should be clarified. 

> Thanks,
> Ilyas

regards, 
R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210903/2b7a83fc/attachment-0001.htm>

From jesper at selskabet.org  Fri Sep  3 08:30:58 2021
From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=)
Date: Fri, 3 Sep 2021 10:30:58 +0200
Subject: Dominance in pattern matching for switch: Spec and Javac
 inconsistency
In-Reply-To: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr>
References: <CANbUyJcbcmmrjSuk1oFvp-A1LtMjriEfeYZJyJv2AhXqHZzE2Q@mail.gmail.com>
 <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr>
Message-ID: <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org>

Hi

If I understand correctly, a guarded switch label effectively can't dominate any other labels, since the spec doesn't go into trying to statically analyse whether or not the guard could ever be false.
I guess the spec could mention that (but it would be a comment, since it follows from the other rules).

-Jesper


> On 3 Sep 2021, at 09.29, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 
> 
> From: "Ilyas Selimov" <ilyas.selimov at jetbrains.com>
> To: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Vendredi 3 Septembre 2021 07:27:42
> Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency
> Hello!
> 
> The next code compiles correctly, but it seems to contradict the dominance rules:
> 
> void test(Integer i) {
>   switch (i) {
>     case Integer in && in != null:
>       break;
>     case 1:
>       break;
>     case default:
>       break;  
>   }
> }
> 
> > A switch label that has a pattern case label element p dominates another switch label that has a constant case label element c if either of the following is true:
> > - the type of c is a primitive type and its wrapper class (5.1.7) is a subtype of the erasure of the type of p.
> 
> Maybe the type of p should also be total for the type of selector expression like in the rules for pattern-over-null dominance?
> 
> For me, the problem comes from the guard, if you write the same code without the guard, the compiler correctly emits an error
> void test(Integer i) {
>   switch (i) {
>     case Integer in:
>       break;
>     case 1:
>       break;
>     case default:
>       break;  
>   }
> }
> 
> for me, this rule should apply even if p is a guard, the type of p when p is a guard is the type of the type part (the left part) of a guard.
> 
> So it's more a bug in the implementation than a spec issue.
> But given that Eclipse has the same issue, the spec should be clarified.
> 
> 
> 
> Thanks,
> Ilyas
> 
> regards,
> R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210903/eed94518/attachment.htm>

From jlahoda at openjdk.java.net  Fri Sep  3 08:46:27 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Sep 2021 08:46:27 GMT
Subject: RFR: 8268148: unchecked warnings handle ? and ? extends Object
 differently
In-Reply-To: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
References: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
Message-ID: <H-bOlWhG-u27P68YhZ7Rm3ZsPKVtitOcGT1CJdZewso=.af5367a7-ff12-4676-a174-223ac0a35c07@github.com>

On Mon, 23 Aug 2021 16:17:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR. Currently javac handles differently `?` and `? extends Object` when reporting unchecked warnings when according to the spec they should be handled the same way. This PR is fixing this.
> 
> TIA

Overall, looks reasonable. A few questions/comments inline.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 882:

> 880:             // is it `?` or `? extends Object`?
> 881:             return kind == UNBOUND ||
> 882:                     (kind == EXTENDS && type.hasTag(CLASS) && ((ClassType)type).supertype_field == Type.noType);

For the test on whether `type` is j.l.Object, would something like this work better?
Suggestion:

                    (kind == EXTENDS && type.tsym.flatName() == type.tsym.name.table.names.java_lang_Object);


Just an idea. (Sadly, we can't use `Symtab` here, that would be ideal.)

test/langtools/tools/javac/warnings/UnboundAndBoundByObjectTest.java line 28:

> 26:  * @bug 8268148
> 27:  * @summary unchecked warnings handle ? and ? extends Object differently
> 28:  * @compile -Xlint:all UnboundAndBoundByObjectTest.java

Should there be a verification of the output? Possibly `-Werror`?

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

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

From shade at openjdk.java.net  Fri Sep  3 09:17:42 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Sep 2021 09:17:42 GMT
Subject: RFR: 8273314: Add tier4 test groups
Message-ID: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>

During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).

Sample run:


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
   jtreg:test/langtools:tier4                            0     0     0     0   
   jtreg:test/jaxp:tier4                                 0     0     0     0   
==============================

real	64m13.994s
user	1462m1.213s
sys	39m38.032s


There are interesting test failures on my machine, which I would address separately.

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

Commit messages:
 - Add tier4 test groups

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

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

From asotona at openjdk.java.net  Fri Sep  3 09:24:26 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Fri, 3 Sep 2021 09:24:26 GMT
Subject: RFR: 8268869: java in source-file mode suggests javac-only Xlint
 flags
In-Reply-To: <qjY5eulWucRl0uOLn3SUAN5kNfssM9FIzu3Dd9wudsE=.87757a9c-b29a-4797-8fcf-a6fa2260f7b9@github.com>
References: <qjY5eulWucRl0uOLn3SUAN5kNfssM9FIzu3Dd9wudsE=.87757a9c-b29a-4797-8fcf-a6fa2260f7b9@github.com>
Message-ID: <hQ5CbrBimCFfj9SJtqa1IVzGzMW1wksIphaYjqi1hMQ=.e18d66d3-b648-4aef-98da-6c3725da8bd6@github.com>

On Mon, 28 Jun 2021 13:33:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope.
> 
> This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details."   by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations.
> 
> Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode.
> 
> Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094
> 
> The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose

test/langtools/tools/javac/launcher/SourceLauncherTest.java already contains 29 other tests and none of them is using text blocks so overall test readibility does not change much by adding a test #30. 
>From the perspective of potential backporting of the fix and related test I still think it is contra-productive to use backward incompatible language feature in JDK tests. Clean backports (already approved patches applicable unchanged without conflict) are almost automated process, while any modifications to the backported patches trigger individual full review process for each target JDK branch/version.

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

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

From jlahoda at openjdk.java.net  Fri Sep  3 09:33:33 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Sep 2021 09:33:33 GMT
Subject: Integrated: 8273263: Incorrect recovery attribution of record
 component type when j.l.Record is unavailable
In-Reply-To: <VpZk4m7-HZCHw-vzZtyse4CdMXUMoqofFct6dULQ8bk=.7052efd8-6754-4dcd-aecf-3f739c2cd29b@github.com>
References: <VpZk4m7-HZCHw-vzZtyse4CdMXUMoqofFct6dULQ8bk=.7052efd8-6754-4dcd-aecf-3f739c2cd29b@github.com>
Message-ID: <uWEu4putneZgXgHZubuj9-gPss-SavGACiIbIvfAI98=.6cbfe76b-5e60-4e27-8836-39bbae432632@github.com>

On Thu, 2 Sep 2021 10:54:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a little obscure case where `j.l.Record` is not available, yet the source code contains a record, the AST model is slightly broken - the first record's component has an erroneous type. The reason is that `syms.recordType` is used directly, and when it is completed (for the first time), the `CompletionFailure` thrown will break the component's type. It would be better to report the error on the proper place at a proper place. This is already done for enums, where the supertype is attributed from an AST, which reports any errors at an appropriate place. The proposal in this patch is to also create a temporary AST for `j.l.Record` and attribute it, so that the errors are reported at an appropriate time and place.

This pull request has now been integrated.

Changeset: f17ee0c5
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f17ee0c5c796951801c2026a2acac895a5c0af73
Stats:     51 lines in 3 files changed: 49 ins; 0 del; 2 mod

8273263: Incorrect recovery attribution of record component type when j.l.Record is unavailable

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Fri Sep  3 09:34:32 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Sep 2021 09:34:32 GMT
Subject: Integrated: 8273257: jshell doesn't compile a sealed hierarchy with a
 sealed interface and a non-sealed leaf
In-Reply-To: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>
References: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>
Message-ID: <LTddO_fgwqrGeF0QQXU4iew1Eg3n0ajYazpcadhHNRc=.5fd1ea20-d191-476f-9303-289fbe5435d7@github.com>

On Thu, 2 Sep 2021 10:34:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> non-sealed class C implements Undefined {}
> 
> 
> javac will currently produce these compile-time errors:

This pull request has now been integrated.

Changeset: 7b023a3f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b023a3f607f44da1b13bc9d2884a5f13723d524
Stats:     45 lines in 3 files changed: 40 ins; 0 del; 5 mod

8273257: jshell doesn't compile a sealed hierarchy with a sealed interface and a non-sealed leaf

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Fri Sep  3 09:35:28 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Sep 2021 09:35:28 GMT
Subject: Integrated: 8272776: NullPointerException not reported
In-Reply-To: <4Fld7kLSi-ib_IkmeS04RUU7RFt-Trb9oZ2If5D3FJc=.2a82a5e1-d68e-4062-ad41-94e3ee5e4a74@github.com>
References: <4Fld7kLSi-ib_IkmeS04RUU7RFt-Trb9oZ2If5D3FJc=.2a82a5e1-d68e-4062-ad41-94e3ee5e4a74@github.com>
Message-ID: <oBvJA5gopoFJN-KQHspVXe87qdyjDXW7pnzLDjSNB-4=.97a7c421-d11d-4830-a713-ceda218f1f48@github.com>

On Tue, 31 Aug 2021 07:25:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Code like:
> 
> public void foo(Object o) {
>         switch (o) {
>           default: break;
>           case String s :System.out.println(s); break;
>         } 
> }
> public static void main(String[] args) {
>         (new X()).foo(null); // NPE expected, but prints null
> }
> 
> 
> Should lead to a NPE when executed, because `default` does not cover `null` and there is no total pattern in the switch, but the NPE is not thrown. The reason is that when generating the code, a `hasTotalPattern` flag is used, which means "has a total pattern or default". The code needs to check whether there is a real total pattern (which covers `null`) or not. That is done by looking for the `default` case label, but the code only checks the last case for `default`. It needs to check all cases to differentiate between a switch with a real total pattern and a switch with a `default`.

This pull request has now been integrated.

Changeset: 93eec9a1
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/93eec9a103de7f4d9a87eac5b295c9a50702ee94
Stats:     18 lines in 2 files changed: 14 ins; 1 del; 3 mod

8272776: NullPointerException not reported

Reviewed-by: vromero

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

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

From gli at openjdk.java.net  Fri Sep  3 09:36:30 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 3 Sep 2021 09:36:30 GMT
Subject: Integrated: 8266239: Some duplicated javac command-line options have
 repeated effect
In-Reply-To: <UJabUDvvY1kArtsHt37QwftXns9v2rtOFCIw4TCIxuE=.42a6643e-5385-42ed-b4f7-f91e8880a914@github.com>
References: <UJabUDvvY1kArtsHt37QwftXns9v2rtOFCIw4TCIxuE=.42a6643e-5385-42ed-b4f7-f91e8880a914@github.com>
Message-ID: <_zsSIXYnxXyCsfrHa2D93l9_da2jZ5ONhx8QnnLPBms=.fb922f3e-015d-438f-aa56-3b68484a699b@github.com>

On Fri, 28 May 2021 12:29:45 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Some duplicated info options (`--version`, `--help`, `--help-extra`, `--help-lint`, `--full-version`) have repeated effect. Please see the following example.
> 
> 
> $ javac -version -version
> javac 17-internal
> javac 17-internal
> 
> 
> The patch fixes it and adds a corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: d05494f9
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d05494f98bad351532cdb769c9da6b6e2359b16e
Stats:     41 lines in 3 files changed: 39 ins; 0 del; 2 mod

8266239: Some duplicated javac command-line options have repeated effect

Reviewed-by: vromero

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

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

From gli at openjdk.java.net  Fri Sep  3 09:36:30 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 3 Sep 2021 09:36:30 GMT
Subject: RFR: 8266239: Some duplicated javac command-line options have
 repeated effect
In-Reply-To: <dkuFNOkRdPoP3ujIdWnXPlEFmYXQ55eobPBFY3UKfF0=.2269a714-086b-406c-968c-797c80c3dccb@github.com>
References: <UJabUDvvY1kArtsHt37QwftXns9v2rtOFCIw4TCIxuE=.42a6643e-5385-42ed-b4f7-f91e8880a914@github.com>
 <dkuFNOkRdPoP3ujIdWnXPlEFmYXQ55eobPBFY3UKfF0=.2269a714-086b-406c-968c-797c80c3dccb@github.com>
Message-ID: <AxrsrPlKk2fkxqaenv55GIvr7g8UqS-67Nv-freADeY=.570e57c7-6f68-4b2d-a847-19e48f8c37b7@github.com>

On Thu, 2 Sep 2021 23:47:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hi all,
>> 
>> Some duplicated info options (`--version`, `--help`, `--help-extra`, `--help-lint`, `--full-version`) have repeated effect. Please see the following example.
>> 
>> 
>> $ javac -version -version
>> javac 17-internal
>> javac 17-internal
>> 
>> 
>> The patch fixes it and adds a corresponding test case.
>> Thank you for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> lgtm

@vicente-romero-oracle Thanks for your review.

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

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

From vromero at openjdk.java.net  Fri Sep  3 13:14:33 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 3 Sep 2021 13:14:33 GMT
Subject: RFR: 8273234: extended 'for' with expression of type tvar causes
 the compiler to crash
In-Reply-To: <l-vAOsh_cm9ioktB-Xmz58Bf99udBn9SuYoEnO6OXm4=.a3362c38-e3d3-4acb-be1f-e46d33852a8d@github.com>
References: <l-vAOsh_cm9ioktB-Xmz58Bf99udBn9SuYoEnO6OXm4=.a3362c38-e3d3-4acb-be1f-e46d33852a8d@github.com>
Message-ID: <6Q5XTewhMpeU0ySs550UMB2lMOBBNZzhEu0NorFkYsY=.ff4610b0-8641-4d1a-8ae4-80d8b13606a7@github.com>

On Thu, 2 Sep 2021 04:18:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this one liner patch that is fixing a crash in the compiler. Method `Attr::visitForeachLoop` is doing a lookup for method `iterator` without making sure that the `site` where the method is being looked for is not a type variable.
> 
> TIA

thanks for the review

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

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

From vromero at openjdk.java.net  Fri Sep  3 13:14:35 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 3 Sep 2021 13:14:35 GMT
Subject: Integrated: 8273234: extended 'for' with expression of type tvar
 causes the compiler to crash
In-Reply-To: <l-vAOsh_cm9ioktB-Xmz58Bf99udBn9SuYoEnO6OXm4=.a3362c38-e3d3-4acb-be1f-e46d33852a8d@github.com>
References: <l-vAOsh_cm9ioktB-Xmz58Bf99udBn9SuYoEnO6OXm4=.a3362c38-e3d3-4acb-be1f-e46d33852a8d@github.com>
Message-ID: <LMCnDzFdhJEqvaZfa938gtuzyqrqq5poZ73Bq4LjhOM=.e2e71c9d-4b05-4531-bb5c-29f607f49ddf@github.com>

On Thu, 2 Sep 2021 04:18:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this one liner patch that is fixing a crash in the compiler. Method `Attr::visitForeachLoop` is doing a lookup for method `iterator` without making sure that the `site` where the method is being looked for is not a type variable.
> 
> TIA

This pull request has now been integrated.

Changeset: 8c379092
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8c379092747301de70db1ef8e441cbe09fd742e7
Stats:     50 lines in 2 files changed: 49 ins; 0 del; 1 mod

8273234: extended 'for' with expression of type tvar causes the compiler to crash

Reviewed-by: jlahoda

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

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

From vromero at openjdk.java.net  Fri Sep  3 13:35:00 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 3 Sep 2021 13:35:00 GMT
Subject: RFR: 8268148: unchecked warnings handle ? and ? extends Object
 differently [v2]
In-Reply-To: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
References: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
Message-ID: <Rr9Ma5DoYd2ki4N_V9sPQHziWBxG04zCBj3-cSkRyCg=.82abc136-1ceb-4d21-988b-2c6266f29998@github.com>

> Please review this PR. Currently javac handles differently `?` and `? extends Object` when reporting unchecked warnings when according to the spec they should be handled the same way. This PR is fixing this.
> 
> 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.java.net/jdk/pull/5224/files
  - new: https://git.openjdk.java.net/jdk/pull/5224/files/cfbede77..511890b0

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

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

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

From jlahoda at openjdk.java.net  Fri Sep  3 14:13:28 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Sep 2021 14:13:28 GMT
Subject: RFR: 8268148: unchecked warnings handle ? and ? extends Object
 differently [v2]
In-Reply-To: <Rr9Ma5DoYd2ki4N_V9sPQHziWBxG04zCBj3-cSkRyCg=.82abc136-1ceb-4d21-988b-2c6266f29998@github.com>
References: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
 <Rr9Ma5DoYd2ki4N_V9sPQHziWBxG04zCBj3-cSkRyCg=.82abc136-1ceb-4d21-988b-2c6266f29998@github.com>
Message-ID: <dyDcTKo6SHzcoGNAG8BTq25ckJh2mVS56hqlRbTYgIo=.33c7557d-4bf1-4e41-9f15-8b1945c1af36@github.com>

On Fri, 3 Sep 2021 13:35:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR. Currently javac handles differently `?` and `? extends Object` when reporting unchecked warnings when according to the spec they should be handled the same way. This PR is fixing this.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

Looks good, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

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

From vromero at openjdk.java.net  Fri Sep  3 15:13:26 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 3 Sep 2021 15:13:26 GMT
Subject: RFR: 8268148: unchecked warnings handle ? and ? extends Object
 differently [v2]
In-Reply-To: <dyDcTKo6SHzcoGNAG8BTq25ckJh2mVS56hqlRbTYgIo=.33c7557d-4bf1-4e41-9f15-8b1945c1af36@github.com>
References: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
 <Rr9Ma5DoYd2ki4N_V9sPQHziWBxG04zCBj3-cSkRyCg=.82abc136-1ceb-4d21-988b-2c6266f29998@github.com>
 <dyDcTKo6SHzcoGNAG8BTq25ckJh2mVS56hqlRbTYgIo=.33c7557d-4bf1-4e41-9f15-8b1945c1af36@github.com>
Message-ID: <lH0W1pp1UXGtuzlLm3jGkQfs5MiJmK_DbkBj8-KTHAY=.1a4d8e46-acdb-4371-84c1-a744f2542ba9@github.com>

On Fri, 3 Sep 2021 14:10:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Looks good, thanks!

thanks for the review

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

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

From vromero at openjdk.java.net  Fri Sep  3 15:23:32 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 3 Sep 2021 15:23:32 GMT
Subject: Integrated: 8268148: unchecked warnings handle ? and ? extends Object
 differently
In-Reply-To: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
References: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
Message-ID: <w9FCRJ3ahUX3jZxdcKrYCEzwqbOwTUsSI5y5JLinGR0=.927fe50e-3d69-4014-a2a7-f65c11c93db0@github.com>

On Mon, 23 Aug 2021 16:17:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR. Currently javac handles differently `?` and `? extends Object` when reporting unchecked warnings when according to the spec they should be handled the same way. This PR is fixing this.
> 
> TIA

This pull request has now been integrated.

Changeset: ff4018bc
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff4018bc867841b566d619029fb637a128bc39a7
Stats:     46 lines in 3 files changed: 43 ins; 1 del; 2 mod

8268148: unchecked warnings handle ? and ? extends Object differently

Reviewed-by: jlahoda

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

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

From iignatyev at openjdk.java.net  Fri Sep  3 18:34:40 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 3 Sep 2021 18:34:40 GMT
Subject: RFR: 8273314: Add tier4 test groups
In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
Message-ID: <bZed3GdLHgEPxved-UASMNFMw3qAyQyLTgZjSwkNYAE=.1ad02c65-b425-4c07-8a77-9283f64264e0@github.com>

On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
> 
> Sample run:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>    jtreg:test/langtools:tier4                            0     0     0     0   
>    jtreg:test/jaxp:tier4                                 0     0     0     0   
> ==============================
> 
> real	64m13.994s
> user	1462m1.213s
> sys	39m38.032s
> 
> 
> There are interesting test failures on my machine, which I would address separately.

> <...> I have excluded `vmTestbase` and `hotspot:tier4`<...>  I have also excluded `applications` from `hotspot:tier4` <...> 

assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them.

-- Igor

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

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

From shade at openjdk.java.net  Fri Sep  3 18:43:28 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Sep 2021 18:43:28 GMT
Subject: RFR: 8273314: Add tier4 test groups
In-Reply-To: <bZed3GdLHgEPxved-UASMNFMw3qAyQyLTgZjSwkNYAE=.1ad02c65-b425-4c07-8a77-9283f64264e0@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <bZed3GdLHgEPxved-UASMNFMw3qAyQyLTgZjSwkNYAE=.1ad02c65-b425-4c07-8a77-9283f64264e0@github.com>
Message-ID: <VNY2cEZJyL6xFyn6eCYchntsYJp5xEkJrJ4efJxlHJE=.88b24266-d244-44d6-841f-27ab4a887444@github.com>

On Fri, 3 Sep 2021 18:32:21 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...>  I have also excluded `applications` from `hotspot:tier4` <...>
> 
> assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them.

Apart from practicality of using `tier4`, I think `vmTestbase` and `applications` are separate test suites in their own right. `tier4` is catching all the assorted Hotspot tests that are not part of larger suites. Makes sense?

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

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

From serb at openjdk.java.net  Sat Sep  4 02:54:46 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 4 Sep 2021 02:54:46 GMT
Subject: RFR: 8273314: Add tier4 test groups
In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
Message-ID: <4ZMjEBOeBv6RVtgEhcfQ1sMVUyL8t2v4W4sc3iGY3r0=.d88a0dbc-d8d0-497b-bde7-9d5de283d11f@github.com>

On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
> 
> Sample run:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>    jtreg:test/langtools:tier4                            0     0     0     0   
>    jtreg:test/jaxp:tier4                                 0     0     0     0   
> ==============================
> 
> real	64m13.994s
> user	1462m1.213s
> sys	39m38.032s
> 
> 
> There are interesting test failures on my machine, which I would address separately.

it looks like the results above do not include the headful tests did you filter them out?
>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<

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

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

From iignatyev at openjdk.java.net  Sat Sep  4 03:16:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 4 Sep 2021 03:16:52 GMT
Subject: RFR: 8273314: Add tier4 test groups
In-Reply-To: <VNY2cEZJyL6xFyn6eCYchntsYJp5xEkJrJ4efJxlHJE=.88b24266-d244-44d6-841f-27ab4a887444@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <bZed3GdLHgEPxved-UASMNFMw3qAyQyLTgZjSwkNYAE=.1ad02c65-b425-4c07-8a77-9283f64264e0@github.com>
 <VNY2cEZJyL6xFyn6eCYchntsYJp5xEkJrJ4efJxlHJE=.88b24266-d244-44d6-841f-27ab4a887444@github.com>
Message-ID: <q5xjWsdIKJmpNLN0cdE1GMf9wm2sN9-kzyT0KPTYK7U=.2f7f0a28-ac0f-41f7-99c0-989da960ad60@github.com>

On Fri, 3 Sep 2021 18:40:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...>  I have also excluded `applications` from `hotspot:tier4` <...>
> > 
> > 
> > assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them.
> 
> Apart from practicality of using `tier4`, I think `vmTestbase` and `applications` are separate test suites in their own right. `tier4` is catching all the assorted Hotspot tests that are not part of larger suites. Makes sense?

to some extent. I agree that `applications` tests can/should be seen as a separate test suite, yet I differ on `vmTestbase` as the end goal for `vmTestbase` tests is (and always was) to become just another test within hotspot jtreg test suite, hence I don't think we should treat them any different than other jtreg tests. there is also a plan (which I need to formalize and share w/ a broader audience) to rearrange `vmTestbase` tests so they will be placed within the corresponding component subdirectories, which would bring us closer to the end goal and at the same time make it slightly harder to select all `vmTestbase` tests.

-- Igor

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

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

From dholmes at openjdk.java.net  Sun Sep  5 23:29:50 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 5 Sep 2021 23:29:50 GMT
Subject: RFR: 8273314: Add tier4 test groups
In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
Message-ID: <o2XKf2L07itb6WTj_t0TbKJvr2msed9iAfMvPVvFq0M=.f70e0de9-a21d-4737-a314-24938b805bdf@github.com>

On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
> 
> Sample run:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>    jtreg:test/langtools:tier4                            0     0     0     0   
>    jtreg:test/jaxp:tier4                                 0     0     0     0   
> ==============================
> 
> real	64m13.994s
> user	1462m1.213s
> sys	39m38.032s
> 
> 
> There are interesting test failures on my machine, which I would address separately.

Hi Aleksey,

This seems rather arbitrary and subjective to me. The tier 1-3 groupings were driven by existing tier 1-3 notions. But here the definition of tier 4 as "all the rest except ..." is not really a well-defined meaning for tier 4. I don't see that it adds any value. Perhaps there is a need for a group that is "everything except tier 1, tier 2, tier 3, applications, ..." but I wouldn't call that tier 4.

Cheers,
David

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

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

From shade at openjdk.java.net  Mon Sep  6 13:18:06 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Sep 2021 13:18:06 GMT
Subject: RFR: 8273314: Add tier4 test groups [v2]
In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
Message-ID: <vPGyr-E1RLxIY9wkdOxsE2Zsl9Lb8M7wvKgrOibjxTI=.1f1d50af-8f95-4850-93ce-15ddf5e339c2@github.com>

> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
> 
> Sample run:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>    jtreg:test/langtools:tier4                            0     0     0     0   
>    jtreg:test/jaxp:tier4                                 0     0     0     0   
> ==============================
> 
> real	64m13.994s
> user	1462m1.213s
> sys	39m38.032s
> 
> 
> There are interesting test failures on my machine, which I would address separately.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Drop exceptions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5357/files
  - new: https://git.openjdk.java.net/jdk/pull/5357/files/a0753adf..afb77062

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

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

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

From shade at openjdk.java.net  Mon Sep  6 13:22:03 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Sep 2021 13:22:03 GMT
Subject: RFR: 8273314: Add tier4 test groups [v3]
In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
Message-ID: <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>

> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
> 
> Sample run:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>    jtreg:test/langtools:tier4                            0     0     0     0   
>    jtreg:test/jaxp:tier4                                 0     0     0     0   
> ==============================
> 
> real	64m13.994s
> user	1462m1.213s
> sys	39m38.032s
> 
> 
> There are interesting test failures on my machine, which I would address separately.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Drop applications and fix the comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5357/files
  - new: https://git.openjdk.java.net/jdk/pull/5357/files/afb77062..160c13c7

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

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

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

From shade at openjdk.java.net  Mon Sep  6 14:13:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Sep 2021 14:13:45 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1
Message-ID: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>

Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.

I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).

Additional testing:
 - [x] Affected test passes with default version string
 - [x] Affected test fails with JDK-8266239 reverted
 - [ ] Affected test passes with `--with-version-opt=javac`

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

Commit messages:
 - Check that lines start with the message to avoid collisions completely
 - Do not look for specification version in the version string

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

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

From shade at openjdk.java.net  Mon Sep  6 15:17:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Sep 2021 15:17:43 GMT
Subject: RFR: 8273314: Add tier4 test groups
In-Reply-To: <q5xjWsdIKJmpNLN0cdE1GMf9wm2sN9-kzyT0KPTYK7U=.2f7f0a28-ac0f-41f7-99c0-989da960ad60@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <bZed3GdLHgEPxved-UASMNFMw3qAyQyLTgZjSwkNYAE=.1ad02c65-b425-4c07-8a77-9283f64264e0@github.com>
 <VNY2cEZJyL6xFyn6eCYchntsYJp5xEkJrJ4efJxlHJE=.88b24266-d244-44d6-841f-27ab4a887444@github.com>
 <q5xjWsdIKJmpNLN0cdE1GMf9wm2sN9-kzyT0KPTYK7U=.2f7f0a28-ac0f-41f7-99c0-989da960ad60@github.com>
Message-ID: <LSHFji_ti9p-Uedp3Vsuu50eX3msuj7PQQqVZrYhQkY=.f5ed5ed7-e11e-491f-b190-e979a001d2e2@github.com>

On Sat, 4 Sep 2021 03:13:58 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>>> > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...>  I have also excluded `applications` from `hotspot:tier4` <...>
>>> 
>>> assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them.
>> 
>> Apart from practicality of using `tier4`, I think `vmTestbase` and `applications` are separate test suites in their own right. `tier4` is catching all the assorted Hotspot tests that are not part of larger suites. Makes sense?
>
>> > > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...>  I have also excluded `applications` from `hotspot:tier4` <...>
>> > 
>> > 
>> > assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them.
>> 
>> Apart from practicality of using `tier4`, I think `vmTestbase` and `applications` are separate test suites in their own right. `tier4` is catching all the assorted Hotspot tests that are not part of larger suites. Makes sense?
> 
> to some extent. I agree that `applications` tests can/should be seen as a separate test suite, yet I differ on `vmTestbase` as the end goal for `vmTestbase` tests is (and always was) to become just another test within hotspot jtreg test suite, hence I don't think we should treat them any different than other jtreg tests. there is also a plan (which I need to formalize and share w/ a broader audience) to rearrange `vmTestbase` tests so they will be placed within the corresponding component subdirectories, which would bring us closer to the end goal and at the same time make it slightly harder to select all `vmTestbase` tests.
> 
> -- Igor

@iignatev: OK, I reinstated `vmTestbase` and left `applications` out of `hotspot:tier4`.
@dholmes-ora: Generally speaking, all `tierX` definitions are rather arbitrary, as there seem to be nothing intrinsic about the tests to be in a particular tier. In other words, what `tierX` consists of is a matter of agreement. I'd say `hotspot:tier4` is "all assorted Hotspot tests that are not application-specific suites"
@mrserb: Yes, I ran this on a headless config, so headful tests were skipped, apparently. I'll try to arrange runs on my desktop.

Please see new commit. As `hotspot:tier4` is now much longer, it would take me a while to verify everything works there.

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

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

From serb at openjdk.java.net  Mon Sep  6 20:43:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 6 Sep 2021 20:43:36 GMT
Subject: RFR: 8273314: Add tier4 test groups
In-Reply-To: <4ZMjEBOeBv6RVtgEhcfQ1sMVUyL8t2v4W4sc3iGY3r0=.d88a0dbc-d8d0-497b-bde7-9d5de283d11f@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <4ZMjEBOeBv6RVtgEhcfQ1sMVUyL8t2v4W4sc3iGY3r0=.d88a0dbc-d8d0-497b-bde7-9d5de283d11f@github.com>
Message-ID: <LehNaXY5-C4Acc4qPMMYfMmJpxYciuzLsUP-Qd_UUYA=.beeafeda-2983-4fe5-98a2-bfdf6c6d2b73@github.com>

On Sat, 4 Sep 2021 02:51:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>> 
>> Sample run:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	64m13.994s
>> user	1462m1.213s
>> sys	39m38.032s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> it looks like the results above do not include the headful tests did you filter them out?
>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<

> @mrserb: Yes, I ran this on a headless config, so headful tests were skipped, apparently. I'll try to arrange runs on my desktop.

Then you probably need to skip "printer" tests as well. BTW it will be really good somehow to execute headless tests in tier4 concurrently, and run the headful tests in tier5 sequentially.

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

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

From david.holmes at oracle.com  Mon Sep  6 23:04:24 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 7 Sep 2021 09:04:24 +1000
Subject: RFR: 8273314: Add tier4 test groups
In-Reply-To: <LSHFji_ti9p-Uedp3Vsuu50eX3msuj7PQQqVZrYhQkY=.f5ed5ed7-e11e-491f-b190-e979a001d2e2@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <bZed3GdLHgEPxved-UASMNFMw3qAyQyLTgZjSwkNYAE=.1ad02c65-b425-4c07-8a77-9283f64264e0@github.com>
 <VNY2cEZJyL6xFyn6eCYchntsYJp5xEkJrJ4efJxlHJE=.88b24266-d244-44d6-841f-27ab4a887444@github.com>
 <q5xjWsdIKJmpNLN0cdE1GMf9wm2sN9-kzyT0KPTYK7U=.2f7f0a28-ac0f-41f7-99c0-989da960ad60@github.com>
 <LSHFji_ti9p-Uedp3Vsuu50eX3msuj7PQQqVZrYhQkY=.f5ed5ed7-e11e-491f-b190-e979a001d2e2@github.com>
Message-ID: <25b0cf03-689a-93d8-6fca-35a465a8e631@oracle.com>

On 7/09/2021 1:17 am, Aleksey Shipilev wrote:
> @dholmes-ora: Generally speaking, all `tierX` definitions are rather arbitrary, as there seem to be nothing intrinsic about the tests to be in a particular tier. In other words, what `tierX` consists of is a matter of agreement. I'd say `hotspot:tier4` is "all assorted Hotspot tests that are not application-specific suites"

The difference is that your previous work just consolidated the existing 
subsystem tier 1-3 definitions, but here you are choosing to define "all 
the rest" as tier 4. I don't think it is actually helpful/useful to 
anyone - and it bears no resemblance whatsoever to what we call "tier 
4", so that will just lead to unnecessary confusion IMO.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5357
> 

From github.com+53162078+shiyuexw at openjdk.java.net  Tue Sep  7 03:42:59 2021
From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang)
Date: Tue, 7 Sep 2021 03:42:59 GMT
Subject: RFR: 8273401: Remove JarIndex support in URLClassPath
Message-ID: <J8hKu07i7PEvdxHskl83-CabnJJuH5ibIEPSIBF-gew=.f23b21a1-29a6-4eed-8161-17cc1dd6c95f@github.com>

There is a bug for URLClassPath.findResources with JarIndex.
With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, 
and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. 

The PR includes:
1. remove the JarIndex support in URLClassPath
2. move JarIndex into  jdk.jartool module.

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

Commit messages:
 - 8273401: Remove JarIndex support in URLClassPath

Changes: https://git.openjdk.java.net/jdk/pull/5383/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5383&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273401
  Stats: 1117 lines in 21 files changed: 7 ins; 1098 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5383.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5383/head:pull/5383

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

From iignatyev at openjdk.java.net  Tue Sep  7 04:20:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 7 Sep 2021 04:20:38 GMT
Subject: RFR: 8273314: Add tier4 test groups [v3]
In-Reply-To: <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
Message-ID: <WryabTeVUcJpkD0k4cs9Y49TzYyUfCYSpKZ7bVQCRgA=.2615e5a9-e8ca-413f-a68c-b0981c87808e@github.com>

On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>> 
>> Sample run:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	64m13.994s
>> user	1462m1.213s
>> sys	39m38.032s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop applications and fix the comment

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> 
> On 7/09/2021 1:17 am, Aleksey Shipilev wrote:
> 
> > @dholmes-ora: Generally speaking, all `tierX` definitions are rather arbitrary, as there seem to be nothing intrinsic about the tests to be in a particular tier. In other words, what `tierX` consists of is a matter of agreement. I'd say `hotspot:tier4` is "all assorted Hotspot tests that are not application-specific suites"
> 
> The difference is that your previous work just consolidated the existing
> subsystem tier 1-3 definitions, but here you are choosing to define "all
> the rest" as tier 4. I don't think it is actually helpful/useful to
> anyone - and it bears no resemblance whatsoever to what we call "tier
> 4", so that will just lead to unnecessary confusion IMO.

@dholmes-ora , although I fully agree that this might lead to some misunderstanding b/w Oracle and non-Oracle folks, I don't see how it's different from the previous patch, which introduced `hotspot:tier2` and `hotspot:tier3`. even if we reduce `tierN` to just a set of tests, the test groups added by 8272914 bear as much resemblance to the test sets used in Oracle's tier2-3 as the suggested `hotspot:tier4` groups in this patch to the actual `tier4` definition used in Oracle's internal system, e.g. `hotspot:tier2` group has 0 tests from `test/hotspot/jtreg/compiler`, but Oracle's `tier2` does include a number of  `test/hotspot/jtreg/compiler` tests (which aren't part of `:tier1`). I believe that this patch actually moves us closer to a convergence point, as the union of `hotspot:tier1` -- `hotspot:tier4` test groups is very close to the test sets used in hotspot parts of Oracle's `tier1`  -- `tier4` definitions. 

Thanks,
-- Igor

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

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

From david.holmes at oracle.com  Tue Sep  7 05:05:39 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 7 Sep 2021 15:05:39 +1000
Subject: RFR: 8273314: Add tier4 test groups [v3]
In-Reply-To: <WryabTeVUcJpkD0k4cs9Y49TzYyUfCYSpKZ7bVQCRgA=.2615e5a9-e8ca-413f-a68c-b0981c87808e@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
 <WryabTeVUcJpkD0k4cs9Y49TzYyUfCYSpKZ7bVQCRgA=.2615e5a9-e8ca-413f-a68c-b0981c87808e@github.com>
Message-ID: <6000402c-061e-d786-3367-73a8bb934811@oracle.com>

On 7/09/2021 2:20 pm, Igor Ignatyev wrote:
> On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> 
>>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>>>
>>> Sample run:
>>>
>>>
>>> ==============================
>>> Test summary
>>> ==============================
>>>     TEST                                              TOTAL  PASS  FAIL ERROR
>>>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>>>     jtreg:test/langtools:tier4                            0     0     0     0
>>>     jtreg:test/jaxp:tier4                                 0     0     0     0
>>> ==============================
>>>
>>> real	64m13.994s
>>> user	1462m1.213s
>>> sys	39m38.032s
>>>
>>>
>>> There are interesting test failures on my machine, which I would address separately.
>>
>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Drop applications and fix the comment
> 
>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
>>
>> On 7/09/2021 1:17 am, Aleksey Shipilev wrote:
>>
>>> @dholmes-ora: Generally speaking, all `tierX` definitions are rather arbitrary, as there seem to be nothing intrinsic about the tests to be in a particular tier. In other words, what `tierX` consists of is a matter of agreement. I'd say `hotspot:tier4` is "all assorted Hotspot tests that are not application-specific suites"
>>
>> The difference is that your previous work just consolidated the existing
>> subsystem tier 1-3 definitions, but here you are choosing to define "all
>> the rest" as tier 4. I don't think it is actually helpful/useful to
>> anyone - and it bears no resemblance whatsoever to what we call "tier
>> 4", so that will just lead to unnecessary confusion IMO.
> 
> @dholmes-ora , although I fully agree that this might lead to some misunderstanding b/w Oracle and non-Oracle folks, I don't see how it's different from the previous patch, which introduced `hotspot:tier2` and `hotspot:tier3`. 

Because hotspot:tier2 and hotspot:tier3 simply grouped existing 
component definitions for tiers 2 and 3:

+tier2 = \
+  :hotspot_tier2_runtime \
+  :hotspot_tier2_runtime_platform_agnostic \
+  :hotspot_tier2_serviceability \
+  :tier2_gc_epsilon \
+  :tier2_gc_shenandoah
+
+tier3 = \
+  :hotspot_tier3_runtime \
+  :tier3_gc_shenandoah

but that is not the case for tier4.

> even if we reduce `tierN` to just a set of tests, the test groups added by 8272914 bear as much resemblance to the test sets used in Oracle's tier2-3 as the suggested `hotspot:tier4` groups in this patch to the actual `tier4` definition used in Oracle's internal system, e.g. `hotspot:tier2` group has 0 tests from `test/hotspot/jtreg/compiler`, but Oracle's `tier2` does include a number of  `test/hotspot/jtreg/compiler` tests (which aren't part of `:tier1`). I believe that this patch actually moves us closer to a convergence point, as the union of `hotspot:tier1` -- `hotspot:tier4` test groups is very close to the test sets used in hotspot parts of Oracle's `tier1`  -- `tier4` definitions.

We can discuss Oracle's tier definitions privately - I don't see any 
connection between those and this tier4 however.

Thanks,
David
-----

> Thanks,
> -- Igor
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5357
> 

From shade at openjdk.java.net  Tue Sep  7 08:14:37 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Sep 2021 08:14:37 GMT
Subject: RFR: 8273314: Add tier4 test groups [v3]
In-Reply-To: <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
Message-ID: <4izBbOzjSpoP4EwfJPEILXvLU0fCdI6xy4PTo3mYEtI=.5796ff23-e9f2-4cbe-8c8c-eb825633dd66@github.com>

On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>> 
>> Sample run:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	64m13.994s
>> user	1462m1.213s
>> sys	39m38.032s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop applications and fix the comment

Once again, the disconnect between Oracle and OpenJDK test definitions seems to be the problem for Oracle's side. Rectifying that disconnect might fall under the scope of this PR, but I have to point out that it is a courtesy of upstream open-source project to care about proprietary downstream definitions.

More to the point: since `tier4` as "catch-all-the-rest" was Igor's idea, I assumed that would be in agreement with Oracle's test definitions. Following this discussion, it seems I assumed wrong. So it puts me in a weird position to be between two Oracle engineers arguing about proprietary test definitions I cannot really know about, and have no decision power about. For all I care for OpenJDK, we might as well model `tier4` after what Oracle does, as to minimize confusion for Oracle engineers. But then again, I have no idea what Oracle means by `tier4`. So as the alternative, I can postpone this PR until you folks have a coherent view on this, or I can just give up on this PR and re-assign the RFE to Igor, assuming he is willing to work this out.

Tell me what you want me to do here.

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

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

From mcimadamore at openjdk.java.net  Tue Sep  7 10:26:36 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 7 Sep 2021 10:26:36 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces [v2]
In-Reply-To: <IWraNEjQ33oLeT-82yvCJh-u-5E5vypBQxUC2mkAIB4=.fc8ec1aa-499b-4d28-a618-89e12ec2a50f@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
 <IWraNEjQ33oLeT-82yvCJh-u-5E5vypBQxUC2mkAIB4=.fc8ec1aa-499b-4d28-a618-89e12ec2a50f@github.com>
Message-ID: <f54B89lw1xT7WZzLTr6E1aIC_02mmh7qiuORuO-hgjs=.bc1a1820-b842-449a-9504-d88be1baf0bb@github.com>

On Thu, 19 Aug 2021 12:56:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider these declarations:
>> 
>>     interface I {
>>         public String toString();
>>     }
>>     interface J extends I {}
>> 
>> 
>> There are two issues with the `toString` inherited from `I` into `J`:
>> -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
>> -as a slightly less problematic case, consider:
>> 
>> I i = null;
>> i.toString(); //AST and classfile contain call to I.toString()
>> J j = null;
>> j.toString(); //AST and classfile contain call to j.l.Object.toString()
>> 
>> 
>> I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing unnecessary method call.

The implementation logic seems to be moving in the right direction.It is true that interface do not inherit members for `Object` - but the JLS is set up in a strange way:


 If an interface has no direct superinterface types, then the interface implicitly declares a public abstract member method m with signature s, return type r, and throws clause t corresponding to each public instance method m with signature s, return type r, and throws clause t declared in Object (?4.3.2), unless an abstract method with the same signature, same return type, and a compatible throws clause is explicitly declared by the interface. 
 ```
 
 This seems to suggest that resolution should return `I.toString` even if `I` does NOT declare a `toString` method. That makes sense, after all, implementations of `I` will _always_ have some toString(). This is not what your fallback Object lookup in `findMethod` does.

I also suggest running benchmarks, as the effect of these changes would be to generate invokeinterface where we used to have invokevirtual. VM should be smart enough to figure that one out, but better check.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1858:

> 1856:         InterfaceLookupPhase iphase = InterfaceLookupPhase.ABSTRACT_OK;
> 1857:         boolean isInterface = site.tsym.isInterface();
> 1858:         for (TypeSymbol s : isInterface ? List.of(intype.tsym) : superclasses(intype)) {

I wonder if the code here is making it more difficult because we include the initial type into `superclasses`. Maybe it could be worth to have an initial round where we just look into the initial type - followed by an (optional) round where we look at superclasses, followed by a round where we look at superinterfaces, followed by a fallback (optional) round where we look at Object.

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

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

From darcy at openjdk.java.net  Tue Sep  7 23:22:10 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 7 Sep 2021 23:22:10 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v2]
In-Reply-To: <X1WoLyswl8wVFNy7eFdQoj6IGD3Lfd0wEa4iwzRdnbg=.6279753d-846f-4672-abb5-2810a4288119@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
 <X1WoLyswl8wVFNy7eFdQoj6IGD3Lfd0wEa4iwzRdnbg=.6279753d-846f-4672-abb5-2810a4288119@github.com>
Message-ID: <vWdh0L7FR9oo12C-jExFFD3RAab-NnYx_TYzCXyVELo=.b32ebb5c-fb42-4521-b442-57a2db56c954@github.com>

On Tue, 10 Aug 2021 20:06:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8224922
>  - 8224922: Access JavaFileObject from Element(s)

Keep-alive.

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

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

From dholmes at openjdk.java.net  Wed Sep  8 00:19:10 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 00:19:10 GMT
Subject: RFR: 8273314: Add tier4 test groups [v3]
In-Reply-To: <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
Message-ID: <kCloubvrVZu1sbhHQR3bgtAcI9SOU_A3_g6PPlHlxew=.f9f5135a-2f6e-4171-b1d4-f00e8ab83eef@github.com>

On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>> 
>> Sample run:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	64m13.994s
>> user	1462m1.213s
>> sys	39m38.032s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop applications and fix the comment

Hi Aleksey,

I've discussed this with Igor and while I don't agree with the rationale I won't "block it".

Cheers,
David

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

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

From cushon at google.com  Wed Sep  8 00:40:45 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 7 Sep 2021 17:40:45 -0700
Subject: String concatenation order of operations
Message-ID: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>

I noticed that the result of string concatenation is different for the
invokedynamic and inline strategies when the arguments have side effects.

With the inline strategy, each subexpression is evaluated and converted to
a string in order. With indy each subexpression is evaluated in order *but
not converted to a string*, and later each subexpression is converted to a
string in order.

Is one of these behaviours more correct than the other?

class T {
  static String test() {
    StringBuilder builder = new StringBuilder("foo");
    return "" + builder + builder.append("bar");
  }

  public static void main(String[] args) {
    System.err.println(test());
  }
}

$ javac -XDstringConcat=inline T.java ; java T
foofoobar

$ javac -XDstringConcat=indy T.java ; java T
foobarfoobar

I read some of the related discussion about the spec requirements for
string concatenation in [1], and also some of the discussion around
JEP-280, and didn't find a conclusive answer. There was a bug [2] about the
evaluation order of string concat subexpressions with indy, but that was
about converting the arguments to strings in the wrong order.

[1]
http://mail.openjdk.java.net/pipermail/compiler-dev/2015-March/009357.html
[2] https://bugs.openjdk.java.net/browse/JDK-8200118
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210907/3cff8ce2/attachment.htm>

From brian.goetz at oracle.com  Wed Sep  8 00:55:39 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 7 Sep 2021 20:55:39 -0400
Subject: String concatenation order of operations
In-Reply-To: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
Message-ID: <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>

(Ouch.? Don't code like this.)

JLS 15.18.1 says:

> If only one operand expression is of type String, then string 
> conversion (?5.1.11)
> is performed on the other operand to produce a string at run time.

JLS 15.7.1 says "left to right", and also says "the left hand operand 
appears to be fully evaluated before any part of the right hand operand 
is evaluated."

Together, these say to me that string conversion on the left hand 
operand (if needed) must be performed _before_ evaluating the right hand 
operand.? Otherwise, in:

 ??? notAString + aString

the left hand operand of the string concatenation is a string, which is 
the result of evaluating notAString and then string-converting it.? My 
read of 15.7.1 says that we should do that before evaluating any part of 
aString.

This suggests that the answer should be foofoobar, as the inline 
strategy does but not the indy strategy.




On 9/7/2021 8:40 PM, Liam Miller-Cushon wrote:
> I noticed that the result of string concatenation is different for the 
> invokedynamic and inline strategies when the arguments have side effects.
>
> With the inline strategy, each subexpression is evaluated and 
> converted to a string in order. With indy each subexpression is 
> evaluated in order *but not converted to a string*, and later each 
> subexpression is converted to a string in order.
>
> Is one of these?behaviours more correct than the other?
>
> class T {
> ? static String test() {
> ? ? StringBuilder builder = new StringBuilder("foo");
> ? ? return "" + builder?+ builder.append("bar");
> ? }
>
> ? public static void main(String[] args) {
> ? ? System.err.println(test());
> ? }
> }
>
> $ javac -XDstringConcat=inline T.java ; java T
> foofoobar
>
> $ javac -XDstringConcat=indy T.java ; java T
> foobarfoobar
>
> I read some of the related discussion about the spec requirements for 
> string concatenation in [1], and also some of the discussion around 
> JEP-280, and didn't find a conclusive answer. There was a bug [2] 
> about the evaluation order of string concat subexpressions with indy, 
> but that was about converting the arguments to strings in the wrong order.
>
> [1] 
> http://mail.openjdk.java.net/pipermail/compiler-dev/2015-March/009357.html 
> <http://mail.openjdk.java.net/pipermail/compiler-dev/2015-March/009357.html>
> [2] https://bugs.openjdk.java.net/browse/JDK-8200118 
> <https://bugs.openjdk.java.net/browse/JDK-8200118>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210907/bee0d0b2/attachment-0001.htm>

From jpai at openjdk.java.net  Wed Sep  8 02:28:07 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 8 Sep 2021 02:28:07 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1
In-Reply-To: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
Message-ID: <joKzH3jAsXSF2TT8LwE4RPI8ZIHaWni_o3P0IjwhB5U=.b1fb415f-a4fd-419d-94bd-bba28acd8cda@github.com>

On Mon, 6 Sep 2021 13:54:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.
> 
> I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).
> 
> Additional testing:
>  - [x] Affected test passes with default version string
>  - [x] Affected test fails with JDK-8266239 reverted
>  - [x] Affected test passes with `--with-version-opt=javac`

Marked as reviewed by jpai (Committer).

I'm not a Reviewer, nor an expert in this area, but this change looks OK to me.

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

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

From vromero at openjdk.java.net  Wed Sep  8 04:09:29 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 8 Sep 2021 04:09:29 GMT
Subject: RFR: 8269121: Type inference bug with method references
Message-ID: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>

Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.

TIA

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

Commit messages:
 - 8269121: Type inference bug with method references

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

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

From shade at openjdk.java.net  Wed Sep  8 08:16:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 08:16:10 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1
In-Reply-To: <joKzH3jAsXSF2TT8LwE4RPI8ZIHaWni_o3P0IjwhB5U=.b1fb415f-a4fd-419d-94bd-bba28acd8cda@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
 <joKzH3jAsXSF2TT8LwE4RPI8ZIHaWni_o3P0IjwhB5U=.b1fb415f-a4fd-419d-94bd-bba28acd8cda@github.com>
Message-ID: <TgxZzK7STsvNCk4mpZfeK6lfB91KTgfFTqAN3ZZgO5U=.8f83e597-a307-469e-bec4-337d657772bc@github.com>

On Wed, 8 Sep 2021 02:25:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.
>> 
>> I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).
>> 
>> Additional testing:
>>  - [x] Affected test passes with default version string
>>  - [x] Affected test fails with JDK-8266239 reverted
>>  - [x] Affected test passes with `--with-version-opt=javac`
>
> I'm not a Reviewer, nor an expert in this area, but this change looks OK to me.

Thanks for review, @jaikiran. Any formal Reviewer wants to chime in? Would be nice to get GHA all green again.

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

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

From ihse at openjdk.java.net  Wed Sep  8 09:12:04 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Sep 2021 09:12:04 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1
In-Reply-To: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
Message-ID: <Wc2BCukSj6EPUug869xPLsZG5-YBHsMqzeco8n_LGTA=.d439bd71-2b57-4bf5-963e-d7a42b02fba7@github.com>

On Mon, 6 Sep 2021 13:54:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.
> 
> I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).
> 
> Additional testing:
>  - [x] Affected test passes with default version string
>  - [x] Affected test fails with JDK-8266239 reverted
>  - [x] Affected test passes with `--with-version-opt=javac`

Marked as reviewed by ihse (Reviewer).

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

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

From jlahoda at openjdk.java.net  Wed Sep  8 09:25:11 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 8 Sep 2021 09:25:11 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1
In-Reply-To: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
Message-ID: <lbA_Sw4dE5XLfqAEGhnb0neN7jwci3XfDAtq7xxGaoQ=.0ac47a0a-857e-4b12-aa27-c6f711bd4080@github.com>

On Mon, 6 Sep 2021 13:54:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.
> 
> I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).
> 
> Additional testing:
>  - [x] Affected test passes with default version string
>  - [x] Affected test fails with JDK-8266239 reverted
>  - [x] Affected test passes with `--with-version-opt=javac`

It would seem better to me if the test didn't depend on hardcoded localized strings (e.g. by printing the content of e.g. `javac --help` and checking the result is the same for `javac --help --help`; or by reading the bundle and using it as a template; or by checking if there are any duplicate line if the output), but since the test didn't do it originally, I don't think it is a stopper.

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

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

From shade at openjdk.java.net  Wed Sep  8 09:41:37 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 09:41:37 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1 [v2]
In-Reply-To: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
Message-ID: <hHUtVpH_DKbxCt4-DnV0UAEfTadnsSwxY0AzcD12MoI=.30f04d27-51e1-4a2c-91ba-f688e5969291@github.com>

> Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.
> 
> I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).
> 
> Additional testing:
>  - [x] Affected test passes with default version string
>  - [x] Affected test fails with JDK-8266239 reverted
>  - [x] Affected test passes with `--with-version-opt=javac`

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - No need for Scanner import anymore
 - Do the duplicate checks instead of checking for particular strings

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5381/files
  - new: https://git.openjdk.java.net/jdk/pull/5381/files/a3558a44..557de023

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

  Stats: 32 lines in 2 files changed: 5 ins; 11 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5381.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5381/head:pull/5381

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

From shade at openjdk.java.net  Wed Sep  8 09:41:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 09:41:38 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1
In-Reply-To: <lbA_Sw4dE5XLfqAEGhnb0neN7jwci3XfDAtq7xxGaoQ=.0ac47a0a-857e-4b12-aa27-c6f711bd4080@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
 <lbA_Sw4dE5XLfqAEGhnb0neN7jwci3XfDAtq7xxGaoQ=.0ac47a0a-857e-4b12-aa27-c6f711bd4080@github.com>
Message-ID: <wuZq-dEK1B4YScKw14cKhRnYT0iE4oPF1C4Tw7E4Tgo=.2c1bac26-714b-4463-ae6e-a6605aa71ad6@github.com>

On Wed, 8 Sep 2021 09:20:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> by printing the content of e.g. `javac --help` and checking the result is the same for `javac --help --help`; 

Oh, I like that idea. See new commit.

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

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

From mcimadamore at openjdk.java.net  Wed Sep  8 09:43:07 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 8 Sep 2021 09:43:07 GMT
Subject: RFR: 8269121: Type inference bug with method references
In-Reply-To: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
Message-ID: <fkebBRf4LZNfgWegqcEW0Fk9RLg207SIAHhDpZJ8IpU=.cfd9217c-61b6-43d9-a3e7-9095f349d394@github.com>

On Wed, 8 Sep 2021 04:01:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
> 
> TIA

Overall, it seems like a good first step. Perhaps worth spending some more time to think if we can find other cases where the erasure of the lambda method type would be incompatible with the erasure of the target function descriptor, and see if we need to make the logic in `typeToMethodType` more general.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1091:

> 1089:     }
> 1090: 
> 1091:     private MethodType typeToMethodType(Type mt, MethodType interfaceMethodType) {

It is nice that we can put all the complexity in this method. I wonder if we could somehow make this more general - e.g. instead of detecting whether there is an intersection type - simply compare the erased signature of the function descriptor with the erased signature of the lambda method, and see if the two are compatible. I believe that, maybe, a resolution check might work (e.g. try to pass the erased parameter to the erased function descriptor and see if we get a resolution error or not). In `Lower` we do something similar - see `Lower::lookupMethod`.

Another option could be to always use the erased function descriptor type, and then add the required casts inside the lambda method implementation body (in most cases there would be no casts) - e.g. do not rely on the conversions handled by the lambda metafactory, but generate code that is more 1-1 with what the metafactory expects (and fix it up on the javac side). But doing this might change signature for some of the lambda bodies - which, if we take into account serializable lambdas, could be problematic.

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

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

From jlahoda at openjdk.java.net  Wed Sep  8 09:48:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 8 Sep 2021 09:48:04 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1 [v2]
In-Reply-To: <hHUtVpH_DKbxCt4-DnV0UAEfTadnsSwxY0AzcD12MoI=.30f04d27-51e1-4a2c-91ba-f688e5969291@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
 <hHUtVpH_DKbxCt4-DnV0UAEfTadnsSwxY0AzcD12MoI=.30f04d27-51e1-4a2c-91ba-f688e5969291@github.com>
Message-ID: <402Lz5RQDWXB5sryF8o6XPdhVtkVm4Wn0XvuJPFQjF0=.ee5b8195-0caa-410b-be48-fb55db57f143@github.com>

On Wed, 8 Sep 2021 09:41:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.
>> 
>> I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).
>> 
>> Additional testing:
>>  - [x] Affected test passes with default version string
>>  - [x] Affected test fails with JDK-8266239 reverted
>>  - [x] Affected test passes with `--with-version-opt=javac`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - No need for Scanner import anymore
>  - Do the duplicate checks instead of checking for particular strings

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From ihse at openjdk.java.net  Wed Sep  8 12:45:10 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Sep 2021 12:45:10 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1 [v2]
In-Reply-To: <hHUtVpH_DKbxCt4-DnV0UAEfTadnsSwxY0AzcD12MoI=.30f04d27-51e1-4a2c-91ba-f688e5969291@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
 <hHUtVpH_DKbxCt4-DnV0UAEfTadnsSwxY0AzcD12MoI=.30f04d27-51e1-4a2c-91ba-f688e5969291@github.com>
Message-ID: <Kh0oVa53kx_62dFQdYJI0OH9-JWPd9RmVAlAZCCVFsQ=.09e0ed38-762d-4515-b761-b9718da92824@github.com>

On Wed, 8 Sep 2021 09:41:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.
>> 
>> I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).
>> 
>> Additional testing:
>>  - [x] Affected test passes with default version string
>>  - [x] Affected test fails with JDK-8266239 reverted
>>  - [x] Affected test passes with `--with-version-opt=javac`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - No need for Scanner import anymore
>  - Do the duplicate checks instead of checking for particular strings

Marked as reviewed by ihse (Reviewer).

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

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

From vromero at openjdk.java.net  Wed Sep  8 15:38:10 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 8 Sep 2021 15:38:10 GMT
Subject: RFR: 8269121: Type inference bug with method references
In-Reply-To: <fkebBRf4LZNfgWegqcEW0Fk9RLg207SIAHhDpZJ8IpU=.cfd9217c-61b6-43d9-a3e7-9095f349d394@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
 <fkebBRf4LZNfgWegqcEW0Fk9RLg207SIAHhDpZJ8IpU=.cfd9217c-61b6-43d9-a3e7-9095f349d394@github.com>
Message-ID: <tgPRzrnDUqih7FE4iC_xqdcTPVAoR0BD4Bz8pf1LnC4=.ee6bcf58-83b7-4fb8-8c43-0c45bd5bf583@github.com>

On Wed, 8 Sep 2021 09:38:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
>> 
>> TIA
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1091:
> 
>> 1089:     }
>> 1090: 
>> 1091:     private MethodType typeToMethodType(Type mt, MethodType interfaceMethodType) {
> 
> It is nice that we can put all the complexity in this method. I wonder if we could somehow make this more general - e.g. instead of detecting whether there is an intersection type - simply compare the erased signature of the function descriptor with the erased signature of the lambda method, and see if the two are compatible. I believe that, maybe, a resolution check might work (e.g. try to pass the erased parameter to the erased function descriptor and see if we get a resolution error or not). In `Lower` we do something similar - see `Lower::lookupMethod`.
> 
> Another option could be to always use the erased function descriptor type, and then add the required casts inside the lambda method implementation body (in most cases there would be no casts) - e.g. do not rely on the conversions handled by the lambda metafactory, but generate code that is more 1-1 with what the metafactory expects (and fix it up on the javac side). But doing this might change signature for some of the lambda bodies - which, if we take into account serializable lambdas, could be problematic.

I think I prefer the second option, but I'm wondering if there are really cases when we need to insert any cast. It seem that at least at the place where we are making the changes all the needed casts in the lambda body has already being inserted. What do you think?

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

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

From shade at openjdk.java.net  Wed Sep  8 16:40:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 16:40:10 GMT
Subject: Integrated: 8273361: InfoOptsTest is failing in tier1
In-Reply-To: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
Message-ID: <cTcg81LDwbd6wkjXLJ8okU17XQRMqDCe1pPWr6Q5HzQ=.d59036aa-c10f-4aae-837d-f1cf776fa328@github.com>

On Mon, 6 Sep 2021 13:54:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.
> 
> I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).
> 
> Additional testing:
>  - [x] Affected test passes with default version string
>  - [x] Affected test fails with JDK-8266239 reverted
>  - [x] Affected test passes with `--with-version-opt=javac`

This pull request has now been integrated.

Changeset: 267c61a1
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/267c61a16a916e35762e8df5737ec74b06defae8
Stats:     25 lines in 2 files changed: 5 ins; 4 del; 16 mod

8273361: InfoOptsTest is failing in tier1

Reviewed-by: jpai, ihse, jlahoda

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

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

From shade at openjdk.java.net  Wed Sep  8 16:40:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 16:40:10 GMT
Subject: RFR: 8273361: InfoOptsTest is failing in tier1 [v2]
In-Reply-To: <hHUtVpH_DKbxCt4-DnV0UAEfTadnsSwxY0AzcD12MoI=.30f04d27-51e1-4a2c-91ba-f688e5969291@github.com>
References: <8rK5olU3VjCKyuI1w-zwsKkt1qUyaiGlO9qkgpNpIjM=.86178ede-cba7-496c-8f3f-440d2ff7bc61@github.com>
 <hHUtVpH_DKbxCt4-DnV0UAEfTadnsSwxY0AzcD12MoI=.30f04d27-51e1-4a2c-91ba-f688e5969291@github.com>
Message-ID: <VWGZ3CPXZm2Q70rl26MfMdrdwt0auh9jIa75c4dY_34=.8087a737-eced-4ff7-ac80-d14f7d4ba9d8@github.com>

On Wed, 8 Sep 2021 09:41:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current test checks that informational messages are not printed twice. The failing tests verifies that by checking `java.specification.version` is not present twice in the version string. Effectively, it searches for `18`. But a second `18` could get to version string from anywhere: the Git hash, the user name, etc. It is failing in current GHA due to Git hash containing `18`.
>> 
>> I believe the test should be more conservative: look for more unique strings, and check that the lines start with it. "javac" and "javac full version" seem unique enough. Checking that lines start with "javac" handles the case of accidental version strings that includes that string (think username that includes "javac" for some reason, who are we to judge...).
>> 
>> Additional testing:
>>  - [x] Affected test passes with default version string
>>  - [x] Affected test fails with JDK-8266239 reverted
>>  - [x] Affected test passes with `--with-version-opt=javac`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - No need for Scanner import anymore
>  - Do the duplicate checks instead of checking for particular strings

GHA checks are green, I am integrating.

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

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

From vromero at openjdk.java.net  Wed Sep  8 17:03:37 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 8 Sep 2021 17:03:37 GMT
Subject: RFR: 8269121: Type inference bug with method references [v2]
In-Reply-To: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
Message-ID: <bn9q0rVewl5ncEd2ByezpPTEk8DoKr0vmSSR511IM2M=.1df71f87-bddf-4706-91c2-0263cc263c27@github.com>

> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
> 
> 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.java.net/jdk/pull/5406/files
  - new: https://git.openjdk.java.net/jdk/pull/5406/files/a6c653c4..bd425138

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

  Stats: 31 lines in 1 file changed: 23 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5406.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5406/head:pull/5406

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

From vromero at openjdk.java.net  Wed Sep  8 20:14:01 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 8 Sep 2021 20:14:01 GMT
Subject: RFR: 8269121: Type inference bug with method references [v2]
In-Reply-To: <bn9q0rVewl5ncEd2ByezpPTEk8DoKr0vmSSR511IM2M=.1df71f87-bddf-4706-91c2-0263cc263c27@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
 <bn9q0rVewl5ncEd2ByezpPTEk8DoKr0vmSSR511IM2M=.1df71f87-bddf-4706-91c2-0263cc263c27@github.com>
Message-ID: <5AQXAR2uSQzuLSWdMgvfrCmiJmXaozJyhdgORoO219c=.ed52965b-2c2e-471c-b8e7-cfcf2902a6cf@github.com>

On Wed, 8 Sep 2021 17:03:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

I found another very related bug in my list: https://bugs.openjdk.java.net/browse/JDK-8259491 I will check if I can kill two with one

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

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

From cushon at google.com  Wed Sep  8 20:50:23 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 8 Sep 2021 13:50:23 -0700
Subject: String concatenation order of operations
In-Reply-To: <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
 <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
Message-ID: <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>

On Tue, Sep 7, 2021 at 5:55 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> (Ouch.  Don't code like this.)
>

(Agreed!)

For more context, we've been using the string concat strategy proposed in
the compiler-dev thread I linked to earlier, which is like inline but with
a presized stringbuilder. I'm finally trying to enable the indy strategy,
and I stumbled upon this difference. I haven't seen this in real world
code, but I also haven't looked very hard yet.

I expect this is going to be extremely rare and is also worth discouraging,
so I don't think this will stop us from using indy. Given that the indy
strategy shipped in 9 and this doesn't seem to have come up yet, maybe it
isn't worth worrying about that much.

It'd be nice to reconcile the implementation with the spec if possible,
though. I wonder what the performance hit would be from calling toString on
the arguments more eagerly to preserve the evaluation order.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210908/ccaba08c/attachment.htm>

From brian.goetz at oracle.com  Wed Sep  8 22:01:00 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 8 Sep 2021 18:01:00 -0400
Subject: [External] : Re: String concatenation order of operations
In-Reply-To: <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
 <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
 <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>
Message-ID: <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>



> It'd be nice to reconcile the implementation with the spec if 
> possible, though. I wonder what the performance hit would be from 
> calling toString on the arguments more eagerly to preserve the 
> evaluation order.

The nature of indy leads to the structure we ended up with.? The natural 
way to do this is to have the various arguments passed as real stack 
arguments, causing them to all be evaluated before being pushed through 
the MH nest (which is where the string conversion happens, using 
MethodHandle::filterArguments.)? We'd essentially have to write a new 
bootstrap (but leave the old one in place), and have the compiler 
generate bytecode to do the string conversion as the values are being 
pushed on the stack.? This requires a different bootstrap and a 
different calling convention.? So old bytecode will stay around, and the 
old bootstrap would have to be kept around ... pretty disruptive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210908/fa8955e8/attachment.htm>

From jlahoda at openjdk.java.net  Thu Sep  9 11:14:34 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 9 Sep 2021 11:14:34 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces [v3]
In-Reply-To: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
Message-ID: <SFZyyzA0of6ZvYi6I2hgrrwk4iVSx-wWWPQ07zJt-sM=.92ca546b-e064-4def-9f2d-10abca6f63b4@github.com>

> Consider these declarations:
> 
>     interface I {
>         public String toString();
>     }
>     interface J extends I {}
> 
> 
> There are two issues with the `toString` inherited from `I` into `J`:
> -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
> -as a slightly less problematic case, consider:
> 
> I i = null;
> i.toString(); //AST and classfile contain call to I.toString()
> J j = null;
> j.toString(); //AST and classfile contain call to j.l.Object.toString()
> 
> 
> I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.

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/5165/files
  - new: https://git.openjdk.java.net/jdk/pull/5165/files/9ea15dcc..16ed87f3

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

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

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

From jlahoda at openjdk.java.net  Thu Sep  9 11:34:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 9 Sep 2021 11:34:04 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces [v2]
In-Reply-To: <f54B89lw1xT7WZzLTr6E1aIC_02mmh7qiuORuO-hgjs=.bc1a1820-b842-449a-9504-d88be1baf0bb@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
 <IWraNEjQ33oLeT-82yvCJh-u-5E5vypBQxUC2mkAIB4=.fc8ec1aa-499b-4d28-a618-89e12ec2a50f@github.com>
 <f54B89lw1xT7WZzLTr6E1aIC_02mmh7qiuORuO-hgjs=.bc1a1820-b842-449a-9504-d88be1baf0bb@github.com>
Message-ID: <pUqivrSFy2Rhzxb1AZUCwyKQaO6Xno1VnNlzy6Sh_0c=.74b7a205-d13b-466c-8808-3f914c4ba0ca@github.com>

On Tue, 7 Sep 2021 10:23:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing unnecessary method call.
>
> The implementation logic seems to be moving in the right direction.It is true that interface do not inherit members for `Object` - but the JLS is set up in a strange way:
> 
> 
>  If an interface has no direct superinterface types, then the interface implicitly declares a public abstract member method m with signature s, return type r, and throws clause t corresponding to each public instance method m with signature s, return type r, and throws clause t declared in Object (?4.3.2), unless an abstract method with the same signature, same return type, and a compatible throws clause is explicitly declared by the interface. 
>  ```
>  
>  This seems to suggest that resolution should return `I.toString` even if `I` does NOT declare a `toString` method. That makes sense, after all, implementations of `I` will _always_ have some toString(). This is not what your fallback Object lookup in `findMethod` does.
> 
> I also suggest running benchmarks, as the effect of these changes would be to generate invokeinterface where we used to have invokevirtual. VM should be smart enough to figure that one out, but better check.

Thanks for the comment @mcimadamore!

In https://github.com/openjdk/jdk/pull/5165/commits/16ed87f33afd14d2d0513f11c83d8b14232c4aca, I changed the code to generate `invokeinterface` for methods from j.l.Object if invoked on an interface. I ran a JMH benchmark, and it does not seem to cause much issues for the sustained case:

Benchmark                        (p)   Mode  Cnt          Score          Error  Units
MyBenchmark.testNewDesugaring  param  thrpt   25  280021515.383 ? 11477634.990  ops/s
MyBenchmark.testOldDesugaring  param  thrpt   25  272013631.484 ?  9960654.146  ops/s

I also tried the benchmarks, but the results are more unclear there.

I tried to split the loop for the current type and the superclasses, but in the end it didn't look very nice, so I skipped that for now. I can push the code somewhere, if desired.

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

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

From prappo at openjdk.java.net  Thu Sep  9 13:40:20 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 9 Sep 2021 13:40:20 GMT
Subject: RFR: 8266666: Implementation for snippets [v22]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <8tVKbGDS6B0HQq0gCLv1v_1sfuS2E5to3h2OBhmPGrk=.727b6e80-3108-4a9a-b74a-e5abf46a8c67@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Clean up code
   
   Removes stale FIXMEs, TODOs and comments; downgrades FIXMEs to TODOs where possible; wraps overly long lines.
 - Merge branch 'master' into 8266666
 - Merge branch 'master' into 8266666
 - Refactor SnippetTaglet
   
   Improves code style; reformats.
 - Improve snippet attributes parsing
   
   DocCommentParser now recognizes end-of-input better. To test that in testBadTagSyntax, the ToolBox.writeJavaFiles approach was used instead that of ClassBuilder.write. This is because ClassBuilder muddled doc comments with extra formatting such as trailing newline. So from within `ClassBuilder.MethodBuilder.setComments(java.lang.String...)` one couldn't make an immediate end-of-input: there was always `\n` appended to the comment.
   
   Also reformatted testBadTagSyntax for ease of comparing input and expected error output.
 - Merge branch 'master' into 8266666
 - Be more specific when testing for syntax errors
   
   This commit (i) improves tests for bad syntax, (ii) re-formats testBadTagSyntax for ease of commenting out individual testcases, and (iii) removes commented out testcases that are unfeasible.
 - Merge branch 'master' into 8266666
 - Merge branch 'master' into 8266666
 - Clean up tag parsing
   
   Removes two methods from an older implementation where HTML and javadoc tag attributes were modelled by different DocTree subtypes. Moves the `tagAttrs` method to TagParser responsible for parsing `@snippet` because `:` attribute terminator is specific to `@snippet`. Makes parser stop on `:`. Removes chatty discussion comments from code as suggested by Jonathan Gibbons.
 - ... and 21 more: https://git.openjdk.java.net/jdk/compare/f6cc1732...a2173165

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

Changes: https://git.openjdk.java.net/jdk/pull/4795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=21
  Stats: 4932 lines in 44 files changed: 4906 ins; 4 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

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

From prappo at openjdk.java.net  Thu Sep  9 15:27:34 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 9 Sep 2021 15:27:34 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

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

  Remove trailing whitespace to satisfy jcheck

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/a2173165..3c654e6b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=21-22

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

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

From jlahoda at openjdk.java.net  Thu Sep  9 18:19:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 9 Sep 2021 18:19:04 GMT
Subject: RFR: 8268885: duplicate checkcast when destination type is not
 first type of intersection type
In-Reply-To: <C9xnnNuWix0tt7UnKyIz_27hXTEpiZm7-j6J8P2FH1k=.ccc07ece-afd3-4e21-bf30-21f0dae82ffd@github.com>
References: <C9xnnNuWix0tt7UnKyIz_27hXTEpiZm7-j6J8P2FH1k=.ccc07ece-afd3-4e21-bf30-21f0dae82ffd@github.com>
Message-ID: <tVrLiW40eWZAioD97-sWtqyO62t47DLkUNiHrzyKYIs=.94bab69a-2e9c-435b-b02e-191fce8ec175@github.com>

On Mon, 23 Aug 2021 23:29:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing the following bug: javac is generating duplicate checkcast for cases like:
> 
> 
> class IntersectionTypeTest {
>     interface I1 {}
>     interface I2 {}
>     static class C {}
>     void test() {
>         I2 i = (I1 & I2) new C();
>     }
> }
> 
> basically when an intersection type is used in a cast expression and the target is not the type in the intersection.
> 
> TIA
> 
> PS. I also ran the JCK tests for this patch, same results as without the patch

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From vromero at openjdk.java.net  Thu Sep  9 18:40:10 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 9 Sep 2021 18:40:10 GMT
Subject: RFR: 8268885: duplicate checkcast when destination type is not
 first type of intersection type
In-Reply-To: <tVrLiW40eWZAioD97-sWtqyO62t47DLkUNiHrzyKYIs=.94bab69a-2e9c-435b-b02e-191fce8ec175@github.com>
References: <C9xnnNuWix0tt7UnKyIz_27hXTEpiZm7-j6J8P2FH1k=.ccc07ece-afd3-4e21-bf30-21f0dae82ffd@github.com>
 <tVrLiW40eWZAioD97-sWtqyO62t47DLkUNiHrzyKYIs=.94bab69a-2e9c-435b-b02e-191fce8ec175@github.com>
Message-ID: <TTucI4HzvnCdJJ9R8eL7dDIE6oE3mtSMlCVWoAQaT7A=.ea10c066-949d-49b5-99ef-6c065f8228a8@github.com>

On Thu, 9 Sep 2021 18:16:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Please review this PR which is fixing the following bug: javac is generating duplicate checkcast for cases like:
>> 
>> 
>> class IntersectionTypeTest {
>>     interface I1 {}
>>     interface I2 {}
>>     static class C {}
>>     void test() {
>>         I2 i = (I1 & I2) new C();
>>     }
>> }
>> 
>> basically when an intersection type is used in a cast expression and the target is not the type in the intersection.
>> 
>> TIA
>> 
>> PS. I also ran the JCK tests for this patch, same results as without the patch
>
> Looks good to me.

@lahodaj thanks for the review

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

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

From vromero at openjdk.java.net  Thu Sep  9 18:40:10 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 9 Sep 2021 18:40:10 GMT
Subject: Integrated: 8268885: duplicate checkcast when destination type is not
 first type of intersection type
In-Reply-To: <C9xnnNuWix0tt7UnKyIz_27hXTEpiZm7-j6J8P2FH1k=.ccc07ece-afd3-4e21-bf30-21f0dae82ffd@github.com>
References: <C9xnnNuWix0tt7UnKyIz_27hXTEpiZm7-j6J8P2FH1k=.ccc07ece-afd3-4e21-bf30-21f0dae82ffd@github.com>
Message-ID: <TXlCwtqomaZSzMl6uF3oom3JO0Q7Vd9inGJbHRiVYao=.91c8acfd-6112-42a8-bb81-e0fa7d46e262@github.com>

On Mon, 23 Aug 2021 23:29:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing the following bug: javac is generating duplicate checkcast for cases like:
> 
> 
> class IntersectionTypeTest {
>     interface I1 {}
>     interface I2 {}
>     static class C {}
>     void test() {
>         I2 i = (I1 & I2) new C();
>     }
> }
> 
> basically when an intersection type is used in a cast expression and the target is not the type in the intersection.
> 
> TIA
> 
> PS. I also ran the JCK tests for this patch, same results as without the patch

This pull request has now been integrated.

Changeset: dd1209e4
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dd1209e4ae3c8e42d121329639ec4bd359d0a456
Stats:     37 lines in 2 files changed: 24 ins; 3 del; 10 mod

8268885: duplicate checkcast when destination type is not first type of intersection type

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.java.net  Fri Sep 10 15:09:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 10 Sep 2021 15:09:10 GMT
Subject: RFR: 8273584: TypeElement.getSuperclass crashes for a record
 TypeElement when j.l.Record is not available
Message-ID: <XRB2On6AlzrCGieZhAahEzI5TNTE3oNvyIqoIjuqV1s=.c75c861b-926e-40b8-bfe3-7744540c9a66@github.com>

After JDK-8273263, calling TypeElement.getSuperclass may fail on a record when j.l.Record is not available, because the method will try to synthesize the type based on treee, but the tree is not filled. The proposal is to fill in the tree.

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

Commit messages:
 - 8273584: TypeElement.getSuperclass crashes for a record TypeElement when j.l.Record is not available

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

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

From prappo at openjdk.java.net  Fri Sep 10 17:49:01 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 10 Sep 2021 17:49:01 GMT
Subject: RFR: 8273609: Fix trivial doc typos in the compiler area
Message-ID: <J1XCwyZF2uH5wB-Ptp9S-FokwsW_GnqWkz5mULJWOXE=.d207ac4d-a1d2-405a-885c-2976ba9c4dc7@github.com>

8273609: Fix trivial doc typos in the compiler area

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

Commit messages:
 - Initial commit

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

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

From rriggs at openjdk.java.net  Fri Sep 10 17:49:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 10 Sep 2021 17:49:02 GMT
Subject: RFR: 8273609: Fix trivial doc typos in the compiler area
In-Reply-To: <J1XCwyZF2uH5wB-Ptp9S-FokwsW_GnqWkz5mULJWOXE=.d207ac4d-a1d2-405a-885c-2976ba9c4dc7@github.com>
References: <J1XCwyZF2uH5wB-Ptp9S-FokwsW_GnqWkz5mULJWOXE=.d207ac4d-a1d2-405a-885c-2976ba9c4dc7@github.com>
Message-ID: <tSSst48kUk3sjaD6bzY3ZmVhNtkPk0V1p0xkEF08PP0=.5eca1519-5cc8-437d-856d-78a1d6a26819@github.com>

On Fri, 10 Sep 2021 17:39:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 8273609: Fix trivial doc typos in the compiler area

Marked as reviewed by rriggs (Reviewer).

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

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

From vromero at openjdk.java.net  Fri Sep 10 17:49:02 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 10 Sep 2021 17:49:02 GMT
Subject: RFR: 8273609: Fix trivial doc typos in the compiler area
In-Reply-To: <J1XCwyZF2uH5wB-Ptp9S-FokwsW_GnqWkz5mULJWOXE=.d207ac4d-a1d2-405a-885c-2976ba9c4dc7@github.com>
References: <J1XCwyZF2uH5wB-Ptp9S-FokwsW_GnqWkz5mULJWOXE=.d207ac4d-a1d2-405a-885c-2976ba9c4dc7@github.com>
Message-ID: <Qqvu1A38o4C4nWWZ8BiL4pdK7YxzFsDxZDYKU7X3Uk0=.2d13e399-4004-4f2e-8eb0-70756a63e3d9@github.com>

On Fri, 10 Sep 2021 17:39:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 8273609: Fix trivial doc typos in the compiler area

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From iris at openjdk.java.net  Fri Sep 10 18:35:48 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 10 Sep 2021 18:35:48 GMT
Subject: RFR: 8273609: Fix trivial doc typos in the compiler area
In-Reply-To: <J1XCwyZF2uH5wB-Ptp9S-FokwsW_GnqWkz5mULJWOXE=.d207ac4d-a1d2-405a-885c-2976ba9c4dc7@github.com>
References: <J1XCwyZF2uH5wB-Ptp9S-FokwsW_GnqWkz5mULJWOXE=.d207ac4d-a1d2-405a-885c-2976ba9c4dc7@github.com>
Message-ID: <AHyrwuKZBzwf69keB1eOfauVa3iGETuoEvNGnTAL4Qw=.59c05820-9e6f-4838-94e0-6f6287cc210f@github.com>

On Fri, 10 Sep 2021 17:39:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 8273609: Fix trivial doc typos in the compiler area

Marked as reviewed by iris (Reviewer).

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

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

From vromero at openjdk.java.net  Fri Sep 10 18:48:47 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 10 Sep 2021 18:48:47 GMT
Subject: RFR: 8273584: TypeElement.getSuperclass crashes for a record
 TypeElement when j.l.Record is not available
In-Reply-To: <XRB2On6AlzrCGieZhAahEzI5TNTE3oNvyIqoIjuqV1s=.c75c861b-926e-40b8-bfe3-7744540c9a66@github.com>
References: <XRB2On6AlzrCGieZhAahEzI5TNTE3oNvyIqoIjuqV1s=.c75c861b-926e-40b8-bfe3-7744540c9a66@github.com>
Message-ID: <cRr6XexQPmJ7xNlbx2RcDyYLUQY4UES_VNO0YXC6zP8=.8bbbb3f7-1501-4de9-8d8d-9473d8b0658a@github.com>

On Fri, 10 Sep 2021 15:00:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> After JDK-8273263, calling TypeElement.getSuperclass may fail on a record when j.l.Record is not available, because the method will try to synthesize the type based on treee, but the tree is not filled. The proposal is to fill in the tree.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From prappo at openjdk.java.net  Fri Sep 10 19:36:53 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 10 Sep 2021 19:36:53 GMT
Subject: Integrated: 8273609: Fix trivial doc typos in the compiler area
In-Reply-To: <J1XCwyZF2uH5wB-Ptp9S-FokwsW_GnqWkz5mULJWOXE=.d207ac4d-a1d2-405a-885c-2976ba9c4dc7@github.com>
References: <J1XCwyZF2uH5wB-Ptp9S-FokwsW_GnqWkz5mULJWOXE=.d207ac4d-a1d2-405a-885c-2976ba9c4dc7@github.com>
Message-ID: <k8AyfADBlP4ANQGuedH3dS8U07ycw8ZlX0EJYQ-EiLs=.b95240f5-95d9-4c5f-a3a2-49f53922cb31@github.com>

On Fri, 10 Sep 2021 17:39:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 8273609: Fix trivial doc typos in the compiler area

This pull request has now been integrated.

Changeset: f42b9279
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f42b92790a6977ff17869762cd90a58cddccb8be
Stats:     16 lines in 7 files changed: 0 ins; 0 del; 16 mod

8273609: Fix trivial doc typos in the compiler area

Reviewed-by: rriggs, vromero, iris

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

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

From jpai at openjdk.java.net  Mon Sep 13 05:44:22 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 13 Sep 2021 05:44:22 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time
Message-ID: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>

The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.

The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.

This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:

1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 

2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.

If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

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

Commit messages:
 - 8258117: jar tool sets the time stamp of module-info.class entries to the current time

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

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

From jlahoda at openjdk.java.net  Mon Sep 13 09:27:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 13 Sep 2021 09:27:10 GMT
Subject: Integrated: 8273584: TypeElement.getSuperclass crashes for a record
 TypeElement when j.l.Record is not available
In-Reply-To: <XRB2On6AlzrCGieZhAahEzI5TNTE3oNvyIqoIjuqV1s=.c75c861b-926e-40b8-bfe3-7744540c9a66@github.com>
References: <XRB2On6AlzrCGieZhAahEzI5TNTE3oNvyIqoIjuqV1s=.c75c861b-926e-40b8-bfe3-7744540c9a66@github.com>
Message-ID: <-Fogo8Ba8E8Lfnme60cX6Ai9jL3yJIr8vpEPwMWogRk=.ad5118ef-7f40-439f-bcd4-83e1cb91330e@github.com>

On Fri, 10 Sep 2021 15:00:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> After JDK-8273263, calling TypeElement.getSuperclass may fail on a record when j.l.Record is not available, because the method will try to synthesize the type based on treee, but the tree is not filled. The proposal is to fill in the tree.

This pull request has now been integrated.

Changeset: b0d04976
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b0d04976bd334f840cb91e3f6dfa2ea680948a39
Stats:     122 lines in 2 files changed: 120 ins; 0 del; 2 mod

8273584: TypeElement.getSuperclass crashes for a record TypeElement when j.l.Record is not available

Reviewed-by: vromero

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

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

From ggarrison5 at gmail.com  Mon Sep 13 12:59:05 2021
From: ggarrison5 at gmail.com (G G)
Date: Mon, 13 Sep 2021 07:59:05 -0500
Subject: Method Signature Ambiguity
Message-ID: <CAGx_305_A48_X70Wj2h5HQmdTrQKEkP27FHT0iWB3h17JkUOjw@mail.gmail.com>

Hello,

Sorry if this is the wrong place for this email, I'm fairly new to OpenJDK
projects. I was recently asked "What is a method signature in Java?" Having
recently worked with bytecode, I was confident that my JVMS (?4.7.9.1
<https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-4.html#jvms-4.7.9.1>)
based knowledge would be correct in this fashion:

> A *method signature* encodes type information about a (possibly generic)
> method declaration. It describes any type parameters of the method; the
> (possibly parameterized) types of any formal parameters; the (possibly
> parameterized) return type, if any; and the types of any exceptions
> declared in the method's throws clause.

However, after a quick Google search I was able to uncover that the JLS (?
<http://goog_6165633>8.4.2
<https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.4.2>)
gave a different definition:

> Two methods or constructors, M and N, have the *same signature* if they
> have the same name, the same type parameters (if any) (?8.4.4
> <https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.4.4>),
> and, after adapting the formal parameter types of N to the type
> parameters of M, the same formal parameter types.

While both are consistent with the implementation, I believe that the two
disagree on the question of "What is a method signature in Java?" After
asking a few other people, I found that I was told each definition a few
times, so I do believe that I am not entirely alone in this confusion.
My suggestion for this is to rename one or both of the names. The JLS
definition could be changed to "override method signature", as the
definition seems to be defined around that. The JVMS definition could steal
a page out of what Wikipedia currently calls it (not backed up by official
documentation as far as I know) and call it an "internal method signature".
I may be completely off base here, if so at the very least it will be a
learning experience for me and a few others.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210913/8d6aa396/attachment.htm>

From hannesw at openjdk.java.net  Mon Sep 13 14:42:02 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 13 Sep 2021 14:42:02 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
Message-ID: <FmyxLtwGUyc8_zOEdDEsXgr0tsDBUC5Wj_qF7M3veSA=.580b2f76-6597-4a5f-bcef-b02100d159a7@github.com>

On Thu, 9 Sep 2021 15:27:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove trailing whitespace to satisfy jcheck

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1193:

> 1191:             }
> 1192:         } else if (refMemName == null) {
> 1193:             // Must be a class reference since refClass is not null and refMemName is null.

One problem with the code duplication introduced with this method is that fixes in `seeTagToContent` are not picked up in this method. One instance where this might already have occurred is JDK-8259499, which affected the code below. I would propose to go through changes in `seeTagToContent` since the snippet branch was created and look for simple fixes to "port". 

As a long term solution, the best way to go may not be to unify these methods but rather extract common pieces of code that can be used by both methods. They are way too long and convoluted anyway. It may be a good idea to file a JBS issue for this.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java line 138:

> 136:         return treeFactory.newLinkPlainTree(ref, List.of(makeTextTree(label)));
> 137:     }
> 138: 

It looks like these two new methods aren't used anywhere (according to IntelliJ).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 297:

> 295:             // corresponding positions in snippet source.
> 296:             final String value = regex.get().value();
> 297:             assert value.equals(Pattern.compile(value).pattern()) : value;

What is the purpose of this assertion, and when would it ever fail?

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

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

From hannesw at openjdk.java.net  Mon Sep 13 14:42:00 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 13 Sep 2021 14:42:00 GMT
Subject: RFR: 8266666: Implementation for snippets [v22]
In-Reply-To: <8tVKbGDS6B0HQq0gCLv1v_1sfuS2E5to3h2OBhmPGrk=.727b6e80-3108-4a9a-b74a-e5abf46a8c67@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <8tVKbGDS6B0HQq0gCLv1v_1sfuS2E5to3h2OBhmPGrk=.727b6e80-3108-4a9a-b74a-e5abf46a8c67@github.com>
Message-ID: <70cb3nRg_74M7wADkeoza4JpCQdNO6snb7zAhAfaVJ4=.d5a1d98b-953d-4f27-b8ab-20eb2b324723@github.com>

On Thu, 9 Sep 2021 13:40:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Clean up code
>    
>    Removes stale FIXMEs, TODOs and comments; downgrades FIXMEs to TODOs where possible; wraps overly long lines.
>  - Merge branch 'master' into 8266666
>  - Merge branch 'master' into 8266666
>  - Refactor SnippetTaglet
>    
>    Improves code style; reformats.
>  - Improve snippet attributes parsing
>    
>    DocCommentParser now recognizes end-of-input better. To test that in testBadTagSyntax, the ToolBox.writeJavaFiles approach was used instead that of ClassBuilder.write. This is because ClassBuilder muddled doc comments with extra formatting such as trailing newline. So from within `ClassBuilder.MethodBuilder.setComments(java.lang.String...)` one couldn't make an immediate end-of-input: there was always `\n` appended to the comment.
>    
>    Also reformatted testBadTagSyntax for ease of comparing input and expected error output.
>  - Merge branch 'master' into 8266666
>  - Be more specific when testing for syntax errors
>    
>    This commit (i) improves tests for bad syntax, (ii) re-formats testBadTagSyntax for ease of commenting out individual testcases, and (iii) removes commented out testcases that are unfeasible.
>  - Merge branch 'master' into 8266666
>  - Merge branch 'master' into 8266666
>  - Clean up tag parsing
>    
>    Removes two methods from an older implementation where HTML and javadoc tag attributes were modelled by different DocTree subtypes. Moves the `tagAttrs` method to TagParser responsible for parsing `@snippet` because `:` attribute terminator is specific to `@snippet`. Makes parser stop on `:`. Removes chatty discussion comments from code as suggested by Jonathan Gibbons.
>  - ... and 21 more: https://git.openjdk.java.net/jdk/compare/f6cc1732...a2173165

I went through the changes again, they mostly look good. There are a few areas (mostly handling of tags and styled text) where I still want to do more exploring in order to better understand the code.

I left inline comments for minor issues/questions I encountered.

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

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

From gli at openjdk.java.net  Mon Sep 13 15:36:10 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 13 Sep 2021 15:36:10 GMT
Subject: RFR: 8271254: javac generates unreachable code when using empty
 semicolon statement
Message-ID: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>

Hi all,

The method `Gen#genTry` is used by `visitTry` and `visitSynchronized`, but `genTry` can't identify who is invoking it so that it can't solve the concrete issues about try statement or synchronized statement separately. This patch adds a new parameter `actualTry` to identify the concrete situation( try or synchronized) and fixes this issue about using empty skip statement in the try statement body. And some related test cases are added.

Thanks for taking the time to review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - Revise copyright
 - Fix test.
 - 8271254: javac generates unreachable code when using empty semicolon statement

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

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

From jjg at openjdk.java.net  Mon Sep 13 15:41:55 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 13 Sep 2021 15:41:55 GMT
Subject: RFR: 8259039: Passing different version to --release flag than
 javac version output warning
In-Reply-To: <z2rJBSptf2E3VUduC_2UCZvtduZOiNTeCsUu5W53x8c=.41ebb396-a5be-40cc-a149-e78ed0ff5d8e@github.com>
References: <z2rJBSptf2E3VUduC_2UCZvtduZOiNTeCsUu5W53x8c=.41ebb396-a5be-40cc-a149-e78ed0ff5d8e@github.com>
Message-ID: <1e9uNlaJloLCXALuIrlc9WCYLgySpoOsP8WKGs-emL4=.3d7aebec-1d8d-492f-9f04-fa9f9a7b590c@github.com>

On Mon, 9 Aug 2021 13:33:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like:
> 
> com.sun.nio.file.ExtendedOpenOption o;
> 
> 
> certain combination of command line options produce a proprietary warnings:
> 
> $ javac --release 11 T.java 
> T.java:2: warning: ExtendedOpenOption is internal proprietary API and may be removed in a future release
>     com.sun.nio.file.ExtendedOpenOption o;
>                     ^
> 1 warning
> 
> 
> But some do not:
> 
> $ javac -source 8 T.java 
> warning: [options] bootstrap class path not set in conjunction with -source 8
> 1 warning
> 
> 
> The reason is that the `ct.properties` files does not mark `com.sun.nio.file` as proprietary. The proposed fix has two parts:
> -adds `proprietary` to the `com.sun.nio.file` package in `ct.properties`
> -limits the `ct.properties` so that it is only used for `-source 8`. The `ct.properties` contains 3 types of information: it hides some packages, it marks some packages as "proprietary" (so that they produce the warning), and assigns packages to compact profiles. For `-source 9+`, most of these is not needed - packages are hidden using the module system, the only packages that need a warning are from the `jdk.unsupported` module, and there are no compact profiles. So for `-source 9+`, we don't need to use the `ct.properties`. (Note none of this applies to `--release` - it uses a different database.)

Nice work

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

Marked as reviewed by jjg (Reviewer).

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

From vromero at openjdk.java.net  Mon Sep 13 17:21:53 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 13 Sep 2021 17:21:53 GMT
Subject: RFR: 8271254: javac generates unreachable code when using empty
 semicolon statement
In-Reply-To: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>
References: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>
Message-ID: <9pm1S-9iOsfit_ZIt2-KFAdtaHlODRcD1i5N9G26_Ho=.0e259594-8c3d-4b4f-94d3-a429d78b034a@github.com>

On Mon, 13 Sep 2021 15:26:38 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `Gen#genTry` is used by `visitTry` and `visitSynchronized`, but `genTry` can't identify who is invoking it so that it can't solve the concrete issues about try statement or synchronized statement separately. This patch adds a new parameter `actualTry` to identify the concrete situation( try or synchronized) and fixes this issue about using empty skip statement in the try statement body. And some related test cases are added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Changes requested by vromero (Reviewer).

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

> 1515:          *  @param actualTry Identify try or synchronized statement, true for try and false for synchronized.
> 1516:          */
> 1517:         void genTry(JCTree body, List<JCCatch> catchers, Env<GenContext> env, boolean actualTry) {

I don't think you really need an additional argument, I think that you can check for the tree at the `env` argument and you should be able to find out if this method is being invoked from a `try` or not. Kind of:

boolean actualTry = env.tree.hasTag(TRY);

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

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

From jjg at openjdk.java.net  Mon Sep 13 18:42:05 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 13 Sep 2021 18:42:05 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <vA4noMbc5zZJjJ2SN4xhIkI-Tm6spdigQ9Pj1YU9uOk=.109c065f-f425-43c3-8ccb-a26db97d4c30@github.com>

On Fri, 20 Aug 2021 18:12:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 178:
> 
>> 176:         }
>> 177: 
>> 178:         // FIXME cache parsed external snippet (WeakHashMap)
> 
> FIXME

Still a FIXME

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

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

From jjg at openjdk.java.net  Mon Sep 13 18:42:04 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 13 Sep 2021 18:42:04 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
Message-ID: <u4v9ehaWSx33znWQ5ngeelYnrf4BRJDan0-YaewMg9Q=.f12b1e56-bbf3-4773-8dba-d8426e4f85dc@github.com>

On Thu, 9 Sep 2021 15:27:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove trailing whitespace to satisfy jcheck

The primary actionable item is that all strings that are intended for use in end-user error messages need to be localizable.  i.e. see `Parser.ParseException`

Other comments are minor and can be deferred.

src/jdk.compiler/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java line 460:

> 458:      * @return  the result of {@code defaultAction}
> 459:      * @since 18
> 460:      */

optional: reformat the latter part of the comment to align param descriptions ... i.e. use IntelliJ IDEA reformat code

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

> 1075:         return ch == ' ' || ch == '\t' /* || ch == '\f'*/;
> 1076:     }
> 1077: 

It would be good to resolve this issue sooner rather than later, but not right now.
I suggest we file a JBS issue to make a determination and update the doc comment world accordingly. Yes, it will be a minor change for DocCommentParser. The JBS issue will provide a good place to record the decision and its rationale.

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

> 1445:                         throw new ParseException("dc.no.content");
> 1446:                     } else {
> 1447:                         throw new ParseException("dc.unexpected.content");

Heads up, there may be a merge conflict with the upcoming work on `DCTree` diagnostic positions. `ParseException` will soon take an optional "pos" parameter to better specify the position at which the error was detected.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 404:

> 402:                         e = getLinkedElement(element, t);
> 403:                         if (e == null) {
> 404:                             // diagnostic output

Use TODO?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 444:

> 442:      * the provided signature; returns null if such element could not be found.
> 443:      *
> 444:      * This method is to be used when it's the target of the link that is

very minor ... this would read better without the contraction (replace "it's" with "it is")

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 455:

> 453:         var fabricatedPath = new DocTreePath(rootPath, reference);
> 454:         return utils.docTrees.getElement(fabricatedPath);
> 455:     }

This feels like a plausible addition to the `DocTrees`API, where it ought to be possible to do it without creating the `ReferenceTree` and `DoctreePath` wrapper objects.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 200:

> 198:             var path = writer.configuration().utils.getCommentHelper(holder)
> 199:                 .getDocTreePath(snippetTag.getBody());
> 200:             // FIXME: there should be a method in Messages; that method should mirror Reporter's; use that method instead accessing Reporter.

downgrade to TODO?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 270:

> 268:      * diff view, but for now simply outputting both sides of a hybrid snippet
> 269:      * would do. A user could then use a diff tool of their choice to compare
> 270:      * those sides.

For discussion ... a partial solution that may be good enough is to identify the position (e.g. line+offset) of the first character that is different.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java line 87:

> 85:         if (!Character.isUnicodeIdentifierStart(ch)) {
> 86:             // TODO: internationalize!
> 87:             throw new ParseException("Bad character: '%s' (0x%s)".formatted(ch, Integer.toString(ch, 16)), bp);

Heads up: this should be updated when `ParseException` takes a position.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/ParseException.java line 50:

> 48:      * @param position the approximate position
> 49:      */
> 50:     public ParseException(String message, int position) {

I know it is common to use English-only strings in exceptions that are not intended to be seen in normal use by an end user, but here, you're using `ParseException` to contain content that is intended to appear in end-user error messages, triggered by errors in the content provided by an end-user.   As such, it is close to a firm requirement that these messages can be localized.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 85:

> 83:     // Incomplete actions waiting for their complementary @end
> 84:     private final Regions regions = new Regions();
> 85:     // List of tags; consumed from top to bottom

"top to bottom" is somewhere between ambiguous and confusing.  Is it file-centric or queue-as-stack -centric?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 217:

> 215:                 case "link" -> {
> 216:                     var target = attributes.get("target", Attribute.Valued.class)
> 217:                             .orElseThrow(() -> new ParseException("target is absent",

internationalize

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 234:

> 232:                 case "replace" -> {
> 233:                     var replacement = attributes.get("replacement", Attribute.Valued.class)
> 234:                             .orElseThrow(() -> new ParseException("replacement is absent",

internationalize

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 255:

> 253:                 case "start" -> {
> 254:                     var region = attributes.get("region", Attribute.Valued.class)
> 255:                             .orElseThrow(() -> new ParseException("Unnamed start",

internationalize

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

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

From jjg at openjdk.java.net  Mon Sep 13 19:02:59 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 13 Sep 2021 19:02:59 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <u4v9ehaWSx33znWQ5ngeelYnrf4BRJDan0-YaewMg9Q=.f12b1e56-bbf3-4773-8dba-d8426e4f85dc@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
 <u4v9ehaWSx33znWQ5ngeelYnrf4BRJDan0-YaewMg9Q=.f12b1e56-bbf3-4773-8dba-d8426e4f85dc@github.com>
Message-ID: <OjQ9qH1J4jq360Fqo0hdEu2k6yxsbxthCt6JiOK-fwA=.ceab6805-fffe-4568-bb5e-d629d0cf57a9@github.com>

On Mon, 13 Sep 2021 18:34:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove trailing whitespace to satisfy jcheck
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/ParseException.java line 50:
> 
>> 48:      * @param position the approximate position
>> 49:      */
>> 50:     public ParseException(String message, int position) {
> 
> I know it is common to use English-only strings in exceptions that are not intended to be seen in normal use by an end user, but here, you're using `ParseException` to contain content that is intended to appear in end-user error messages, triggered by errors in the content provided by an end-user.   As such, it is close to a firm requirement that these messages can be localized.

One possible solution at this time that would be minimally invasive would be to replace `new ParseException(String message, int pos)` with use of a method that localizes the string first, as in,

ParseException newParseException(int pos, String resourceKey, Object... args)

so the code becomes something like

   throw newParseException(pos, key, args);

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

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

From alex.buckley at oracle.com  Mon Sep 13 23:39:24 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 13 Sep 2021 16:39:24 -0700
Subject: Method Signature Ambiguity
In-Reply-To: <CAGx_305_A48_X70Wj2h5HQmdTrQKEkP27FHT0iWB3h17JkUOjw@mail.gmail.com>
References: <CAGx_305_A48_X70Wj2h5HQmdTrQKEkP27FHT0iWB3h17JkUOjw@mail.gmail.com>
Message-ID: <838220fa-2ffc-4f30-22fc-a587ecaec856@oracle.com>

A method signature in Java is as defined by JLS 8.4.2.

Since method signatures in Java are erased when creating method 
descriptors in a class file (JVMS 4.3.3), it is useful to record the 
unerased method signatures in the class file. This allows, for example, 
java.lang.reflect.Method::getGenericParameterTypes to expose an unerased 
method signature. The Signature attribute (JVMS 4.7.9.1) records the 
unerased method signatures, among other things.

Frankly the Signature attribute is rather obscure and you can mostly 
forget about it and its method signatures. The primary confusion I have 
seen over the years is between a method signature in Java (does not 
include return type) and a method descriptor in the class file (does 
include return type). When speaking about class files, many people say 
"method signature" when they mean "method descriptor", and it's then 
unclear whether they mean to care about the return type. This shows that 
the presence of clear terminology is no guarantee of its proper use.

Alex

On 9/13/2021 5:59 AM, G G wrote:
> Hello,
> 
> Sorry if this is the wrong place for this email, I'm fairly new to 
> OpenJDK projects. I was recently asked "What is a method signature in 
> Java?" Having recently worked with bytecode, I was confident that my 
> JVMS (?4.7.9.1 
> <https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-4.html#jvms-4.7.9.1>) 
> based knowledge would be correct in this fashion:
> 
>     A/method signature/encodes type information about a (possibly
>     generic) method declaration. It describes any type parameters of the
>     method; the (possibly parameterized) types of any formal parameters;
>     the (possibly parameterized) return type, if any; and the types of
>     any exceptions declared in the method's|throws|clause.
> 
> However, after a quick Google search I was able to uncover that the JLS 
> (? <http://goog_6165633>8.4.2 
> <https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.4.2>) 
> gave a different definition:
> 
>     Two methods or constructors,|M|and|N|, have the/same signature/if
>     they have the same name, the same type parameters (if any) (?8.4.4
>     <https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.4.4>),
>     and, after adapting the formal parameter types of|N|to the type
>     parameters of|M|, the same formal parameter types.
> 
> While both are consistent with the implementation, I believe that the 
> two disagree on the question of "What is a method signature in Java?" 
> After asking a few other people, I found that I was told each definition 
> a few times, so I do believe that I am not entirely alone in this confusion.
> My suggestion for this is to rename one or both of the names. The JLS 
> definition could be changed to "override method signature", as the 
> definition seems to be defined around that. The JVMS definition?could 
> steal a page out of what Wikipedia currently calls it (not backed up by 
> official documentation as far as I know) and call it an "internal method 
> signature".
> I may be completely off base here, if so at the very least it will be a 
> learning experience for me and a few others.
> 
> Thanks!

From jai.forums2013 at gmail.com  Tue Sep 14 01:36:13 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 14 Sep 2021 07:06:13 +0530
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time
In-Reply-To: <AM0PR03MB4145F66A3743E87D64AD8A09FFDA9@AM0PR03MB4145.eurprd03.prod.outlook.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <AM0PR03MB4145F66A3743E87D64AD8A09FFDA9@AM0PR03MB4145.eurprd03.prod.outlook.com>
Message-ID: <4097a3d1-9f0b-aabf-9908-131f2aa390a3@gmail.com>

Hello Bernd,

On 14/09/21 6:10 am, Bernd Eckenfels wrote:
> Is there support for repeatable builds planned? Using the source file might be acceptable, but the class file timestamp could be changing more likely for repeated builds?

To clarify the description of my PR, this change uses the timestamp of 
the (compiled) module-info.class file that is being added/updated to the 
jar.


-Jaikiran


From gli at openjdk.java.net  Tue Sep 14 05:36:34 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 14 Sep 2021 05:36:34 GMT
Subject: RFR: 8271254: javac generates unreachable code when using empty
 semicolon statement [v2]
In-Reply-To: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>
References: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>
Message-ID: <3vd7OCwObEMjrblKEUcODVsD0j2aXO_vcuZTcrwbATc=.e9e17327-51db-4d1d-9a0a-7e0e6d18e454@github.com>

> Hi all,
> 
> The method `Gen#genTry` is used by `visitTry` and `visitSynchronized`, but `genTry` can't identify who is invoking it so that it can't solve the concrete issues about try statement or synchronized statement separately. This patch adds a new parameter `actualTry` to identify the concrete situation( try or synchronized) and fixes this issue about using empty skip statement in the try statement body. And some related test cases are added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Remove the new parameter

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5495/files
  - new: https://git.openjdk.java.net/jdk/pull/5495/files/0f6f3cdd..f9c870c8

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

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

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

From gli at openjdk.java.net  Tue Sep 14 05:36:39 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 14 Sep 2021 05:36:39 GMT
Subject: RFR: 8271254: javac generates unreachable code when using empty
 semicolon statement [v2]
In-Reply-To: <9pm1S-9iOsfit_ZIt2-KFAdtaHlODRcD1i5N9G26_Ho=.0e259594-8c3d-4b4f-94d3-a429d78b034a@github.com>
References: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>
 <9pm1S-9iOsfit_ZIt2-KFAdtaHlODRcD1i5N9G26_Ho=.0e259594-8c3d-4b4f-94d3-a429d78b034a@github.com>
Message-ID: <u2cFUi5fie141MEkL-pzjByf32wqTvDh4KyVhMFtwBY=.d9cb9af1-7746-47fb-b929-babfb63ffb5c@github.com>

On Mon, 13 Sep 2021 17:18:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the new parameter
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1517:
> 
>> 1515:          *  @param actualTry Identify try or synchronized statement, true for try and false for synchronized.
>> 1516:          */
>> 1517:         void genTry(JCTree body, List<JCCatch> catchers, Env<GenContext> env, boolean actualTry) {
> 
> I don't think you really need an additional argument, I think that you can check for the tree at the `env` argument and you should be able to find out if this method is being invoked from a `try` or not. Kind of:
> 
> boolean actualTry = env.tree.hasTag(TRY);

@vicente-romero-oracle you are right. I updated the code just now by using the `env` instead of the new parameter.

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

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

From prappo at openjdk.java.net  Tue Sep 14 09:03:07 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 14 Sep 2021 09:03:07 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <FmyxLtwGUyc8_zOEdDEsXgr0tsDBUC5Wj_qF7M3veSA=.580b2f76-6597-4a5f-bcef-b02100d159a7@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
 <FmyxLtwGUyc8_zOEdDEsXgr0tsDBUC5Wj_qF7M3veSA=.580b2f76-6597-4a5f-bcef-b02100d159a7@github.com>
Message-ID: <20JsbeQwV-UfBzhhDSNfElj1NoBWm5HcEIbY2KLGF_8=.2575a0a6-d17d-4868-b1a6-219d8edcc33a@github.com>

On Mon, 13 Sep 2021 14:23:59 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove trailing whitespace to satisfy jcheck
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 297:
> 
>> 295:             // corresponding positions in snippet source.
>> 296:             final String value = regex.get().value();
>> 297:             assert value.equals(Pattern.compile(value).pattern()) : value;
> 
> What is the purpose of this assertion, and when would it ever fail?

I think that this assertion is misguided. The assertion I wanted to make should be a test, which I will provide shortly. Thanks for directing my attention to it.

The purpose of that assertion was to encode the following factual statement: the value of the regex attribute is WYSIWYG. That is, javadoc interprets that value as is: characters or sequences thereof are treated literally. Compare this with Java source or jshell, where escape sequences are recognized:


jshell> Pattern.compile("name\t=\t"value"")
$1 ==> name	=	"value"


Why is it important? Because of error messages. Knowing how a regex is represented in source allows javadoc to map the index passed in an instance of `java.util.regex.PatternSyntaxException` back to regex source so as to adjust the caret position in a diagnostic message should the regex be invalid.

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

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

From prappo at openjdk.java.net  Tue Sep 14 09:35:19 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 14 Sep 2021 09:35:19 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <u4v9ehaWSx33znWQ5ngeelYnrf4BRJDan0-YaewMg9Q=.f12b1e56-bbf3-4773-8dba-d8426e4f85dc@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
 <u4v9ehaWSx33znWQ5ngeelYnrf4BRJDan0-YaewMg9Q=.f12b1e56-bbf3-4773-8dba-d8426e4f85dc@github.com>
Message-ID: <Ev6bWiJK1HJPtO47REPIuf8r2UScG0fENAopd5mxXNk=.b0e944fc-0931-48c9-a746-47c73e05e327@github.com>

On Mon, 13 Sep 2021 17:32:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove trailing whitespace to satisfy jcheck
>
> src/jdk.compiler/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java line 460:
> 
>> 458:      * @return  the result of {@code defaultAction}
>> 459:      * @since 18
>> 460:      */
> 
> optional: reformat the latter part of the comment to align param descriptions ... i.e. use IntelliJ IDEA reformat code

Optional? Then I choose not to do it; thanks. In this PR, I tried hard to respect the ambient formatting for consistency.

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

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

From prappo at openjdk.java.net  Tue Sep 14 12:44:13 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 14 Sep 2021 12:44:13 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <FmyxLtwGUyc8_zOEdDEsXgr0tsDBUC5Wj_qF7M3veSA=.580b2f76-6597-4a5f-bcef-b02100d159a7@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
 <FmyxLtwGUyc8_zOEdDEsXgr0tsDBUC5Wj_qF7M3veSA=.580b2f76-6597-4a5f-bcef-b02100d159a7@github.com>
Message-ID: <CUWkg7l4ZhpIn-8liatgNUrGKZGkyDE-4L10zzPz1IY=.388802c0-0e93-4279-aab3-22cf64fc43a1@github.com>

On Mon, 13 Sep 2021 11:59:06 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove trailing whitespace to satisfy jcheck
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1193:
> 
>> 1191:             }
>> 1192:         } else if (refMemName == null) {
>> 1193:             // Must be a class reference since refClass is not null and refMemName is null.
> 
> One problem with the code duplication introduced with this method is that fixes in `seeTagToContent` are not picked up in this method. One instance where this might already have occurred is JDK-8259499, which affected the code below. I would propose to go through changes in `seeTagToContent` since the snippet branch was created and look for simple fixes to "port". 
> 
> As a long term solution, the best way to go may not be to unify these methods but rather extract common pieces of code that can be used by both methods. They are way too long and convoluted anyway. It may be a good idea to file a JBS issue for this.

The reason I extracted a separate method rather than reused the existing one is not because I disagree with what you are saying. It's because I couldn't find an easy way to reuse the existing method.

`seeTagToContent` uses the tree node corresponding to a link/see tag, for example, to construct a tree path. In snippet `@link` markup tag, there's no corresponding `LinkTree`. When I tried to quickly fabricate it, I found out that it cannot be easily done. For deep fabrication, one needs to embed a fake node into the tree structure at least for the duration of call to `seeTagToContent`. At that stage I decided not to explore that further.

I filed a bug as you suggested: https://bugs.openjdk.java.net/browse/JDK-8273721.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java line 138:
> 
>> 136:         return treeFactory.newLinkPlainTree(ref, List.of(makeTextTree(label)));
>> 137:     }
>> 138: 
> 
> It looks like these two new methods aren't used anywhere (according to IntelliJ).

These two methods are what has left of my failed attempt to fabricate a `LinkTree` node to process the `@link` snippet markup tag. I will remove them, thanks.

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

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

From vromero at openjdk.java.net  Tue Sep 14 13:38:14 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 14 Sep 2021 13:38:14 GMT
Subject: RFR: 8271254: javac generates unreachable code when using empty
 semicolon statement [v2]
In-Reply-To: <3vd7OCwObEMjrblKEUcODVsD0j2aXO_vcuZTcrwbATc=.e9e17327-51db-4d1d-9a0a-7e0e6d18e454@github.com>
References: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>
 <3vd7OCwObEMjrblKEUcODVsD0j2aXO_vcuZTcrwbATc=.e9e17327-51db-4d1d-9a0a-7e0e6d18e454@github.com>
Message-ID: <pVzOlz62y-KBMWtpUFIVV1gTRtu5IQrASH3TzMl6uKw=.17277f9e-7ff9-4b56-b5e6-e327154616c0@github.com>

On Tue, 14 Sep 2021 05:36:34 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> The method `Gen#genTry` is used by `visitTry` and `visitSynchronized`, but `genTry` can't identify who is invoking it so that it can't solve the concrete issues about try statement or synchronized statement separately. This patch adds a new parameter `actualTry` to identify the concrete situation( try or synchronized) and fixes this issue about using empty skip statement in the try statement body. And some related test cases are added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the new parameter

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From prappo at openjdk.java.net  Tue Sep 14 13:58:10 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 14 Sep 2021 13:58:10 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <Ev6bWiJK1HJPtO47REPIuf8r2UScG0fENAopd5mxXNk=.b0e944fc-0931-48c9-a746-47c73e05e327@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
 <u4v9ehaWSx33znWQ5ngeelYnrf4BRJDan0-YaewMg9Q=.f12b1e56-bbf3-4773-8dba-d8426e4f85dc@github.com>
 <Ev6bWiJK1HJPtO47REPIuf8r2UScG0fENAopd5mxXNk=.b0e944fc-0931-48c9-a746-47c73e05e327@github.com>
Message-ID: <MTMzZRvRWQMmK9K_1NkYjMJ4egcWE69NC_kvf9WsXKQ=.d1047b57-ba7f-431b-8ff7-c4765cdf595f@github.com>

On Tue, 14 Sep 2021 09:32:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java line 460:
>> 
>>> 458:      * @return  the result of {@code defaultAction}
>>> 459:      * @since 18
>>> 460:      */
>> 
>> optional: reformat the latter part of the comment to align param descriptions ... i.e. use IntelliJ IDEA reformat code
>
> Optional? Then I choose not to do it; thanks. In this PR, I tried hard to respect the ambient formatting for consistency.

I'm not sure that my IDE code style is configured the way you'd expect it to be. Please file a bug to reformat that and all similar methods in `SimpleDocTreeVisitor.java`. We might want to agree on and apply common doc comment style not only to this class but also to all classes in `com.sun.source.util` and maybe even `com.sun.source.**`.

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

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

From gli at openjdk.java.net  Tue Sep 14 14:47:07 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 14 Sep 2021 14:47:07 GMT
Subject: RFR: 8271254: javac generates unreachable code when using empty
 semicolon statement [v2]
In-Reply-To: <pVzOlz62y-KBMWtpUFIVV1gTRtu5IQrASH3TzMl6uKw=.17277f9e-7ff9-4b56-b5e6-e327154616c0@github.com>
References: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>
 <3vd7OCwObEMjrblKEUcODVsD0j2aXO_vcuZTcrwbATc=.e9e17327-51db-4d1d-9a0a-7e0e6d18e454@github.com>
 <pVzOlz62y-KBMWtpUFIVV1gTRtu5IQrASH3TzMl6uKw=.17277f9e-7ff9-4b56-b5e6-e327154616c0@github.com>
Message-ID: <gTNv1Lp8qxwPkivAxZMvTF0hEJk5of99mQttwvlOsMw=.b04f53ab-b186-42cb-b85a-36e95bcc1fa4@github.com>

On Tue, 14 Sep 2021 13:34:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the new parameter
>
> looks good

@vicente-romero-oracle Thanks for your review.

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

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

From gli at openjdk.java.net  Tue Sep 14 14:50:10 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 14 Sep 2021 14:50:10 GMT
Subject: Integrated: 8271254: javac generates unreachable code when using
 empty semicolon statement
In-Reply-To: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>
References: <A8Z3s42XEneNNAvSIuHCE07tSYU3rEjs5VxjTVjC1pw=.95b6fe26-42d6-4e44-97f8-49fe47995411@github.com>
Message-ID: <f7gY5Yymx7td4yHHrfvVqB3Fn6QNGDsggOuN4eR-Yy8=.f0a9e841-764a-4baf-9e11-dcab5db35422@github.com>

On Mon, 13 Sep 2021 15:26:38 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `Gen#genTry` is used by `visitTry` and `visitSynchronized`, but `genTry` can't identify who is invoking it so that it can't solve the concrete issues about try statement or synchronized statement separately. This patch adds a new parameter `actualTry` to identify the concrete situation( try or synchronized) and fixes this issue about using empty skip statement in the try statement body. And some related test cases are added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: fe89dd3b
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fe89dd3b0d47807c7dbfe24d17f6aca152fc8908
Stats:     101 lines in 2 files changed: 92 ins; 0 del; 9 mod

8271254: javac generates unreachable code when using empty semicolon statement

Reviewed-by: vromero

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

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

From gavin.bierman at oracle.com  Tue Sep 14 16:02:50 2021
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Tue, 14 Sep 2021 16:02:50 +0000
Subject: Dominance in pattern matching for switch: Spec and Javac
 inconsistency
In-Reply-To: <CANbUyJcbcmmrjSuk1oFvp-A1LtMjriEfeYZJyJv2AhXqHZzE2Q@mail.gmail.com>
References: <CANbUyJcbcmmrjSuk1oFvp-A1LtMjriEfeYZJyJv2AhXqHZzE2Q@mail.gmail.com>
Message-ID: <04A1BD76-E178-4F6E-A0F0-C321A8C49C52@oracle.com>

Thanks Ilyas,

Yes, this is a small bug in the spec which is causing your confusion. When it was first drafted it there was only one pattern case label element - a type pattern. By the time we published, there were two more - parenthesised patterns and guarded patterns. The rule didn?t get updated :-(

The rule you read only applies to *type* patterns. We need a couple of extra rules for parenthesised and guarded patterns. 

As it happens the compiler is correct here. We treat a guarded pattern as a subset pattern, unless the guard is a constant expression whose value is true (a rare case!). So, in your example, we see that the first pattern matches *some* integers. We don?t know which ones, so we can?t be sure that it dominates the integer value 1. So the code is correct. 

We could attempt to look at the guards to see what we can infer statically, but I think this unlikely to be a fruitful direction to take.

Thanks,
Gavin

> On 3 Sep 2021, at 06:27, Ilyas Selimov <ilyas.selimov at jetbrains.com> wrote:
> 
> Hello!
> 
> The next code compiles correctly, but it seems to contradict the dominance rules:
> 
> void test(Integer i) {
>   switch (i) {
>     case Integer in && in != null:
>       break;
>     case 1:
>       break;
>     case default:
>       break;  
>   }
> }
> 
> > A switch label that has a pattern case label element p dominates another switch label that has a constant case label element c if either of the following is true:
> > - the type of c is a primitive type and its wrapper class (5.1.7) is a subtype of the erasure of the type of p.
> 
> Maybe the type of p should also be total for the type of selector expression like in the rules for pattern-over-null dominance?
> 
> Thanks,
> Ilyas


From vromero at openjdk.java.net  Tue Sep 14 17:21:07 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 14 Sep 2021 17:21:07 GMT
Subject: RFR: 8269121: Type inference bug with method references [v3]
In-Reply-To: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
Message-ID: <7_Xqc1EhzVyBYJdZFso65cJ5bSxxFlfnj5-OuMoVOYw=.195728b1-85ac-4652-9c25-8c831ee7bd0b@github.com>

> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
> 
> TIA

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

  changing the verification of LMF

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5406/files
  - new: https://git.openjdk.java.net/jdk/pull/5406/files/bd425138..579ebdf8

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

  Stats: 143 lines in 3 files changed: 76 ins; 53 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5406.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5406/head:pull/5406

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

From gli at openjdk.java.net  Tue Sep 14 17:50:38 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 14 Sep 2021 17:50:38 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on generated
 class property of record
Message-ID: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>

Hi all,

After processing annotation, if new source files are generated, the compiler should re-parse and re-enter the source files so that the type and symbol can keep right. The compiler always holds this convention in the past. But when the feature `record` is added, the convention is broken. In this bug, the compiler doesn't  catch or enter the new/good type for record component after processing annotation. So some issues may occur at the later phases.

This patch fixes the type of the record component so that the phases `Gen` and `ClassWriter` can get the right type. And a test case is added.

Thanks for taking the time to review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - Polish
 - 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record

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

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

From jjg at openjdk.java.net  Tue Sep 14 17:51:26 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 14 Sep 2021 17:51:26 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree
Message-ID: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>

Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world.

## Previously ...

Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class.  (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.)  The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available.

## Now ... 

All `DCTree` nodes have 4 positions, 3 publicly available.
* the position of the first unique character, `pos`
* the starting position of the range of characters, `getStartPosition()`
* the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()`
* the end position of the range of characters, `getEndPosition()`.
These are all relative to the beginning of the comment text, and are converted to file positions as needed.

Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods.

`DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic.

`DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods.

`DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified.

## Testing ...

Up until the point at which `DCTree.pos` was modified, all tests passed without change.   When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated.

Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker`  which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue.

## Behavior ...

Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`.  This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work.  Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files.

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

Commit messages:
 - JDK-8273244: Improve diagnostic output related to ErroneousTree

Changes: https://git.openjdk.java.net/jdk/pull/5510/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5510&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273244
  Stats: 772 lines in 49 files changed: 412 ins; 123 del; 237 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5510.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5510/head:pull/5510

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

From prappo at openjdk.java.net  Tue Sep 14 20:11:42 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 14 Sep 2021 20:11:42 GMT
Subject: RFR: 8266666: Implementation for snippets [v24]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <Q-hJiaykzDiQcv37heMdHWFTU4vWvA4OujGaZPzbzj4=.0f1e6a80-6bdc-4ce7-af7f-5fff50a74cfd@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

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

  Address feedback
  
  1. Reverts changes from CommentUtils.java (unused methods)
  2. Changes misguided regex-related assertion to tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/3c654e6b..4a22c09d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=22-23

  Stats: 116 lines in 3 files changed: 93 ins; 22 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

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

From vromero at openjdk.java.net  Wed Sep 15 01:47:08 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 15 Sep 2021 01:47:08 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record
In-Reply-To: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
Message-ID: <ib4CIa8FNSNaJ3L_8xbIBzN_66D4TZ_UvaqLVSrE2Ec=.e786c8e2-b430-40d6-9c46-7102b450a501@github.com>

On Tue, 14 Sep 2021 16:14:39 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> After processing annotation, if new source files are generated, the compiler should re-parse and re-enter the source files so that the type and symbol can keep right. The compiler always holds this convention in the past. But when the feature `record` is added, the convention is broken. In this bug, the compiler doesn't  catch or enter the new/good type for record component after processing annotation. So some issues may occur at the later phases.
> 
> This patch fixes the type of the record component so that the phases `Gen` and `ClassWriter` can get the right type. And a test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

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

> 1515:                         // If the class type of the record component is generated by annotation processor, it should
> 1516:                         // use the new actual class type and symbol instead of the old dummy ErrorType.
> 1517:                         // toRemove = rc;

there is dead code here, `toRemove` doesn't seem to be assigned ever, probably you uploaded an intermediate patch?

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

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

From vromero at openjdk.java.net  Wed Sep 15 02:36:51 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 15 Sep 2021 02:36:51 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record
In-Reply-To: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
Message-ID: <EpNsEgNHzviAKobnR9FYMjNXz1ScB0EjUNd4az9JdIA=.e87c1fe7-d111-45f5-b0b4-24e0f236555d@github.com>

On Tue, 14 Sep 2021 16:14:39 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> After processing annotation, if new source files are generated, the compiler should re-parse and re-enter the source files so that the type and symbol can keep right. The compiler always holds this convention in the past. 

could you please add a link to where this is done in the compiler for other cases different from records? thanks

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

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

From vromero at openjdk.java.net  Wed Sep 15 03:21:32 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 15 Sep 2021 03:21:32 GMT
Subject: RFR: 8269121: Type inference bug with method references [v4]
In-Reply-To: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
Message-ID: <W3fjBgOPTFzjEZsI0HVEFY8LuefphqUJHnJ0fYir5P8=.41cc4e4c-38ab-4330-a862-80bcb81fb0e3@github.com>

> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
> 
> TIA

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

  support for sealed classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5406/files
  - new: https://git.openjdk.java.net/jdk/pull/5406/files/579ebdf8..d443a48b

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

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

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

From gli at openjdk.java.net  Wed Sep 15 06:10:27 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 15 Sep 2021 06:10:27 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record [v2]
In-Reply-To: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
Message-ID: <gR9tYq5L5ofKPrIWPp81wOQN2Vbc-nvMS3pnzU45uI0=.8682105a-0636-45c6-bcd3-401fd09f84ac@github.com>

> Hi all,
> 
> After processing annotation, if new source files are generated, the compiler should re-parse and re-enter the source files so that the type and symbol can keep right. The compiler always holds this convention in the past. But when the feature `record` is added, the convention is broken. In this bug, the compiler doesn't  catch or enter the new/good type for record component after processing annotation. So some issues may occur at the later phases.
> 
> This patch fixes the type of the record component so that the phases `Gen` and `ClassWriter` can get the right type. And a test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Treat source as comment mistakenly. Remove the comment symbol.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5511/files
  - new: https://git.openjdk.java.net/jdk/pull/5511/files/e6b35178..7b756883

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

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

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

From gli at openjdk.java.net  Wed Sep 15 06:16:43 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 15 Sep 2021 06:16:43 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record [v2]
In-Reply-To: <ib4CIa8FNSNaJ3L_8xbIBzN_66D4TZ_UvaqLVSrE2Ec=.e786c8e2-b430-40d6-9c46-7102b450a501@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
 <ib4CIa8FNSNaJ3L_8xbIBzN_66D4TZ_UvaqLVSrE2Ec=.e786c8e2-b430-40d6-9c46-7102b450a501@github.com>
Message-ID: <zcmtY3WyduP7RjjrWOC3u0hoQDbTCWJMC9c59yoRiU8=.3fffe28f-6547-4f3e-9c29-11bbb5b8e694@github.com>

On Wed, 15 Sep 2021 01:43:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Treat source as comment mistakenly. Remove the comment symbol.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1517:
> 
>> 1515:                         // If the class type of the record component is generated by annotation processor, it should
>> 1516:                         // use the new actual class type and symbol instead of the old dummy ErrorType.
>> 1517:                         // toRemove = rc;
> 
> there is dead code here, `toRemove` doesn't seem to be assigned ever, probably you uploaded an intermediate patch?

The `// toRemove = rc;` should be `toRemove = rc;`. It is a statement instead of a comment. I revised it mitakenly in my second commit `Polish`. In the second commit `Polish`, I only want to fix the indentation so that I didn't test again after revising. Unfortunately, the IDE changed `toRemove = rc;` to a comment. Apology for the mistake.

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

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

From gli at openjdk.java.net  Wed Sep 15 07:18:45 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 15 Sep 2021 07:18:45 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record
In-Reply-To: <EpNsEgNHzviAKobnR9FYMjNXz1ScB0EjUNd4az9JdIA=.e87c1fe7-d111-45f5-b0b4-24e0f236555d@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
 <EpNsEgNHzviAKobnR9FYMjNXz1ScB0EjUNd4az9JdIA=.e87c1fe7-d111-45f5-b0b4-24e0f236555d@github.com>
Message-ID: <aFgbFc5SfopvHfNej9JH6c2D1rcBj90IRwyc3GCDwno=.3da30c92-c11c-456c-9998-1060bddf7d11@github.com>

On Wed, 15 Sep 2021 02:34:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> could you please add a link to where this is done in the compiler for other cases different from records? thanks

The compiler would [parse the newly generated source files](https://github.com/openjdk/jdk/blob/febcc72a549e973de4649503fc686fc520e3b3cd/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#L1393)  and [enter all the source files again](https://github.com/openjdk/jdk/blob/febcc72a549e973de4649503fc686fc520e3b3cd/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#L1133). Many dummy types or symbols, such as ErrorType, would be replaced with the actually right ones.

> But when the feature record is added, the convention is broken. 

This description may be excessive. Actually, new features always obey the convention, so as record. But the method `getRecordComponent` in this bug is an example which obscures the convention.

In detail, please read the following source code, currently in the main line.


// Symbol.java
        public RecordComponent getRecordComponent(JCVariableDecl var, boolean addIfMissing, List<JCAnnotation> annotations) {
            for (RecordComponent rc : recordComponents) {
                /* it could be that a record erroneously declares two record components with the same name, in that
                 * case we need to use the position to disambiguate
                 */
                if (rc.name == var.name && var.pos == rc.pos) {
                    return rc;
                }
            }
            RecordComponent rc = null;
            if (addIfMissing) {
                recordComponents = recordComponents.append(rc = new RecordComponent(var.sym, annotations));
            }
            return rc;
        }


Before the first processing round, the `var` is not right at all, because `var.sym.type` is `ErrorType`. So the `getRecordComponent` would generate a not good `RecordComponent` by using the wrong `var.sym` whose type is `ErrorType`.

After the first processing round, the new source files are created and we can catch the right type from the newly generated source files. When the compiler invokes `getRecordComponent` to get the `RecordComponent`, it only can get the wrong one(the type is `ErrorType`). At this time, the `var.sym.type` is the right `ClassType` which is created correctly earier. So we should use current argument `var` and the right `var.sym.type` instead of the old wrong one.

So you can see my patch, I judge whether the type is right. If it is right, which means the `RecordComponent` created earier is right, I reuse it. If the type is `ErrorType`, we shouldn't keep it and should create a new one by using the right `var` whose `var.sym.type` is not `ErrorType`.


                    if (rc.type.hasTag(TypeTag.ERROR) && !var.sym.type.hasTag(TypeTag.ERROR)) {
                        // Found a wrong record component: save it so that we can remove it later.
                        // If the class type of the record component is generated by annotation processor, it should
                        // use the new actual class type and symbol instead of the old dummy ErrorType.
                        toRemove = rc;
                    } else {
                        // Found a good record component: just return.
                        return rc;
                    }


You can put breakpoints at the method `getRecordComponent` to watch the `var.sym.type` and `rc.type`. You can observe that the `var.sym.type` is an `ErrorType` at first and is a right `ClassType` after first processing round.

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

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

From prappo at openjdk.java.net  Wed Sep 15 11:49:52 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 15 Sep 2021 11:49:52 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <u4v9ehaWSx33znWQ5ngeelYnrf4BRJDan0-YaewMg9Q=.f12b1e56-bbf3-4773-8dba-d8426e4f85dc@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
 <u4v9ehaWSx33znWQ5ngeelYnrf4BRJDan0-YaewMg9Q=.f12b1e56-bbf3-4773-8dba-d8426e4f85dc@github.com>
Message-ID: <vKoWvJRhcAZoOnel-xVicrk5htjiHBph1IAhnlV4U6o=.b59855d8-f799-42a6-99a7-bfd66bb5f6e0@github.com>

On Mon, 13 Sep 2021 17:42:20 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove trailing whitespace to satisfy jcheck
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1077:
> 
>> 1075:         return ch == ' ' || ch == '\t' /* || ch == '\f'*/;
>> 1076:     }
>> 1077: 
> 
> It would be good to resolve this issue sooner rather than later, but not right now.
> I suggest we file a JBS issue to make a determination and update the doc comment world accordingly. Yes, it will be a minor change for DocCommentParser. The JBS issue will provide a good place to record the decision and its rationale.

I have filed a bug and assigned it to you for the time being: https://bugs.openjdk.java.net/browse/JDK-8273809

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

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

From prappo at openjdk.java.net  Wed Sep 15 13:39:56 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 15 Sep 2021 13:39:56 GMT
Subject: RFR: 8266666: Implementation for snippets [v23]
In-Reply-To: <OjQ9qH1J4jq360Fqo0hdEu2k6yxsbxthCt6JiOK-fwA=.ceab6805-fffe-4568-bb5e-d629d0cf57a9@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <m66mX98GQcFltaCcfgI1Dk-EGM5z4k4d7AaCERlQVXA=.72c54265-95d0-421d-bfb2-651146cd7442@github.com>
 <u4v9ehaWSx33znWQ5ngeelYnrf4BRJDan0-YaewMg9Q=.f12b1e56-bbf3-4773-8dba-d8426e4f85dc@github.com>
 <OjQ9qH1J4jq360Fqo0hdEu2k6yxsbxthCt6JiOK-fwA=.ceab6805-fffe-4568-bb5e-d629d0cf57a9@github.com>
Message-ID: <s4yCFzTrIPeG1TWtL61vfWuHAwH9wFx5EgQHYra1jME=.27a768e5-dc27-41ec-a4ca-ecf12b37d904@github.com>

On Mon, 13 Sep 2021 18:59:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/ParseException.java line 50:
>> 
>>> 48:      * @param position the approximate position
>>> 49:      */
>>> 50:     public ParseException(String message, int position) {
>> 
>> I know it is common to use English-only strings in exceptions that are not intended to be seen in normal use by an end user, but here, you're using `ParseException` to contain content that is intended to appear in end-user error messages, triggered by errors in the content provided by an end-user.   As such, it is close to a firm requirement that these messages can be localized.
>
> One possible solution at this time that would be minimally invasive would be to replace `new ParseException(String message, int pos)` with use of a method that localizes the string first, as in,
> 
> ParseException newParseException(int pos, String resourceKey, Object... args)
> 
> so the code becomes something like
> 
>    throw newParseException(pos, key, args);

> I know it is common to use English-only strings in exceptions that are not intended to be seen in normal use by an end user, but here, you're using `ParseException` to contain content that is intended to appear in end-user error messages, triggered by errors in the content provided by an end-user. As such, it is close to a firm requirement that these messages can be localized.

You are completely right. In fact, I was going to internationalize those messages initially in this PR, but then decided to postpone it until the https://bugs.openjdk.java.net/browse/JDK-8273544 follow-up bug. I removed the respective FIXMEs in one of the updates either to this PR or the originating sandbox branch.

One reason I was postponing internationalization is that I was sure neither about the wording nor about the granularity of the messages. But I guess, it's not that big a deal to amend either of those later.

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

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

From shade at openjdk.java.net  Wed Sep 15 14:25:07 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Sep 2021 14:25:07 GMT
Subject: RFR: 8273314: Add tier4 test groups [v3]
In-Reply-To: <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
Message-ID: <54l9_jkU4qhnz_ULvtN7sQXJ46LIdUhcdvxAkhCmlw4=.4a7adb15-e01c-4a38-bb99-3b577e9e05ca@github.com>

On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>> 
>> Sample run:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                      426   425     1     0 <<
>>>> jtreg:test/jdk:tier4                               2891  2885     4     2 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	64m13.994s
>> user	1462m1.213s
>> sys	39m38.032s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop applications and fix the comment

Progress: 
 a) `hotspot:tier4` still runs cleanly, and a bit faster due to recent `vmTestbase` parallelism improvements.
 b) `jdk:tier4` has a lot of failures in headful mode, probably because the tests do not like to run in parallel, see for example #5533. It would take a while to resolve for all GUI tests. If we are in agreement that current `tier4` definition is good, maybe it would be proper to integrate this PR, and then make `tier4` clean for headful mode?

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

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

From vromero at openjdk.java.net  Wed Sep 15 14:30:52 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 15 Sep 2021 14:30:52 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record [v2]
In-Reply-To: <gR9tYq5L5ofKPrIWPp81wOQN2Vbc-nvMS3pnzU45uI0=.8682105a-0636-45c6-bcd3-401fd09f84ac@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
 <gR9tYq5L5ofKPrIWPp81wOQN2Vbc-nvMS3pnzU45uI0=.8682105a-0636-45c6-bcd3-401fd09f84ac@github.com>
Message-ID: <aPJrEV5xnyhoaTbZrph-j-8fpLDTRdfHRtaBFzVdf4E=.6a52e473-738a-4753-8ce6-a9161e185245@github.com>

On Wed, 15 Sep 2021 06:10:27 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> After processing annotation, if new source files are generated, the compiler should re-parse and re-enter the source files so that the type and symbol can keep right. The compiler always holds this convention in the past. But when the feature `record` is added, the convention is broken. In this bug, the compiler doesn't  catch or enter the new/good type for record component after processing annotation. So some issues may occur at the later phases.
>> 
>> This patch fixes the type of the record component so that the phases `Gen` and `ClassWriter` can get the right type. And a test case is added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat source as comment mistakenly. Remove the comment symbol.

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

> 1512:                 if (rc.name == var.name && var.pos == rc.pos) {
> 1513:                     if (rc.type.hasTag(TypeTag.ERROR) && !var.sym.type.hasTag(TypeTag.ERROR)) {
> 1514:                         // Found a wrong record component: save it so that we can remove it later.

suggestion for the comment:

Found a record component with an erroneous type, save it so that it can be removed later.
If the class type of the ...

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

> 1524:             RecordComponent rc = null;
> 1525:             if (toRemove != null) {
> 1526:                 // Found a wrong record component: remove it and create a new one.

suggestion:

Found a record component with an erroneous type, remove it and create a new one

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

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

From vromero at openjdk.java.net  Wed Sep 15 14:37:46 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 15 Sep 2021 14:37:46 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record [v2]
In-Reply-To: <gR9tYq5L5ofKPrIWPp81wOQN2Vbc-nvMS3pnzU45uI0=.8682105a-0636-45c6-bcd3-401fd09f84ac@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
 <gR9tYq5L5ofKPrIWPp81wOQN2Vbc-nvMS3pnzU45uI0=.8682105a-0636-45c6-bcd3-401fd09f84ac@github.com>
Message-ID: <prcoMmkqvtDRH0TqqqE1jZ_UN3JI6zJklsgDvViGvX8=.3ddf503b-2366-4c17-88c1-c2f66836022d@github.com>

On Wed, 15 Sep 2021 06:10:27 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> After processing annotation, if new source files are generated, the compiler should re-parse and re-enter the source files so that the type and symbol can keep right. The compiler always holds this convention in the past. But when the feature `record` is added, the convention is broken. In this bug, the compiler doesn't  catch or enter the new/good type for record component after processing annotation. So some issues may occur at the later phases.
>> 
>> This patch fixes the type of the record component so that the phases `Gen` and `ClassWriter` can get the right type. And a test case is added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat source as comment mistakenly. Remove the comment symbol.

I think that there are two test cases missing here. I think that you should investigate the interaction of your patch with something like:


record R(unknownType t) {}


and see what happens, if your code creates another record component when I think it shouldn't, etc. Actually you could try to override the type in the existing record component instead of creating a new one.

Another investigation you should do is how your code interacts with annotations (declaration and type anotations) on the record component. So in your test add annotations to the record component and see if you need to copy them etc. I think that if you override the type of the record component instead of creating a new one you should be fine with annotations, but not sure TBH

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

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

From forax at univ-mlv.fr  Wed Sep 15 15:55:04 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 15 Sep 2021 17:55:04 +0200 (CEST)
Subject: Dominance in pattern matching for switch: Spec and Javac
 inconsistency
In-Reply-To: <04A1BD76-E178-4F6E-A0F0-C321A8C49C52@oracle.com>
References: <CANbUyJcbcmmrjSuk1oFvp-A1LtMjriEfeYZJyJv2AhXqHZzE2Q@mail.gmail.com>
 <04A1BD76-E178-4F6E-A0F0-C321A8C49C52@oracle.com>
Message-ID: <566333489.1695952.1631721304102.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Gavin Bierman" <gavin.bierman at oracle.com>
> To: "Ilyas Selimov" <ilyas.selimov at jetbrains.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Mardi 14 Septembre 2021 18:02:50
> Subject: Re: Dominance in pattern matching for switch: Spec and Javac inconsistency

> Thanks Ilyas,
> 
> Yes, this is a small bug in the spec which is causing your confusion. When it
> was first drafted it there was only one pattern case label element - a type
> pattern. By the time we published, there were two more - parenthesised patterns
> and guarded patterns. The rule didn?t get updated :-(
> 
> The rule you read only applies to *type* patterns. We need a couple of extra
> rules for parenthesised and guarded patterns.
> 
> As it happens the compiler is correct here. We treat a guarded pattern as a
> subset pattern, unless the guard is a constant expression whose value is true
> (a rare case!). So, in your example, we see that the first pattern matches
> *some* integers. We don?t know which ones, so we can?t be sure that it
> dominates the integer value 1. So the code is correct.
> 
> We could attempt to look at the guards to see what we can infer statically, but
> I think this unlikely to be a fruitful direction to take.

I disagree, the spec should have a supplementary rule that says that a guard that starts with a type pattern behave like that type pattern with respect to the constants of that type.

This rule allows to bubble up the constants on top of the corresponding type pattern or guards that starts with that type pattern,
making the implementation more efficient (you can test several integer constants with a binary search, or any constants with a hashmap by example).

If we do not have that rule, you can have constants in between guards of the type of the constants, so we have to degrade the implementation of a bunch of if ... equals. 

> 
> Thanks,
> Gavin

regards,
R?mi

> 
>> On 3 Sep 2021, at 06:27, Ilyas Selimov <ilyas.selimov at jetbrains.com> wrote:
>> 
>> Hello!
>> 
>> The next code compiles correctly, but it seems to contradict the dominance
>> rules:
>> 
>> void test(Integer i) {
>>   switch (i) {
>>     case Integer in && in != null:
>>       break;
>>     case 1:
>>       break;
>>     case default:
>>       break;
>>   }
>> }
>> 
>> > A switch label that has a pattern case label element p dominates another switch
>> > label that has a constant case label element c if either of the following is
>> > true:
>> > - the type of c is a primitive type and its wrapper class (5.1.7) is a subtype
>> > of the erasure of the type of p.
>> 
>> Maybe the type of p should also be total for the type of selector expression
>> like in the rules for pattern-over-null dominance?
>> 
>> Thanks,
> > Ilyas

From victorwssilva at gmail.com  Wed Sep 15 18:42:45 2021
From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva)
Date: Wed, 15 Sep 2021 15:42:45 -0300
Subject: NullPointerException in JDK compiler 17 - Cannot read field
 "bindingsWhenTrue" because "currentBindings" is null
Message-ID: <CAJ0GajRqeOjVoRXmG4y3Y99qKy3zJ2Ks=BqXCr26HS1oh0Wxpw@mail.gmail.com>

Hi. I tried to run some of my projects in JDK 17 and the compiler crashed
with a NPE. It used to work just fine in JDK 16.

After trying to find out the source of the problem. I got it to
Lombok's @Builder and @Singular. I know that since Lombok hacks into
compiler's inner guts and there are no guarantees of retrocompatibility
there, it is likely that it should be fixed on Lombok's side. However,
there is a chance that it is not that simple and maybe I am facing a real
compiler bug. Also, it is always good to keep an eye there to avoid having
problems around very unusual edge cases flying under the radar.

Here is the link to Lombok's issue that I just created, including all the
NPE's stacktrace produced by JDK 17:
https://github.com/projectlombok/lombok/issues/2962
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210915/7125843e/attachment.htm>

From vromero at openjdk.java.net  Thu Sep 16 04:24:31 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 16 Sep 2021 04:24:31 GMT
Subject: RFR: 8269121: Type inference bug with method references [v5]
In-Reply-To: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
Message-ID: <aCq6KTlRwOOkCZk-GUtroDUnRSEpe4c41qlbFNQD39s=.2802baad-423e-4d49-8912-e48e54be6f14@github.com>

> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
> 
> TIA

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

  implement verification based on conversions used at MethodHandle::asType

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5406/files
  - new: https://git.openjdk.java.net/jdk/pull/5406/files/d443a48b..3c394425

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

  Stats: 165 lines in 2 files changed: 90 ins; 47 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5406.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5406/head:pull/5406

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

From gli at openjdk.java.net  Thu Sep 16 12:24:28 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 16 Sep 2021 12:24:28 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record [v3]
In-Reply-To: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
Message-ID: <t-MfuyOxqeUhnX9SGFUirq14O2bqws5X6uBYjvpUUD8=.a1f0130c-8449-488e-8249-dd9417fb2404@github.com>

> Hi all,
> 
> After processing annotation, if new source files are generated, the compiler should re-parse and re-enter the source files so that the type and symbol can keep right. The compiler always holds this convention in the past. But when the feature `record` is added, the convention is broken. In this bug, the compiler doesn't  catch or enter the new/good type for record component after processing annotation. So some issues may occur at the later phases.
> 
> This patch fixes the type of the record component so that the phases `Gen` and `ClassWriter` can get the right type. And a test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li 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:

 - Add test cases about unknown type and annotation.
 - Fix comments.
 - Merge branch 'master' into JDK-8273408
 - Treat source as comment mistakenly. Remove the comment symbol.
 - Polish
 - 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5511/files
  - new: https://git.openjdk.java.net/jdk/pull/5511/files/7b756883..f262a85c

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

  Stats: 904 lines in 89 files changed: 653 ins; 85 del; 166 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5511.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5511/head:pull/5511

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

From gli at openjdk.java.net  Thu Sep 16 12:41:54 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 16 Sep 2021 12:41:54 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record [v2]
In-Reply-To: <prcoMmkqvtDRH0TqqqE1jZ_UN3JI6zJklsgDvViGvX8=.3ddf503b-2366-4c17-88c1-c2f66836022d@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
 <gR9tYq5L5ofKPrIWPp81wOQN2Vbc-nvMS3pnzU45uI0=.8682105a-0636-45c6-bcd3-401fd09f84ac@github.com>
 <prcoMmkqvtDRH0TqqqE1jZ_UN3JI6zJklsgDvViGvX8=.3ddf503b-2366-4c17-88c1-c2f66836022d@github.com>
Message-ID: <QfANCk7RBY1vwxDpN9m_6lDV8jqBvq9ib_jiKjsuqrg=.d4a9683e-392b-4f48-9385-72e058e12993@github.com>

On Wed, 15 Sep 2021 14:35:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Treat source as comment mistakenly. Remove the comment symbol.
>
> I think that there are two test cases missing here. I think that you should investigate the interaction of your patch with something like:
> 
> 
> record R(unknownType t) {}
> 
> 
> and see what happens, if your code creates another record component when I think it shouldn't, etc. Actually you could try to override the type in the existing record component instead of creating a new one.
> 
> Another investigation you should do is how your code interacts with annotations (declaration and type anotations) on the record component. So in your test add annotations to the record component and see if you need to copy them etc. I think that if you override the type of the record component instead of creating a new one you should be fine with annotations, but not sure TBH

@vicente-romero-oracle thanks for your comment.

> I think that there are two test cases missing here. 

I added some tests about unknown type and annotation. Please take a look.

> Actually you could try to override the type in the existing record component instead of creating a new one.

I don't think that overriding the type in the existing record component can solve this issue. As we can see the constructor of the `RecordComponent`, the current fields `RecordComponent.type` and `RecordComponent.isVarargs` depend on the `type` of the argument `VarSymbol field`(`field.type`). So we need to revise `RecordComponent.type` and `RecordComponent.isVarargs` in the method `getRecordComponent`. If the `RecordComponent` adds new fields which depend on the `type` of the argument `VarSymbol field`(`field.type`) in the future, the developers need to revise the method `getRecordComponent` to override the new fields. It is uncomfortable and the code is hard to maintain. So I consider that creating a new one is a better way. 


        public RecordComponent(VarSymbol field, List<JCAnnotation> annotations) {
            super(PUBLIC, field.name, field.type, field.owner);   // <---- here uses `field.type`
            this.originalAnnos = annotations;
            this.pos = field.pos;
            /* it is better to store the original information for this one, instead of relying
             * on the info in the type of the symbol. This is because on the presence of APs
             * the symbol will be blown out and we won't be able to know if the original
             * record component was declared varargs or not.
             */
            this.isVarargs = type.hasTag(TypeTag.ARRAY) && ((ArrayType)type).isVarargs();  // <---- here `type` is `field.type`, too
        }

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1514:
> 
>> 1512:                 if (rc.name == var.name && var.pos == rc.pos) {
>> 1513:                     if (rc.type.hasTag(TypeTag.ERROR) && !var.sym.type.hasTag(TypeTag.ERROR)) {
>> 1514:                         // Found a wrong record component: save it so that we can remove it later.
> 
> suggestion for the comment:
> 
> Found a record component with an erroneous type, save it so that it can be removed later.
> If the class type of the ...

Fixed.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1526:
> 
>> 1524:             RecordComponent rc = null;
>> 1525:             if (toRemove != null) {
>> 1526:                 // Found a wrong record component: remove it and create a new one.
> 
> suggestion:
> 
> Found a record component with an erroneous type, remove it and create a new one

Fixed.

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

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

From vromero at openjdk.java.net  Thu Sep 16 15:15:46 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 16 Sep 2021 15:15:46 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record [v3]
In-Reply-To: <t-MfuyOxqeUhnX9SGFUirq14O2bqws5X6uBYjvpUUD8=.a1f0130c-8449-488e-8249-dd9417fb2404@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
 <t-MfuyOxqeUhnX9SGFUirq14O2bqws5X6uBYjvpUUD8=.a1f0130c-8449-488e-8249-dd9417fb2404@github.com>
Message-ID: <n5eU0WKq9bQZeWESMpAGq23Ksx6aRwUeKGKDQfeupp0=.b9afa930-de34-457d-b50f-b65583af13a5@github.com>

On Thu, 16 Sep 2021 12:24:28 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> After processing annotation, if new source files are generated, the compiler should re-parse and re-enter the source files so that the type and symbol can keep right. The compiler always holds this convention in the past. But when the feature `record` is added, the convention is broken. In this bug, the compiler doesn't  catch or enter the new/good type for record component after processing annotation. So some issues may occur at the later phases.
>> 
>> This patch fixes the type of the record component so that the phases `Gen` and `ClassWriter` can get the right type. And a test case is added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li 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:
> 
>  - Add test cases about unknown type and annotation.
>  - Fix comments.
>  - Merge branch 'master' into JDK-8273408
>  - Treat source as comment mistakenly. Remove the comment symbol.
>  - Polish
>  - 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record

looks good, thanks for the additional research

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

Marked as reviewed by vromero (Reviewer).

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

From cushon at google.com  Thu Sep 16 23:38:53 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 16 Sep 2021 16:38:53 -0700
Subject: [External] : Re: String concatenation order of operations
In-Reply-To: <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
 <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
 <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>
 <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>
Message-ID: <CAL4QsgsafKg5ux=RsCpB1hFoqtYRh0_bEMbEnjq8J4B34EKY0A@mail.gmail.com>

Thanks Brian, I filed https://bugs.openjdk.java.net/browse/JDK-8273914 to
keep track of this.

On Wed, Sep 8, 2021 at 3:01 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> It'd be nice to reconcile the implementation with the spec if possible,
> though. I wonder what the performance hit would be from calling toString on
> the arguments more eagerly to preserve the evaluation order.
>
>
> The nature of indy leads to the structure we ended up with.  The natural
> way to do this is to have the various arguments passed as real stack
> arguments, causing them to all be evaluated before being pushed through the
> MH nest (which is where the string conversion happens, using
> MethodHandle::filterArguments.)  We'd essentially have to write a new
> bootstrap (but leave the old one in place), and have the compiler generate
> bytecode to do the string conversion as the values are being pushed on the
> stack.  This requires a different bootstrap and a different calling
> convention.  So old bytecode will stay around, and the old bootstrap would
> have to be kept around ... pretty disruptive.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210916/cd698fb9/attachment-0001.htm>

From gli at openjdk.java.net  Fri Sep 17 05:37:51 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 17 Sep 2021 05:37:51 GMT
Subject: RFR: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record [v2]
In-Reply-To: <prcoMmkqvtDRH0TqqqE1jZ_UN3JI6zJklsgDvViGvX8=.3ddf503b-2366-4c17-88c1-c2f66836022d@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
 <gR9tYq5L5ofKPrIWPp81wOQN2Vbc-nvMS3pnzU45uI0=.8682105a-0636-45c6-bcd3-401fd09f84ac@github.com>
 <prcoMmkqvtDRH0TqqqE1jZ_UN3JI6zJklsgDvViGvX8=.3ddf503b-2366-4c17-88c1-c2f66836022d@github.com>
Message-ID: <LyCDBrEZfA53U2PJrw62IZToN-kPsABJYlhiQ2SUL68=.90189a00-c5d1-46e4-89c9-7c63419db546@github.com>

On Wed, 15 Sep 2021 14:35:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Treat source as comment mistakenly. Remove the comment symbol.
>
> I think that there are two test cases missing here. I think that you should investigate the interaction of your patch with something like:
> 
> 
> record R(unknownType t) {}
> 
> 
> and see what happens, if your code creates another record component when I think it shouldn't, etc. Actually you could try to override the type in the existing record component instead of creating a new one.
> 
> Another investigation you should do is how your code interacts with annotations (declaration and type anotations) on the record component. So in your test add annotations to the record component and see if you need to copy them etc. I think that if you override the type of the record component instead of creating a new one you should be fine with annotations, but not sure TBH

@vicente-romero-oracle Thanks for your review.

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

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

From gli at openjdk.java.net  Fri Sep 17 05:37:54 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 17 Sep 2021 05:37:54 GMT
Subject: Integrated: 8273408: java.lang.AssertionError: typeSig ERROR on
 generated class property of record
In-Reply-To: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
References: <0RzRSg31UW8ZZql-qUTPrj9IYPdwFzrBEEAQQTWKjzs=.1ee13d9b-1a62-4aa5-b3f0-b72dd9ac3c61@github.com>
Message-ID: <1T6-fDuQ26S9tfDZiwudUIAbS1wReA6YKdZgMLnU9bY=.4d280abc-737e-4a4a-923c-ff166617a09b@github.com>

On Tue, 14 Sep 2021 16:14:39 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> After processing annotation, if new source files are generated, the compiler should re-parse and re-enter the source files so that the type and symbol can keep right. The compiler always holds this convention in the past. But when the feature `record` is added, the convention is broken. In this bug, the compiler doesn't  catch or enter the new/good type for record component after processing annotation. So some issues may occur at the later phases.
> 
> This patch fixes the type of the record component so that the phases `Gen` and `ClassWriter` can get the right type. And a test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: e07ab82e
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e07ab82ee555f27921287a871ba582e0906ad45c
Stats:     243 lines in 3 files changed: 241 ins; 0 del; 2 mod

8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record

Reviewed-by: vromero

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

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

From john.r.rose at oracle.com  Fri Sep 17 06:51:07 2021
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 17 Sep 2021 06:51:07 +0000
Subject: [External] : Re: String concatenation order of operations
In-Reply-To: <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
 <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
 <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>
 <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>
Message-ID: <A691B288-ADFC-430F-B049-0C8F405E8029@oracle.com>

On Sep 8, 2021, at 3:01 PM, Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:

We'd essentially have to write a new bootstrap (but leave the old one in place), and have the compiler generate bytecode to do the string conversion as the values are being pushed on the stack.  This requires a different bootstrap and a different calling convention.  So old bytecode will stay around, and the old bootstrap would have to be kept around ... pretty disruptive.

Wouldn?t be enough for javac to run toString() on arguments that need it, and pass those (to the *old* indy mechanism) as strings?

If javac can determine that toString() can be safely delayed (for String and primitive boxes, for example) then it doesn?t need to call toString() eagerly.

But in order to fix this issue, it may be necessary to run toString() calls while arguments are being computed for the indy.

Yuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210917/7c431590/attachment.htm>

From shade at openjdk.java.net  Fri Sep 17 06:59:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 17 Sep 2021 06:59:09 GMT
Subject: RFR: 8273314: Add tier4 test groups [v4]
In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
Message-ID: <v2nomvkJIgNeqXOXNwt4sG0ec0zWK6CyLK-eLwINsjY=.2642ee46-10de-4db4-87f2-06aa62082c84@github.com>

> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. 
> 
> Caveats:
>  - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>  - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel
> 
> Sample run with `JTREG_KEYWORDS=!headful`:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:tier4                     3585  3584     0     1 <<
>>> jtreg:test/jdk:tier4                               2893  2887     5     1 <<
>    jtreg:test/langtools:tier4                            0     0     0     0   
>    jtreg:test/jaxp:tier4                                 0     0     0     0   
> ==============================
> 
> real	699m39.462s
> user	6626m8.448s
> sys	1110m43.704s
> 
> 
> There are interesting test failures on my machine, which I would address separately.

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

 - Merge branch 'master' into JDK-8273314-tier4
 - Merge branch 'master' into JDK-8273314-tier4
 - Drop applications and fix the comment
 - Drop exceptions
 - Add tier4 test groups

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5357/files
  - new: https://git.openjdk.java.net/jdk/pull/5357/files/160c13c7..a5115a8d

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

  Stats: 14580 lines in 682 files changed: 9082 ins; 3191 del; 2307 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5357.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5357/head:pull/5357

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

From shade at openjdk.java.net  Fri Sep 17 06:59:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 17 Sep 2021 06:59:10 GMT
Subject: RFR: 8273314: Add tier4 test groups [v3]
In-Reply-To: <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <ynF9TuZQLa8AbbNALabZ-wSq2Ga5zRLGThYuCVbGWvA=.ec85539f-b8cb-4b3b-9911-8bfcc6f16e4c@github.com>
Message-ID: <XTy0yAT4PxmLKdaizn-W0hmcVZDwRqFgpv0CxA_5WDs=.2d918cad-d4a1-4e1c-8423-bc21e98de615@github.com>

On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. 
>> 
>> Caveats:
>>  - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>>  - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel
>> 
>> Sample run with `JTREG_KEYWORDS=!headful`:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                     3585  3584     0     1 <<
>>>> jtreg:test/jdk:tier4                               2893  2887     5     1 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	699m39.462s
>> user	6626m8.448s
>> sys	1110m43.704s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop applications and fix the comment

All right, I am convinced that current patch is as good as it gets. GUI tests still do not run well with default parallelism, but I see no reason to block this integration before that is resolved. Either run `tier4` in headless mode, or limit the parallelism.

@iignatev, @mrserb, @dholmes-ora -- are you good with this?

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

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

From serb at openjdk.java.net  Fri Sep 17 07:17:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 17 Sep 2021 07:17:48 GMT
Subject: RFR: 8273314: Add tier4 test groups [v4]
In-Reply-To: <v2nomvkJIgNeqXOXNwt4sG0ec0zWK6CyLK-eLwINsjY=.2642ee46-10de-4db4-87f2-06aa62082c84@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <v2nomvkJIgNeqXOXNwt4sG0ec0zWK6CyLK-eLwINsjY=.2642ee46-10de-4db4-87f2-06aa62082c84@github.com>
Message-ID: <5Lc2i9bPCfmNRnco-B7Ru5VhREqKDbBrnjTS0YcVo8o=.950bb2c9-76a1-4278-855e-7d506686715c@github.com>

On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. 
>> 
>> Caveats:
>>  - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>>  - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel
>> 
>> Sample run with `JTREG_KEYWORDS=!headful`:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                     3585  3584     0     1 <<
>>>> jtreg:test/jdk:tier4                               2893  2887     5     1 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	699m39.462s
>> user	6626m8.448s
>> sys	1110m43.704s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8273314-tier4
>  - Merge branch 'master' into JDK-8273314-tier4
>  - Drop applications and fix the comment
>  - Drop exceptions
>  - Add tier4 test groups

It is fine to run headful and headless tests separately.

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

Marked as reviewed by serb (Reviewer).

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

From jpai at openjdk.java.net  Fri Sep 17 12:54:07 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 17 Sep 2021 12:54:07 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v2]
In-Reply-To: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
Message-ID: <Rq_AiI1WCvlFNkHWLeIWXxZ9Vx7l-ETmdmUIpkZLweg=.f92d8005-a0c4-46c1-a8c7-d06d5aede0a0@github.com>

> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
> 
> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
> 
> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
> 
> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
> 
> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
> 
> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge latest from master branch
 - 8258117: jar tool sets the time stamp of module-info.class entries to the current time

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5486/files
  - new: https://git.openjdk.java.net/jdk/pull/5486/files/e2193081..d91f02a3

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

  Stats: 5483 lines in 274 files changed: 3475 ins; 1249 del; 759 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486

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

From forax at univ-mlv.fr  Fri Sep 17 13:25:43 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 17 Sep 2021 15:25:43 +0200 (CEST)
Subject: [External] : Re: String concatenation order of operations
In-Reply-To: <A691B288-ADFC-430F-B049-0C8F405E8029@oracle.com>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
 <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
 <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>
 <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>
 <A691B288-ADFC-430F-B049-0C8F405E8029@oracle.com>
Message-ID: <1745626037.2582964.1631885143576.JavaMail.zimbra@u-pem.fr>

> From: "John Rose" <john.r.rose at oracle.com>
> To: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Liam Miller-Cushon" <cushon at google.com>, "compiler-dev"
> <compiler-dev at openjdk.java.net>
> Sent: Vendredi 17 Septembre 2021 08:51:07
> Subject: Re: [External] : Re: String concatenation order of operations

> On Sep 8, 2021, at 3:01 PM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] > wrote:

>> We'd essentially have to write a new bootstrap (but leave the old one in place),
>> and have the compiler generate bytecode to do the string conversion as the
>> values are being pushed on the stack. This requires a different bootstrap and a
>> different calling convention. So old bytecode will stay around, and the old
>> bootstrap would have to be kept around ... pretty disruptive.

> Wouldn?t be enough for javac to run toString() on arguments that need it, and
> pass those (to the *old* indy mechanism) as strings?

> If javac can determine that toString() can be safely delayed (for String and
> primitive boxes, for example) then it doesn?t need to call toString() eagerly.

> But in order to fix this issue, it may be necessary to run toString() calls
> while arguments are being computed for the indy.

It will be less efficient because the StringConcatFactory for a primitive type does not create the intermediary String objects. 

> Yuck

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210917/ab322e6a/attachment.htm>

From iignatyev at openjdk.java.net  Fri Sep 17 13:32:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 17 Sep 2021 13:32:48 GMT
Subject: RFR: 8273314: Add tier4 test groups [v4]
In-Reply-To: <v2nomvkJIgNeqXOXNwt4sG0ec0zWK6CyLK-eLwINsjY=.2642ee46-10de-4db4-87f2-06aa62082c84@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <v2nomvkJIgNeqXOXNwt4sG0ec0zWK6CyLK-eLwINsjY=.2642ee46-10de-4db4-87f2-06aa62082c84@github.com>
Message-ID: <BVA2XaJgH3PYNSFp0XDbb-MwHRHztazgmZwtCwNF-80=.4d3e4cb4-9812-44a5-b08c-76cb01d8bcb2@github.com>

On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. 
>> 
>> Caveats:
>>  - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>>  - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel
>> 
>> Sample run with `JTREG_KEYWORDS=!headful`:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                     3585  3584     0     1 <<
>>>> jtreg:test/jdk:tier4                               2893  2887     5     1 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	699m39.462s
>> user	6626m8.448s
>> sys	1110m43.704s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8273314-tier4
>  - Merge branch 'master' into JDK-8273314-tier4
>  - Drop applications and fix the comment
>  - Drop exceptions
>  - Add tier4 test groups

LGTM

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

Marked as reviewed by iignatyev (Reviewer).

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

From mullan at openjdk.java.net  Fri Sep 17 14:29:34 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 17 Sep 2021 14:29:34 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

Sean Mullan has updated the pull request incrementally with four additional commits since the last revision:

 - Add some more comments in the PKIX date() and timestamp() methods.
   Remove extra newline from debugging output.
 - Revert "Revert "Initial revision.""
   
   This reverts commit 4601bbb301455a5e35a3e9d691f791972cdd8204.
 - Remove.
 - Revert "Initial revision."
   
   This reverts commit d49ba3f0aaec51768298fe2247f53ffcbeb7c442.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5320/files
  - new: https://git.openjdk.java.net/jdk/pull/5320/files/626f7ed8..d797f32a

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

  Stats: 108 lines in 4 files changed: 8 ins; 96 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5320.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5320/head:pull/5320

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

From aoqi at openjdk.java.net  Sat Sep 18 16:01:03 2021
From: aoqi at openjdk.java.net (Ao Qi)
Date: Sat, 18 Sep 2021 16:01:03 GMT
Subject: RFR: 8273965: some testlibrary_tests/ir_framework tests fail when c1
 disabled
Message-ID: <aFrJVnwvx-jpnkoJZtyqaRZMdiabWEpNa60vihLeHqo=.dcfccc02-36b8-4aac-909e-2c165def7c21@github.com>

These tests failed with c2-only build:

test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompLevels.java
test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestControls.java
test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestRunTests.java

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

Commit messages:
 - 8273965: some testlibrary_tests/ir_framework tests fail when c1 disabled

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

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

From cushon at google.com  Sat Sep 18 22:34:32 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Sat, 18 Sep 2021 15:34:32 -0700
Subject: [External] : Re: String concatenation order of operations
In-Reply-To: <1745626037.2582964.1631885143576.JavaMail.zimbra@u-pem.fr>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
 <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
 <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>
 <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>
 <A691B288-ADFC-430F-B049-0C8F405E8029@oracle.com>
 <1745626037.2582964.1631885143576.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAL4QsgvyvXLwm9=5Nfaj__qX-W8LMOrARQ52bWbaTbv7N5PZxg@mail.gmail.com>

On Wed, Sep 8, 2021 at 3:01 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> The natural way to do this is to have the various arguments passed as real
> stack arguments, causing them to all be evaluated before being pushed
> through the MH nest
>

I'm not sure I understand this part. Aren't non-constant arguments already
being evaluated and passed as stack arguments to the invokedynamic?

On Thu, Sep 16, 2021 at 11:51 PM John Rose <john.r.rose at oracle.com> wrote:

> Wouldn?t be enough for javac to run toString() on arguments that need it,
> and pass those (to the *old* indy mechanism) as strings?
>
> If javac can determine that toString() can be safely delayed (for String
> and primitive boxes, for example) then it doesn?t need to call toString()
> eagerly.
>

That sounds like it'd work to me.

On Fri, Sep 17, 2021 at 6:25 AM Remi Forax <forax at univ-mlv.fr> wrote:

> It will be less efficient because the StringConcatFactory for a primitive
> type does not create the intermediary String objects.
>

Remi isn't that addressed by John's suggestion to skip eagerly calling
toString() for types where it's safe to do so (including primitives and
their boxes, and Strings)?

The main performance disadvantage might be the additional bytecode from the
extra calls to toString (or valueOf, for null-safety), but I'm not sure how
to avoid that and also have the evaluation order required by the spec.

The following patch adds the extra valueOf calls to the indyWithConstants
strategy, and passes tier1 langtools tests (*). If there's interest in
pursuing this approach I can write a test and open a PR.

(*) except for test/langtools/tools/javac/StringConcat/access/Test.java,
which is testing the types of the arguments in the invokedynamic call and
needs updating

diff --git
a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java
index f11054d7302..5a46fd8a468 100644
---
a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java
+++
b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java
@@ -439,10 +439,16 @@ public abstract class StringConcat {
                     } else {
                         // Ordinary arguments come through the dynamic
arguments.
                         recipe.append(TAG_ARG);
-                        dynamicArgs.add(sharpestAccessible(arg.type));
+                        Type argType = sharpestAccessible(arg.type);
                         if (!first || generateFirstArg) {
                             gen.genExpr(arg, arg.type).load();
+                            if
(!types.unboxedTypeOrType(argType).isPrimitive() && argType.tsym !=
syms.stringType.tsym) {
+                                gen.callMethod(pos, syms.stringType,
names.valueOf,
+                                        List.of(syms.objectType), true);
+                                argType = syms.stringType;
+                            }
                         }
+                        dynamicArgs.add(argType);
                         first = false;
                     }
                 }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210918/66c3cd87/attachment.htm>

From brian.goetz at oracle.com  Sun Sep 19 01:11:50 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 18 Sep 2021 21:11:50 -0400
Subject: [External] : Re: String concatenation order of operations
In-Reply-To: <CAL4QsgvyvXLwm9=5Nfaj__qX-W8LMOrARQ52bWbaTbv7N5PZxg@mail.gmail.com>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
 <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
 <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>
 <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>
 <A691B288-ADFC-430F-B049-0C8F405E8029@oracle.com>
 <1745626037.2582964.1631885143576.JavaMail.zimbra@u-pem.fr>
 <CAL4QsgvyvXLwm9=5Nfaj__qX-W8LMOrARQ52bWbaTbv7N5PZxg@mail.gmail.com>
Message-ID: <d197f5ce-5a7c-7753-4735-e19b23b3ba63@oracle.com>



On 9/18/2021 6:34 PM, Liam Miller-Cushon wrote:
> On Wed, Sep 8, 2021 at 3:01 PM Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     The natural way to do this is to have the various arguments passed
>     as real stack arguments, causing them to all be evaluated before
>     being pushed through the MH nest
>
>
> I'm not sure I understand this part. Aren't non-constant arguments 
> already being evaluated and passed as stack arguments to the 
> invokedynamic?

Yes, they are being evaluated, but not toString'ed.? So the compiler 
generates code to evaluate and push all the arguments, and then the 
bootstrap does the toString'ing.? That means that arg #2 is evaluated 
before arg #1 is toString'ed.? For non-string / primitive arguments, the 
compiler would have to emit `invokevirtual Object::toString` for each 
argument as it is pushed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210918/ce664de5/attachment-0001.htm>

From cushon at google.com  Sun Sep 19 01:50:28 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Sat, 18 Sep 2021 18:50:28 -0700
Subject: [External] : Re: String concatenation order of operations
In-Reply-To: <d197f5ce-5a7c-7753-4735-e19b23b3ba63@oracle.com>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
 <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
 <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>
 <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>
 <A691B288-ADFC-430F-B049-0C8F405E8029@oracle.com>
 <1745626037.2582964.1631885143576.JavaMail.zimbra@u-pem.fr>
 <CAL4QsgvyvXLwm9=5Nfaj__qX-W8LMOrARQ52bWbaTbv7N5PZxg@mail.gmail.com>
 <d197f5ce-5a7c-7753-4735-e19b23b3ba63@oracle.com>
Message-ID: <CAL4Qsgs15-C=BxC3DEwJFwZ7K1q-7mHGj=aBwRB_ELOA8M=zbA@mail.gmail.com>

Thanks for the clarification!

I think that's what the patch is doing, then, aside from using
String.valueOf instead of Object.toString.

On Sat, Sep 18, 2021 at 6:12 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> On 9/18/2021 6:34 PM, Liam Miller-Cushon wrote:
>
> On Wed, Sep 8, 2021 at 3:01 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> The natural way to do this is to have the various arguments passed as
>> real stack arguments, causing them to all be evaluated before being pushed
>> through the MH nest
>>
>
> I'm not sure I understand this part. Aren't non-constant arguments already
> being evaluated and passed as stack arguments to the invokedynamic?
>
>
> Yes, they are being evaluated, but not toString'ed.  So the compiler
> generates code to evaluate and push all the arguments, and then the
> bootstrap does the toString'ing.  That means that arg #2 is evaluated
> before arg #1 is toString'ed.  For non-string / primitive arguments, the
> compiler would have to emit `invokevirtual Object::toString` for each
> argument as it is pushed.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210918/04a3358d/attachment.htm>

From john.r.rose at oracle.com  Sun Sep 19 03:33:03 2021
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 19 Sep 2021 03:33:03 +0000
Subject: [External] : Re: String concatenation order of operations
In-Reply-To: <CAL4Qsgs15-C=BxC3DEwJFwZ7K1q-7mHGj=aBwRB_ELOA8M=zbA@mail.gmail.com>
References: <CAL4Qsgt51FS1rwmKUbWum0kqSRLYvhugfbGBzQTzO6RB-gq-1w@mail.gmail.com>
 <9db44a6a-8a66-e1be-105a-2bffb6f425ac@oracle.com>
 <CAL4QsgusO1gSzZQokONYQY4FWmPf0y+CXPvJPmz+kJLbhCqHMQ@mail.gmail.com>
 <e8feed29-5947-7cce-7343-2bb9f0052ada@oracle.com>
 <A691B288-ADFC-430F-B049-0C8F405E8029@oracle.com>
 <1745626037.2582964.1631885143576.JavaMail.zimbra@u-pem.fr>
 <CAL4QsgvyvXLwm9=5Nfaj__qX-W8LMOrARQ52bWbaTbv7N5PZxg@mail.gmail.com>
 <d197f5ce-5a7c-7753-4735-e19b23b3ba63@oracle.com>
 <CAL4Qsgs15-C=BxC3DEwJFwZ7K1q-7mHGj=aBwRB_ELOA8M=zbA@mail.gmail.com>
Message-ID: <63F8076C-5C77-4534-A7A0-91449443AF60@oracle.com>

Yup, S.valueOf is what I meant by toString. Not on primitives of course.

On Sep 18, 2021, at 6:50 PM, Liam Miller-Cushon <cushon at google.com> wrote:

?
Thanks for the clarification!

I think that's what the patch is doing, then, aside from using String.valueOf instead of Object.toString.

On Sat, Sep 18, 2021 at 6:12 PM Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:


On 9/18/2021 6:34 PM, Liam Miller-Cushon wrote:
On Wed, Sep 8, 2021 at 3:01 PM Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:
The natural way to do this is to have the various arguments passed as real stack arguments, causing them to all be evaluated before being pushed through the MH nest

I'm not sure I understand this part. Aren't non-constant arguments already being evaluated and passed as stack arguments to the invokedynamic?

Yes, they are being evaluated, but not toString'ed.  So the compiler generates code to evaluate and push all the arguments, and then the bootstrap does the toString'ing.  That means that arg #2 is evaluated before arg #1 is toString'ed.  For non-string / primitive arguments, the compiler would have to emit `invokevirtual Object::toString` for each argument as it is pushed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210919/24ccd62c/attachment.htm>

From dholmes at openjdk.java.net  Sun Sep 19 13:15:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 19 Sep 2021 13:15:51 GMT
Subject: RFR: 8273314: Add tier4 test groups [v4]
In-Reply-To: <v2nomvkJIgNeqXOXNwt4sG0ec0zWK6CyLK-eLwINsjY=.2642ee46-10de-4db4-87f2-06aa62082c84@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <v2nomvkJIgNeqXOXNwt4sG0ec0zWK6CyLK-eLwINsjY=.2642ee46-10de-4db4-87f2-06aa62082c84@github.com>
Message-ID: <T99Obzi6HM97SwHttKr0w3dzAWegJFSNfDKRhoUO0GA=.3810c105-a968-4f47-aaf5-bd37b5bb8cef@github.com>

On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. 
>> 
>> Caveats:
>>  - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>>  - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel
>> 
>> Sample run with `JTREG_KEYWORDS=!headful`:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                     3585  3584     0     1 <<
>>>> jtreg:test/jdk:tier4                               2893  2887     5     1 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	699m39.462s
>> user	6626m8.448s
>> sys	1110m43.704s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8273314-tier4
>  - Merge branch 'master' into JDK-8273314-tier4
>  - Drop applications and fix the comment
>  - Drop exceptions
>  - Add tier4 test groups

I abstain - you have your reviews.

Cheers,
David

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

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

From shade at openjdk.java.net  Mon Sep 20 07:40:59 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 20 Sep 2021 07:40:59 GMT
Subject: RFR: 8273314: Add tier4 test groups [v4]
In-Reply-To: <v2nomvkJIgNeqXOXNwt4sG0ec0zWK6CyLK-eLwINsjY=.2642ee46-10de-4db4-87f2-06aa62082c84@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
 <v2nomvkJIgNeqXOXNwt4sG0ec0zWK6CyLK-eLwINsjY=.2642ee46-10de-4db4-87f2-06aa62082c84@github.com>
Message-ID: <Ga-stxhASjNxn5kSkJOlfN89MUq_1NqmY2K0PxekEwc=.e5c8e451-ee14-43a5-a26a-cc1aa898c810@github.com>

On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. 
>> 
>> Caveats:
>>  - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>>  - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel
>> 
>> Sample run with `JTREG_KEYWORDS=!headful`:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier4                     3585  3584     0     1 <<
>>>> jtreg:test/jdk:tier4                               2893  2887     5     1 <<
>>    jtreg:test/langtools:tier4                            0     0     0     0   
>>    jtreg:test/jaxp:tier4                                 0     0     0     0   
>> ==============================
>> 
>> real	699m39.462s
>> user	6626m8.448s
>> sys	1110m43.704s
>> 
>> 
>> There are interesting test failures on my machine, which I would address separately.
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8273314-tier4
>  - Merge branch 'master' into JDK-8273314-tier4
>  - Drop applications and fix the comment
>  - Drop exceptions
>  - Add tier4 test groups

All right, there goes.

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

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

From mcimadamore at openjdk.java.net  Mon Sep 20 09:50:19 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 09:50:19 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces [v3]
In-Reply-To: <SFZyyzA0of6ZvYi6I2hgrrwk4iVSx-wWWPQ07zJt-sM=.92ca546b-e064-4def-9f2d-10abca6f63b4@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
 <SFZyyzA0of6ZvYi6I2hgrrwk4iVSx-wWWPQ07zJt-sM=.92ca546b-e064-4def-9f2d-10abca6f63b4@github.com>
Message-ID: <PMlWWUxmAeQ4RyZV0MMmq6RsyRRN6Kk2kilFRwPJUc4=.11bce306-1d91-44a1-af05-d9d79463af27@github.com>

On Thu, 9 Sep 2021 11:14:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider these declarations:
>> 
>>     interface I {
>>         public String toString();
>>     }
>>     interface J extends I {}
>> 
>> 
>> There are two issues with the `toString` inherited from `I` into `J`:
>> -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
>> -as a slightly less problematic case, consider:
>> 
>> I i = null;
>> i.toString(); //AST and classfile contain call to I.toString()
>> J j = null;
>> j.toString(); //AST and classfile contain call to j.l.Object.toString()
>> 
>> 
>> I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments.

I think we can go ahead for now. Thanks.

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

Marked as reviewed by mcimadamore (Reviewer).

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

From jlahoda at openjdk.java.net  Mon Sep 20 13:48:15 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 20 Sep 2021 13:48:15 GMT
Subject: Integrated: 8259039: Passing different version to --release flag than
 javac version output warning
In-Reply-To: <z2rJBSptf2E3VUduC_2UCZvtduZOiNTeCsUu5W53x8c=.41ebb396-a5be-40cc-a149-e78ed0ff5d8e@github.com>
References: <z2rJBSptf2E3VUduC_2UCZvtduZOiNTeCsUu5W53x8c=.41ebb396-a5be-40cc-a149-e78ed0ff5d8e@github.com>
Message-ID: <7SNCja3ri4Wy0k0HTbsc-gCG9bL0AjeUguVz-kgX3cs=.5449fd75-40b5-4f62-aec1-22b1a53b2891@github.com>

On Mon, 9 Aug 2021 13:33:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like:
> 
> com.sun.nio.file.ExtendedOpenOption o;
> 
> 
> certain combination of command line options produce a proprietary warnings:
> 
> $ javac --release 11 T.java 
> T.java:2: warning: ExtendedOpenOption is internal proprietary API and may be removed in a future release
>     com.sun.nio.file.ExtendedOpenOption o;
>                     ^
> 1 warning
> 
> 
> But some do not:
> 
> $ javac -source 8 T.java 
> warning: [options] bootstrap class path not set in conjunction with -source 8
> 1 warning
> 
> 
> The reason is that the `ct.properties` files does not mark `com.sun.nio.file` as proprietary. The proposed fix has two parts:
> -adds `proprietary` to the `com.sun.nio.file` package in `ct.properties`
> -limits the `ct.properties` so that it is only used for `-source 8`. The `ct.properties` contains 3 types of information: it hides some packages, it marks some packages as "proprietary" (so that they produce the warning), and assigns packages to compact profiles. For `-source 9+`, most of these is not needed - packages are hidden using the module system, the only packages that need a warning are from the `jdk.unsupported` module, and there are no compact profiles. So for `-source 9+`, we don't need to use the `ct.properties`. (Note none of this applies to `--release` - it uses a different database.)

This pull request has now been integrated.

Changeset: 699865f7
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/699865f76cdf76fbd8042c1b5677b71e29faa4bc
Stats:     162 lines in 4 files changed: 152 ins; 4 del; 6 mod

8259039: Passing different version to --release flag than javac version output warning

Reviewed-by: jjg

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

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

From shade at openjdk.java.net  Mon Sep 20 14:07:06 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 20 Sep 2021 14:07:06 GMT
Subject: Integrated: 8273314: Add tier4 test groups
In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com>
Message-ID: <2EIwJmplZv9-2ffL0Ye4pf3tgPEsx7HPhu-oM54T8Hk=.129e646b-333d-4ba1-b65d-ddd9ca731d2a@github.com>

On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. 
> 
> Caveats:
>  - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress).
>  - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel
> 
> Sample run with `JTREG_KEYWORDS=!headful`:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:tier4                     3585  3584     0     1 <<
>>> jtreg:test/jdk:tier4                               2893  2887     5     1 <<
>    jtreg:test/langtools:tier4                            0     0     0     0   
>    jtreg:test/jaxp:tier4                                 0     0     0     0   
> ==============================
> 
> real	699m39.462s
> user	6626m8.448s
> sys	1110m43.704s
> 
> 
> There are interesting test failures on my machine, which I would address separately.

This pull request has now been integrated.

Changeset: 1f8af524
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1f8af524ffe2d2d1469d8f07887b1f61c6e4d7b8
Stats:     20 lines in 4 files changed: 20 ins; 0 del; 0 mod

8273314: Add tier4 test groups

Reviewed-by: serb, iignatyev

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

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

From mullan at openjdk.java.net  Mon Sep 20 15:18:28 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 15:18:28 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v3]
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <FTDDhQon5eFfKzmRQWWld8sWff0J0Jj7uKWbCfuQFtY=.bf1611ba-adac-451e-a5d1-6f0242612ca6@github.com>

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Add back DynStatic.java test which was accidentally removed in prior commit.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5320/files
  - new: https://git.openjdk.java.net/jdk/pull/5320/files/d797f32a..ae1ea608

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

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

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

From mullan at openjdk.java.net  Mon Sep 20 15:35:56 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 15:35:56 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v4]
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <aEI2KvKcHxvwu0XXHjRRPq8ycLIVod8XSDhR6R-KElA=.9b8de5c8-cb2d-4464-b8f2-8fe44fea4da4@github.com>

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Remove trailing whitespace.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5320/files
  - new: https://git.openjdk.java.net/jdk/pull/5320/files/ae1ea608..ee2d3080

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

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

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

From weijun at openjdk.java.net  Mon Sep 20 15:35:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 20 Sep 2021 15:35:57 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
 <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
Message-ID: <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>

On Fri, 17 Sep 2021 14:29:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
>> 
>> Some additional notes about the fix:
>> 
>> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.
>
> Sean Mullan has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add some more comments in the PKIX date() and timestamp() methods.
>    Remove extra newline from debugging output.
>  - Revert "Revert "Initial revision.""
>    
>    This reverts commit 4601bbb301455a5e35a3e9d691f791972cdd8204.
>  - Remove.
>  - Revert "Initial revision."
>    
>    This reverts commit d49ba3f0aaec51768298fe2247f53ffcbeb7c442.

Marked as reviewed by weijun (Reviewer).

src/java.base/share/classes/sun/security/provider/certpath/PKIX.java line 228:

> 226:             }
> 227:             return timestampDate;
> 228:         }

Can we also add some words to the `date()` method? Something which tells the major difference between it and `timestamp()`?

src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java line 114:

> 112: 
> 113:     // extract last certificate and key from chain
> 114:     private void init(CertPath cp) {

The `init` name suggests it's only done once at the beginning, but actually it's an accumulation process. Can we find another name?

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

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

From vromero at openjdk.java.net  Mon Sep 20 15:37:06 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 20 Sep 2021 15:37:06 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces [v3]
In-Reply-To: <SFZyyzA0of6ZvYi6I2hgrrwk4iVSx-wWWPQ07zJt-sM=.92ca546b-e064-4def-9f2d-10abca6f63b4@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
 <SFZyyzA0of6ZvYi6I2hgrrwk4iVSx-wWWPQ07zJt-sM=.92ca546b-e064-4def-9f2d-10abca6f63b4@github.com>
Message-ID: <HGUL-__ZXpVLg5YUM1tQdP8prOUR0jtKr876cAzd9JU=.3ba7d7c4-26ed-4f58-b4b2-f7582d0802c4@github.com>

On Thu, 9 Sep 2021 11:14:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider these declarations:
>> 
>>     interface I {
>>         public String toString();
>>     }
>>     interface J extends I {}
>> 
>> 
>> There are two issues with the `toString` inherited from `I` into `J`:
>> -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
>> -as a slightly less problematic case, consider:
>> 
>> I i = null;
>> i.toString(); //AST and classfile contain call to I.toString()
>> J j = null;
>> j.toString(); //AST and classfile contain call to j.l.Object.toString()
>> 
>> 
>> I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

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

From prappo at openjdk.java.net  Mon Sep 20 17:01:20 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 20 Sep 2021 17:01:20 GMT
Subject: RFR: 8266666: Implementation for snippets [v25]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <SOTXueIAEC9anA5iVDJ0kdAyM60Uqkrh62bBpLzWJbw=.49d98750-dd35-41e6-b35b-7d90adc54dad@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge branch 'master' into 8266666
 - Improve markup error messages
   
    * Cleans up error string format
    * Internationalizes error messages, mapping them to fewer resource keys
    * Fixes a few bugs related to error messages, including: inaccurate caret positioning and runaway resource name (i.e. the resource key wasn't translated into an error)
 - Merge branch 'master' into 8266666
 - Address trivial feedback
 - Address feedback
   
   1. Reverts changes from CommentUtils.java (unused methods)
   2. Changes misguided regex-related assertion to tests
 - Remove trailing whitespace to satisfy jcheck
 - Clean up code
   
   Removes stale FIXMEs, TODOs and comments; downgrades FIXMEs to TODOs where possible; wraps overly long lines.
 - Merge branch 'master' into 8266666
 - Merge branch 'master' into 8266666
 - Refactor SnippetTaglet
   
   Improves code style; reformats.
 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/4b3a4fff...edb7cf85

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

Changes: https://git.openjdk.java.net/jdk/pull/4795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=24
  Stats: 5208 lines in 43 files changed: 5183 ins; 4 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

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

From mullan at openjdk.java.net  Mon Sep 20 17:09:58 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 17:09:58 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
 <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
 <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
Message-ID: <x1UpCUnn27YAH61YLuyargOOKDIUzItu3s1AOGFNag0=.05ddbd95-b8bc-4168-8af6-20fe482847d9@github.com>

On Mon, 20 Sep 2021 14:28:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add some more comments in the PKIX date() and timestamp() methods.
>>    Remove extra newline from debugging output.
>>  - Revert "Revert "Initial revision.""
>>    
>>    This reverts commit 4601bbb301455a5e35a3e9d691f791972cdd8204.
>>  - Remove.
>>  - Revert "Initial revision."
>>    
>>    This reverts commit d49ba3f0aaec51768298fe2247f53ffcbeb7c442.
>
> src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java line 114:
> 
>> 112: 
>> 113:     // extract last certificate and key from chain
>> 114:     private void init(CertPath cp) {
> 
> The `init` name suggests it's only done once at the beginning, but actually it's an accumulation process. Can we find another name?

I have renamed it to `addToCertsAndKeys`.

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

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

From mullan at openjdk.java.net  Mon Sep 20 17:26:12 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 17:26:12 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v5]
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <Hy4f-DylhuKZW71A3TJtLCromRd-PXQMthdhlAETKjY=.4cfc12d4-364c-467c-bbe2-192d1ea2eefc@github.com>

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Rename JarConstraintsParameter.init to addToCertsAndKeys. Add more comments
  describing PKIX date() method.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5320/files
  - new: https://git.openjdk.java.net/jdk/pull/5320/files/ee2d3080..3f942e52

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

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

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

From mullan at openjdk.java.net  Mon Sep 20 17:30:49 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 20 Sep 2021 17:30:49 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
 <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
 <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
Message-ID: <4iNZ_0FIYPpNq9JTCYUcuaCfZJa5vNVqljZjzmljoYk=.4c26869d-2109-487e-896e-5d88273d202b@github.com>

On Mon, 20 Sep 2021 14:32:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add some more comments in the PKIX date() and timestamp() methods.
>>    Remove extra newline from debugging output.
>>  - Revert "Revert "Initial revision.""
>>    
>>    This reverts commit 4601bbb301455a5e35a3e9d691f791972cdd8204.
>>  - Remove.
>>  - Revert "Initial revision."
>>    
>>    This reverts commit d49ba3f0aaec51768298fe2247f53ffcbeb7c442.
>
> src/java.base/share/classes/sun/security/provider/certpath/PKIX.java line 228:
> 
>> 226:             }
>> 227:             return timestampDate;
>> 228:         }
> 
> Can we also add some words to the `date()` method? Something which tells the major difference between it and `timestamp()`?

Done - see latest commit.

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

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

From vromero at openjdk.java.net  Mon Sep 20 19:12:11 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 20 Sep 2021 19:12:11 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface
Message-ID: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>

Please review this PR, which is my proposal to fix an existing regression. This code:


import java.util.Optional;

class App {
    public static void main(String[] args) {
        Optional.of("").map(outer -> {
            Optional.of("")
                .map(inner -> returnGeneric(outer))
                .ifPresent(String::toString);
            return "";
        });
    }

    private static <RG> RG returnGeneric(RG generic) {
        return generic;
    }
}

is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?

TIA

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

Commit messages:
 - 8268312: Compilation error with nested generic functional interface

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

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

From weijun at openjdk.java.net  Mon Sep 20 21:43:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 20 Sep 2021 21:43:19 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs [v2]
In-Reply-To: <4iNZ_0FIYPpNq9JTCYUcuaCfZJa5vNVqljZjzmljoYk=.4c26869d-2109-487e-896e-5d88273d202b@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
 <Ce0CsRCGOnKnf8AtnSreX8HOIn4i5dkiC_BxEYszAJo=.470cad3b-595e-4b69-b8a0-5efc9733839f@github.com>
 <fMTDS2_NuEGFMbwMI4N0TD9rpj_TTmdWKOOc48PM55M=.afb54d9d-632c-48de-beb7-0e30fe155eec@github.com>
 <4iNZ_0FIYPpNq9JTCYUcuaCfZJa5vNVqljZjzmljoYk=.4c26869d-2109-487e-896e-5d88273d202b@github.com>
Message-ID: <--rx7zLzVnvYXqRJl6-b-I9UWEo9L0GL4EL_4mii3dw=.76673de1-d3c8-4730-a023-008f355a2a71@github.com>

On Mon, 20 Sep 2021 17:27:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/PKIX.java line 228:
>> 
>>> 226:             }
>>> 227:             return timestampDate;
>>> 228:         }
>> 
>> Can we also add some words to the `date()` method? Something which tells the major difference between it and `timestamp()`?
>
> Done - see latest commit.

All is good. No any other comment.

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

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

From jjg at openjdk.java.net  Tue Sep 21 02:11:56 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 21 Sep 2021 02:11:56 GMT
Subject: RFR: 8266666: Implementation for snippets [v25]
In-Reply-To: <SOTXueIAEC9anA5iVDJ0kdAyM60Uqkrh62bBpLzWJbw=.49d98750-dd35-41e6-b35b-7d90adc54dad@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <SOTXueIAEC9anA5iVDJ0kdAyM60Uqkrh62bBpLzWJbw=.49d98750-dd35-41e6-b35b-7d90adc54dad@github.com>
Message-ID: <3unQUiVLJ-exIVZLZ4hXNU9GSl1lU6w_Zs7nfbTKvh8=.e37e34d6-41bd-4a70-94ed-adb3580d2cdf@github.com>

On Mon, 20 Sep 2021 17:01:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'master' into 8266666
>  - Improve markup error messages
>    
>     * Cleans up error string format
>     * Internationalizes error messages, mapping them to fewer resource keys
>     * Fixes a few bugs related to error messages, including: inaccurate caret positioning and runaway resource name (i.e. the resource key wasn't translated into an error)
>  - Merge branch 'master' into 8266666
>  - Address trivial feedback
>  - Address feedback
>    
>    1. Reverts changes from CommentUtils.java (unused methods)
>    2. Changes misguided regex-related assertion to tests
>  - Remove trailing whitespace to satisfy jcheck
>  - Clean up code
>    
>    Removes stale FIXMEs, TODOs and comments; downgrades FIXMEs to TODOs where possible; wraps overly long lines.
>  - Merge branch 'master' into 8266666
>  - Merge branch 'master' into 8266666
>  - Refactor SnippetTaglet
>    
>    Improves code style; reformats.
>  - ... and 27 more: https://git.openjdk.java.net/jdk/compare/4b3a4fff...edb7cf85

My primary concern in the last round of review was internationalization. You've addressed that: good.

When reading, and re-reading, a contribution this big, it's always possible to see new tiny details that could be improved. I've mentioned some here, and I'm sure that in times to come we will look at the code more and maybe see more tweaks. So, enough for now. Well done.

I note the varied references to improve JavadocTester.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 400:

> 398: # 0: path; 1: exception
> 399: doclet.error_setting_snippet_path=\
> 400:   Error setting snippet path {0}: {1}

Add newline at end of file

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java line 220:

> 218:         switch (ch) {
> 219:             case ':': // indicates that the instruction relates to the next line
> 220:             case ' ': case '\t':

What about other whitespace? Is that already covered?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/ParseException.java line 35:

> 33:  * This exception is only used to capture a user-facing error message.
> 34:  * The message supplier is accepted not to control when to obtain a message,
> 35:  * but to abstract how to obtain in.

typo "in"?  maybe "one" or "it"?

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 88:

> 86:     /*
> 87:      * While the "id" and "lang" attributes are advertised in JEP 413, they are
> 88:      * currently unused by the implementation. The goal of this test is to make

id's should be propagated to the output HTML

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 149:

> 147:                 {@snippet id=:
> 148:                     Hello, Snippet!
> 149:                 }

empty ids should be rejected.

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 473:

> 471:         // out of order with respect to the errors checked above.
> 472:         // This is because the below errors are modelled as exceptions thrown
> 473:         // at parse time, when there are no doc trees yet. And the above errors

This would read better as "the errors below" and "the errors above"
https://www.grammarphobia.com/blog/2012/12/below.html

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 608:

> 606:             failed("Looks like a stacktrace: " + matcher.group());
> 607:         }
> 608:     }

This could maybe be promoted to a default-enabled check in JavadocTester

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 1201:

> 1199: 
> 1200:     // TODO: perhaps this method could be added to JavadocTester
> 1201:     private void checkOutputEither(Output out, String first, String... other) {

1. This method allows a call with just a single String arg.
2. Given that the method allows many String args, the name might be better as `checkOneOf`

Note to self/@jonathan-gibbons: review all references for suggestions to JavadocTester

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

Marked as reviewed by jjg (Reviewer).

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

From prappo at openjdk.java.net  Tue Sep 21 10:58:26 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 10:58:26 GMT
Subject: RFR: 8266666: Implementation for snippets [v26]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <mZQwNAVOSiSJo_A0mZLbrHEGqK46L7vxFtEILB07N9M=.2fbff90a-6600-4d91-8a35-cf261fe6f21f@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

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

  Address feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/edb7cf85..884dcb00

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=24-25

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

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

From prappo at openjdk.java.net  Tue Sep 21 10:58:31 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 10:58:31 GMT
Subject: RFR: 8266666: Implementation for snippets [v25]
In-Reply-To: <SOTXueIAEC9anA5iVDJ0kdAyM60Uqkrh62bBpLzWJbw=.49d98750-dd35-41e6-b35b-7d90adc54dad@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <SOTXueIAEC9anA5iVDJ0kdAyM60Uqkrh62bBpLzWJbw=.49d98750-dd35-41e6-b35b-7d90adc54dad@github.com>
Message-ID: <V8hYqdiUD7XxJsa4lx4DnD_7KMW16Y-f6OkBoR3fuEU=.f3aa7d0a-72c5-46ef-b476-dfe8ee33f3d5@github.com>

On Mon, 20 Sep 2021 17:01:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'master' into 8266666
>  - Improve markup error messages
>    
>     * Cleans up error string format
>     * Internationalizes error messages, mapping them to fewer resource keys
>     * Fixes a few bugs related to error messages, including: inaccurate caret positioning and runaway resource name (i.e. the resource key wasn't translated into an error)
>  - Merge branch 'master' into 8266666
>  - Address trivial feedback
>  - Address feedback
>    
>    1. Reverts changes from CommentUtils.java (unused methods)
>    2. Changes misguided regex-related assertion to tests
>  - Remove trailing whitespace to satisfy jcheck
>  - Clean up code
>    
>    Removes stale FIXMEs, TODOs and comments; downgrades FIXMEs to TODOs where possible; wraps overly long lines.
>  - Merge branch 'master' into 8266666
>  - Merge branch 'master' into 8266666
>  - Refactor SnippetTaglet
>    
>    Improves code style; reformats.
>  - ... and 27 more: https://git.openjdk.java.net/jdk/compare/4b3a4fff...edb7cf85

Thanks for approving the change, Jon. Some of your suggestions are added to 884dcb00d74.

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

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

From prappo at openjdk.java.net  Tue Sep 21 10:58:38 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 10:58:38 GMT
Subject: RFR: 8266666: Implementation for snippets [v25]
In-Reply-To: <3unQUiVLJ-exIVZLZ4hXNU9GSl1lU6w_Zs7nfbTKvh8=.e37e34d6-41bd-4a70-94ed-adb3580d2cdf@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <SOTXueIAEC9anA5iVDJ0kdAyM60Uqkrh62bBpLzWJbw=.49d98750-dd35-41e6-b35b-7d90adc54dad@github.com>
 <3unQUiVLJ-exIVZLZ4hXNU9GSl1lU6w_Zs7nfbTKvh8=.e37e34d6-41bd-4a70-94ed-adb3580d2cdf@github.com>
Message-ID: <XxhzXb_SEcm8wacDMziMYeP70YWB2Cc8dAWgUhxv2q0=.1170ad8d-9292-4887-8269-29465bf43a02@github.com>

On Tue, 21 Sep 2021 01:33:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge branch 'master' into 8266666
>>  - Improve markup error messages
>>    
>>     * Cleans up error string format
>>     * Internationalizes error messages, mapping them to fewer resource keys
>>     * Fixes a few bugs related to error messages, including: inaccurate caret positioning and runaway resource name (i.e. the resource key wasn't translated into an error)
>>  - Merge branch 'master' into 8266666
>>  - Address trivial feedback
>>  - Address feedback
>>    
>>    1. Reverts changes from CommentUtils.java (unused methods)
>>    2. Changes misguided regex-related assertion to tests
>>  - Remove trailing whitespace to satisfy jcheck
>>  - Clean up code
>>    
>>    Removes stale FIXMEs, TODOs and comments; downgrades FIXMEs to TODOs where possible; wraps overly long lines.
>>  - Merge branch 'master' into 8266666
>>  - Merge branch 'master' into 8266666
>>  - Refactor SnippetTaglet
>>    
>>    Improves code style; reformats.
>>  - ... and 27 more: https://git.openjdk.java.net/jdk/compare/4b3a4fff...edb7cf85
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 400:
> 
>> 398: # 0: path; 1: exception
>> 399: doclet.error_setting_snippet_path=\
>> 400:   Error setting snippet path {0}: {1}
> 
> Add newline at end of file

Although it wasn't there to begin with, adding it won't be as big a deal as reformatting code in other places you suggested earlier.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java line 220:
> 
>> 218:         switch (ch) {
>> 219:             case ':': // indicates that the instruction relates to the next line
>> 220:             case ' ': case '\t':
> 
> What about other whitespace? Is that already covered?

Which other whitespace? If you are talking about `\r` or `\n`, then the string parsed by `MarkupParser` cannot have those. `MarkupParser` gets a single line without a trailing line terminator.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/ParseException.java line 35:
> 
>> 33:  * This exception is only used to capture a user-facing error message.
>> 34:  * The message supplier is accepted not to control when to obtain a message,
>> 35:  * but to abstract how to obtain in.
> 
> typo "in"?  maybe "one" or "it"?

Good catch! It should've been "it".

> test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 88:
> 
>> 86:     /*
>> 87:      * While the "id" and "lang" attributes are advertised in JEP 413, they are
>> 88:      * currently unused by the implementation. The goal of this test is to make
> 
> id's should be propagated to the output HTML

About empty id's and propagating id's to the output HTML. I think we can address these in a follow-up issue. Would you be okay with it?

> test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 473:
> 
>> 471:         // out of order with respect to the errors checked above.
>> 472:         // This is because the below errors are modelled as exceptions thrown
>> 473:         // at parse time, when there are no doc trees yet. And the above errors
> 
> This would read better as "the errors below" and "the errors above"
> https://www.grammarphobia.com/blog/2012/12/below.html

Thanks.

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

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

From jlahoda at openjdk.java.net  Tue Sep 21 11:14:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 21 Sep 2021 11:14:06 GMT
Subject: RFR: 8270139: jshell InternalError crash for import of @Repeatable
 followed by unresolved ref
Message-ID: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>

For code like:

import java.lang.annotation.Repeatable;
@Repeatable(TestContainer.class)
@interface Test { int value(); }


javac crashes like this:

$ javac -XDdev /tmp/Test.java

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

Commit messages:
 - 8270139: jshell InternalError crash for import of @Repeatable followed by unresolved ref

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

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

From prappo at openjdk.java.net  Tue Sep 21 13:25:19 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 13:25:19 GMT
Subject: RFR: 8266666: Implementation for snippets [v27]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <GmZfA87me2md3Y5X7vXz4mDd5TCAWguHMAbuh-NCE-w=.1c43ff16-a657-478e-acbe-05c0b05bf410@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

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

 - Merge branch 'master' into 8266666
 - Use bug id, not JEP id
 - Address feedback
 - Merge branch 'master' into 8266666
 - Improve markup error messages
   
    * Cleans up error string format
    * Internationalizes error messages, mapping them to fewer resource keys
    * Fixes a few bugs related to error messages, including: inaccurate caret positioning and runaway resource name (i.e. the resource key wasn't translated into an error)
 - Merge branch 'master' into 8266666
 - Address trivial feedback
 - Address feedback
   
   1. Reverts changes from CommentUtils.java (unused methods)
   2. Changes misguided regex-related assertion to tests
 - Remove trailing whitespace to satisfy jcheck
 - Clean up code
   
   Removes stale FIXMEs, TODOs and comments; downgrades FIXMEs to TODOs where possible; wraps overly long lines.
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/afd218d3...a7299d8f

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

Changes: https://git.openjdk.java.net/jdk/pull/4795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=26
  Stats: 5208 lines in 43 files changed: 5183 ins; 4 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

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

From mullan at openjdk.java.net  Tue Sep 21 13:49:35 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 21 Sep 2021 13:49:35 GMT
Subject: Integrated: 8269039: Disable SHA-1 Signed JARs
In-Reply-To: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
References: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>
Message-ID: <CBCQBBUQuz9TQb2V4_dhINWaJYlo-Y9_OLkaLgKpA4A=.59952170-c2a2-4d1e-beb8-d233d8b97018@github.com>

On Tue, 31 Aug 2021 18:53:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.
> 
> Some additional notes about the fix:
> 
> - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
>     - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
>     - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
>  - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
>  - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

This pull request has now been integrated.

Changeset: 6d91a3eb
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6d91a3eb7bd1e1403cfb67f7eb8ce06d7e08e7a7
Stats:     666 lines in 27 files changed: 314 ins; 214 del; 138 mod

8269039: Disable SHA-1 Signed JARs

Reviewed-by: weijun

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

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

From prappo at openjdk.java.net  Tue Sep 21 15:56:46 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 21 Sep 2021 15:56:46 GMT
Subject: Integrated: 8266666: Implementation for snippets
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <cjkdaJycrkEgQjZ-tq081jt1ubzfKN2wJUXGc6bzHWM=.f345bce1-ae33-45fe-931d-04877a0ac4fc@github.com>

On Thu, 15 Jul 2021 14:13:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

This pull request has now been integrated.

Changeset: 0fc47e99
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0fc47e99d20a1ee886df878f1302769bdd913aab
Stats:     5208 lines in 43 files changed: 5183 ins; 4 del; 21 mod

8266666: Implementation for snippets

Co-authored-by: Jonathan Gibbons <jjg at openjdk.org>
Co-authored-by: Hannes Walln?fer <hannesw at openjdk.org>
Reviewed-by: jjg

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

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

From vromero at openjdk.java.net  Tue Sep 21 16:42:34 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 21 Sep 2021 16:42:34 GMT
Subject: RFR: 8270139: jshell InternalError crash for import of
 @Repeatable followed by unresolved ref
In-Reply-To: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>
References: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>
Message-ID: <t4jahqAbnjfuJGLKGqaL5g_DD0cF0taPk00jocZXzzo=.0e1a71b2-7dca-4c13-a7df-9d5bf3f2377b@github.com>

On Tue, 21 Sep 2021 11:05:45 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like:
> 
> import java.lang.annotation.Repeatable;
> @Repeatable(TestContainer.class)
> @interface Test { int value(); }
> 
> 
> javac crashes like this:
> 
> $ javac -XDdev /tmp/Test.java

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

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

From jjg at openjdk.java.net  Tue Sep 21 21:42:56 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 21 Sep 2021 21:42:56 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree
In-Reply-To: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
Message-ID: <TAvMRIr5ADYsxfpsWwmG0-j4UUJq1reA_OJ4T1C8LaI=.cf40f195-2a15-4d6a-a1cb-7359bb975ed6@github.com>

On Tue, 14 Sep 2021 16:05:41 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world.
> 
> ## Previously ...
> 
> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class.  (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.)  The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available.
> 
> ## Now ... 
> 
> All `DCTree` nodes have 4 positions, 3 publicly available.
> * the position of the first unique character, `pos`
> * the starting position of the range of characters, `getStartPosition()`
> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()`
> * the end position of the range of characters, `getEndPosition()`.
> These are all relative to the beginning of the comment text, and are converted to file positions as needed.
> 
> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods.
> 
> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic.
> 
> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods.
> 
> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified.
> 
> ## Testing ...
> 
> Up until the point at which `DCTree.pos` was modified, all tests passed without change.   When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated.
> 
> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker`  which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue.
> 
> ## Behavior ...
> 
> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`.  This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work.  Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 295:

> 293:     t.printStackTrace();
> 294:     throw t;
> 295: }

This needs to be reverted.

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

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

From jjg at openjdk.java.net  Tue Sep 21 22:20:07 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 21 Sep 2021 22:20:07 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v2]
In-Reply-To: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
Message-ID: <nd3U4Jd_Pg-ITmoueijIGX-T2vAiOBwmbWDKp0Vqdu8=.a0dfaca7-20ee-4320-ad65-8bda801660e1@github.com>

> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world.
> 
> ## Previously ...
> 
> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class.  (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.)  The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available.
> 
> ## Now ... 
> 
> All `DCTree` nodes have 4 positions, 3 publicly available.
> * the position of the first unique character, `pos`
> * the starting position of the range of characters, `getStartPosition()`
> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()`
> * the end position of the range of characters, `getEndPosition()`.
> These are all relative to the beginning of the comment text, and are converted to file positions as needed.
> 
> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods.
> 
> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic.
> 
> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods.
> 
> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified.
> 
> ## Testing ...
> 
> Up until the point at which `DCTree.pos` was modified, all tests passed without change.   When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated.
> 
> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker`  which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue.
> 
> ## Behavior ...
> 
> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`.  This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work.  Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  revert unrelated debug edit

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5510/files
  - new: https://git.openjdk.java.net/jdk/pull/5510/files/4a485168..4ddc0aaf

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

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

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

From prappo at openjdk.java.net  Wed Sep 22 12:45:58 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 22 Sep 2021 12:45:58 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v2]
In-Reply-To: <nd3U4Jd_Pg-ITmoueijIGX-T2vAiOBwmbWDKp0Vqdu8=.a0dfaca7-20ee-4320-ad65-8bda801660e1@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <nd3U4Jd_Pg-ITmoueijIGX-T2vAiOBwmbWDKp0Vqdu8=.a0dfaca7-20ee-4320-ad65-8bda801660e1@github.com>
Message-ID: <OtcR7_ubTp4uMytjY4iNZroQl8CaCHuJZW4RmgtbqqE=.147a0d1e-d2df-427c-bcc7-05898d3497ca@github.com>

On Tue, 21 Sep 2021 22:20:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world.
>> 
>> ## Previously ...
>> 
>> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class.  (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.)  The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available.
>> 
>> ## Now ... 
>> 
>> All `DCTree` nodes have 4 positions, 3 publicly available.
>> * the position of the first unique character, `pos`
>> * the starting position of the range of characters, `getStartPosition()`
>> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()`
>> * the end position of the range of characters, `getEndPosition()`.
>> These are all relative to the beginning of the comment text, and are converted to file positions as needed.
>> 
>> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods.
>> 
>> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic.
>> 
>> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods.
>> 
>> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified.
>> 
>> ## Testing ...
>> 
>> Up until the point at which `DCTree.pos` was modified, all tests passed without change.   When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated.
>> 
>> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker`  which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue.
>> 
>> ## Behavior ...
>> 
>> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`.  This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work.  Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert unrelated debug edit

As this PR contains a lot clean-up changes and improvements, it will take me extra time to review it. Here's the first batch of comments.

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 269:

> 267:                     DCTree dcTree = (DCTree) tree;
> 268:                     if (dcComment.getSourcePosition(dcTree.getEndPosition()) == 0) {
> 269:                         System.err.println("WARNING: comment:" + dcComment.comment + ": " + dcTree.getKind() + " end:" + dcTree.getEndPosition() + " result: " + dcComment.getSourcePosition(dcTree.getEndPosition()));

This looks like a leftover debugging aid.

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

> 969:     /**
> 970:      * Creates an {@code ErroneousTree} node, for a range of text starting at a given position,
> 971:      * ending at the last non-white character before the current position,

In this file and in JDK overall, such characters as predominantly called "non-whitespace".

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

> 983:     /**
> 984:      * Creates an {@code ErroneousTree} node, for a range of text starting at a given position,
> 985:      * ending at the last non-white character before the current position,

ditto

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

> 984:      * Creates an {@code ErroneousTree} node, for a range of text starting at a given position,
> 985:      * ending at the last non-white character before the current position,
> 986:      * and with a given preferred position

Add full stop.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ReferenceParser.java line 124:

> 122:             moduleName = switch (slash) {
> 123:                 case -1 -> null;
> 124:                 case 0 -> throw new ParseException(0, "dc.ref.syntax.error");

There's a slight change in error output. Although it is likely insignificant, I felt I should note it. For example, compare the error output for `{@link //java.lang.Object}`.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 74:

> 72:  * </ul>
> 73:  *
> 74:  * All are values relative to the beginning of the

Transposition error? "All values are relative..."

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 88:

> 86:     /**
> 87:      * The position of the first character that is unique to this node.
> 88:      * It is normally set by the methods in {@link DocTreeMaker}.

Since this change also includes cleanup, we might as well fix "the the" and "non-white space" at DocTreeMaker.java:699.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 161:

> 159:         }
> 160: 
> 161:         switch (getKind()) {

This switch might become even better after "Pattern Matching for switch" has been integrated (currently in preview, JEP 406).

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 265:

> 263:      * {@return a diagnostic position based on the positions in a comment}
> 264:      *
> 265:      * The positions are lazily converted to file-based positions as needed.

"lazily" somewhat duplicates "as needed", no?

test/langtools/tools/javac/doctree/SerialTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 7021614 8273244 8273244

Duplicating bug IDs.

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

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

From jlahoda at openjdk.java.net  Wed Sep 22 12:56:00 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 22 Sep 2021 12:56:00 GMT
Subject: Integrated: 8270139: jshell InternalError crash for import of
 @Repeatable followed by unresolved ref
In-Reply-To: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>
References: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>
Message-ID: <k_ErGIiidQRYSg2xA92daRYGGA088ZX0qqjl_EykFhk=.c51a6716-c1d3-41aa-9fdf-d93d0bbf48be@github.com>

On Tue, 21 Sep 2021 11:05:45 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like:
> 
> import java.lang.annotation.Repeatable;
> @Repeatable(TestContainer.class)
> @interface Test { int value(); }
> 
> 
> javac crashes like this:
> 
> $ javac -XDdev /tmp/Test.java

This pull request has now been integrated.

Changeset: ba7d550c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ba7d550c6e6d84b36d81aafa1dfded0c99b5c248
Stats:     169 lines in 3 files changed: 168 ins; 0 del; 1 mod

8270139: jshell InternalError crash for import of @Repeatable followed by unresolved ref

Reviewed-by: vromero

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

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

From jjg at openjdk.java.net  Wed Sep 22 14:59:07 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 22 Sep 2021 14:59:07 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v2]
In-Reply-To: <OtcR7_ubTp4uMytjY4iNZroQl8CaCHuJZW4RmgtbqqE=.147a0d1e-d2df-427c-bcc7-05898d3497ca@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <nd3U4Jd_Pg-ITmoueijIGX-T2vAiOBwmbWDKp0Vqdu8=.a0dfaca7-20ee-4320-ad65-8bda801660e1@github.com>
 <OtcR7_ubTp4uMytjY4iNZroQl8CaCHuJZW4RmgtbqqE=.147a0d1e-d2df-427c-bcc7-05898d3497ca@github.com>
Message-ID: <vX-X-prauL3ZfZkQaK2COrkqrjJ4ZUZFbqMpPvzDPw0=.07ac6c1f-8eb5-4f55-83e6-307b49f1d2dc@github.com>

On Wed, 22 Sep 2021 10:29:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert unrelated debug edit
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 269:
> 
>> 267:                     DCTree dcTree = (DCTree) tree;
>> 268:                     if (dcComment.getSourcePosition(dcTree.getEndPosition()) == 0) {
>> 269:                         System.err.println("WARNING: comment:" + dcComment.comment + ": " + dcTree.getKind() + " end:" + dcTree.getEndPosition() + " result: " + dcComment.getSourcePosition(dcTree.getEndPosition()));
> 
> This looks like a leftover debugging aid.

Oops. Thanks

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 971:
> 
>> 969:     /**
>> 970:      * Creates an {@code ErroneousTree} node, for a range of text starting at a given position,
>> 971:      * ending at the last non-white character before the current position,
> 
> In this file and in JDK overall, such characters as predominantly called "non-whitespace".

Will fix.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 74:
> 
>> 72:  * </ul>
>> 73:  *
>> 74:  * All are values relative to the beginning of the
> 
> Transposition error? "All values are relative..."

Noted

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 88:
> 
>> 86:     /**
>> 87:      * The position of the first character that is unique to this node.
>> 88:      * It is normally set by the methods in {@link DocTreeMaker}.
> 
> Since this change also includes cleanup, we might as well fix "the the" and "non-white space" at DocTreeMaker.java:699.

Noted

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

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

From jjg at openjdk.java.net  Wed Sep 22 15:05:09 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 22 Sep 2021 15:05:09 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v2]
In-Reply-To: <OtcR7_ubTp4uMytjY4iNZroQl8CaCHuJZW4RmgtbqqE=.147a0d1e-d2df-427c-bcc7-05898d3497ca@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <nd3U4Jd_Pg-ITmoueijIGX-T2vAiOBwmbWDKp0Vqdu8=.a0dfaca7-20ee-4320-ad65-8bda801660e1@github.com>
 <OtcR7_ubTp4uMytjY4iNZroQl8CaCHuJZW4RmgtbqqE=.147a0d1e-d2df-427c-bcc7-05898d3497ca@github.com>
Message-ID: <UQAuxWevv5joKNj0QKQ-DDt0KFMjn0bSLoZYpl90GGA=.8745bb73-0127-4d2d-8d56-0e753b794e32@github.com>

On Wed, 22 Sep 2021 12:40:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert unrelated debug edit
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ReferenceParser.java line 124:
> 
>> 122:             moduleName = switch (slash) {
>> 123:                 case -1 -> null;
>> 124:                 case 0 -> throw new ParseException(0, "dc.ref.syntax.error");
> 
> There's a slight change in error output. Although it is likely insignificant, I felt I should note it. For example, compare the error output for `{@link //java.lang.Object}`.

Yes, there were some minor changes to a few (3?) tests because of this work. because of the enhanced precision of the positions.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 161:
> 
>> 159:         }
>> 160: 
>> 161:         switch (getKind()) {
> 
> This switch might become even better after "Pattern Matching for switch" has been integrated (currently in preview, JEP 406).

Noted. I go back and forth between switch and methods, but JEP 406 would improve the switch.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 265:
> 
>> 263:      * {@return a diagnostic position based on the positions in a comment}
>> 264:      *
>> 265:      * The positions are lazily converted to file-based positions as needed.
> 
> "lazily" somewhat duplicates "as needed", no?

Noted

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

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

From prappo at openjdk.java.net  Wed Sep 22 15:12:07 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 22 Sep 2021 15:12:07 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v2]
In-Reply-To: <UQAuxWevv5joKNj0QKQ-DDt0KFMjn0bSLoZYpl90GGA=.8745bb73-0127-4d2d-8d56-0e753b794e32@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <nd3U4Jd_Pg-ITmoueijIGX-T2vAiOBwmbWDKp0Vqdu8=.a0dfaca7-20ee-4320-ad65-8bda801660e1@github.com>
 <OtcR7_ubTp4uMytjY4iNZroQl8CaCHuJZW4RmgtbqqE=.147a0d1e-d2df-427c-bcc7-05898d3497ca@github.com>
 <UQAuxWevv5joKNj0QKQ-DDt0KFMjn0bSLoZYpl90GGA=.8745bb73-0127-4d2d-8d56-0e753b794e32@github.com>
Message-ID: <jAepg-0ApAP4z8jXFHRR-gOUiqoFdswZrfsqfRlDUec=.79d362d6-6813-416c-8329-1c2d626cf7c3@github.com>

On Wed, 22 Sep 2021 15:02:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ReferenceParser.java line 124:
>> 
>>> 122:             moduleName = switch (slash) {
>>> 123:                 case -1 -> null;
>>> 124:                 case 0 -> throw new ParseException(0, "dc.ref.syntax.error");
>> 
>> There's a slight change in error output. Although it is likely insignificant, I felt I should note it. For example, compare the error output for `{@link //java.lang.Object}`.
>
> Yes, there were some minor changes to a few (3?) tests because of this work. because of the enhanced precision of the positions.

In this case, not only the position has changed but also the error description.

Before:

: error: unexpected text
 * {@link //java.lang.Object}
   ^

After:

error: syntax error in reference
 * {@link //java.lang.Object}
          ^

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

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

From jjg at openjdk.java.net  Wed Sep 22 15:18:01 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 22 Sep 2021 15:18:01 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v2]
In-Reply-To: <UQAuxWevv5joKNj0QKQ-DDt0KFMjn0bSLoZYpl90GGA=.8745bb73-0127-4d2d-8d56-0e753b794e32@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <nd3U4Jd_Pg-ITmoueijIGX-T2vAiOBwmbWDKp0Vqdu8=.a0dfaca7-20ee-4320-ad65-8bda801660e1@github.com>
 <OtcR7_ubTp4uMytjY4iNZroQl8CaCHuJZW4RmgtbqqE=.147a0d1e-d2df-427c-bcc7-05898d3497ca@github.com>
 <UQAuxWevv5joKNj0QKQ-DDt0KFMjn0bSLoZYpl90GGA=.8745bb73-0127-4d2d-8d56-0e753b794e32@github.com>
Message-ID: <eKEbfsl2hZ5fPP73fnr4Uu0fs046A3GKe_0D_coYP-c=.bc144a2c-dd01-4dbb-a11f-7a744a533424@github.com>

On Wed, 22 Sep 2021 14:59:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 265:
>> 
>>> 263:      * {@return a diagnostic position based on the positions in a comment}
>>> 264:      *
>>> 265:      * The positions are lazily converted to file-based positions as needed.
>> 
>> "lazily" somewhat duplicates "as needed", no?
>
> Noted

It doesn't read as well without "lazily" or "as needed".  Would prefer to mostly leave alone.

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

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

From jjg at openjdk.java.net  Wed Sep 22 16:11:07 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 22 Sep 2021 16:11:07 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
Message-ID: <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>

> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world.
> 
> ## Previously ...
> 
> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class.  (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.)  The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available.
> 
> ## Now ... 
> 
> All `DCTree` nodes have 4 positions, 3 publicly available.
> * the position of the first unique character, `pos`
> * the starting position of the range of characters, `getStartPosition()`
> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()`
> * the end position of the range of characters, `getEndPosition()`.
> These are all relative to the beginning of the comment text, and are converted to file positions as needed.
> 
> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods.
> 
> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic.
> 
> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods.
> 
> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified.
> 
> ## Testing ...
> 
> Up until the point at which `DCTree.pos` was modified, all tests passed without change.   When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated.
> 
> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker`  which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue.
> 
> ## Behavior ...
> 
> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`.  This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work.  Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address preliminary review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5510/files
  - new: https://git.openjdk.java.net/jdk/pull/5510/files/4ddc0aaf..cf6d3b8e

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

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

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

From vromero at openjdk.java.net  Wed Sep 22 17:23:39 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 22 Sep 2021 17:23:39 GMT
Subject: RFR: 8269121: Type inference bug with method references [v6]
In-Reply-To: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
Message-ID: <VZnGYBh8VzR7rnm2crhJF-_dfP1qZWaa8k6jUf7UvE4=.cc4af529-c04c-47ae-bb85-366e51d3dd80@github.com>

> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
> 
> TIA

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - merge
 - implement verification based on conversions used at MethodHandle::asType

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5406/files
  - new: https://git.openjdk.java.net/jdk/pull/5406/files/3c394425..be009432

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

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

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

From vromero at openjdk.java.net  Wed Sep 22 17:31:20 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 22 Sep 2021 17:31:20 GMT
Subject: RFR: 8269121: Type inference bug with method references [v7]
In-Reply-To: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
Message-ID: <DVesDXsMHJQl-3mZgdij4U49ux6bmX6N7d1exmR8XTM=.f824e0b0-662f-4498-acd7-01ed804cd5d0@github.com>

> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
> 
> TIA

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into JDK-8269121
 - merge
 - implement verification based on conversions used at MethodHandle::asType
 - implement verification based on conversions used at MethodHandle::asType
 - support for sealed classes
 - changing the verification of LMF
 - addressing review comments
 - 8269121: Type inference bug with method references

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

Changes: https://git.openjdk.java.net/jdk/pull/5406/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5406&range=06
  Stats: 198 lines in 3 files changed: 185 ins; 2 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5406.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5406/head:pull/5406

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Sep 22 18:22:06 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 22 Sep 2021 18:22:06 GMT
Subject: RFR: 8274161: Cleanup redundant casts in java.compiler
Message-ID: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>

Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

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

Commit messages:
 - [PATCH] Cleanup redundant casts, when type is actually known beforehand

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

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

From vromero at openjdk.java.net  Wed Sep 22 18:35:00 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 22 Sep 2021 18:35:00 GMT
Subject: RFR: 8274161: Cleanup redundant casts in java.compiler
In-Reply-To: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>
References: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>
Message-ID: <_eWTj1Mr7bZ2-tHH9H1ONoUxBglhQOFM0aIc3rgvZ9Y=.5d0ef54d-abd9-426e-977a-2abce0601966@github.com>

On Fri, 27 Aug 2021 18:30:31 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Wed Sep 22 20:24:55 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 22 Sep 2021 20:24:55 GMT
Subject: RFR: 8269121: Type inference bug with method references [v8]
In-Reply-To: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
Message-ID: <cqDLeO2T268E1VYd68YxPm6W_cRKv_H2CpCkDJYGyKw=.db336784-0be7-4c9c-9b7d-a9119d7f3c77@github.com>

> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
> 
> TIA

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

  refactoring

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5406/files
  - new: https://git.openjdk.java.net/jdk/pull/5406/files/7e8c121f..1cb20651

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

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

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

From jjg at openjdk.java.net  Thu Sep 23 03:18:00 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 23 Sep 2021 03:18:00 GMT
Subject: RFR: 8274161: Cleanup redundant casts in java.compiler
In-Reply-To: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>
References: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>
Message-ID: <-df7UMk4nd_A0JfqCfJ39N1H94MnSkROfP3s7XRKp3Y=.7060c302-3924-4309-aba9-ad015886aa9f@github.com>

On Fri, 27 Aug 2021 18:30:31 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

The module name in the summary (java.compiler) does not match the module name in the edited files (jdk.compiler)

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

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

From jpai at openjdk.java.net  Thu Sep 23 06:28:01 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 23 Sep 2021 06:28:01 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v2]
In-Reply-To: <Rq_AiI1WCvlFNkHWLeIWXxZ9Vx7l-ETmdmUIpkZLweg=.f92d8005-a0c4-46c1-a8c7-d06d5aede0a0@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <Rq_AiI1WCvlFNkHWLeIWXxZ9Vx7l-ETmdmUIpkZLweg=.f92d8005-a0c4-46c1-a8c7-d06d5aede0a0@github.com>
Message-ID: <d2mzV1P0qoTbBbEjJuPtYfJzHmm7XwgtXHTU61qz330=.21a37637-c39e-4784-a285-1cbf3cf89f66@github.com>

On Fri, 17 Sep 2021 12:54:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - 8258117: jar tool sets the time stamp of module-info.class entries to the current time

Any reviews for this one, please?

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 07:26:56 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 07:26:56 GMT
Subject: RFR: 8274161: Cleanup redundant casts in jdk.compiler
In-Reply-To: <-df7UMk4nd_A0JfqCfJ39N1H94MnSkROfP3s7XRKp3Y=.7060c302-3924-4309-aba9-ad015886aa9f@github.com>
References: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>
 <-df7UMk4nd_A0JfqCfJ39N1H94MnSkROfP3s7XRKp3Y=.7060c302-3924-4309-aba9-ad015886aa9f@github.com>
Message-ID: <VBvlwcEeRU6pr_z_QGuFz59sS7zBBZvlzi5vGHYOLpk=.f5479ec7-07b6-4e32-b1bc-1b90b99b7dc0@github.com>

On Thu, 23 Sep 2021 03:14:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>The module name in the summary (java.compiler) does not match the module name in the edited files (jdk.compiler)

Oops. Updated.

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

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

From jjg at openjdk.java.net  Thu Sep 23 22:45:09 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 23 Sep 2021 22:45:09 GMT
Subject: RFR: JDK-8274233: Minor cleanup for ToolBox
Message-ID: <1PVrG13CteSibmNOr3qeeKTQu_tJpuJkwdU8x_hnfYY=.c3a843ac-7d4f-408c-95bc-9121b529fdb3@github.com>

Please review some superficial cleanup to the ToolBox class.  There are no API changes and no changes to any tests.

1. Change `Paths.get` to `Path.of`
2. Minor code cleanup suggested by IDE, such as removing unnecessary type parameters, etc
3. Reformat doc comments to commonly prevailing standards

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

Commit messages:
 - JDK-8274233: Minor cleanup for ToolBox

Changes: https://git.openjdk.java.net/jdk/pull/5667/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5667&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274233
  Stats: 111 lines in 1 file changed: 47 ins; 12 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5667.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5667/head:pull/5667

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

From iris at openjdk.java.net  Fri Sep 24 01:31:54 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 24 Sep 2021 01:31:54 GMT
Subject: RFR: JDK-8274233: Minor cleanup for ToolBox
In-Reply-To: <1PVrG13CteSibmNOr3qeeKTQu_tJpuJkwdU8x_hnfYY=.c3a843ac-7d4f-408c-95bc-9121b529fdb3@github.com>
References: <1PVrG13CteSibmNOr3qeeKTQu_tJpuJkwdU8x_hnfYY=.c3a843ac-7d4f-408c-95bc-9121b529fdb3@github.com>
Message-ID: <qUL9GZ01MNc_ZqvhYLUvJw3GweL3L31UogFvyYFZJxQ=.88aa32e0-5213-4d75-9abc-a877e62afcc1@github.com>

On Thu, 23 Sep 2021 22:37:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some superficial cleanup to the ToolBox class.  There are no API changes and no changes to any tests.
> 
> 1. Change `Paths.get` to `Path.of`
> 2. Minor code cleanup suggested by IDE, such as removing unnecessary type parameters, etc
> 3. Reformat doc comments to commonly prevailing standards

Marked as reviewed by iris (Reviewer).

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

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

From jjg at openjdk.java.net  Fri Sep 24 15:48:52 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 24 Sep 2021 15:48:52 GMT
Subject: Integrated: JDK-8274233: Minor cleanup for ToolBox
In-Reply-To: <1PVrG13CteSibmNOr3qeeKTQu_tJpuJkwdU8x_hnfYY=.c3a843ac-7d4f-408c-95bc-9121b529fdb3@github.com>
References: <1PVrG13CteSibmNOr3qeeKTQu_tJpuJkwdU8x_hnfYY=.c3a843ac-7d4f-408c-95bc-9121b529fdb3@github.com>
Message-ID: <niGgzYqwwvTX3syfV613UAJYmbYN_ODyE_dCBvQXI1k=.d84f5d09-a9b4-4b10-a90b-7ccfaf77d257@github.com>

On Thu, 23 Sep 2021 22:37:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some superficial cleanup to the ToolBox class.  There are no API changes and no changes to any tests.
> 
> 1. Change `Paths.get` to `Path.of`
> 2. Minor code cleanup suggested by IDE, such as removing unnecessary type parameters, etc
> 3. Reformat doc comments to commonly prevailing standards

This pull request has now been integrated.

Changeset: e741a180
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e741a18062061c1959f7881503aaf3a4cbcae776
Stats:     111 lines in 1 file changed: 47 ins; 12 del; 52 mod

8274233: Minor cleanup for ToolBox

Reviewed-by: iris

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

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

From darcy at openjdk.java.net  Fri Sep 24 19:19:07 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 24 Sep 2021 19:19:07 GMT
Subject: RFR: 8274255: Update javac messages to use "enum class" rather than
 "enum type"
Message-ID: <sff_Qw5j8KEt0c9Y1zJP_rSkaeQAchvjXHewWdbmemA=.7dfaa689-318a-4314-91c6-a18787789332@github.com>

As a belated part of the terminology update (JDK-8246772), change

enum type -> enum class
annotation type -> annotation interface

in javac's compiler.properties files. General analysis of the use of "type" in that file is beyond the scope of this PR.

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

Commit messages:
 - 8274255: Update javac messages to use "enum class" rather than "enum type"

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

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

From jiefu at openjdk.java.net  Sat Sep 25 02:43:56 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 02:43:56 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <FK-Tn5YDrSZZSR1_dL6txjPj_8GtRAan5S0X81fu9xI=.855d0006-df99-44d9-8ec9-139753386382@github.com>

On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

There are still 1500+ failures due to non-US locale after this patch.

So my question is: does it make sense to fix only 4 of them?
Thanks.

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

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

From serb at openjdk.java.net  Sat Sep 25 03:13:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 03:13:48 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@github.com>

On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

These are the only tests reported in Fr and Ru locales in t1/t2/t3. Are you sure that 1500 failures are caused by the tests issues and not a problem in JDK?

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

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

From jiefu at openjdk.java.net  Sat Sep 25 03:26:53 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 03:26:53 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@github.com>
Message-ID: <dLH6tzkd2Q3kUn7db21uw8S3bVwTWmkIHi8H3cRp3sI=.db58a312-0a7c-4c07-a62b-580d7a184636@github.com>

On Sat, 25 Sep 2021 03:10:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> These are the only tests reported in Fr and Ru locales in t1/t2/t3. Are you sure that 1500 failures are caused by the tests issues and not a problem in JDK?

If I test with `JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"`, most of the failures would disappear.

make test  TEST="tier1 tier2 tier3" with your patch

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
>> jtreg:test/hotspot/jtreg:tier1                     1810  1809     1     0 <<
>> jtreg:test/jdk:tier1                               2069  2065     4     0 <<
>> jtreg:test/langtools:tier1                         4238  2643  1593     2 <<
   jtreg:test/jaxp:tier1                                 0     0     0     0
   jtreg:test/lib-test:tier1                             0     0     0     0
   jtreg:test/hotspot/jtreg:tier2                      444   444     0     0
>> jtreg:test/jdk:tier2                               3765  3727    38     0 <<
>> jtreg:test/langtools:tier2                           12    10     2     0 <<
>> jtreg:test/jaxp:tier2                               452   449     3     0 <<
   jtreg:test/hotspot/jtreg:tier3                       85    85     0     0
   jtreg:test/jdk:tier3                                174   174     0     0
   jtreg:test/langtools:tier3                            0     0     0     0
   jtreg:test/jaxp:tier3                                 0     0     0     0
==============================
TEST FAILURE


------

make test JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" TEST="tier1 tier2 tier3" with your patch

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
>> jtreg:test/hotspot/jtreg:tier1                     1810  1809     1     0 <<
   jtreg:test/jdk:tier1                               2069  2069     0     0
>> jtreg:test/langtools:tier1                         4238  4230     8     0 <<
   jtreg:test/jaxp:tier1                                 0     0     0     0
   jtreg:test/lib-test:tier1                             0     0     0     0
   jtreg:test/hotspot/jtreg:tier2                      444   444     0     0
>> jtreg:test/jdk:tier2                               3765  3747    18     0 <<
   jtreg:test/langtools:tier2                           12    12     0     0
>> jtreg:test/jaxp:tier2                               452   451     1     0 <<
   jtreg:test/hotspot/jtreg:tier3                       85    85     0     0   
   jtreg:test/jdk:tier3                                174   174     0     0
   jtreg:test/langtools:tier3                            0     0     0     0
   jtreg:test/jaxp:tier3                                 0     0     0     0
==============================
TEST FAILURE

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

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

From serb at openjdk.java.net  Sat Sep 25 03:40:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 03:40:56 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <dLH6tzkd2Q3kUn7db21uw8S3bVwTWmkIHi8H3cRp3sI=.db58a312-0a7c-4c07-a62b-580d7a184636@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@github.com>
 <dLH6tzkd2Q3kUn7db21uw8S3bVwTWmkIHi8H3cRp3sI=.db58a312-0a7c-4c07-a62b-580d7a184636@github.com>
Message-ID: <2xQ3i6O5Q6NPZ2IQYfidFza31R9U4MyTwmC9qyY9OR4=.3949819c-e49f-4f32-addf-5f1d06c2d8c8@github.com>

On Sat, 25 Sep 2021 03:23:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> If I test with `JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"`, most of the failures would disappear.

If the failure disappeared if the "user.language=en" is used does not mean that this is not a JDK bug or some other bugs in the tests. What is the reason for the falure?

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

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

From jiefu at openjdk.java.net  Sat Sep 25 03:52:00 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 03:52:00 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <2xQ3i6O5Q6NPZ2IQYfidFza31R9U4MyTwmC9qyY9OR4=.3949819c-e49f-4f32-addf-5f1d06c2d8c8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@github.com>
 <dLH6tzkd2Q3kUn7db21uw8S3bVwTWmkIHi8H3cRp3sI=.db58a312-0a7c-4c07-a62b-580d7a184636@github.com>
 <2xQ3i6O5Q6NPZ2IQYfidFza31R9U4MyTwmC9qyY9OR4=.3949819c-e49f-4f32-addf-5f1d06c2d8c8@github.com>
Message-ID: <lOpDEph8HRdNIUpcX6d65fjSS77RaaK6C4Zrl3g3hlk=.d7290a62-a404-44cb-ad54-f45ed12b1246@github.com>

On Sat, 25 Sep 2021 03:38:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > If I test with `JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"`, most of the failures would disappear.
> 
> If the failure disappeared if the "user.language=en" is used does not mean that this is not a JDK bug or some other bugs in the tests. What is the reason for the falure?

An important reason is that the expected output doesn't match due to different languages.

 STDERR:
  stdout: [];
  stderr: [??: ?? emptynumbootstrapmethods1 ???? main ??, ?? main ?????:
    public static void main(String[] args) 
 ?? JavaFX ?????????javafx.application.Application
 ]
  exitValue = 1
 
 java.lang.RuntimeException: 'Main method not found in class emptynumbootstrapmethods1' missing from stdout/stderr 
 
        at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221)
        at TestEmptyBootstrapMethodsAttr.main(TestEmptyBootstrapMethodsAttr.java:56)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
        at java.base/java.lang.Thread.run(Thread.java:833)
 
 JavaTest Message: Test threw exception: java.lang.RuntimeException
 JavaTest Message: shutting down test
 
 
 TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'Main method not found in class emptynumbootstrapmethods1' missing from stdout/stderr


E.g., Test runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java with the locale:

LANG=en_US.UTF-8 \
LC_ALL=C \

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

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

From serb at openjdk.java.net  Sat Sep 25 05:16:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 05:16:59 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <FK-Tn5YDrSZZSR1_dL6txjPj_8GtRAan5S0X81fu9xI=.855d0006-df99-44d9-8ec9-139753386382@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <FK-Tn5YDrSZZSR1_dL6txjPj_8GtRAan5S0X81fu9xI=.855d0006-df99-44d9-8ec9-139753386382@github.com>
Message-ID: <WrLMxgK_mhps4eR32AkXwCWfqHvwBIPki_aJZbspsrg=.6956c860-f68f-4ab9-80e1-44d795ecc7be@github.com>

On Sat, 25 Sep 2021 02:41:10 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> There are still 1500+ failures due to non-US locale after this patch.
> 
> So my question is: does it make sense to fix only 4 of them?

This error means that your OpenJDK build contains the translation for your locale, and different tools use the resource bundles to translate different outputs. Looks like nobody validates that the translated output is correct for the various cases since the tests fail on non-US translated locales. I guess in the ideal world that tests should be updated to validate the output for each locale, or probably even better they should check that the output is correct for some specific "key" in the resource bundle.

The current issue is different, it fixes the tests depended on some specific float format and has no dependency on the resource bundles.

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

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

From jiefu at openjdk.java.net  Sat Sep 25 07:41:54 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 07:41:54 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <WrLMxgK_mhps4eR32AkXwCWfqHvwBIPki_aJZbspsrg=.6956c860-f68f-4ab9-80e1-44d795ecc7be@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <FK-Tn5YDrSZZSR1_dL6txjPj_8GtRAan5S0X81fu9xI=.855d0006-df99-44d9-8ec9-139753386382@github.com>
 <WrLMxgK_mhps4eR32AkXwCWfqHvwBIPki_aJZbspsrg=.6956c860-f68f-4ab9-80e1-44d795ecc7be@github.com>
Message-ID: <-6m-FQLBb9SgouaBObjGmNW0eukggujk_gVgqxv4Nmc=.c3887d22-1163-48e5-8d74-a870770abd39@github.com>

On Sat, 25 Sep 2021 05:13:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > There are still 1500+ failures due to non-US locale after this patch.
> > So my question is: does it make sense to fix only 4 of them?
> 
> This error means that your OpenJDK build contains the translation for your locale, and different tools use the resource bundles to translate different outputs. Looks like nobody validates that the translated output is correct for the various cases since the tests fail on non-US translated locales. I guess in the ideal world that tests should be updated to validate the output for each locale, or probably even better they should check that the output is correct for some specific "key" in the resource bundle.
> 
> The current issue is different, it fixes the tests depended on some specific float format and has no dependency on the resource bundles.

I still don't understand why the failures are different.

But the fix doesn't work even with these 4 tests.


* Before this fix: make test TEST="..."

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/langtools/jdk/jshell/ToolBasicTest.java
>>                                                       1     0     1     0 <<
   jtreg:test/langtools/jdk/jshell/ToolSimpleTest.java
>>                                                       1     0     1     0 <<
   jtreg:test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java
                                                         1     1     0     0
   jtreg:test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java
                                                         1     1     0     0
==============================
TEST FAILURE



* After this fix: make test TEST="..."

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/langtools/jdk/jshell/ToolBasicTest.java
>>                                                       1     0     1     0 <<
   jtreg:test/langtools/jdk/jshell/ToolSimpleTest.java
>>                                                       1     0     1     0 <<
   jtreg:test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java
                                                         1     1     0     0
   jtreg:test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java
                                                         1     1     0     0
==============================
TEST FAILURE


But if I run with make test JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" TEST="...", all of them get passed.

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

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

From serb at openjdk.java.net  Sat Sep 25 10:01:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 10:01:50 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <-6m-FQLBb9SgouaBObjGmNW0eukggujk_gVgqxv4Nmc=.c3887d22-1163-48e5-8d74-a870770abd39@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <FK-Tn5YDrSZZSR1_dL6txjPj_8GtRAan5S0X81fu9xI=.855d0006-df99-44d9-8ec9-139753386382@github.com>
 <WrLMxgK_mhps4eR32AkXwCWfqHvwBIPki_aJZbspsrg=.6956c860-f68f-4ab9-80e1-44d795ecc7be@github.com>
 <-6m-FQLBb9SgouaBObjGmNW0eukggujk_gVgqxv4Nmc=.c3887d22-1163-48e5-8d74-a870770abd39@github.com>
Message-ID: <6Xtrgr_XaaB4_i80BPEbX2AnT6QFE16kmEGMHyIn9lA=.336d6708-9709-41cd-88c4-69975899f8bf@github.com>

On Sat, 25 Sep 2021 07:38:54 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> I still don't understand why the failures are different.

The difference is that if the test uses golden data for EN locale only while the tested tool like javac supports more than one locale for some specific output message then the test should check that specific localized message.

> But the fix doesn't work even with these 4 tests.

Look like you use one of ja or zh_CN locales since only for these locales there are translations, the test should take it into account. It is not strictly correct to run add "-Duser.language=en -Duser.country=US" to it to fix such issues.

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

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

From lance.andersen at oracle.com  Sat Sep 25 10:47:20 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 25 Sep 2021 10:47:20 +0000
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v2]
In-Reply-To: <d2mzV1P0qoTbBbEjJuPtYfJzHmm7XwgtXHTU61qz330=.21a37637-c39e-4784-a285-1cbf3cf89f66@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <Rq_AiI1WCvlFNkHWLeIWXxZ9Vx7l-ETmdmUIpkZLweg=.f92d8005-a0c4-46c1-a8c7-d06d5aede0a0@github.com>
 <d2mzV1P0qoTbBbEjJuPtYfJzHmm7XwgtXHTU61qz330=.21a37637-c39e-4784-a285-1cbf3cf89f66@github.com>
Message-ID: <AF9EA397-6D9F-4CE1-9E86-AB710D4899B5@oracle.com>



On Sep 23, 2021, at 2:28 AM, Jaikiran Pai <jpai at openjdk.java.net<mailto:jpai at openjdk.java.net>> wrote:

On Fri, 17 Sep 2021 12:54:07 GMT, Jaikiran Pai <jpai at openjdk.org<mailto:jpai at openjdk.org>> wrote:

The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.

The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.

This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:

1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`.

2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.

If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

- Merge latest from master branch
- 8258117: jar tool sets the time stamp of module-info.class entries to the current time

Any reviews for this one, please?

Hi Jaikiran

This is on my todo list, sorry for the delay.

Hoping we can get a couple additional eyes on this as well.

Best
Lance

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

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

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210925/df79e772/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210925/df79e772/oracle_sig_logo-0001.gif>

From jiefu at openjdk.java.net  Sat Sep 25 12:12:53 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 12:12:53 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <6Xtrgr_XaaB4_i80BPEbX2AnT6QFE16kmEGMHyIn9lA=.336d6708-9709-41cd-88c4-69975899f8bf@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <FK-Tn5YDrSZZSR1_dL6txjPj_8GtRAan5S0X81fu9xI=.855d0006-df99-44d9-8ec9-139753386382@github.com>
 <WrLMxgK_mhps4eR32AkXwCWfqHvwBIPki_aJZbspsrg=.6956c860-f68f-4ab9-80e1-44d795ecc7be@github.com>
 <-6m-FQLBb9SgouaBObjGmNW0eukggujk_gVgqxv4Nmc=.c3887d22-1163-48e5-8d74-a870770abd39@github.com>
 <6Xtrgr_XaaB4_i80BPEbX2AnT6QFE16kmEGMHyIn9lA=.336d6708-9709-41cd-88c4-69975899f8bf@github.com>
Message-ID: <dkln0dazIDjEGd1PL0SoapfuomyHQqBuLx6Amig4oSo=.7735abe3-0eb7-4be7-a4a8-ed18c143b5ed@github.com>

On Sat, 25 Sep 2021 09:58:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I still don't understand why the failures are different.
> 
> The difference is that if the test uses golden data for EN locale only while the tested tool like javac supports more than one locale for some specific output message then the test should check that specific localized message.
> 
> > But the fix doesn't work even with these 4 tests.
> 
> Look like you use one of ja or zh_CN locales since only for these locales there are translations, the test should take it into account. It is not strictly correct to run add "-Duser.language=en -Duser.country=US" to it to fix such issues.

Thanks @mrserb for your clarification.

Shall we also fix ToolBasicTest.java and ToolSimpleTest.java just as what is done for LambdaTranslationTest1.java and LambdaTranslationTest2.java?
If so, the 4 tests would be also fixed on our MacOS platforms.

And do you test the fix on Linux?
Thanks.

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

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

From jai.forums2013 at gmail.com  Sat Sep 25 12:49:50 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 25 Sep 2021 18:19:50 +0530
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v2]
In-Reply-To: <AF9EA397-6D9F-4CE1-9E86-AB710D4899B5@oracle.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <Rq_AiI1WCvlFNkHWLeIWXxZ9Vx7l-ETmdmUIpkZLweg=.f92d8005-a0c4-46c1-a8c7-d06d5aede0a0@github.com>
 <d2mzV1P0qoTbBbEjJuPtYfJzHmm7XwgtXHTU61qz330=.21a37637-c39e-4784-a285-1cbf3cf89f66@github.com>
 <AF9EA397-6D9F-4CE1-9E86-AB710D4899B5@oracle.com>
Message-ID: <6a8bbc86-b6aa-6099-2aa7-c93c3eb362c0@gmail.com>


On 25/09/21 4:17 pm, Lance Andersen wrote:
>
> Hi Jaikiran
>
> This is on my todo list, sorry for the delay.
>
> Hoping we can get a couple additional eyes on this as well.

Thank you Lance. Please take your time.


-Jaikiran


From prappo at openjdk.java.net  Sat Sep 25 17:54:04 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 25 Sep 2021 17:54:04 GMT
Subject: RFR: 8274321: Standardize values of @since tags in javax.lang.model
Message-ID: <bIl-JJrw7eJZ-hV4lV4oNq906pNzkiMz6lIgjbtMfJk=.2518710f-f963-4488-873d-6cdf937b54d5@github.com>

This changes values of four `@since` tags from 8 to 1.8, which is predominantly used to refer to JDK 1.8.

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

Commit messages:
 - Initial commit

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

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

From darcy at openjdk.java.net  Sat Sep 25 19:39:52 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 25 Sep 2021 19:39:52 GMT
Subject: RFR: 8274321: Standardize values of @since tags in
 javax.lang.model
In-Reply-To: <bIl-JJrw7eJZ-hV4lV4oNq906pNzkiMz6lIgjbtMfJk=.2518710f-f963-4488-873d-6cdf937b54d5@github.com>
References: <bIl-JJrw7eJZ-hV4lV4oNq906pNzkiMz6lIgjbtMfJk=.2518710f-f963-4488-873d-6cdf937b54d5@github.com>
Message-ID: <gIXqrbp7RmNmE5N3yMUfXryadExaOL4w_F-hAvSFUCM=.89864916-1949-4a12-99d4-3941e8529541@github.com>

On Sat, 25 Sep 2021 17:45:17 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This changes values of four `@since` tags from 8 to 1.8, which is predominantly used to refer to JDK 1.8.

Marked as reviewed by darcy (Reviewer).

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

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

From prappo at openjdk.java.net  Sat Sep 25 21:07:56 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 25 Sep 2021 21:07:56 GMT
Subject: Integrated: 8274321: Standardize values of @since tags in
 javax.lang.model
In-Reply-To: <bIl-JJrw7eJZ-hV4lV4oNq906pNzkiMz6lIgjbtMfJk=.2518710f-f963-4488-873d-6cdf937b54d5@github.com>
References: <bIl-JJrw7eJZ-hV4lV4oNq906pNzkiMz6lIgjbtMfJk=.2518710f-f963-4488-873d-6cdf937b54d5@github.com>
Message-ID: <LR4-mmn__XsuVEnwjUULwdrSEBrVQ99tAyeHg6ocM7I=.b535aa52-d699-4666-9197-32442826ff88@github.com>

On Sat, 25 Sep 2021 17:45:17 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This changes values of four `@since` tags from 8 to 1.8, which is predominantly used to refer to JDK 1.8.

This pull request has now been integrated.

Changeset: 5ec1cdca
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5ec1cdcaf39229a7d2457313600b0dc2bf8c6453
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8274321: Standardize values of @since tags in javax.lang.model

Reviewed-by: darcy

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

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

From darcy at openjdk.java.net  Mon Sep 27 09:29:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 09:29:09 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields
Message-ID: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>

This is an initial PR for expanded lint warnings done under two bugs:

8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type

to get feedback on the general approach and test strategy before further polishing the implementation.

The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.

Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.

Please also review the corresponding CSRs:

https://bugs.openjdk.java.net/browse/JDK-8274335
https://bugs.openjdk.java.net/browse/JDK-8274336

Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.

The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.

In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

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

Commit messages:
 - Appease jcheck
 - Implement checks chegar recommended for interfaces.
 - Update comment.
 - Add tests for instance field checks.
 - Clean build with instance field checks in place.
 - Merge branch 'master' into JDK-8202056
 - Put Externalizable checks last.
 - Add checks for constructor access in Serializable classes.
 - Add no-arg ctor check for Externalizable classes.
 - Improve Externalization warnings.
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5756385c...d498ff5f

Changes: https://git.openjdk.java.net/jdk/pull/5709/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8202056
  Stats: 1519 lines in 79 files changed: 1511 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

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

From jlahoda at openjdk.java.net  Mon Sep 27 11:25:18 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 27 Sep 2021 11:25:18 GMT
Subject: RFR: 8269113: Javac throws when compiling switch (null)
Message-ID: <Ze8SZv4oBmjbRULcgC7_SuRZI6BYCrsxPByjH0s2AfQ=.8957a09a-a725-4c80-aa64-dceea621a270@github.com>

This handles a case of `switch (null)` (i.e. switch over a literal `null`). It is necessary to handle `BOT` (null type) in the switch's selector, similarly to how it is handled in `null instanceof ...`. Note that since any reference type is a supertype of the `null` (JLS 4.10.2.), any type pattern is total for `switch (null)`.

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

Commit messages:
 - Removing debug code.
 - 8269113: Javac throws when compiling switch (null)

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

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

From erikj at openjdk.java.net  Mon Sep 27 13:01:58 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 27 Sep 2021 13:01:58 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <fleMwIh15sptLebA-p9240UO1uEZArpMzJ2LzaeAOms=.a8932c58-a9ea-45f4-a532-696aecdea5d3@github.com>

On Mon, 27 Sep 2021 01:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

Build change looks ok.

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

Marked as reviewed by erikj (Reviewer).

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

From prappo at openjdk.java.net  Mon Sep 27 15:58:10 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 27 Sep 2021 15:58:10 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
Message-ID: <CYk4C6inAvWUTTAztInRVorvaMWR0BWYJqN2R3bLQtk=.649b9b3b-cce9-4cf0-8f94-6924e42bc049@github.com>

On Wed, 22 Sep 2021 16:11:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world.
>> 
>> ## Previously ...
>> 
>> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class.  (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.)  The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available.
>> 
>> ## Now ... 
>> 
>> All `DCTree` nodes have 4 positions, 3 publicly available.
>> * the position of the first unique character, `pos`
>> * the starting position of the range of characters, `getStartPosition()`
>> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()`
>> * the end position of the range of characters, `getEndPosition()`.
>> These are all relative to the beginning of the comment text, and are converted to file positions as needed.
>> 
>> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods.
>> 
>> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic.
>> 
>> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods.
>> 
>> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified.
>> 
>> ## Testing ...
>> 
>> Up until the point at which `DCTree.pos` was modified, all tests passed without change.   When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated.
>> 
>> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker`  which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue.
>> 
>> ## Behavior ...
>> 
>> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`.  This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work.  Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address preliminary review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 161:

> 159:         }
> 160: 
> 161:         switch (getKind()) {

I can see that you changed this switch while moving it from JavacTrees.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 174:

> 172:             case IDENTIFIER -> {
> 173:                 DCIdentifier ident = (DCIdentifier) this;
> 174:                 return ident.pos + ident.name.length();

While in JavacTrees, this logic contained some special handling for `names.error`. What was that about?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 177:

> 175:             }
> 176: 
> 177:             case AUTHOR, DEPRECATED, HIDDEN, PARAM, RETURN, SEE, SERIAL, SERIAL_DATA, SERIAL_FIELD, SINCE, THROWS, UNKNOWN_BLOCK_TAG, VERSION -> {

You added HIDDEN and merged PARAM into this case of block tags. Should we also add PROVIDES and USES? If so, then we should add respective tests.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 192:

> 190:             case ENTITY -> {
> 191:                 DCEntity endEl = (DCEntity) this;
> 192:                 return endEl.pos + endEl.name.length() + 2;

A similar question about `names.error`.

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

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

From vromero at openjdk.java.net  Mon Sep 27 16:24:01 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 27 Sep 2021 16:24:01 GMT
Subject: RFR: 8274255: Update javac messages to use "enum class" rather
 than "enum type"
In-Reply-To: <sff_Qw5j8KEt0c9Y1zJP_rSkaeQAchvjXHewWdbmemA=.7dfaa689-318a-4314-91c6-a18787789332@github.com>
References: <sff_Qw5j8KEt0c9Y1zJP_rSkaeQAchvjXHewWdbmemA=.7dfaa689-318a-4314-91c6-a18787789332@github.com>
Message-ID: <o9SHImP2HGypAAjp0CGDrwWY4qQUSpHRCx5DS6GnIDc=.17021ac6-ada2-441e-bfb6-d7ed82a98aa7@github.com>

On Fri, 24 Sep 2021 19:11:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> As a belated part of the terminology update (JDK-8246772), change
> 
> enum type -> enum class
> annotation type -> annotation interface
> 
> in javac's compiler.properties files. General analysis of the use of "type" in that file is beyond the scope of this PR.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.java.net  Mon Sep 27 16:32:03 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 16:32:03 GMT
Subject: Integrated: 8274255: Update javac messages to use "enum class" rather
 than "enum type"
In-Reply-To: <sff_Qw5j8KEt0c9Y1zJP_rSkaeQAchvjXHewWdbmemA=.7dfaa689-318a-4314-91c6-a18787789332@github.com>
References: <sff_Qw5j8KEt0c9Y1zJP_rSkaeQAchvjXHewWdbmemA=.7dfaa689-318a-4314-91c6-a18787789332@github.com>
Message-ID: <TUgwmh8yhtiI312q1fXpjvGKU-u22Gf1Y7HtEhs4-ik=.4302d781-57aa-4f63-be9d-2ef570b8ec25@github.com>

On Fri, 24 Sep 2021 19:11:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> As a belated part of the terminology update (JDK-8246772), change
> 
> enum type -> enum class
> annotation type -> annotation interface
> 
> in javac's compiler.properties files. General analysis of the use of "type" in that file is beyond the scope of this PR.

This pull request has now been integrated.

Changeset: 172900da
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/172900dab133aad9029c904101ff9ddaaced6a8f
Stats:     22 lines in 1 file changed: 0 ins; 0 del; 22 mod

8274255: Update javac messages to use "enum class" rather than "enum type"

Reviewed-by: vromero

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

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

From prappo at openjdk.java.net  Mon Sep 27 17:39:05 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 27 Sep 2021 17:39:05 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
Message-ID: <3ZmvNUogo4Atv8FZLWK57AtUjwVR1K-fjOr5g639znw=.038b6cb1-8ff4-47b5-8e17-0b73017d49f9@github.com>

On Wed, 22 Sep 2021 16:11:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world.
>> 
>> ## Previously ...
>> 
>> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class.  (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.)  The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available.
>> 
>> ## Now ... 
>> 
>> All `DCTree` nodes have 4 positions, 3 publicly available.
>> * the position of the first unique character, `pos`
>> * the starting position of the range of characters, `getStartPosition()`
>> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()`
>> * the end position of the range of characters, `getEndPosition()`.
>> These are all relative to the beginning of the comment text, and are converted to file positions as needed.
>> 
>> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods.
>> 
>> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic.
>> 
>> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods.
>> 
>> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified.
>> 
>> ## Testing ...
>> 
>> Up until the point at which `DCTree.pos` was modified, all tests passed without change.   When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated.
>> 
>> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker`  which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue.
>> 
>> ## Behavior ...
>> 
>> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`.  This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work.  Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address preliminary review comments

I'd feel more confident if Hannes looked at changes related to ReferenceParser.

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

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

From prappo at openjdk.java.net  Mon Sep 27 18:03:02 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 27 Sep 2021 18:03:02 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
Message-ID: <gPJg4pRjfkdZ9-7lOUAqr3UotX1dFyjmSt7fLFx42hw=.e57991a0-05b7-47b1-a467-6a399331deea@github.com>

On Wed, 22 Sep 2021 16:11:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world.
>> 
>> ## Previously ...
>> 
>> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class.  (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.)  The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available.
>> 
>> ## Now ... 
>> 
>> All `DCTree` nodes have 4 positions, 3 publicly available.
>> * the position of the first unique character, `pos`
>> * the starting position of the range of characters, `getStartPosition()`
>> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()`
>> * the end position of the range of characters, `getEndPosition()`.
>> These are all relative to the beginning of the comment text, and are converted to file positions as needed.
>> 
>> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods.
>> 
>> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic.
>> 
>> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods.
>> 
>> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified.
>> 
>> ## Testing ...
>> 
>> Up until the point at which `DCTree.pos` was modified, all tests passed without change.   When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated.
>> 
>> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker`  which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue.
>> 
>> ## Behavior ...
>> 
>> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`.  This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work.  Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address preliminary review comments

> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty DocCommentTree the ending position is now the same at the starting position, and not NOPOS. 

I suppose we don't need to reflect this change anywhere in the API (CSR), do we?

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

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

From prappo at openjdk.java.net  Mon Sep 27 18:17:05 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 27 Sep 2021 18:17:05 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
Message-ID: <CM_yMDcpIa5JcJcNzymyeEmOhKtEXK-8hv1JDsJ268Q=.113c306f-14d8-4431-a508-a5a95340e66c@github.com>

On Wed, 22 Sep 2021 16:11:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world.
>> 
>> ## Previously ...
>> 
>> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class.  (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.)  The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available.
>> 
>> ## Now ... 
>> 
>> All `DCTree` nodes have 4 positions, 3 publicly available.
>> * the position of the first unique character, `pos`
>> * the starting position of the range of characters, `getStartPosition()`
>> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()`
>> * the end position of the range of characters, `getEndPosition()`.
>> These are all relative to the beginning of the comment text, and are converted to file positions as needed.
>> 
>> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods.
>> 
>> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic.
>> 
>> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods.
>> 
>> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified.
>> 
>> ## Testing ...
>> 
>> Up until the point at which `DCTree.pos` was modified, all tests passed without change.   When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated.
>> 
>> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker`  which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue.
>> 
>> ## Behavior ...
>> 
>> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`.  This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work.  Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address preliminary review comments

src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java line 498:

> 496:                             //the newline:
> 497:                             long endPos = sp.getEndPosition(null, dcTree, tree);
> 498:                             if (endPos >= offset) {

What's that about?

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

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

From jlahoda at openjdk.java.net  Mon Sep 27 18:19:43 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 27 Sep 2021 18:19:43 GMT
Subject: RFR: 8274363: Transitively sealed classes not considered exhaustive
 in switches
Message-ID: <4Ic1_oURyu8UUM4voPOjhtqy9LhVEHB0eHW7_c_RvHI=.32af168f-774e-45a6-bb8a-de8b67dd06e7@github.com>

Consider code like:

public class SwitchCoverage {
    sealed interface A {}
    sealed interface B1 extends A {}
    sealed interface B2 extends A {}
    sealed interface C extends A {}
    final class D1 implements B1, C {}
    final class D2 implements B2, C {}
    
    void test(A arg) {
        int i = switch (arg) {
            case B1 b1 -> 1;
            case B2 b2 -> 2;
        };
    }
    
} 


Note that `B1` covers `D1` and `B2` covers `D2`. So, `B1` and `B2` cover `C`, and hence `B1` and `B2` cover `A`.  To detect this, when looking for coverage of permitted types of `A`, we need to transitively look if any of the permitted type is covered.

The check uses the `DeferredCompletionFailureHandler`, because if don't want to fail the compilation on unresolvable permitted subclass. (In case the permitted subclass is covered by some other means, of course.)

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

Commit messages:
 - Fixing tests.
 - 8274363: Transitively sealed classes not considered exhaustive in switches

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

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

From vromero at openjdk.java.net  Mon Sep 27 18:53:58 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 27 Sep 2021 18:53:58 GMT
Subject: RFR: 8274363: Transitively sealed classes not considered
 exhaustive in switches
In-Reply-To: <4Ic1_oURyu8UUM4voPOjhtqy9LhVEHB0eHW7_c_RvHI=.32af168f-774e-45a6-bb8a-de8b67dd06e7@github.com>
References: <4Ic1_oURyu8UUM4voPOjhtqy9LhVEHB0eHW7_c_RvHI=.32af168f-774e-45a6-bb8a-de8b67dd06e7@github.com>
Message-ID: <nmxkvm_ML9C2mg6k2Zx77UvGX62WQLMVSKprlE3unik=.68c937a5-2a02-4931-92b6-9a05d9263d9b@github.com>

On Mon, 27 Sep 2021 18:05:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class SwitchCoverage {
>     sealed interface A {}
>     sealed interface B1 extends A {}
>     sealed interface B2 extends A {}
>     sealed interface C extends A {}
>     final class D1 implements B1, C {}
>     final class D2 implements B2, C {}
>     
>     void test(A arg) {
>         int i = switch (arg) {
>             case B1 b1 -> 1;
>             case B2 b2 -> 2;
>         };
>     }
>     
> } 
> 
> 
> Note that `B1` covers `D1` and `B2` covers `D2`. So, `B1` and `B2` cover `C`, and hence `B1` and `B2` cover `A`.  To detect this, when looking for coverage of permitted types of `A`, we need to transitively look if any of the permitted type is covered.
> 
> The check uses the `DeferredCompletionFailureHandler`, because if don't want to fail the compilation on unresolvable permitted subclass. (In case the permitted subclass is covered by some other means, of course.)

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

> 774:                         for (Type sup : types.directSupertypes(sym.type)) {
> 775:                             if (sup.tsym.kind == TYP) {
> 776:                                 if (isTransitivellyCovered(sup.tsym, covered) &&

typo: Transitively?

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

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

From vromero at openjdk.java.net  Mon Sep 27 19:23:04 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 27 Sep 2021 19:23:04 GMT
Subject: RFR: 8274363: Transitively sealed classes not considered
 exhaustive in switches
In-Reply-To: <4Ic1_oURyu8UUM4voPOjhtqy9LhVEHB0eHW7_c_RvHI=.32af168f-774e-45a6-bb8a-de8b67dd06e7@github.com>
References: <4Ic1_oURyu8UUM4voPOjhtqy9LhVEHB0eHW7_c_RvHI=.32af168f-774e-45a6-bb8a-de8b67dd06e7@github.com>
Message-ID: <jyANYF7moMMq1KHV1IbiXnVuZU0DKWUk9CEDX-Cb3tg=.e2a17f2e-fc01-451a-8136-93247263f42b@github.com>

On Mon, 27 Sep 2021 18:05:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class SwitchCoverage {
>     sealed interface A {}
>     sealed interface B1 extends A {}
>     sealed interface B2 extends A {}
>     sealed interface C extends A {}
>     final class D1 implements B1, C {}
>     final class D2 implements B2, C {}
>     
>     void test(A arg) {
>         int i = switch (arg) {
>             case B1 b1 -> 1;
>             case B2 b2 -> 2;
>         };
>     }
>     
> } 
> 
> 
> Note that `B1` covers `D1` and `B2` covers `D2`. So, `B1` and `B2` cover `C`, and hence `B1` and `B2` cover `A`.  To detect this, when looking for coverage of permitted types of `A`, we need to transitively look if any of the permitted type is covered.
> 
> The check uses the `DeferredCompletionFailureHandler`, because if don't want to fail the compilation on unresolvable permitted subclass. (In case the permitted subclass is covered by some other means, of course.)

looks good to me

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.java.net  Mon Sep 27 20:32:31 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 20:32:31 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields [v2]
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <VviglSaaLjFqBSk2igEXY2283ZfEgNaaxyPBkC2pnMo=.e350b77c-6f5b-4e6e-9e10-185376ad937f@github.com>

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

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

 - Merge branch 'master' into JDK-8202056
 - Appease jcheck
 - Implement checks chegar recommended for interfaces.
 - Update comment.
 - Add tests for instance field checks.
 - Clean build with instance field checks in place.
 - Merge branch 'master' into JDK-8202056
 - Put Externalizable checks last.
 - Add checks for constructor access in Serializable classes.
 - Add no-arg ctor check for Externalizable classes.
 - ... and 20 more: https://git.openjdk.java.net/jdk/compare/fa1a96de...053de6bb

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5709/files
  - new: https://git.openjdk.java.net/jdk/pull/5709/files/d498ff5f..053de6bb

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

  Stats: 469 lines in 32 files changed: 252 ins; 70 del; 147 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

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

From vromero at openjdk.java.net  Tue Sep 28 00:55:08 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 28 Sep 2021 00:55:08 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <PHUfoSo_D19IxSkWjelFh-YlFnVHjrpndk8zNc2u4vc=.125d6364-75a2-40be-9b26-e367417ea84c@github.com>

On Mon, 20 Sep 2021 19:00:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

ping

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

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

From darcy at openjdk.java.net  Tue Sep 28 02:18:58 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 28 Sep 2021 02:18:58 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc
Message-ID: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>

Augmentations to javac's Xlint:serial checking are out for review (#5709) and various javac and javadoc implementation libraries would need some changes to pass under the expanded checks.

The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.

I'll run a script to update the copyright year before pushing.

Sending this change out for review separately in an effort to de-bulk the review needed for the new checks themselves.

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

Commit messages:
 - 8274405: Suppress warnings on non-serializable non-transient instance fields in javac and javadoc

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Sep 28 08:19:16 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 28 Sep 2021 08:19:16 GMT
Subject: RFR: 8274425: Remove unused Modules.extraLimitMods
Message-ID: <3XU4OpaQ6kW3DXLru4uScWtbIQBiYgHyoUPBdkkoo-g=.bd1ac042-fb54-4b37-9433-d4c0c5990e6f@github.com>

HashSet `com.sun.tools.javac.comp.Modules.extraLimitMods` is always empty. Code only check its content, but no content added.
There was a method `addExtraLimitModules`, but it was removed under [JDK-8175191](https://bugs.openjdk.java.net/browse/JDK-8175191) 253fdcd0b26
Method `addExtraLimitModules` itself was added in ec9ca2997f4, but was never actually used .

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

Commit messages:
 - [PATCH] Remove unused Modules.extraLimitMods

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

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

From vromero at openjdk.java.net  Tue Sep 28 15:36:32 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 28 Sep 2021 15:36:32 GMT
Subject: RFR: 8269113: Javac throws when compiling switch (null)
In-Reply-To: <Ze8SZv4oBmjbRULcgC7_SuRZI6BYCrsxPByjH0s2AfQ=.8957a09a-a725-4c80-aa64-dceea621a270@github.com>
References: <Ze8SZv4oBmjbRULcgC7_SuRZI6BYCrsxPByjH0s2AfQ=.8957a09a-a725-4c80-aa64-dceea621a270@github.com>
Message-ID: <p2tYcVCprVoYf8elgJG_MV1B596z-ENU72-OkBAcztE=.2304daeb-61ce-46a9-ba3b-ad5e301815bd@github.com>

On Mon, 27 Sep 2021 11:15:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This handles a case of `switch (null)` (i.e. switch over a literal `null`). It is necessary to handle `BOT` (null type) in the switch's selector, similarly to how it is handled in `null instanceof ...`. Note that since any reference type is a supertype of the `null` (JLS 4.10.2.), any type pattern is total for `switch (null)`.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

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

From mcimadamore at openjdk.java.net  Tue Sep 28 17:26:38 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 28 Sep 2021 17:26:38 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <dfO9QWL1Z0okPhWM90elJxeNTm7e0qKpQGG7yfhm4Jc=.1f7f32f2-ea9b-4735-92b0-52ac2de3288f@github.com>

On Mon, 20 Sep 2021 19:00:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

Very tricky issue. Basically, the deferred diagnostic handler checks whether the diagnostic is associated with the tree being speculatively attributed. This is required, because sometimes, when attributing a piece of code, we could have completion events, causing the compiler to jump from one file to another - it is important that completion related issues are logged, even if we're inside deferred attribution, which is why the logic is there.

The resolution diagnostic rewrite throws a spanner in the work though - because it can sometime update the diagnostic position to make it appear like the error was on an outermost node, which then will fall outside the tree covered by the deferred diagnostic handler, and result in spurious errors being generated.

I think a more robust solution would be to leave the diagnostic as is (since the diagnostic handler in DeferredAttr depends on it), but at the same time, maybe record something on the JCDiagnostic object - e.g. like a Supplier<JCDiagnostic> which allows the diagnostic to be simplified later, by `Log`, rather than eagerly, by `Resolve`. It is possible that, if we do this, we might no longer require a COMPRESSED flag on the diagnostic at all - after all, if Log is in charge of the rewriting, it knows which diagnostics have been touched.

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

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

From darcy at openjdk.java.net  Tue Sep 28 21:30:17 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 28 Sep 2021 21:30:17 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields [v3]
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <LVNbUls3UcsrkCQCn73A5IpAEI2oo4EKcq0wAYwamFI=.e4a6a7c4-4cd3-487b-bdfc-7f72368e9d63@github.com>

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

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

 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Restore serial checks on java.xml module.
 - Merge branch 'master' into JDK-8202056
 - Appease jcheck
 - Implement checks chegar recommended for interfaces.
 - Update comment.
 - Add tests for instance field checks.
 - Clean build with instance field checks in place.
 - Merge branch 'master' into JDK-8202056
 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/7925d0cc...bacff4e9

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5709/files
  - new: https://git.openjdk.java.net/jdk/pull/5709/files/053de6bb..bacff4e9

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

  Stats: 2951 lines in 77 files changed: 2399 ins; 397 del; 155 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

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

From darcy at openjdk.java.net  Tue Sep 28 22:10:11 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 28 Sep 2021 22:10:11 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields [v4]
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <Ndc1gCssOnG3eQs7_U-v562m13kjakdG8ZWo55Mlrzs=.1f68a8fc-e218-454e-a82e-a6938e2b6743@github.com>

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

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

 - Fix whitespace.
 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Restore serial checks on java.xml module.
 - Merge branch 'master' into JDK-8202056
 - Appease jcheck
 - Implement checks chegar recommended for interfaces.
 - Update comment.
 - Add tests for instance field checks.
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/d8a278f3...37ad8778

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

Changes: https://git.openjdk.java.net/jdk/pull/5709/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=03
  Stats: 1495 lines in 64 files changed: 1488 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

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

From duke at openjdk.java.net  Tue Sep 28 23:56:30 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 28 Sep 2021 23:56:30 GMT
Subject: Withdrawn: 8271623: Omit enclosing instance fields from inner classes
 that don't use it
In-Reply-To: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
Message-ID: <xggX9XBhlbwKhStQALd_tzNhmIRvHjy7fgOJSA6pEpo=.fb328aa5-f292-478a-9893-3162990898fc@github.com>

On Tue, 3 Aug 2021 03:19:13 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.

This pull request has been closed without being integrated.

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

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

From jjg at openjdk.java.net  Wed Sep 29 03:07:43 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 29 Sep 2021 03:07:43 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <CYk4C6inAvWUTTAztInRVorvaMWR0BWYJqN2R3bLQtk=.649b9b3b-cce9-4cf0-8f94-6924e42bc049@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
 <CYk4C6inAvWUTTAztInRVorvaMWR0BWYJqN2R3bLQtk=.649b9b3b-cce9-4cf0-8f94-6924e42bc049@github.com>
Message-ID: <5k-NokDnsit6veesUaENZNCHMFcqm6pnoxuhmh0fdD0=.094c2232-c80e-459a-b282-201ba28d2d81@github.com>

On Mon, 27 Sep 2021 15:49:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address preliminary review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 177:
> 
>> 175:             }
>> 176: 
>> 177:             case AUTHOR, DEPRECATED, HIDDEN, PARAM, RETURN, SEE, SERIAL, SERIAL_DATA, SERIAL_FIELD, SINCE, THROWS, UNKNOWN_BLOCK_TAG, VERSION -> {
> 
> You added HIDDEN and merged PARAM into this case of block tags. Should we also add PROVIDES and USES? If so, then we should add respective tests.

Yes, and agreed.

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

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

From jjg at openjdk.java.net  Wed Sep 29 03:13:41 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 29 Sep 2021 03:13:41 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <gPJg4pRjfkdZ9-7lOUAqr3UotX1dFyjmSt7fLFx42hw=.e57991a0-05b7-47b1-a467-6a399331deea@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
 <gPJg4pRjfkdZ9-7lOUAqr3UotX1dFyjmSt7fLFx42hw=.e57991a0-05b7-47b1-a467-6a399331deea@github.com>
Message-ID: <dKsquXo04u_RtLyzPQhmo664_OXKFWX0mLIq0ls3zLc=.407af9f9-8edd-469f-a6c6-153a6526ad11@github.com>

On Mon, 27 Sep 2021 18:00:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty DocCommentTree the ending position is now the same at the starting position, and not NOPOS.
> 
> I suppose we don't need to reflect this change anywhere in the API (CSR), do we?

I don't believe the specification is so fine-grained.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 174:
> 
>> 172:             case IDENTIFIER -> {
>> 173:                 DCIdentifier ident = (DCIdentifier) this;
>> 174:                 return ident.pos + ident.name.length();
> 
> While in JavacTrees, this logic contained some special handling for `names.error`. What was that about?

`names.error` is used by javac in various error conditions. It has the string  value `<error>`.  I don't believe it can arise in `DocTree` nodes, so I dropped the code.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 192:
> 
>> 190:             case ENTITY -> {
>> 191:                 DCEntity endEl = (DCEntity) this;
>> 192:                 return endEl.pos + endEl.name.length() + 2;
> 
> A similar question about `names.error`.

Similar answer.

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

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

From jjg at openjdk.java.net  Wed Sep 29 03:22:37 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 29 Sep 2021 03:22:37 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <CYk4C6inAvWUTTAztInRVorvaMWR0BWYJqN2R3bLQtk=.649b9b3b-cce9-4cf0-8f94-6924e42bc049@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
 <CYk4C6inAvWUTTAztInRVorvaMWR0BWYJqN2R3bLQtk=.649b9b3b-cce9-4cf0-8f94-6924e42bc049@github.com>
Message-ID: <IWtGhCL34u5TKX2vfJ1_pLpgANk33rC9flGpGIcHNVs=.33ec43ee-8d8b-42fc-ae6c-f4577c9d7f4a@github.com>

On Mon, 27 Sep 2021 15:48:17 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address preliminary review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 161:
> 
>> 159:         }
>> 160: 
>> 161:         switch (getKind()) {
> 
> I can see that you changed this switch while moving it from JavacTrees.

Yes.

> src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java line 498:
> 
>> 496:                             //the newline:
>> 497:                             long endPos = sp.getEndPosition(null, dcTree, tree);
>> 498:                             if (endPos >= offset) {
> 
> What's that about?

Without the change, you can get an exception like `StringIndexOutOfBoundsException` for a bad `endPos`.

I believe there's some underlying weirdness for synthesized HTML comments (i.e. full `<html>...</html>` comments e.g. for `package.html`) that needs to be investigated, but this is in `jshell` code and getting out of scope for this round of work.

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

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

From vromero at openjdk.java.net  Wed Sep 29 06:16:22 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 29 Sep 2021 06:16:22 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v2]
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <aWX6-iUHQorNM2vWY30_CRtPsecpuHttGRpT0ZScil0=.a32c6409-9120-4b9a-ac7b-3bc93291a8ba@github.com>

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> 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.java.net/jdk/pull/5586/files
  - new: https://git.openjdk.java.net/jdk/pull/5586/files/60857430..95a0839a

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

  Stats: 190 lines in 13 files changed: 104 ins; 69 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5586.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5586/head:pull/5586

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

From prappo at openjdk.java.net  Wed Sep 29 10:42:41 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 29 Sep 2021 10:42:41 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <DOewX4UyCvvBQGbXaD4gtt4Q13Ll-aQRKxxY0x70g_g=.303bccb9-d0b1-4e03-9aa2-234c980bb094@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
 <CYk4C6inAvWUTTAztInRVorvaMWR0BWYJqN2R3bLQtk=.649b9b3b-cce9-4cf0-8f94-6924e42bc049@github.com>
 <5k-NokDnsit6veesUaENZNCHMFcqm6pnoxuhmh0fdD0=.094c2232-c80e-459a-b282-201ba28d2d81@github.com>
 <DOewX4UyCvvBQGbXaD4gtt4Q13Ll-aQRKxxY0x70g_g=.303bccb9-d0b1-4e03-9aa2-234c980bb094@github.com>
Message-ID: <oqsvzyvy5VLWttNOJ-oQzejk9rMY8zJOuOj6isrD5G0=.d526b7d9-48ef-485e-80f8-91b323f809bf@github.com>

On Wed, 29 Sep 2021 03:22:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yes, and agreed.
>
> FWIW, I'm still in two minds whether this should be a switch or overriding methods. It's ... er, disappointing ... that the lack of support for `PROVIDES` and `USES` didn't "automatically" show up in testing.  That may suggest a lack of coverage in the `DocTree` tests, which suggests the need for a test to check coverage.

For the sake of this review, using `switch` would be better: fewer changes, less cognitive load. Later we can think of ways of improving that code. It would be nice to structure it such that it would fail at compile time, if we forgot a case.

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

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

From jjg at openjdk.java.net  Wed Sep 29 10:42:40 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 29 Sep 2021 10:42:40 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <5k-NokDnsit6veesUaENZNCHMFcqm6pnoxuhmh0fdD0=.094c2232-c80e-459a-b282-201ba28d2d81@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
 <CYk4C6inAvWUTTAztInRVorvaMWR0BWYJqN2R3bLQtk=.649b9b3b-cce9-4cf0-8f94-6924e42bc049@github.com>
 <5k-NokDnsit6veesUaENZNCHMFcqm6pnoxuhmh0fdD0=.094c2232-c80e-459a-b282-201ba28d2d81@github.com>
Message-ID: <DOewX4UyCvvBQGbXaD4gtt4Q13Ll-aQRKxxY0x70g_g=.303bccb9-d0b1-4e03-9aa2-234c980bb094@github.com>

On Wed, 29 Sep 2021 03:04:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 177:
>> 
>>> 175:             }
>>> 176: 
>>> 177:             case AUTHOR, DEPRECATED, HIDDEN, PARAM, RETURN, SEE, SERIAL, SERIAL_DATA, SERIAL_FIELD, SINCE, THROWS, UNKNOWN_BLOCK_TAG, VERSION -> {
>> 
>> You added HIDDEN and merged PARAM into this case of block tags. Should we also add PROVIDES and USES? If so, then we should add respective tests.
>
> Yes, and agreed.

FWIW, I'm still in two minds whether this should be a switch or overriding methods. It's ... er, disappointing ... that the lack of support for `PROVIDES` and `USES` didn't "automatically" show up in testing.  That may suggest a lack of coverage in the `DocTree` tests, which suggests the need for a test to check coverage.

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

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

From mcimadamore at openjdk.java.net  Wed Sep 29 16:05:33 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 29 Sep 2021 16:05:33 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v2]
In-Reply-To: <aWX6-iUHQorNM2vWY30_CRtPsecpuHttGRpT0ZScil0=.a32c6409-9120-4b9a-ac7b-3bc93291a8ba@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <aWX6-iUHQorNM2vWY30_CRtPsecpuHttGRpT0ZScil0=.a32c6409-9120-4b9a-ac7b-3bc93291a8ba@github.com>
Message-ID: <X-WUfPLcATl4io1piPNESBvJq7U5GOJn90M4zIy9V7k=.ca58ed2e-46d1-4a67-8171-931303d3f16e@github.com>

On Wed, 29 Sep 2021 06:16:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR, which is my proposal to fix an existing regression. This code:
>> 
>> 
>> import java.util.Optional;
>> 
>> class App {
>>     public static void main(String[] args) {
>>         Optional.of("").map(outer -> {
>>             Optional.of("")
>>                 .map(inner -> returnGeneric(outer))
>>                 .ifPresent(String::toString);
>>             return "";
>>         });
>>     }
>> 
>>     private static <RG> RG returnGeneric(RG generic) {
>>         return generic;
>>     }
>> }
>> 
>> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4138:

> 4136: 
> 4137:             Pair<Symbol, JCDiagnostic> c = errCandidate();
> 4138:             if (compactMethodDiags) {

I think what 'm really after here is to drop this branch - e.g. always create the "non compressed" diagnostic (e.g. cannot.apply) with the right position.

But, before returning that, attach a rewriter to it e.g.


            Symbol ws = c.fst.asMemberOf(site, types);
            return diags.create(dkind, log.currentSource(), pos,
                      "cant.apply.symbol",
                      kindName(ws),
                      ws.name == names.init ? ws.owner.name : ws.name,
                      methodArguments(ws.type.getParameterTypes()),
                      methodArguments(argtypes),
                      kindName(ws.owner),
                      ws.owner.type,
                      c.snd).withRewriter(() -> MethodResolutionDiagHelper.rewrite(diags, pos, log.currentSource(), dkind, c.snd));

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4788:

> 4786:                         diag -> diags.create(preferredKind, preferredSource, pos, "prob.found.req", cause) :
> 4787:                         null;
> 4788:                 return diags.create(preferredKind, preferredSource, preferredPos,

I guess here we should return the diagnostic unmodified? E.g. you are still returning a rewritten diagnostic here, the only thing that changes is the position (which is what avoids the bug). What I'm hoping is that we can obtain a new diagnostic (with a rewriter) from an existing diagnostic. See my other comment.

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1716:

> 1714:         chk.reportDeferredDiagnostics();
> 1715:         preview.reportDeferredDiagnostics();
> 1716:         if (log.compressedOutput) {

This can be kept, no?

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

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

From prappo at openjdk.java.net  Wed Sep 29 17:38:37 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 29 Sep 2021 17:38:37 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc
In-Reply-To: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
Message-ID: <Gvi5L9wssX5CMhKLZOmfPjtUZMgkLwx-uTBuKWlUUEg=.f96fbd7d-ea4b-4884-9ca4-d65b9258f0b7@github.com>

On Tue, 28 Sep 2021 00:07:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Augmentations to javac's Xlint:serial checking are out for review (#5709) and various javac and javadoc implementation libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.
> 
> Sending this change out for review separately in an effort to de-bulk the review needed for the new checks themselves.

Is there any semantic difference between "not statically Serilizable" and "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.

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

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

From darcy at openjdk.java.net  Wed Sep 29 17:52:32 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 17:52:32 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc
In-Reply-To: <Gvi5L9wssX5CMhKLZOmfPjtUZMgkLwx-uTBuKWlUUEg=.f96fbd7d-ea4b-4884-9ca4-d65b9258f0b7@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
 <Gvi5L9wssX5CMhKLZOmfPjtUZMgkLwx-uTBuKWlUUEg=.f96fbd7d-ea4b-4884-9ca4-d65b9258f0b7@github.com>
Message-ID: <RzWZC9OkKh67AWsIFZ_saH-094i5JMEVPxLMUjztntw=.d9951263-9755-4d05-b9ad-f870c04da4ce@github.com>

On Wed, 29 Sep 2021 17:35:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 
> 
> Is there any semantic difference between "not statically Serilizable" and "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.

Same semantics. The first phase of this cleanup used "not statically Serilizable"; however, I thought "not a Serilizable type" is a more precise statement. I can make a pass over the PR and make the wording consistent in the new comments.

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

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

From prappo at openjdk.java.net  Wed Sep 29 18:14:35 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 29 Sep 2021 18:14:35 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc
In-Reply-To: <RzWZC9OkKh67AWsIFZ_saH-094i5JMEVPxLMUjztntw=.d9951263-9755-4d05-b9ad-f870c04da4ce@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
 <Gvi5L9wssX5CMhKLZOmfPjtUZMgkLwx-uTBuKWlUUEg=.f96fbd7d-ea4b-4884-9ca4-d65b9258f0b7@github.com>
 <RzWZC9OkKh67AWsIFZ_saH-094i5JMEVPxLMUjztntw=.d9951263-9755-4d05-b9ad-f870c04da4ce@github.com>
Message-ID: <47Onwf3kNIaprB_icxxU4wx50ekna_djnV7uVTDeMDM=.ff519ca5-eaf8-482a-aeb1-47ff4559c8f6@github.com>

On Wed, 29 Sep 2021 17:49:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Is there any semantic difference between "not statically Serilizable" and "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.
> 
> Same semantics. The first phase of this cleanup used "not statically Serilizable"; however, I thought "not a Serilizable type" is a more precise statement. I can make a pass over the PR and make the wording consistent in the new comments.

You could update this PR if only to fix the typo; the phrasing is up to you.

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

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

From darcy at openjdk.java.net  Wed Sep 29 21:13:20 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 21:13:20 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc [v2]
In-Reply-To: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
Message-ID: <FsIOr9SiteGGRbucg_ONc6ysDow4j6l0Ud6EopDVkp4=.a3ea6089-3d02-4c73-8287-cd2740b36378@github.com>

> Augmentations to javac's Xlint:serial checking are out for review (#5709) and various javac and javadoc implementation libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.
> 
> Sending this change out for review separately in an effort to de-bulk the review needed for the new checks themselves.

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

 - Merge branch 'master' into JDK-8274405
 - 8274405: Suppress warnings on non-serializable non-transient instance fields in javac and javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5728/files
  - new: https://git.openjdk.java.net/jdk/pull/5728/files/c7cfa110..7ad3a07c

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

  Stats: 4793 lines in 167 files changed: 3399 ins; 976 del; 418 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5728/head:pull/5728

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

From darcy at openjdk.java.net  Wed Sep 29 21:13:22 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 21:13:22 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc [v2]
In-Reply-To: <47Onwf3kNIaprB_icxxU4wx50ekna_djnV7uVTDeMDM=.ff519ca5-eaf8-482a-aeb1-47ff4559c8f6@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
 <Gvi5L9wssX5CMhKLZOmfPjtUZMgkLwx-uTBuKWlUUEg=.f96fbd7d-ea4b-4884-9ca4-d65b9258f0b7@github.com>
 <RzWZC9OkKh67AWsIFZ_saH-094i5JMEVPxLMUjztntw=.d9951263-9755-4d05-b9ad-f870c04da4ce@github.com>
 <47Onwf3kNIaprB_icxxU4wx50ekna_djnV7uVTDeMDM=.ff519ca5-eaf8-482a-aeb1-47ff4559c8f6@github.com>
Message-ID: <7UbxwE4_Vn9yPuEwjVNoQLD49MxMS_0KZY-FyTe5dJI=.19396863-a6e1-448b-a99b-11d86f993d12@github.com>

On Wed, 29 Sep 2021 18:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 
> 
> > > Is there any semantic difference between "not statically Serilizable" and "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.
> > 
> > 
> > Same semantics. The first phase of this cleanup used "not statically Serilizable"; however, I thought "not a Serilizable type" is a more precise statement. I can make a pass over the PR and make the wording consistent in the new comments.
> 
> You could update this PR if only to fix the typo; the phrasing is up to you.

Wording updated.

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

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

From mcimadamore at openjdk.java.net  Wed Sep 29 21:21:34 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 29 Sep 2021 21:21:34 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v2]
In-Reply-To: <aWX6-iUHQorNM2vWY30_CRtPsecpuHttGRpT0ZScil0=.a32c6409-9120-4b9a-ac7b-3bc93291a8ba@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <aWX6-iUHQorNM2vWY30_CRtPsecpuHttGRpT0ZScil0=.a32c6409-9120-4b9a-ac7b-3bc93291a8ba@github.com>
Message-ID: <XpO2U7JkeMWlbgO07-q4hlCF6yTI26Op0A8KsIfLkFY=.8c5bed31-f4cd-494c-a3c5-4fa61bce92dd@github.com>

On Wed, 29 Sep 2021 06:16:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR, which is my proposal to fix an existing regression. This code:
>> 
>> 
>> import java.util.Optional;
>> 
>> class App {
>>     public static void main(String[] args) {
>>         Optional.of("").map(outer -> {
>>             Optional.of("")
>>                 .map(inner -> returnGeneric(outer))
>>                 .ifPresent(String::toString);
>>             return "";
>>         });
>>     }
>> 
>>     private static <RG> RG returnGeneric(RG generic) {
>>         return generic;
>>     }
>> }
>> 
>> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 710:

> 708:                 break;
> 709:             }
> 710:             if (diagnostic.isFlagSet(JCDiagnostic.DiagnosticFlag.COMPRESSED)) {

Who sets this now?

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

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

From prappo at openjdk.java.net  Wed Sep 29 21:35:38 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 29 Sep 2021 21:35:38 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc [v2]
In-Reply-To: <FsIOr9SiteGGRbucg_ONc6ysDow4j6l0Ud6EopDVkp4=.a3ea6089-3d02-4c73-8287-cd2740b36378@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
 <FsIOr9SiteGGRbucg_ONc6ysDow4j6l0Ud6EopDVkp4=.a3ea6089-3d02-4c73-8287-cd2740b36378@github.com>
Message-ID: <iB_Htk6N-q2gS0DKaqmewoOHOT3Ksa8fO0YLf238d3U=.00531188-258c-4f3a-b3cd-fa42891b15e2@github.com>

On Wed, 29 Sep 2021 21:13:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Augmentations to javac's Xlint:serial checking are out for review (#5709) and various javac and javadoc implementation libraries would need some changes to pass under the expanded checks.
>> 
>> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
>> 
>> I'll run a script to update the copyright year before pushing.
>> 
>> Sending this change out for review separately in an effort to de-bulk the review needed for the new checks themselves.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8274405
>  - 8274405: Suppress warnings on non-serializable non-transient instance fields in javac and javadoc

The javadoc changes look good. Hopefully, those Result errors, whose serial warnings this PR suppresses, will go away in JDK-8267690.

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

Marked as reviewed by prappo (Reviewer).

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

From darcy at openjdk.java.net  Wed Sep 29 22:03:00 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 22:03:00 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc [v3]
In-Reply-To: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
Message-ID: <I8gvJf8-IaGq9FFRwo-HCGs8S95WQzh8c6K7OXaQJJU=.ae83aa03-38c2-48f2-b056-04188dd48fe4@github.com>

> Augmentations to javac's Xlint:serial checking are out for review (#5709) and various javac and javadoc implementation libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.
> 
> Sending this change out for review separately in an effort to de-bulk the review needed for the new checks themselves.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5728/files
  - new: https://git.openjdk.java.net/jdk/pull/5728/files/7ad3a07c..ceb0450e

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

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

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

From jjg at openjdk.java.net  Wed Sep 29 22:55:38 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 29 Sep 2021 22:55:38 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc [v3]
In-Reply-To: <I8gvJf8-IaGq9FFRwo-HCGs8S95WQzh8c6K7OXaQJJU=.ae83aa03-38c2-48f2-b056-04188dd48fe4@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
 <I8gvJf8-IaGq9FFRwo-HCGs8S95WQzh8c6K7OXaQJJU=.ae83aa03-38c2-48f2-b056-04188dd48fe4@github.com>
Message-ID: <tWdqVtTIFHmXTgoTo93IX41emWqkwnWg2fh5bqsya5g=.e86fc204-9831-4ad0-939e-48e446e49850@github.com>

On Wed, 29 Sep 2021 22:03:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Augmentations to javac's Xlint:serial checking are out for review (#5709) and various javac and javadoc implementation libraries would need some changes to pass under the expanded checks.
>> 
>> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
>> 
>> I'll run a script to update the copyright year before pushing.
>> 
>> Sending this change out for review separately in an effort to de-bulk the review needed for the new checks themselves.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

There are 3, maybe just 2,  groups of files in this review.

`sjavac` is an internal utility that ought not to be in the `src/` tree, so the changes there don't matter.

The various `Result` classes and the javadoc exceptions are all "internal" exceptions used for internal control flow, and not intended to be seen by API clients.  As @pavelrappo notes, we have plans to make the `Result` classes go away by rewriting the relevant scanners to make them unnecessary. That leaves the javadoc exceptions. The commented annotations have a slight code-smell about them, in the sense of brushing the warning under the carpet, so to speak. It would be better if there was a better way to remove the cause of the warning, rather than just hiding the warning itself.  But, that's not easy, and the original sin was making `Throwable` (and hence all subtypes) implement `Serializable` in the first place. But, that's the serialization we have and we have to deal with it.

As a final note, I never did like the `Runnable` in the last exception, and seeing it again may be a good reason to try and get rid of it, like those `Result` classes mentioned earlier.   I also note that `DocPath` _could_ be made `Serializable` but `DocFile` cannot reasonably be made serializable (incompatible API change to `Location`) and even thinking about it seems like a case of the tail wagging the elephant!

So, with some disappointment, I accept that the changes you propose are the least bad of the possible solutions, at least for now, and so I approve the review.

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

Marked as reviewed by jjg (Reviewer).

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

From darcy at openjdk.java.net  Wed Sep 29 23:03:03 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 23:03:03 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc [v4]
In-Reply-To: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
Message-ID: <X_ygoyCWHVeUf4NTXbqZOg1HSGxBLesf91vDbdyYTl0=.5b101c38-5088-4d64-a330-3aeee83889b6@github.com>

> Augmentations to javac's Xlint:serial checking are out for review (#5709) and various javac and javadoc implementation libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.
> 
> Sending this change out for review separately in an effort to de-bulk the review needed for the new checks themselves.

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

  Update copyright years.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5728/files
  - new: https://git.openjdk.java.net/jdk/pull/5728/files/ceb0450e..b2a9e636

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

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

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

From darcy at openjdk.java.net  Wed Sep 29 23:05:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 23:05:37 GMT
Subject: Integrated: 8274405: Suppress warnings on non-serializable
 non-transient instance fields in javac and javadoc
In-Reply-To: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
Message-ID: <yslosLoYT3fqayQvg3I2LwxPNEiXz5_9KkyDnNaS0W4=.2b61a1b2-11f8-44e6-be05-590c63a00e12@github.com>

On Tue, 28 Sep 2021 00:07:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Augmentations to javac's Xlint:serial checking are out for review (#5709) and various javac and javadoc implementation libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.
> 
> Sending this change out for review separately in an effort to de-bulk the review needed for the new checks themselves.

This pull request has now been integrated.

Changeset: 97385d4f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/97385d4f166fbd63a7c91d2ee28b5ed75cb02518
Stats:     22 lines in 12 files changed: 12 ins; 0 del; 10 mod

8274405: Suppress warnings on non-serializable non-transient instance fields in javac and javadoc

Reviewed-by: prappo, jjg

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

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

From darcy at openjdk.java.net  Wed Sep 29 23:33:46 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 23:33:46 GMT
Subject: RFR: 8274405: Suppress warnings on non-serializable non-transient
 instance fields in javac and javadoc [v3]
In-Reply-To: <tWdqVtTIFHmXTgoTo93IX41emWqkwnWg2fh5bqsya5g=.e86fc204-9831-4ad0-939e-48e446e49850@github.com>
References: <5VaHWo2fZ0A57RYZw0se7zYszTyhnxDKkf_3W0YQlz4=.95558f3a-0321-40c8-b3f0-c28988a8e496@github.com>
 <I8gvJf8-IaGq9FFRwo-HCGs8S95WQzh8c6K7OXaQJJU=.ae83aa03-38c2-48f2-b056-04188dd48fe4@github.com>
 <tWdqVtTIFHmXTgoTo93IX41emWqkwnWg2fh5bqsya5g=.e86fc204-9831-4ad0-939e-48e446e49850@github.com>
Message-ID: <4G6yeo_zz22RnHTWaLoWMMPx17CfeCX3aTltQ1lK9o8=.b8e3dd4b-81ce-485f-ab0a-6cd66e28b93a@github.com>

On Wed, 29 Sep 2021 22:52:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> 
> 
> There are 3, maybe just 2, groups of files in this review.
> 
> `sjavac` is an internal utility that ought not to be in the `src/` tree, so the changes there don't matter.
> 
> The various `Result` classes and the javadoc exceptions are all "internal" exceptions used for internal control flow, and not intended to be seen by API clients. As @pavelrappo notes, we have plans to make the `Result` classes go away by rewriting the relevant scanners to make them unnecessary. That leaves the javadoc exceptions. The commented annotations have a slight code-smell about them, in the sense of brushing the warning under the carpet, so to speak. It would be better if there was a better way to remove the cause of the warning, rather than just hiding the warning itself. But, that's not easy, and the original sin was making `Throwable` (and hence all subtypes) implement `Serializable` in the first place. But, that's the serialization we have and we have to deal with it.
> 
> As a final note, I never did like the `Runnable` in the last exception, and seeing it again may be a good reason to try and get rid of it, like those `Result` classes mentioned earlier. I also note that `DocPath` _could_ be made `Serializable` but `DocFile` cannot reasonably be made serializable (incompatible API change to `Location`) and even thinking about it seems like a case of the tail wagging the elephant!
> 
> So, with some disappointment, I accept that the changes you propose are the least bad of the possible solutions, at least for now, and so I approve the review.

If I were to see

@SuppressWarning("serial") // Type of field not Serializable
Foo foo;

in new code I would question the serial-design of the class; that is one of my goals with augmenting the Xlint:serial checks, notice possibly questionable serial coding patterns sooner.

For types where maintaining cross-release serial compatibility is not strictly needed, one approach would be to mark the fields as transient and give the class a different serialVersionUID. If serial compatibility is needed the conceptually transient field, i.e. one that cannot meaningful be serialized, could be nulled-out in a writeObject method and ignored in a readObject method, at the cost of maintaining those additional methods.

Fortunately, the the javax.lang.model API, the issues with exception classes having non-Serializable fields was recognized during the design and we marked all such fields and transient and documented the corresponding getters to possibly return null.

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

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

From darcy at openjdk.java.net  Wed Sep 29 23:44:55 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 29 Sep 2021 23:44:55 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields [v5]
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <DyiS_PZHqsKollGKQ4RP_3R1nLli4gjCG8IJFDK4hAg=.2d0e1be5-0243-4d4b-a6db-f3f887acc490@github.com>

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

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

 - Merge branch 'master' into JDK-8202056
 - Fix whitespace.
 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Restore serial checks on java.xml module.
 - Merge branch 'master' into JDK-8202056
 - Appease jcheck
 - Implement checks chegar recommended for interfaces.
 - Update comment.
 - ... and 26 more: https://git.openjdk.java.net/jdk/compare/355356c4...33504e85

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

Changes: https://git.openjdk.java.net/jdk/pull/5709/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=04
  Stats: 1483 lines in 52 files changed: 1476 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

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

From darcy at openjdk.java.net  Thu Sep 30 05:27:34 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 30 Sep 2021 05:27:34 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields [v5]
In-Reply-To: <DyiS_PZHqsKollGKQ4RP_3R1nLli4gjCG8IJFDK4hAg=.2d0e1be5-0243-4d4b-a6db-f3f887acc490@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
 <DyiS_PZHqsKollGKQ4RP_3R1nLli4gjCG8IJFDK4hAg=.2d0e1be5-0243-4d4b-a6db-f3f887acc490@github.com>
Message-ID: <3bVU1cgI_qZvpODMmyW1zhldSHW4aP1bRCQFUZdH2pc=.5d57b1b6-2a70-4661-8e0c-6f315a55675f@github.com>

On Wed, 29 Sep 2021 23:44:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an initial PR for expanded lint warnings done under two bugs:
>> 
>> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
>> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
>> 
>> to get feedback on the general approach and test strategy before further polishing the implementation.
>> 
>> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
>> 
>> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
>> 
>> Please also review the corresponding CSRs:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8274335
>> https://bugs.openjdk.java.net/browse/JDK-8274336
>> 
>> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
>> 
>> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
>> 
>> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - Merge branch 'master' into JDK-8202056
>  - Fix whitespace.
>  - Merge branch 'master' into JDK-8202056
>  - Merge branch 'master' into JDK-8202056
>  - Merge branch 'master' into JDK-8202056
>  - Restore serial checks on java.xml module.
>  - Merge branch 'master' into JDK-8202056
>  - Appease jcheck
>  - Implement checks chegar recommended for interfaces.
>  - Update comment.
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/355356c4...33504e85

Responding to some off-list comments, I wanted to provide some additional framing and context for this PR.

Serialization is a tricky area to get right. Augmented compile-time checks can help catch code with unexpected (and unwanted) semantics. This existing javac Xlint:serial checks help in this regard with the serialVersionUID field. Before the compile-time checks were enabled in the build, there were a handful of unintentionally introduced serial incompatibilities we had to retroactively fix. Also before the check was in the build, when I did a code review or ccc/CSR review of a Serializable type (which includes all exceptions!), I'd try to remember to check for the declaration of a serialVersionUID. I did catch a few omissions, but I much prefer the current situation where javac will always remember to check and developers don't have to worry about that detail anymore. 

The other fields and methods used in serialization can also be mis-declared in various ways. The proposed checks examine fields and methods in serializable types whose names match names of fields and methods, respectively, used in serialization. The declarations are then examined for well-formedness: 

* are all required modifiers present
* are inappropriate modifiers absent
* for fields, is the correct type used
* for methods are the return type, type and number of parameters, and throws clause correct

A warning will be generated if any of these aspects is mismatched.

Also when reviewing a serializable type , I think it worth noting if any of the non-transient instance fields -- the fields whose values will be attempted to be serialized by default -- are not declared to have serializable types. Checking for that condition is the subject of JDK-8160675, also out for review under this PR. Having such fields isn't *necessary* a problem. Dynamically all the objects pointed to by the field may actually be serializable, a that fact is not captured in type system. Or the type may be conditionally serializable based on if its field values are, as commonly found in collections.  However, it could also be an actual oversight worth correcting or at least noting in a comment as an intentional design.

Assuming a form of this PR gets integrated, there are several possible extensions:

* Checking the bodies of readObject and writeObject for one of the mandated method calls (JDK-7019074)
* Checking that the java.io.Serial annotation is only applied to serialization-related fields and methods. Assuming the other checks on structural well-formedness are in place, this additional check is straightforward to implement.

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

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

From sspitsyn at openjdk.java.net  Thu Sep 30 09:56:50 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 30 Sep 2021 09:56:50 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields [v5]
In-Reply-To: <DyiS_PZHqsKollGKQ4RP_3R1nLli4gjCG8IJFDK4hAg=.2d0e1be5-0243-4d4b-a6db-f3f887acc490@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
 <DyiS_PZHqsKollGKQ4RP_3R1nLli4gjCG8IJFDK4hAg=.2d0e1be5-0243-4d4b-a6db-f3f887acc490@github.com>
Message-ID: <LpoUF9chLFDoS73Cbaqd65STQkgyWczZnEBt6WHvsg4=.672c93c3-dc69-49fc-92b4-ce81e100416e@github.com>

On Wed, 29 Sep 2021 23:44:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an initial PR for expanded lint warnings done under two bugs:
>> 
>> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
>> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
>> 
>> to get feedback on the general approach and test strategy before further polishing the implementation.
>> 
>> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
>> 
>> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
>> 
>> Please also review the corresponding CSRs:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8274335
>> https://bugs.openjdk.java.net/browse/JDK-8274336
>> 
>> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
>> 
>> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
>> 
>> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - Merge branch 'master' into JDK-8202056
>  - Fix whitespace.
>  - Merge branch 'master' into JDK-8202056
>  - Merge branch 'master' into JDK-8202056
>  - Merge branch 'master' into JDK-8202056
>  - Restore serial checks on java.xml module.
>  - Merge branch 'master' into JDK-8202056
>  - Appease jcheck
>  - Implement checks chegar recommended for interfaces.
>  - Update comment.
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/355356c4...33504e85

Joe,
The JDI and management fixes look good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From darcy at openjdk.java.net  Thu Sep 30 17:14:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 30 Sep 2021 17:14:37 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields [v6]
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <WZKUPUk48fv4CguJr6qs09rqs7Aw05TH2kUybAox2tM=.824c5cb6-3e1c-4350-944f-368156e4d320@github.com>

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

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

 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Fix whitespace.
 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Restore serial checks on java.xml module.
 - Merge branch 'master' into JDK-8202056
 - Appease jcheck
 - Implement checks chegar recommended for interfaces.
 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/8215b2eb...b67754e5

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

Changes: https://git.openjdk.java.net/jdk/pull/5709/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=05
  Stats: 1471 lines in 44 files changed: 1464 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

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

From darcy at openjdk.java.net  Thu Sep 30 17:59:01 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 30 Sep 2021 17:59:01 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields [v7]
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <E2x6xtnuqJzudGZGZJ2RFr1IqiVNRskiZd16z1GQRE8=.1bb065ed-6de8-44e3-9983-ad3da4fe35cd@github.com>

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

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

 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Fix whitespace.
 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Merge branch 'master' into JDK-8202056
 - Restore serial checks on java.xml module.
 - Merge branch 'master' into JDK-8202056
 - Appease jcheck
 - ... and 28 more: https://git.openjdk.java.net/jdk/compare/73264811...dd2fafd4

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

Changes: https://git.openjdk.java.net/jdk/pull/5709/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=06
  Stats: 1436 lines in 32 files changed: 1429 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

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

From jjg at openjdk.java.net  Thu Sep 30 19:15:30 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 30 Sep 2021 19:15:30 GMT
Subject: RFR: JDK-8273244: Improve diagnostic output related to
 ErroneousTree [v3]
In-Reply-To: <oqsvzyvy5VLWttNOJ-oQzejk9rMY8zJOuOj6isrD5G0=.d526b7d9-48ef-485e-80f8-91b323f809bf@github.com>
References: <g-MV741DFKz43Otc6vMoQZCjdd7z_Zo75ir-0u5rdvU=.85779694-8696-4852-bca6-c0f291dd0be1@github.com>
 <fpLKkmzeSHvLpo3BpLa3r5mjTcGcBePBE0tmgcZNxhc=.f383ff69-353e-4974-8f8f-42646cff8876@github.com>
 <CYk4C6inAvWUTTAztInRVorvaMWR0BWYJqN2R3bLQtk=.649b9b3b-cce9-4cf0-8f94-6924e42bc049@github.com>
 <5k-NokDnsit6veesUaENZNCHMFcqm6pnoxuhmh0fdD0=.094c2232-c80e-459a-b282-201ba28d2d81@github.com>
 <DOewX4UyCvvBQGbXaD4gtt4Q13Ll-aQRKxxY0x70g_g=.303bccb9-d0b1-4e03-9aa2-234c980bb094@github.com>
 <oqsvzyvy5VLWttNOJ-oQzejk9rMY8zJOuOj6isrD5G0=.d526b7d9-48ef-485e-80f8-91b323f809bf@github.com>
Message-ID: <tuud658vCCH3xwscJkQOcFdoWq4mdPnvh5rL19khLMc=.b3269640-9a79-4258-801c-3611de503cf1@github.com>

On Wed, 29 Sep 2021 10:39:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> FWIW, I'm still in two minds whether this should be a switch or overriding methods. It's ... er, disappointing ... that the lack of support for `PROVIDES` and `USES` didn't "automatically" show up in testing.  That may suggest a lack of coverage in the `DocTree` tests, which suggests the need for a test to check coverage.
>
> For the sake of this review, using `switch` would be better: fewer changes, less cognitive load. Later we can think of ways of improving that code. It would be nice to structure it such that it would fail at compile time, if we forgot a case.

It's hard to know how to make it fail at compile time.  There are essentially 3 groups of trees ... inline tags (and other trees that use `DCEndPosTree`), block tags (the big block of cases round about line 177), and "other".  We could arguably move block tags into the `default` case and use a type test, which would improve the future-safety.  We could arguably catch missing cases at runtime with suitable use of `IllegalStateException`.

As for tests, we *do* have tests for `ProvidesTree` and `UsesTree`, but the new `RangeChecker` didn't catch the missing case labels because the basic checks in `RangeChecker` were satisfied by the code in the default case in the switch statement.

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

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

From prappo at openjdk.java.net  Thu Sep 30 19:43:56 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 30 Sep 2021 19:43:56 GMT
Subject: RFR: 8274605: Fix predicate guarantees on returned values in
 (Doc)SourcePositions
Message-ID: <NJNH_lBprOVrlga8zs08zdY3nAxsVHUGi-eWzIIwpmM=.06b0437f-192b-461a-abd5-91e4055cb97b@github.com>

Please review this documentation change. The result might look verbose, but at least it is no longer confusing.

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

Commit messages:
 - Initial commit

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

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