From vromero at openjdk.java.net  Sun May  2 02:10:26 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sun, 2 May 2021 02:10:26 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v6]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <Q1hazTs6avdgmK4wPDgVdT6Ki77SbjGfYOwCSz_8Yho=.7a7afb71-d34a-4fb0-a98e-3542a1e13949@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

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

  restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/2744f615..304fd76a

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

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

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

From jlahoda at openjdk.java.net  Mon May  3 16:41:54 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 3 May 2021 16:41:54 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v6]
In-Reply-To: <Q1hazTs6avdgmK4wPDgVdT6Ki77SbjGfYOwCSz_8Yho=.7a7afb71-d34a-4fb0-a98e-3542a1e13949@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <Q1hazTs6avdgmK4wPDgVdT6Ki77SbjGfYOwCSz_8Yho=.7a7afb71-d34a-4fb0-a98e-3542a1e13949@github.com>
Message-ID: <WBi6bLOB01au08UiVs1yJKeh-V3E1Ll6n8XzgJPqUVM=.afbc01b3-be3d-4a80-a8ac-26288db464d1@github.com>

On Sun, 2 May 2021 02:10:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>> 
>> Thanks
>> 
>> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build

javac changes look good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.java.net  Mon May  3 16:44:01 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 3 May 2021 16:44:01 GMT
Subject: RFR: 8265319: implement Sealed Classes as a standard feature in
 Java, javax.lang.model changes [v2]
In-Reply-To: <ZhTfc1Q_yIidNXTTfP3EXiI6nbuCK5VJs3cnOEhi6yA=.a8ec9a3e-40bf-4a8e-9982-1133141085ea@github.com>
References: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
 <ZhTfc1Q_yIidNXTTfP3EXiI6nbuCK5VJs3cnOEhi6yA=.a8ec9a3e-40bf-4a8e-9982-1133141085ea@github.com>
Message-ID: <mDYRoU3BFOmVvCQ2NIYVxCUzEPsBLQ8rKfyImJYnNKs=.f930fbdd-fad4-4bd8-8c80-08af95f9a2a6@github.com>

On Fri, 30 Apr 2021 17:39:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review the changes needed in javax.lang.model API to make Sealed Classes a final feature in Java. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265320)
>> 
>> Thanks,
>> 
>> note: this PR is related to [PR-3526](https://github.com/openjdk/jdk/pull/3526)
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8265319
>  - 8265319: implement Sealed Classes as a standard feature in Java, javax.lang.model changes

Looks OK to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.java.net  Mon May  3 17:01:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 3 May 2021 17:01:06 GMT
Subject: RFR: 8266436: Synthetic constructor trees have non-null return type
Message-ID: <5YkepgSns03EXftUy1-5iFS7RBOk4EtV2bPNlHXqPOQ=.30541f9a-7d13-4a7f-9739-b7b339072295@github.com>

When javac generates the AST for default (synthetic) constructor, it will create a return type `void` for them, while for ordinary constructors, it uses `null` as the return type. This change proposes to consistently use `null` as the return type of constructors. (Eventually, we might want to avoid generating the synthetic constructor tree.)

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

Commit messages:
 - 8266436: Synthetic constructor trees have non-null return type

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

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

From hannesw at openjdk.java.net  Mon May  3 17:46:17 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 3 May 2021 17:46:17 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v2]
In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
Message-ID: <2Cc6LqVTqC76GLlsAHnJj2UaSzVHjkbgvV1WWfI-pWI=.07358df8-81d1-4a12-ab63-8326907baa49@github.com>

> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed.

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

 - JDK-8250766: Improve signature normalization and move it to CommentHelper
 - Merge branch 'master' into JDK-8250766
 - JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3754/files
  - new: https://git.openjdk.java.net/jdk/pull/3754/files/a64598c2..fa29f553

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

  Stats: 7175 lines in 220 files changed: 4625 ins; 1884 del; 666 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3754.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3754/head:pull/3754

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

From hannesw at openjdk.java.net  Mon May  3 17:52:12 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 3 May 2021 17:52:12 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v3]
In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
Message-ID: <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com>

> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed.

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

  JDK-8250766: Add comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3754/files
  - new: https://git.openjdk.java.net/jdk/pull/3754/files/fa29f553..3284f1ae

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

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

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

From vromero at openjdk.java.net  Mon May  3 18:00:48 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 3 May 2021 18:00:48 GMT
Subject: RFR: 8266436: Synthetic constructor trees have non-null return
 type
In-Reply-To: <5YkepgSns03EXftUy1-5iFS7RBOk4EtV2bPNlHXqPOQ=.30541f9a-7d13-4a7f-9739-b7b339072295@github.com>
References: <5YkepgSns03EXftUy1-5iFS7RBOk4EtV2bPNlHXqPOQ=.30541f9a-7d13-4a7f-9739-b7b339072295@github.com>
Message-ID: <ozoupWoN_sxyPubTaj3rotddxE_cl_uQGAaOeZTn_Io=.2e57627d-0a8a-46c5-b3df-744d0cfaedc0@github.com>

On Mon, 3 May 2021 16:54:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When javac generates the AST for default (synthetic) constructor, it will create a return type `void` for them, while for ordinary constructors, it uses `null` as the return type. This change proposes to consistently use `null` as the return type of constructors. (Eventually, we might want to avoid generating the synthetic constructor tree.)

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From prappo at openjdk.java.net  Tue May  4 17:14:53 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 4 May 2021 17:14:53 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v3]
In-Reply-To: <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
 <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com>
Message-ID: <Jwi5DngJbivsaRDDrB-g6jDifXfpwdMMMqQlHT-hhwE=.2bda609b-05f0-489f-9459-2aa9c0c545d7@github.com>

On Mon, 3 May 2021 17:52:12 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8250766: Add comments

1. Is whitespace immediately preceding `(` expected to be retained? For example, in


@see        java.net.URL#URL
            (java.lang.String,
             ...


2. Can ReferenceTree.getSignature return null? I dislike unnecessary null checks.
3. The test should also check for whitespace around `,` and `.`

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

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

From darcy at openjdk.java.net  Tue May  4 23:10:07 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 4 May 2021 23:10:07 GMT
Subject: RFR: 8244146: javac changes for JEP 306
Message-ID: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>

8244146: javac changes for JEP 306

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

Commit messages:
 - Add explicit test for warning strictfp suppression.
 - Appease jcheck and enabled strictfp in ConstFold.
 - Follow Jan's suggestion for diagnostics timing.
 - Alternate attempt to get warning suppression working; direct annotations don't work.
 - Checkpoint with initial lint implementation and passing langtools regression tests.
 - Appease jcheck.
 - Add explicit test for strictfp-ness checking for methods and constructors.
 - All langtools regression tests pass; switch to filtering out strictfp bit in ClassWriter.
 - 8244146: javac changes for JEP 306
 - Merge branch 'master' into 8244146
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/1afbab63...a0a68baa

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

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

From darcy at openjdk.java.net  Tue May  4 23:10:07 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 4 May 2021 23:10:07 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <zm5iTExdP65sbVnMppd5kpEiD0iI3pwGGST9_wmppgY=.e996aa89-e8e0-4b77-9891-3dcbe1d04de1@github.com>

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8244146: javac changes for JEP 306

Preliminary implementation of JEP 306 in javac; all langtools tests pass with the changes.

To allow the existing strictfp checks to be used (no abstract strictfp methods, etc.), the strictfp-ness is kept through the compiler stages until being filtered out in ClassWriter.

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

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

From briangoetz at openjdk.java.net  Tue May  4 23:10:08 2021
From: briangoetz at openjdk.java.net (Brian Goetz)
Date: Tue, 4 May 2021 23:10:08 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <JNDN1KQPu12LwVeIJ-R6nTTXI3uG99-RmbtADcP22JI=.f7204c9e-d5b5-4943-8652-9193161f4727@github.com>

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8244146: javac changes for JEP 306

I'd like to better understand what the future plan for VM treatment of the `ACC_STRICT` flag.  It would be nice to have a plan to eventually reclaim this flag.  Right now, it seems we're not setting the flag any more in the static compiler (and eliminating it from the reflective view?), but the VM still accepts the flag.  Is there a plan for eventually warning on, and then rejecting, and then repurposing this valuable real estate?

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

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

From darcy at openjdk.java.net  Tue May  4 23:10:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 4 May 2021 23:10:08 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <JNDN1KQPu12LwVeIJ-R6nTTXI3uG99-RmbtADcP22JI=.f7204c9e-d5b5-4943-8652-9193161f4727@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <JNDN1KQPu12LwVeIJ-R6nTTXI3uG99-RmbtADcP22JI=.f7204c9e-d5b5-4943-8652-9193161f4727@github.com>
Message-ID: <UTfF__bdsw9K9W6kN66Fe4Na6jidDPxZaAxqdZm9MPg=.1653f163-4036-4cbb-bc7e-c5acfecf362b@github.com>

On Mon, 3 May 2021 17:27:58 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

> 
> 
> I'd like to better understand what the future plan for VM treatment of the `ACC_STRICT` flag. It would be nice to have a plan to eventually reclaim this flag. Right now, it seems we're not setting the flag any more in the static compiler (and eliminating it from the reflective view?), but the VM still accepts the flag. Is there a plan for eventually warning on, and then rejecting, and then repurposing this valuable real estate?

For the purposes of javac and JEP 306, in the changeset the ACC_STRICT bit is no longer emitted for -source 17/--target 17. This also implies any strictfp-ness is lost from a reflective representation constructed from a class file, which includes annotation processing from a class file (as directly tested for in TestStrictfpRetention.java) and would include core reflection as well.

Some details of the VM handling of ACC_STRICT are still under discussion. A necessary condition to reclaiming the bit for other purposes is having JVM validation checks dependent on class file version since ACC_STRICT to mean strict floating-point evaluation is valid for class file versions 46.0 through 60.0. Presumably accepting ACC_STRICT for class files 46.0 through 60.0 is desirably for compatibility.

Warning of ACC_STRICT on version 61.0 and higher class files is possible.

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

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

From darcy at openjdk.java.net  Tue May  4 23:14:49 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 4 May 2021 23:14:49 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <O7auvBqD_SzlpbPo6hHXFJPablZSz2umM3MTE1-5ss8=.45709cc6-19dd-4018-81a9-d6acc0736dc5@github.com>

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8244146: javac changes for JEP 306

For core-libs, under JEP 306 strictfp would be a no-op under 17. Therefore, the few uses of the strictfp modifier in the base module can be removed.

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

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

From sadayapalam at openjdk.java.net  Wed May  5 05:30:03 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 May 2021 05:30:03 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com>

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8244146: javac changes for JEP 306

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1704:

> 1702:         if (Feature.REDUNDANT_STRICTFP.allowedInSource(source))
> 1703:             result = result & ~STRICTFP;
> 1704: 

Nitpick: Doing in Rome as ... would mean this is better written as 

result &= ~STRICTFP;

to be in harmony with the code in the vicinity

Also I am OK with the feature-allowed-in-source-check, but wonder if it is an overkill for smaller focussed changes like this one. I will say I don't know what is the standard operating procedure. See that elsewhere in Lint.java you are doing 

if (source.compareTo(Source.JDK17) >= 0) {
                values.add(LintCategory.STRICTFP);
}

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

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

From sadayapalam at openjdk.java.net  Wed May  5 05:34:50 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 May 2021 05:34:50 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <yDxihmH0kM8m2r7u_JzdDAT9mke5tiKkOH4Jclg4gAE=.8d951936-0a4e-4eae-aabf-692a12e04a51@github.com>

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8244146: javac changes for JEP 306

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

> 1767: compiler.warn.strictfp=\
> 1768:     as of release 17, all floating-point expressions are evaluated strictly and ''strictfp'' is not required
> 1769: 

Nitpick: Three other uses of floating point in the same file use the non-hyphenated form.

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

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

From sadayapalam at openjdk.java.net  Wed May  5 06:12:50 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 May 2021 06:12:50 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <oHEYFUhi73KCktT9U7OadJY_PEa9pNYBo7AZ9ZIE09M=.e1f47299-7da4-44df-b370-8d4e7eb3a173@github.com>

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8244146: javac changes for JEP 306

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

> 226:         SEALED_CLASSES(JDK17, Fragments.FeatureSealedClasses, DiagKind.PLURAL),
> 227:         // todo: will need to supplement/replace with target feature for writing out classes
> 228:         REDUNDANT_STRICTFP(JDK17),

Is the todo still relevant ??

test/langtools/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java line 34:

> 32:  * @build toolbox.ToolBox toolbox.JavapTask
> 33:  * @run compile -source 16 -g NestedLambdasCastedTest.java
> 34:  * @run main NestedLambdasCastedTest

To massage the existing tests at some places you are passing -source 16 and at others -release 16. Is there some nuance behind it ?

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

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

From sadayapalam at openjdk.java.net  Wed May  5 06:33:02 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 May 2021 06:33:02 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <0ou8zU8wwL-7iYxebr0qd2kjkiFVgVg1DoZ0QLgUabY=.b6ad8ef9-252e-4331-9f6d-26a9b2baf39c@github.com>

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8244146: javac changes for JEP 306

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1326:

> 1324:     private void warnOnExplicitStrictfp(DiagnosticPosition pos, JCTree tree) {
> 1325:         DiagnosticPosition prevLintPos = deferredLintHandler.setPos(tree.pos());
> 1326:         try {

Do we need tree passed as a parameter at all ? Why can't we use just pos instead of tree.pos() Looking at the 3 call sites of checkFlags it seems guaranteed that pos is same as tree.pos() ?

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

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

From hannesw at openjdk.java.net  Wed May  5 06:41:51 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 May 2021 06:41:51 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v3]
In-Reply-To: <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
 <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com>
Message-ID: <HkBvUzBkCvyUujLavSTjo2InrqZhVzku4IEe18z5Inw=.1d3922be-3dae-44e7-bf47-2969448e8bc9@github.com>

On Mon, 3 May 2021 17:52:12 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8250766: Add comments

Thanks for the review, Pavel.

>     1. Is whitespace immediately preceding `(` expected to be retained? For example, in
> 
> 
> ```
> @see        java.net.URL#URL
>             (java.lang.String,
>              ...
> ```

`DocCommentParser#reference` only accepts whitespace within matching `()` or `<>`. A whitespace character before the parentheses as shown above will result in `java.net.URL#URL` being considered the reference and the part in parentheses being considered the label.

> 
>     1. Can ReferenceTree.getSignature return null? I dislike unnecessary null checks.

Yes, it can. This is covered by test/langtools/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java
 
>     2. The test should also check for whitespace around `,` and `.`

Good point, I'll add a commit with a test covering these cases.

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

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

From hannesw at openjdk.java.net  Wed May  5 07:40:25 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 May 2021 07:40:25 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v4]
In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
Message-ID: <Yo4a4SyVR9Otea24XO5zMdslFMmyvmKby2AUAZHGZBg=.51c2566e-10a5-4218-9458-1d263f1b7df6@github.com>

> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed.

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

  JDK-8250766: Additional test for whitespace normalization in @see signature

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3754/files
  - new: https://git.openjdk.java.net/jdk/pull/3754/files/3284f1ae..1a1ee57d

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

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

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

From sadayapalam at openjdk.java.net  Wed May  5 08:15:01 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 May 2021 08:15:01 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <R3dW3bBC59QR3fW3xv1zqKhuL3T9Yx8sHHXk-3-38Kk=.def2b5c4-462d-48d5-a0ca-2e32d5e5bd84@github.com>

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8244146: javac changes for JEP 306

Overall, looks good other than the various minor issues called out.

I wonder if the tests would have turned out to be a good bit simpler if we simply checked diagnostics against a golden file and skipped the toolbox approach. Is there a strong benefit to using the toolbox approach for the present need ??

Also, another model for tests could have been test/langtools/tools/javac//7166455/CheckACC_STRICTFlagOnclinitTest.java 
rather than using an annotation processor.

(Not asking for a change, just an academic question/observation)

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

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

From prappo at openjdk.java.net  Wed May  5 10:33:10 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 5 May 2021 10:33:10 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v4]
In-Reply-To: <Yo4a4SyVR9Otea24XO5zMdslFMmyvmKby2AUAZHGZBg=.51c2566e-10a5-4218-9458-1d263f1b7df6@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
 <Yo4a4SyVR9Otea24XO5zMdslFMmyvmKby2AUAZHGZBg=.51c2566e-10a5-4218-9458-1d263f1b7df6@github.com>
Message-ID: <8xlDt43hoHUYXaGYjS_hqK2yuaekv-J0jiAgCKic1sc=.46e7e829-3f72-42d7-9915-56d76fa79db7@github.com>

On Wed, 5 May 2021 07:40:25 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8250766: Additional test for whitespace normalization in @see signature

Marked as reviewed by prappo (Reviewer).

Almost forgot: trivially update the copyright year in CommentHelper before pushing.

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

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

From prappo at openjdk.java.net  Wed May  5 10:33:10 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 5 May 2021 10:33:10 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v3]
In-Reply-To: <HkBvUzBkCvyUujLavSTjo2InrqZhVzku4IEe18z5Inw=.1d3922be-3dae-44e7-bf47-2969448e8bc9@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
 <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com>
 <HkBvUzBkCvyUujLavSTjo2InrqZhVzku4IEe18z5Inw=.1d3922be-3dae-44e7-bf47-2969448e8bc9@github.com>
Message-ID: <qGqd9laE1c8PHQqTeeDczL5NmQb6of37a5wqkXhhTLk=.59257433-96e8-4946-9d97-ae3c97f01c97@github.com>

On Wed, 5 May 2021 06:39:14 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> `DocCommentParser#reference` only accepts whitespace within matching `()` or `<>`. A whitespace character before the parentheses as shown above will result in `java.net.URL#URL` being considered the reference and the part in parentheses being considered the label.

You are absolutely right. I got immersed in CommentHelper.normalizeSignature so much so that I forgot about separating function of whitespace in positional argument parsing.

> Yes, it can. This is covered by test/langtools/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java

I think it's an empty string that ReferenceTree.getSignature can return, not null. To check that, I modified DCReference as follows and ran the tests (including TestTagMisuse), which all passed:


         DCReference(String signature, JCTree.JCExpression moduleName, JCTree qualExpr, Name member, List<JCTree> paramTypes) {
-            this.signature = signature;
+            this.signature = Objects.requireNonNull(signature);

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

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

From jlahoda at openjdk.java.net  Wed May  5 10:33:50 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 5 May 2021 10:33:50 GMT
Subject: Integrated: 8266436: Synthetic constructor trees have non-null return
 type
In-Reply-To: <5YkepgSns03EXftUy1-5iFS7RBOk4EtV2bPNlHXqPOQ=.30541f9a-7d13-4a7f-9739-b7b339072295@github.com>
References: <5YkepgSns03EXftUy1-5iFS7RBOk4EtV2bPNlHXqPOQ=.30541f9a-7d13-4a7f-9739-b7b339072295@github.com>
Message-ID: <fvU2h2Gh8LLv-oKbCuS89_kYIBVisOYWBs_bUbHPaUI=.b1b23dcd-c1cd-4ca2-89f6-b70e45b23aca@github.com>

On Mon, 3 May 2021 16:54:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When javac generates the AST for default (synthetic) constructor, it will create a return type `void` for them, while for ordinary constructors, it uses `null` as the return type. This change proposes to consistently use `null` as the return type of constructors. (Eventually, we might want to avoid generating the synthetic constructor tree.)

This pull request has now been integrated.

Changeset: a8046c91
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a8046c9157c4dca601843c953ce67f7372a87a52
Stats:     23 lines in 2 files changed: 17 ins; 3 del; 3 mod

8266436: Synthetic constructor trees have non-null return type

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Wed May  5 11:07:51 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 5 May 2021 11:07:51 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com>
Message-ID: <-M66QLwSbyiS_sX4bV7_wdZaQIG2K0nGi5tHz930Icw=.f79c8e30-44d0-4b30-8c4b-7496f9ef021a@github.com>

On Wed, 5 May 2021 05:26:47 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> 8244146: javac changes for JEP 306
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1704:
> 
>> 1702:         if (Feature.REDUNDANT_STRICTFP.allowedInSource(source))
>> 1703:             result = result & ~STRICTFP;
>> 1704: 
> 
> Nitpick: Doing in Rome as ... would mean this is better written as 
> 
> result &= ~STRICTFP;
> 
> to be in harmony with the code in the vicinity
> 
> Also I am OK with the feature-allowed-in-source-check, but wonder if it is an overkill for smaller focussed changes like this one. I will say I don't know what is the standard operating procedure. See that elsewhere in Lint.java you are doing 
> 
> if (source.compareTo(Source.JDK17) >= 0) {
>                 values.add(LintCategory.STRICTFP);
> }

IMO it is better to have an enum constant in Feature for source level changes.

But here, I wonder if a Target method on this place wouldn't be more appropriate. One can write:

javac -source 16 -targete 17 Test.java


If `Test.java` contains `strictfp`, should the classfile have `STRICTFP` set or not?

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

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

From jlahoda at openjdk.java.net  Wed May  5 11:07:52 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 5 May 2021 11:07:52 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <KHVk6GGe_NkrSzQ6CNmyYLd4fsVHbEoQVefi_jKhwpU=.18880a5f-e19e-44c3-abc5-10ecab039cd1@github.com>

On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8244146: javac changes for JEP 306

src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java line 170:

> 168: 
> 169:         allOptions.add("--should-stop=at=FLOW");
> 170:         allOptions.add("-Xlint:unchecked,-strictfp");

I wonder if JShell should also print the `strictfp` warnings, so that the users would learn about this change. If needed, it should be possible to disable this, I think, possibly like:

diff --git a/test/langtools/jdk/jshell/ClassesTest.java b/test/langtools/jdk/jshell/ClassesTest.java
index 082d757b02f..b0b8156e359 100644
--- a/test/langtools/jdk/jshell/ClassesTest.java
+++ b/test/langtools/jdk/jshell/ClassesTest.java
@@ -342,4 +342,9 @@ public class ClassesTest extends KullaTesting {
         assertEval("new A()");
     }
 
+    @Override
+    public void setUp() {
+        setUp(bc -> bc.compilerOptions("-Xlint:-strictfp"));
+    }
+
 }

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

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

From hannesw at openjdk.java.net  Wed May  5 13:55:11 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 May 2021 13:55:11 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v3]
In-Reply-To: <qGqd9laE1c8PHQqTeeDczL5NmQb6of37a5wqkXhhTLk=.59257433-96e8-4946-9d97-ae3c97f01c97@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
 <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com>
 <HkBvUzBkCvyUujLavSTjo2InrqZhVzku4IEe18z5Inw=.1d3922be-3dae-44e7-bf47-2969448e8bc9@github.com>
 <qGqd9laE1c8PHQqTeeDczL5NmQb6of37a5wqkXhhTLk=.59257433-96e8-4946-9d97-ae3c97f01c97@github.com>
Message-ID: <vywKBo8gUwAxfveYTqPNIC_k1Smtu-Ml_qhZXS0ljVs=.4fd032b2-daa1-41ba-8e3c-7145dc19a21d@github.com>

On Wed, 5 May 2021 10:27:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 
> > Yes, it can. This is covered by test/langtools/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java
> 
> I think it's an empty string that ReferenceTree.getSignature can return, not null. To check that, I modified DCReference as follows and ran the tests (including TestTagMisuse), which all passed:
> 
> ```
>          DCReference(String signature, JCTree.JCExpression moduleName, JCTree qualExpr, Name member, List<JCTree> paramTypes) {
> -            this.signature = signature;
> +            this.signature = Objects.requireNonNull(signature);
> ```

You are right, it is it is not `DCReference` that returns `null` but `CommentHelper#getReferencedSignature`, which returns null as default value if there is no reference object to get the signature from. Among the uses of this method there is one that doesn't do a null check, but there's also one that handles `null` differently than `""`. I don't think the issue is serious enough to warrant a separate bug, so I'll just add the missing null check in my final commit.

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

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

From hannesw at openjdk.java.net  Wed May  5 13:55:10 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 May 2021 13:55:10 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v5]
In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
Message-ID: <kZ6Cra_iZairT1djprl_8E3Pqk-6ZMOf1Pgnptf5oxg=.ec9c4581-6de9-43d0-9bd2-9218af627199@github.com>

> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed.

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

  JDK-8250766: Add missing null check and update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3754/files
  - new: https://git.openjdk.java.net/jdk/pull/3754/files/1a1ee57d..13589ffc

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

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

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

From hannesw at openjdk.java.net  Wed May  5 14:03:52 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 May 2021 14:03:52 GMT
Subject: Integrated: JDK-8250766: javadoc adds redundant spaces when @see
 program element is wrapped
In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
Message-ID: <1J2INMoFZYbNnp3CxTgxrDGe6l7VqIBlyaRMIULaJ1I=.b9963359-eb3d-43e1-a9b7-bfa1e8749c26@github.com>

On Wed, 28 Apr 2021 07:47:23 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed.

This pull request has now been integrated.

Changeset: f07bb2f4
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f07bb2f4b986103bba975de29324c7219c14628d
Stats:     84 lines in 5 files changed: 69 ins; 3 del; 12 mod

8250766: javadoc adds redundant spaces when @see program element is wrapped

Reviewed-by: prappo

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

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

From prappo at openjdk.java.net  Wed May  5 14:09:53 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 5 May 2021 14:09:53 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v5]
In-Reply-To: <kZ6Cra_iZairT1djprl_8E3Pqk-6ZMOf1Pgnptf5oxg=.ec9c4581-6de9-43d0-9bd2-9218af627199@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
 <kZ6Cra_iZairT1djprl_8E3Pqk-6ZMOf1Pgnptf5oxg=.ec9c4581-6de9-43d0-9bd2-9218af627199@github.com>
Message-ID: <sn9aFN-sD_t_WZkkcr927VufwRt-EgvtbTWul5Mk8es=.d695fb7f-57d4-4ee8-895e-07e2a64e4a51@github.com>

On Wed, 5 May 2021 13:55:10 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8250766: Add missing null check and update copyright year

Marked as reviewed by prappo (Reviewer).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 471:

> 469:     @SuppressWarnings("fallthrough")
> 470:     private static String normalizeSignature(String sig) {
> 471:         if (sig == null

Consider removing this null check since we've agreed that ReferenceTree.getSignature() does not return null.

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

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

From hannesw at openjdk.java.net  Wed May  5 14:18:52 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 May 2021 14:18:52 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped [v5]
In-Reply-To: <sn9aFN-sD_t_WZkkcr927VufwRt-EgvtbTWul5Mk8es=.d695fb7f-57d4-4ee8-895e-07e2a64e4a51@github.com>
References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com>
 <kZ6Cra_iZairT1djprl_8E3Pqk-6ZMOf1Pgnptf5oxg=.ec9c4581-6de9-43d0-9bd2-9218af627199@github.com>
 <sn9aFN-sD_t_WZkkcr927VufwRt-EgvtbTWul5Mk8es=.d695fb7f-57d4-4ee8-895e-07e2a64e4a51@github.com>
Message-ID: <4kLUUPWbEh7gBDMT1v4rUZBRYUHiZxkqsyL-9-UUvNI=.e9ed915f-ed03-46c6-833b-cf4983683425@github.com>

On Wed, 5 May 2021 14:03:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Consider removing this null check since we've agreed that ReferenceTree.getSignature() does not return null.

Argh... I was all the time thinking about the `Objects.requireNonNullElse` null check in `HtmlDocletWriter`, not this one. Yes, you are absolutely right, this one is superfluous... Unfortunately I already integrated the PR. I guess I can remove it in a future commit.

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

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

From darcy at openjdk.java.net  Wed May  5 17:38:53 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 May 2021 17:38:53 GMT
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <oHEYFUhi73KCktT9U7OadJY_PEa9pNYBo7AZ9ZIE09M=.e1f47299-7da4-44df-b370-8d4e7eb3a173@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <oHEYFUhi73KCktT9U7OadJY_PEa9pNYBo7AZ9ZIE09M=.e1f47299-7da4-44df-b370-8d4e7eb3a173@github.com>
Message-ID: <w-a4GXWKv3VBFika0LMGdVdVFGcqAqpACS5qWAjOEKk=.a4984876-b904-49a1-a855-14218580ff8b@github.com>

On Wed, 5 May 2021 06:07:23 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> 8244146: javac changes for JEP 306
>
> test/langtools/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java line 34:
> 
>> 32:  * @build toolbox.ToolBox toolbox.JavapTask
>> 33:  * @run compile -source 16 -g NestedLambdasCastedTest.java
>> 34:  * @run main NestedLambdasCastedTest
> 
> To massage the existing tests at some places you are passing -source 16 and at others -release 16. Is there some nuance behind it ?

Yes; --release 16 is generally preferred as a cleaner, more complete way of requesting 16-ness from javac. However, use of features like the @modules tag in jtreg can preclude use from --release because of interactions like:

    exporting a package from system module jdk.jdeps is not allowed with --release

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

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

From joe.darcy at oracle.com  Wed May  5 17:55:14 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 5 May 2021 10:55:14 -0700
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <-M66QLwSbyiS_sX4bV7_wdZaQIG2K0nGi5tHz930Icw=.f79c8e30-44d0-4b30-8c4b-7496f9ef021a@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com>
 <-M66QLwSbyiS_sX4bV7_wdZaQIG2K0nGi5tHz930Icw=.f79c8e30-44d0-4b30-8c4b-7496f9ef021a@github.com>
Message-ID: <a02959d5-b587-87eb-e005-132cc9986d11@oracle.com>

On 5/5/2021 4:07 AM, Jan Lahoda wrote:
> On Wed, 5 May 2021 05:26:47 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:
>
>>> 8244146: javac changes for JEP 306
>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1704:
>>
>>> 1702:         if (Feature.REDUNDANT_STRICTFP.allowedInSource(source))
>>> 1703:             result = result & ~STRICTFP;
>>> 1704:
>> Nitpick: Doing in Rome as ... would mean this is better written as
>>
>> result &= ~STRICTFP;
>>
>> to be in harmony with the code in the vicinity
>>
>> Also I am OK with the feature-allowed-in-source-check, but wonder if it is an overkill for smaller focussed changes like this one. I will say I don't know what is the standard operating procedure. See that elsewhere in Lint.java you are doing
>>
>> if (source.compareTo(Source.JDK17) >= 0) {
>>                  values.add(LintCategory.STRICTFP);
>> }
> IMO it is better to have an enum constant in Feature for source level changes.
>
> But here, I wonder if a Target method on this place wouldn't be more appropriate. One can write:
>
> javac -source 16 -targete 17 Test.java
>
>
> If `Test.java` contains `strictfp`, should the classfile have `STRICTFP` set or not?


Good point on the mixed 16 source / 17 target combination Jan. I've 
pushed a revision that adds a predicate to Target and updated the tests 
accordingly.

Thanks,

-Joe


From darcy at openjdk.java.net  Wed May  5 17:56:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 May 2021 17:56:09 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v2]
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <ltk46GAM-T-LHM7Yr_BjEPBOgtLb6KHW8AOKn7THrEA=.294d2909-11c3-4189-8478-3f466f7b326c@github.com>

> 8244146: javac changes for JEP 306

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/3831/files
  - new: https://git.openjdk.java.net/jdk/pull/3831/files/a0a68baa..ec4d163a

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

  Stats: 19 lines in 9 files changed: 10 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3831.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3831/head:pull/3831

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

From bpb at openjdk.java.net  Wed May  5 17:56:09 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 5 May 2021 17:56:09 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v2]
In-Reply-To: <ltk46GAM-T-LHM7Yr_BjEPBOgtLb6KHW8AOKn7THrEA=.294d2909-11c3-4189-8478-3f466f7b326c@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <ltk46GAM-T-LHM7Yr_BjEPBOgtLb6KHW8AOKn7THrEA=.294d2909-11c3-4189-8478-3f466f7b326c@github.com>
Message-ID: <6uVQVYTcinOxRiwYsbc1KYsLX65bA1S8UT6-usy-nJo=.291ee69f-c8bc-40a2-b9e3-089db7dbf2b9@github.com>

On Wed, 5 May 2021 17:53:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8244146: javac changes for JEP 306
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Changes to `java.base` look fine. The other changes should be approved by a separate reviewer.

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

Marked as reviewed by bpb (Reviewer).

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

From naoto at openjdk.java.net  Wed May  5 18:06:52 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 5 May 2021 18:06:52 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v2]
In-Reply-To: <ltk46GAM-T-LHM7Yr_BjEPBOgtLb6KHW8AOKn7THrEA=.294d2909-11c3-4189-8478-3f466f7b326c@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <ltk46GAM-T-LHM7Yr_BjEPBOgtLb6KHW8AOKn7THrEA=.294d2909-11c3-4189-8478-3f466f7b326c@github.com>
Message-ID: <eyXXJslfN5bfZLqMSC_hh7aJjvaoAlODq1a0gAZ88lM=.f9417148-1cf0-47fa-9174-bdd92a84c4cf@github.com>

On Wed, 5 May 2021 17:56:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8244146: javac changes for JEP 306
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 290:

> 288: 
> 289:         /**
> 290:          * Warning about unnecessary uses of the strictfp modifier

Could be better to align with other comments that use "Warn" as a verb.

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

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

From joe.darcy at oracle.com  Wed May  5 18:14:24 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 5 May 2021 11:14:24 -0700
Subject: RFR: 8244146: javac changes for JEP 306
In-Reply-To: <R3dW3bBC59QR3fW3xv1zqKhuL3T9Yx8sHHXk-3-38Kk=.def2b5c4-462d-48d5-a0ca-2e32d5e5bd84@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <R3dW3bBC59QR3fW3xv1zqKhuL3T9Yx8sHHXk-3-38Kk=.def2b5c4-462d-48d5-a0ca-2e32d5e5bd84@github.com>
Message-ID: <01d705f1-c67e-9f5b-0734-1ec3ea408a32@oracle.com>


On 5/5/2021 1:15 AM, Srikanth Adayapalam wrote:
> On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> 8244146: javac changes for JEP 306
> Overall, looks good other than the various minor issues called out.
>
> I wonder if the tests would have turned out to be a good bit simpler if we simply checked diagnostics against a golden file and skipped the toolbox approach. Is there a strong benefit to using the toolbox approach for the present need ??


I've certainly written golden file tests before, but my understanding 
was that approach was? considered out of favor for new work. While there 
are different kinds of overheads for both approaches, I do like the 
all-in-one-file aspect of the toolbox.


>
> Also, another model for tests could have been test/langtools/tools/javac//7166455/CheckACC_STRICTFlagOnclinitTest.java
> rather than using an annotation processor.
>
> (Not asking for a change, just an academic question/observation)

Having worked on annotation processors, I reach for that tool more often 
than others might :-)

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

From jfranck at openjdk.java.net  Wed May  5 18:51:57 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Wed, 5 May 2021 18:51:57 GMT
Subject: RFR: 8263452: Javac slow compilation due to algorithmic complexity
In-Reply-To: <E08ZDwDImMWNy_8BhR31z2ijeDxKf_ErShsAs3gfLnk=.43946497-a910-4774-9220-e56d7d04f699@github.com>
References: <E08ZDwDImMWNy_8BhR31z2ijeDxKf_ErShsAs3gfLnk=.43946497-a910-4774-9220-e56d7d04f699@github.com>
Message-ID: <VI5-vXXKCsUkLTKvQONzoDbsVlXkztAKBbtyQwSGdCk=.26f770e6-5d86-44e3-a222-69cfd2f31fc5@github.com>

On Thu, 15 Apr 2021 16:30:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a class that extends its enclosing class. There are a few places in javac where javac does some actions for the supertype and enclosing class, doing these actions twice in this scenario. If the enclosing class also extends its enclosing class, and its enclosing type does as well, etc., these checks are done for the enclosing classes, and the number of actions grows exponentially.
> 
> Even though this seems like a rare case, we can improve javac by avoiding redoing the checks that were already done. There are two parts:
> -`Check.checkNonCyclicDecl` will not record the hierarchy is acyclic if a supertype uses a full-qualified name, as it considers the hierarchy to be "partial", as it only considers hierarchies non-partial if all super AST nodes are filled with class symbols. The proposed solution is to not mark the hierarchy as partial if a part of the FQN is attributed as a package symbol. As a side tweak, the cycle detector is now proposed to be a Set rather than a List, to improve lookup times.
> -in `attribClass`, first the superclass and enclosing class of the current class are attributed, but these are done even if already done, and in the case of the class hierarchy described here these no-op attributions can be done very many times. The proposed fix is to do the attribution of super/enclosing only once.

Looks good to me, though you should probably get a second reviewer.

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

Marked as reviewed by jfranck (Reviewer).

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

From darcy at openjdk.java.net  Wed May  5 18:56:50 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 May 2021 18:56:50 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v2]
In-Reply-To: <yDxihmH0kM8m2r7u_JzdDAT9mke5tiKkOH4Jclg4gAE=.8d951936-0a4e-4eae-aabf-692a12e04a51@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <yDxihmH0kM8m2r7u_JzdDAT9mke5tiKkOH4Jclg4gAE=.8d951936-0a4e-4eae-aabf-692a12e04a51@github.com>
Message-ID: <OJPgeCc000CI3coPLtLZP6KLS4Zt6p_9gULL27rtUz0=.a98de1c7-900d-46d8-a483-ecaf393d9fd8@github.com>

On Wed, 5 May 2021 05:31:40 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1769:
> 
>> 1767: compiler.warn.strictfp=\
>> 1768:     as of release 17, all floating-point expressions are evaluated strictly and ''strictfp'' is not required
>> 1769: 
> 
> Nitpick: Three other uses of floating point in the same file use the non-hyphenated form.

As an adjective "floating-point" rather than "floating point" is the more correct construction. JLS uses "floating-point" consistently. I'd prefer to change the other three occurrences to "floating-point" for consistency rather than changing this one to "floating point".

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

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

From darcy at openjdk.java.net  Wed May  5 19:37:19 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 May 2021 19:37:19 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v3]
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <xtwNzJP3uDaSeNurcm2eInsiq2O74tM4nDdNSXEcYls=.7a05df99-fbb5-43b9-8ff7-f7dd6a3550fa@github.com>

> 8244146: javac changes for JEP 306

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/3831/files
  - new: https://git.openjdk.java.net/jdk/pull/3831/files/ec4d163a..9773a8a5

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

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

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

From darcy at openjdk.java.net  Wed May  5 19:37:20 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 May 2021 19:37:20 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v2]
In-Reply-To: <eyXXJslfN5bfZLqMSC_hh7aJjvaoAlODq1a0gAZ88lM=.f9417148-1cf0-47fa-9174-bdd92a84c4cf@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <ltk46GAM-T-LHM7Yr_BjEPBOgtLb6KHW8AOKn7THrEA=.294d2909-11c3-4189-8478-3f466f7b326c@github.com>
 <eyXXJslfN5bfZLqMSC_hh7aJjvaoAlODq1a0gAZ88lM=.f9417148-1cf0-47fa-9174-bdd92a84c4cf@github.com>
Message-ID: <U3ghO7UufrV-Tgxb170DJOnc2dXkOmrONabt9YllKgg=.94889a39-55ba-4538-ab8e-a10d6755399a@github.com>

On Wed, 5 May 2021 18:03:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 290:
> 
>> 288: 
>> 289:         /**
>> 290:          * Warning about unnecessary uses of the strictfp modifier
> 
> Could be better to align with other comments that use "Warn" as a verb.

Good catch; fixed.

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

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

From darcy at openjdk.java.net  Wed May  5 19:37:21 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 May 2021 19:37:21 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v3]
In-Reply-To: <OJPgeCc000CI3coPLtLZP6KLS4Zt6p_9gULL27rtUz0=.a98de1c7-900d-46d8-a483-ecaf393d9fd8@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <yDxihmH0kM8m2r7u_JzdDAT9mke5tiKkOH4Jclg4gAE=.8d951936-0a4e-4eae-aabf-692a12e04a51@github.com>
 <OJPgeCc000CI3coPLtLZP6KLS4Zt6p_9gULL27rtUz0=.a98de1c7-900d-46d8-a483-ecaf393d9fd8@github.com>
Message-ID: <Ns21ScNQx6ZurGq7rzhffJP971fSTEtLJhFKFnhlOcg=.f699a337-3dd2-4d41-8aa3-27fd345ecbf3@github.com>

On Wed, 5 May 2021 18:53:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1769:
>> 
>>> 1767: compiler.warn.strictfp=\
>>> 1768:     as of release 17, all floating-point expressions are evaluated strictly and ''strictfp'' is not required
>>> 1769: 
>> 
>> Nitpick: Three other uses of floating point in the same file use the non-hyphenated form.
>
> As an adjective "floating-point" rather than "floating point" is the more correct construction. JLS uses "floating-point" consistently. I'd prefer to change the other three occurrences to "floating-point" for consistency rather than changing this one to "floating point".

Pushed an update to use "floating-point" consistently.

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

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

From darcy at openjdk.java.net  Wed May  5 19:42:54 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 May 2021 19:42:54 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v3]
In-Reply-To: <-M66QLwSbyiS_sX4bV7_wdZaQIG2K0nGi5tHz930Icw=.f79c8e30-44d0-4b30-8c4b-7496f9ef021a@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com>
 <-M66QLwSbyiS_sX4bV7_wdZaQIG2K0nGi5tHz930Icw=.f79c8e30-44d0-4b30-8c4b-7496f9ef021a@github.com>
Message-ID: <sGR-aGHWv5WAb01V26rCD4REzi4LZv9griHkiCjUw7g=.226f31eb-7a6d-47b2-aed3-1156d3f7279c@github.com>

On Wed, 5 May 2021 11:05:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1704:
>> 
>>> 1702:         if (Feature.REDUNDANT_STRICTFP.allowedInSource(source))
>>> 1703:             result = result & ~STRICTFP;
>>> 1704: 
>> 
>> Nitpick: Doing in Rome as ... would mean this is better written as 
>> 
>> result &= ~STRICTFP;
>> 
>> to be in harmony with the code in the vicinity
>> 
>> Also I am OK with the feature-allowed-in-source-check, but wonder if it is an overkill for smaller focussed changes like this one. I will say I don't know what is the standard operating procedure. See that elsewhere in Lint.java you are doing 
>> 
>> if (source.compareTo(Source.JDK17) >= 0) {
>>                 values.add(LintCategory.STRICTFP);
>> }
>
> IMO it is better to have an enum constant in Feature for source level changes.
> 
> But here, I wonder if a Target method on this place wouldn't be more appropriate. One can write:
> 
> javac -source 16 -targete 17 Test.java
> 
> 
> If `Test.java` contains `strictfp`, should the classfile have `STRICTFP` set or not?

Suggestions taken.

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

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

From darcy at openjdk.java.net  Wed May  5 20:00:16 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 May 2021 20:00:16 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v4]
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <AZBLoOuG1SpqaUYSvVOtIGz7Ti8dQqBtLQiJl1VNMQo=.2a7ba973-6160-411b-ba25-0f4353956bd3@github.com>

> 8244146: javac changes for JEP 306

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/3831/files
  - new: https://git.openjdk.java.net/jdk/pull/3831/files/9773a8a5..008a69ef

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

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

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

From darcy at openjdk.java.net  Wed May  5 20:00:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 May 2021 20:00:18 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v4]
In-Reply-To: <0ou8zU8wwL-7iYxebr0qd2kjkiFVgVg1DoZ0QLgUabY=.b6ad8ef9-252e-4331-9f6d-26a9b2baf39c@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <0ou8zU8wwL-7iYxebr0qd2kjkiFVgVg1DoZ0QLgUabY=.b6ad8ef9-252e-4331-9f6d-26a9b2baf39c@github.com>
Message-ID: <0lvFvCRPSupnbEziX7yDoQmBFCeEg9cBJIi4FSelyc0=.55ae6615-2ba7-470b-a698-d54efd5a40f7@github.com>

On Wed, 5 May 2021 06:29:50 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1326:
> 
>> 1324:     private void warnOnExplicitStrictfp(DiagnosticPosition pos, JCTree tree) {
>> 1325:         DiagnosticPosition prevLintPos = deferredLintHandler.setPos(tree.pos());
>> 1326:         try {
> 
> Do we need tree passed as a parameter at all ? Why can't we use just pos instead of tree.pos() Looking at the 3 call sites of checkFlags it seems guaranteed that pos is same as tree.pos() ?

Yes; tree argument is unnecessary, removed in a subsequent push.

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

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

From naoto at openjdk.java.net  Wed May  5 20:47:52 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 5 May 2021 20:47:52 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v4]
In-Reply-To: <AZBLoOuG1SpqaUYSvVOtIGz7Ti8dQqBtLQiJl1VNMQo=.2a7ba973-6160-411b-ba25-0f4353956bd3@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <AZBLoOuG1SpqaUYSvVOtIGz7Ti8dQqBtLQiJl1VNMQo=.2a7ba973-6160-411b-ba25-0f4353956bd3@github.com>
Message-ID: <km48kIK2PRz-8CpV-D4clCWq4hJNdciRfo2Q2PiVJs4=.7865795c-6b93-414f-9ab5-e6caf2207f0c@github.com>

On Wed, 5 May 2021 20:00:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8244146: javac changes for JEP 306
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by naoto (Reviewer).

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

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

From sadayapalam at openjdk.java.net  Thu May  6 03:55:52 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 6 May 2021 03:55:52 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v4]
In-Reply-To: <AZBLoOuG1SpqaUYSvVOtIGz7Ti8dQqBtLQiJl1VNMQo=.2a7ba973-6160-411b-ba25-0f4353956bd3@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
 <AZBLoOuG1SpqaUYSvVOtIGz7Ti8dQqBtLQiJl1VNMQo=.2a7ba973-6160-411b-ba25-0f4353956bd3@github.com>
Message-ID: <N5M6-LFBN_R1IW_nHl2vFVhBr312ot_dAqCg8h79K-0=.f20f85ad-547a-4976-8a6e-03b9894fe307@github.com>

On Wed, 5 May 2021 20:00:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8244146: javac changes for JEP 306
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Javac changes look good to me.

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

Marked as reviewed by sadayapalam (Reviewer).

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

From gli at openjdk.java.net  Thu May  6 14:02:20 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 6 May 2021 14:02:20 GMT
Subject: RFR: 8266625: The method DiagnosticSource#findLine returns wrong
 results when using the boundary values
Message-ID: <WLBmzUsfKhvzI60vBpef87mhMuAyieCMTk9kmLklkEs=.1b3241da-b9f2-456d-8df8-290f4abd445e@github.com>

Hi all,

Currently, when the file object has N characters, the method `DiagnosticSource#findLine(N)` returns true, which is a wrong result. Becase the position is zero-based, the max index is `N-1`.

The methods `getLineNumber`, `getColumnNumber` and `getLine`, which use `findLine` internally, would also return wrong results when using the boundary values.

This patch mainly fixes `DiagnosticSource#findLine(N)` by using the following code.


-            return bp <= bufLen;
+            return bp < bufLen;


A corresponding test `DiagnosticSourceTest.java` is added. Then, the usages of  `getLineNumber`, `getColumnNumber` and `getLine` need to revised. And two existing tests need to be adjusted.

Thank you for taking the time to review.

Best Regards,
--- Guoxiong

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

Commit messages:
 - 8266625: The method DiagnosticSource#findLine returns wrong results when using the boundary values

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

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

From gli at openjdk.java.net  Thu May  6 14:37:13 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 6 May 2021 14:37:13 GMT
Subject: RFR: 8266625: The method DiagnosticSource#findLine returns wrong
 results when using the boundary values [v2]
In-Reply-To: <WLBmzUsfKhvzI60vBpef87mhMuAyieCMTk9kmLklkEs=.1b3241da-b9f2-456d-8df8-290f4abd445e@github.com>
References: <WLBmzUsfKhvzI60vBpef87mhMuAyieCMTk9kmLklkEs=.1b3241da-b9f2-456d-8df8-290f4abd445e@github.com>
Message-ID: <UUeo1vYoPEGAyS7mMk0kEx0e9yMNTbq8l4NgFyzK78Q=.764cd49f-56d1-4f31-ae44-3f4e3a819bc4@github.com>

> Hi all,
> 
> Currently, when the file object has N characters, the method `DiagnosticSource#findLine(N)` returns true, which is a wrong result. Becase the position is zero-based, the max index is `N-1`.
> 
> The methods `getLineNumber`, `getColumnNumber` and `getLine`, which use `findLine` internally, would also return wrong results when using the boundary values.
> 
> This patch mainly fixes `DiagnosticSource#findLine(N)` by using the following code.
> 
> 
> -            return bp <= bufLen;
> +            return bp < bufLen;
> 
> 
> A corresponding test `DiagnosticSourceTest.java` is added. Then, the usages of  `getLineNumber`, `getColumnNumber` and `getLine` need to revised. And two existing tests need to be adjusted.
> 
> Thank you 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:

  Optimize test case: DiagnosticSourceTest

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3899/files
  - new: https://git.openjdk.java.net/jdk/pull/3899/files/facc5a28..a373f68a

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

  Stats: 37 lines in 1 file changed: 1 ins; 17 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3899.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3899/head:pull/3899

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

From hchao at openjdk.java.net  Thu May  6 16:55:09 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 6 May 2021 16:55:09 GMT
Subject: RFR: 8266225: jarsigner is using incorrect security property to show
 weakness of certs
Message-ID: <TGJgWtDN0GV0YWFDzr5UlGwjX73s4Y8_P_3I2wFp7vU=.fa8d40f4-6523-481f-991a-02e830b12943@github.com>

Please review the change to jarsigner so it uses certpath security property in order to properly display the weakness of the certificate algorithms.

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

Commit messages:
 - 8266225:jarsigner is using incorrect security property to show weakness of certs

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

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

From vromero at openjdk.java.net  Thu May  6 19:06:41 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 May 2021 19:06:41 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v7]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <jNF-OSpoltX9uAQfIsPp1FUzxVoTGE22E6CShSLC0f8=.f3ac3333-64fa-420f-a123-47338d5b6058@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

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

 - Merge branch 'master' into JDK-8260517
 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - updating comment after review feedback
 - removing javax.lang.model changes
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - fixing failing regression tests
 - JVM related changes
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/10336a26...0208dcf0

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/304fd76a..0208dcf0

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

  Stats: 18908 lines in 391 files changed: 9887 ins; 4814 del; 4207 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526

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

From vromero at openjdk.java.net  Thu May  6 19:08:25 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 May 2021 19:08:25 GMT
Subject: RFR: 8265319: implement Sealed Classes as a standard feature in
 Java, javax.lang.model changes [v3]
In-Reply-To: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
References: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
Message-ID: <sCplGRxRzYgPvm_YMEiiX_5vvZdAGVz56QYacMEItQw=.9087c864-91d7-42b8-8e4c-2a2025a28408@github.com>

> Please review the changes needed in javax.lang.model API to make Sealed Classes a final feature in Java. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265320)
> 
> Thanks,
> 
> note: this PR is related to [PR-3526](https://github.com/openjdk/jdk/pull/3526)

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

 - Merge branch 'master' into JDK-8265319
 - Merge branch 'master' into JDK-8265319
 - 8265319: implement Sealed Classes as a standard feature in Java, javax.lang.model changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3528/files
  - new: https://git.openjdk.java.net/jdk/pull/3528/files/543f485a..43cf1dbb

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

  Stats: 18908 lines in 391 files changed: 9887 ins; 4814 del; 4207 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3528.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3528/head:pull/3528

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

From vromero at openjdk.java.net  Thu May  6 20:27:09 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 May 2021 20:27:09 GMT
Subject: RFR: 8266645: javac should not check for sealed supertypes in
 intersection types
Message-ID: <n6kQO2Y0kPek-HU4iwW1XhdgVMLgN4whqZrPUqzSF6o=.6296f13f-6075-4f91-a225-32824d7d634d@github.com>

While trying to convert the hierarchy under package java.lang.constant to a sealed one we discovered that the compiler was issuing an error for intersection types when at least one of the types is sealed. The reason for this is that javac creates a synthetic anonymous class that extends and implements the classes and interfaces in the intersection type and then it attributes that synthetic class. The current implementation for sealed classes then issues an error for this anonymous class. The fix is to do not check for sealed supertypes for classes with an intersection type.

TIA

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

Commit messages:
 - 8266645: javac should not check for sealed supertypes in intersection types

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

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

From mcimadamore at openjdk.java.net  Thu May  6 21:01:54 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 6 May 2021 21:01:54 GMT
Subject: RFR: 8266645: javac should not check for sealed supertypes in
 intersection types
In-Reply-To: <n6kQO2Y0kPek-HU4iwW1XhdgVMLgN4whqZrPUqzSF6o=.6296f13f-6075-4f91-a225-32824d7d634d@github.com>
References: <n6kQO2Y0kPek-HU4iwW1XhdgVMLgN4whqZrPUqzSF6o=.6296f13f-6075-4f91-a225-32824d7d634d@github.com>
Message-ID: <P2gP_HSn3Ku8Q-1irWvfAqBSr6eU7fw1yWkdz3Ejw6g=.0a825a1a-7a67-40fd-8098-0d887d6641d7@github.com>

On Thu, 6 May 2021 20:19:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> While trying to convert the hierarchy under package java.lang.constant to a sealed one we discovered that the compiler was issuing an error for intersection types when at least one of the types is sealed. The reason for this is that javac creates a synthetic anonymous class that extends and implements the classes and interfaces in the intersection type and then it attributes that synthetic class. The current implementation for sealed classes then issues an error for this anonymous class. The fix is to do not check for sealed supertypes for classes with an intersection type.
> 
> TIA

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From gli at openjdk.java.net  Fri May  7 03:35:05 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 7 May 2021 03:35:05 GMT
Subject: RFR: 8266675: Optimize IntHashTable for encapsulation and ease of use
Message-ID: <izXGtuGhgj--KRJS5hac1CTI4ONORWAxzkM6yXu2JRg=.608d21ba-8b50-4b1e-85b4-207779ee8318@github.com>

Hi all,

Currently, the class `com.sun.tools.javac.util.IntHashTable` exposes methods `hash(Object key)` and `lookup(Object key)` to users. It is not good because they are internal methods to achieve the features.

On the other hand, the index of the mapping (key or value) is the internal data struct. The users should not know or use it actually. So the parameters of the following methods should be revised.

1. lookup(Object key, int hash) -> lookup(Object key)
2. getFromIndex(int index) -> get(Object key)
3. putAtIndex(Object key, int value, int index) -> put(Object key, int value)

And the corresponding places where they are used need to be adjusted too.

The patch optimizes them, adds some comments and cleans the code.
Thank you for taking the time to review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - Update copyright
 - 8266675: Optimize IntHashTable for encapsulation and ease of use

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

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

From vromero at openjdk.java.net  Fri May  7 14:41:29 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 7 May 2021 14:41:29 GMT
Subject: RFR: 8266645: javac should not check for sealed supertypes in
 intersection types
In-Reply-To: <n6kQO2Y0kPek-HU4iwW1XhdgVMLgN4whqZrPUqzSF6o=.6296f13f-6075-4f91-a225-32824d7d634d@github.com>
References: <n6kQO2Y0kPek-HU4iwW1XhdgVMLgN4whqZrPUqzSF6o=.6296f13f-6075-4f91-a225-32824d7d634d@github.com>
Message-ID: <7lbkLH8xIp9mNA9VJDTFqvpKwxv3a29sAQ82K6txvMg=.1eba3410-c6aa-4183-ad73-9679366df8bf@github.com>

On Thu, 6 May 2021 20:19:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> While trying to convert the hierarchy under package java.lang.constant to a sealed one we discovered that the compiler was issuing an error for intersection types when at least one of the types is sealed. The reason for this is that javac creates a synthetic anonymous class that extends and implements the classes and interfaces in the intersection type and then it attributes that synthetic class. The current implementation for sealed classes then issues an error for this anonymous class. The fix is to do not check for sealed supertypes for classes with an intersection type.
> 
> TIA

thanks for the review!

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

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

From vromero at openjdk.java.net  Fri May  7 14:41:31 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 7 May 2021 14:41:31 GMT
Subject: Integrated: 8266645: javac should not check for sealed supertypes in
 intersection types
In-Reply-To: <n6kQO2Y0kPek-HU4iwW1XhdgVMLgN4whqZrPUqzSF6o=.6296f13f-6075-4f91-a225-32824d7d634d@github.com>
References: <n6kQO2Y0kPek-HU4iwW1XhdgVMLgN4whqZrPUqzSF6o=.6296f13f-6075-4f91-a225-32824d7d634d@github.com>
Message-ID: <o7OYuDhmE2Qp5AAmZ9ZnjYTc9UJ8E-sxYDE_mF30wz0=.db2eba6f-19bb-43c7-9029-3a52f69b0777@github.com>

On Thu, 6 May 2021 20:19:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> While trying to convert the hierarchy under package java.lang.constant to a sealed one we discovered that the compiler was issuing an error for intersection types when at least one of the types is sealed. The reason for this is that javac creates a synthetic anonymous class that extends and implements the classes and interfaces in the intersection type and then it attributes that synthetic class. The current implementation for sealed classes then issues an error for this anonymous class. The fix is to do not check for sealed supertypes for classes with an intersection type.
> 
> TIA

This pull request has now been integrated.

Changeset: 946b0fe1
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/946b0fe19a8af88a0f0451c86ce4d4790360bb83
Stats:     29 lines in 2 files changed: 20 ins; 6 del; 3 mod

8266645: javac should not check for sealed supertypes in intersection types

Reviewed-by: mcimadamore

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

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

From mcimadamore at openjdk.java.net  Fri May  7 18:08:26 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 7 May 2021 18:08:26 GMT
Subject: RFR: 8266675: Optimize IntHashTable for encapsulation and ease of
 use
In-Reply-To: <izXGtuGhgj--KRJS5hac1CTI4ONORWAxzkM6yXu2JRg=.608d21ba-8b50-4b1e-85b4-207779ee8318@github.com>
References: <izXGtuGhgj--KRJS5hac1CTI4ONORWAxzkM6yXu2JRg=.608d21ba-8b50-4b1e-85b4-207779ee8318@github.com>
Message-ID: <67yGPr4N3eoUneFqPOFh6goGd6OvyoMTU6J5JjwK7dA=.9867d808-0540-4e67-93fe-82020118c76e@github.com>

On Fri, 7 May 2021 03:27:25 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Currently, the class `com.sun.tools.javac.util.IntHashTable` exposes methods `hash(Object key)` and `lookup(Object key)` to users. It is not good because they are internal methods to achieve the features.
> 
> On the other hand, the index of the mapping (key or value) is the internal data struct. The users should not know or use it actually. So the parameters of the following methods should be revised.
> 
> 1. lookup(Object key, int hash) -> lookup(Object key)
> 2. getFromIndex(int index) -> get(Object key)
> 3. putAtIndex(Object key, int value, int index) -> put(Object key, int value)
> 
> And the corresponding places where they are used need to be adjusted too.
> 
> The patch optimizes them, adds some comments and cleans the code.
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

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

From gli at openjdk.java.net  Fri May  7 22:52:41 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 7 May 2021 22:52:41 GMT
Subject: RFR: 8266675: Optimize IntHashTable for encapsulation and ease of
 use
In-Reply-To: <67yGPr4N3eoUneFqPOFh6goGd6OvyoMTU6J5JjwK7dA=.9867d808-0540-4e67-93fe-82020118c76e@github.com>
References: <izXGtuGhgj--KRJS5hac1CTI4ONORWAxzkM6yXu2JRg=.608d21ba-8b50-4b1e-85b4-207779ee8318@github.com>
 <67yGPr4N3eoUneFqPOFh6goGd6OvyoMTU6J5JjwK7dA=.9867d808-0540-4e67-93fe-82020118c76e@github.com>
Message-ID: <bMvNV8U7VfWUYJ3rIYjZ1bXPm7WBQyD-OW4prfqCs4A=.60af1d80-bfe9-4c86-8fcf-df89cc077812@github.com>

On Fri, 7 May 2021 18:00:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, the class `com.sun.tools.javac.util.IntHashTable` exposes methods `hash(Object key)` and `lookup(Object key)` to users. It is not good because they are internal methods to achieve the features.
>> 
>> On the other hand, the index of the mapping (key or value) is the internal data struct. The users should not know or use it actually. So the parameters of the following methods should be revised.
>> 
>> 1. lookup(Object key, int hash) -> lookup(Object key)
>> 2. getFromIndex(int index) -> get(Object key)
>> 3. putAtIndex(Object key, int value, int index) -> put(Object key, int value)
>> 
>> And the corresponding places where they are used need to be adjusted too.
>> 
>> The patch optimizes them, adds some comments and cleans the code.
>> Thank you for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Looks good!

@mcimadamore Thanks for your review. Could I get your help to sponsor this patch?

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

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

From gli at openjdk.java.net  Fri May  7 23:00:40 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 7 May 2021 23:00:40 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v3]
In-Reply-To: <lajA6WApDfLggTsVmhk52OwIrWkzIeyZwL80sE7T-OE=.31e3e37c-b7fd-4a22-89f9-4315bf99415f@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <lajA6WApDfLggTsVmhk52OwIrWkzIeyZwL80sE7T-OE=.31e3e37c-b7fd-4a22-89f9-4315bf99415f@github.com>
Message-ID: <odkK6vfktnw84o0WI34vh31eOKqL2Wc_bL29egU3SF4=.942f93b0-8d36-4de8-9715-7caf348cbee5@github.com>

On Thu, 22 Apr 2021 17:43:06 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
>> so that the output of --help-extra is kept clean and concise.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Update copyright
>  - Merge branch 'master' into JDK-8230623
>  - Remove the content in documentation javac.1
>  - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint

FYI: The CSR was approved just now.

Could I get your help to review this patch? Thanks a lot.

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

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

From gli at openjdk.java.net  Sat May  8 03:13:23 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sat, 8 May 2021 03:13:23 GMT
Subject: Integrated: 8266675: Optimize IntHashTable for encapsulation and ease
 of use
In-Reply-To: <izXGtuGhgj--KRJS5hac1CTI4ONORWAxzkM6yXu2JRg=.608d21ba-8b50-4b1e-85b4-207779ee8318@github.com>
References: <izXGtuGhgj--KRJS5hac1CTI4ONORWAxzkM6yXu2JRg=.608d21ba-8b50-4b1e-85b4-207779ee8318@github.com>
Message-ID: <RpU7nfwTJrXQ4bvRAtqTwPFQARW-ZzJguyBm-UL4oyY=.192f5305-fba5-444e-b80e-75005821211d@github.com>

On Fri, 7 May 2021 03:27:25 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Currently, the class `com.sun.tools.javac.util.IntHashTable` exposes methods `hash(Object key)` and `lookup(Object key)` to users. It is not good because they are internal methods to achieve the features.
> 
> On the other hand, the index of the mapping (key or value) is the internal data struct. The users should not know or use it actually. So the parameters of the following methods should be revised.
> 
> 1. lookup(Object key, int hash) -> lookup(Object key)
> 2. getFromIndex(int index) -> get(Object key)
> 3. putAtIndex(Object key, int value, int index) -> put(Object key, int value)
> 
> And the corresponding places where they are used need to be adjusted too.
> 
> The patch optimizes them, adds some comments and cleans the code.
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: ff77ca8b
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff77ca8bd41ece778cf6f1af6dd1b7a7dfc50eab
Stats:     46 lines in 2 files changed: 10 ins; 19 del; 17 mod

8266675: Optimize IntHashTable for encapsulation and ease of use

Reviewed-by: mcimadamore

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

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

From lgxbslgx at gmail.com  Sun May  9 11:02:33 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Sun, 9 May 2021 19:02:33 +0800
Subject: [Investigation] The relationship between the compile policies and the
 stop policies
Message-ID: <CAPSsVqiZAytonV2PsSS1Z09P5Z5eU96N3PAkkS0yQQNi_zt8uA@mail.gmail.com>

Hi all,

When I read the code of the
`com.sun.tools.javac.main.JavaCompiler#JavaCompiler(Context context)`, I
found the following strange code.

```
        if (options.isSet("should-stop.at") &&
            CompileState.valueOf(options.get("should-stop.at")) ==
CompileState.ATTR)
            compilePolicy = CompilePolicy.ATTR_ONLY;
        else
            compilePolicy =
CompilePolicy.decode(options.get("compilePolicy"));
```

It means that if the `should-stop.at` is `ATTR`, the compile policy will be
`ATTR_ONLY`. It may be not right. Because `should-stop.at` is the same as
`should-stop.ifError`. If no error occurs, the compilation should continue.
But the `ATTR_ONLY` means that the compilation always finishes after
`ATTR`. Therefore, I think the `should-stop.at=ATTR` is not equal to
`compilePolicy=ATTR_ONLY`.

I searched the submit log of these code. I found these codes were submitted
at JDK-8148808 [1]. Please see the following snippet of the patch[2]
of JDK-8148808.

```

-        attrParseOnly = options.isSet("-attrparseonly");
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.22>
        encoding      = options.get(ENCODING);
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.23>
        lineDebugInfo = options.isUnset(G_CUSTOM) ||
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.24>
                        options.isSet(G_CUSTOM, "lines");
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.25>@@
-405,7 +403,8 @@
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.26>
 <http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.27>
        verboseCompilePolicy = options.isSet("verboseCompilePolicy");
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.28>
 <http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.29>-
       if (attrParseOnly)
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.30>+
       if (options.isSet("shouldStopPolicy") &&
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.31>+
           CompileState.valueOf(options.get("shouldStopPolicy")) ==
CompileState.ATTR)
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.32>
            compilePolicy = CompilePolicy.ATTR_ONLY;
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.33>
        else <http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.34>
            compilePolicy =
CompilePolicy.decode(options.get("compilePolicy"));

```

It removed the option `-attrparseonly` and used `shouldStopPolicy` to
replace `-attrparseonly`.(FYI: `shouldStopPolicy` was changed to `
should-stop.at` in another patch.)
Based on the logic of the code above, the original developer might think
that the following two expressions are the same:

*1. options.isSet("-attrparseonly")*
*2. options.isSet("shouldStopPolicy") *
*    && CompileState.valueOf(options.get("shouldStopPolicy")) ==
CompileState.ATTR)*

Actually it is not the same. The first expression may be same as the
following expression:

*options.isSet("should-stop.ifError") *
*&& CompileState.valueOf(options.get("should-stop.ifError")) ==
CompileState.ATTR)*
*&& options.isSet("should-stop.ifNoError") *
*&& CompileState.valueOf(options.get("should-stop.ifNoError")) ==
CompileState.ATTR)*

Anyway, I don't think it is a good idea to mix the compile policies and the
stop policies. So we should only keep this line:

```
            compilePolicy =
CompilePolicy.decode(options.get("compilePolicy"));
```

and remove the following codes:

```
        if (options.isSet("should-stop.at") &&
            CompileState.valueOf(options.get("should-stop.at")) ==
CompileState.ATTR)
            compilePolicy = CompilePolicy.ATTR_ONLY;
        else
```

What's your opinion? Especially, should we mix the compile policies and the
stop policies? Should there be a relationship between the compile policies
and the stop policies?
Any idea is appreciated. Thank you.

[1] https://bugs.openjdk.java.net/browse/JDK-8148808
[2] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07

Best Regards,
-- Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210509/03efbce4/attachment.htm>

From maurizio.cimadamore at oracle.com  Mon May 10 09:41:54 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 10 May 2021 10:41:54 +0100
Subject: [Investigation] The relationship between the compile policies and
 the stop policies
In-Reply-To: <CAPSsVqiZAytonV2PsSS1Z09P5Z5eU96N3PAkkS0yQQNi_zt8uA@mail.gmail.com>
References: <CAPSsVqiZAytonV2PsSS1Z09P5Z5eU96N3PAkkS0yQQNi_zt8uA@mail.gmail.com>
Message-ID: <2cc777cb-1a96-e877-567b-4cd5dcfd0ece@oracle.com>

I think your analysis is correct.

The issue started to appear when we removed and consolidated unused 
hidden option (JDK-8148808).

But the general issue is that policies such as ATTR_ONLY and CHECK_ONLY 
_predate_ the shouldStop options, with which they do overlap significantly.

I believe that policies such ATTR_ONLY (stops after Attr) and CHECK_ONLY 
(stops after Flow) should be removed - and shouldStop should be used 
instead, since it's equally expressive.

In the future, we might want to evaluate whether there is a need for a 
"dry-run" option, to run javac, emit all possible checks but don't 
generate any classfiles - but for now shouldStop should be usable in 
that respect.

Maurizio


On 09/05/2021 12:02, Guoxiong Li wrote:
> Hi all,
>
> When I read the code of the 
> `com.sun.tools.javac.main.JavaCompiler#JavaCompiler(Context context)`, 
> I found the following strange code.
>
> ```
> ? ? ? ? if (options.isSet("should-stop.at <http://should-stop.at>") &&
> ? ? ? ? ? ? CompileState.valueOf(options.get("should-stop.at 
> <http://should-stop.at>")) == CompileState.ATTR)
> ? ? ? ? ? ? compilePolicy = CompilePolicy.ATTR_ONLY;
> ? ? ? ? else
> ? ? ? ? ? ? compilePolicy = 
> CompilePolicy.decode(options.get("compilePolicy"));
> ```
>
> It means that if the `should-stop.at <http://should-stop.at>` is 
> `ATTR`, the compile policy will be `ATTR_ONLY`. It may be not right. 
> Because `should-stop.at <http://should-stop.at>` is the same as 
> `should-stop.ifError`. If no error occurs, the compilation should 
> continue. But the `ATTR_ONLY` means that the compilation always 
> finishes after `ATTR`. Therefore, I think the `should-stop.at 
> <http://should-stop.at>=ATTR` is not equal to `compilePolicy=ATTR_ONLY`.
>
> I searched the submit log of these code. I found these codes were 
> submitted at JDK-8148808 [1]. Please see the following snippet of the 
> patch[2] of?JDK-8148808.
>
> ```
> - attrParseOnly = options.isSet("-attrparseonly");
> encoding = options.get(ENCODING);
> lineDebugInfo = options.isUnset(G_CUSTOM) ||
> options.isSet(G_CUSTOM, "lines");
> @@ -405,7 +403,8 @@
>
> verboseCompilePolicy = options.isSet("verboseCompilePolicy");
>
> - if (attrParseOnly)
> + if (options.isSet("shouldStopPolicy") &&
> + CompileState.valueOf(options.get("shouldStopPolicy")) == 
> CompileState.ATTR)
> compilePolicy = CompilePolicy.ATTR_ONLY;
> else
> compilePolicy = CompilePolicy.decode(options.get("compilePolicy"));
> ```
>
> It removed the option `-attrparseonly` and used `shouldStopPolicy` to 
> replace `-attrparseonly`.(FYI: `shouldStopPolicy` was changed to 
> `should-stop.at <http://should-stop.at>` in another patch.)
> Based on the logic of the code above, the original developer might 
> think that the following two expressions are the same:
>
> *1. options.isSet("-attrparseonly")*
> *2. options.isSet("shouldStopPolicy") *
> *? ? && CompileState.valueOf(options.get("shouldStopPolicy")) == 
> CompileState.ATTR)*
>
> Actually it is not the same. The first expression may be same as the 
> following expression:
>
> *options.isSet("should-stop.ifError") *
> *&& CompileState.valueOf(options.get("should-stop.ifError")) == 
> CompileState.ATTR)*
> *&&?options.isSet("should-stop.ifNoError") *
> *&& CompileState.valueOf(options.get("should-stop.ifNoError")) == 
> CompileState.ATTR)*
>
> Anyway, I don't think it is a good idea to mix the compile policies 
> and the stop policies. So we should only keep this line:
>
> ```
> ? ? ? ? ? ? compilePolicy = 
> CompilePolicy.decode(options.get("compilePolicy"));
> ```
>
> and remove the following codes:
>
> ```
> ? ? ? ? if (options.isSet("should-stop.at <http://should-stop.at>") &&
> ? ? ? ? ? ? CompileState.valueOf(options.get("should-stop.at 
> <http://should-stop.at>")) == CompileState.ATTR)
> ? ? ? ? ? ? compilePolicy = CompilePolicy.ATTR_ONLY;
> ? ? ? ? else
> ```
>
> What's your opinion? Especially, should we mix the compile policies 
> and the stop policies? Should there be a relationship between the 
> compile policies and the stop policies?
> Any idea is appreciated. Thank you.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8148808 
> <https://bugs.openjdk.java.net/browse/JDK-8148808>
> [2] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07 
> <http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07>
>
> Best Regards,
> -- Guoxiong
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210510/d716f7bb/attachment.htm>

From gli at openjdk.java.net  Mon May 10 13:34:58 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 10 May 2021 13:34:58 GMT
Subject: RFR: 8266796: Clean up the unnecessary code in the method
 UnsharedNameTable#fromUtf
Message-ID: <nP6VtleBvkfDhjDXy2odvYTsLPwaMaZPU9_5PNACGek=.7a98101c-eb1c-44c3-b782-77a7dc56f87d@github.com>

Hi all,

This little patch cleans up the redundant code. Please see the code below. 


        while (element != null) {
            if (element == null) {
                break;
            }


The `while (element != null)` has already checked the `element`. So the `if (element == null)` is redundant and unnecessary.

Thank you for taking the time to review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - 8266796: Clean up the unnecessary code in the method UnsharedNameTable#fromUtf

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

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

From mcimadamore at openjdk.java.net  Mon May 10 14:03:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 14:03:55 GMT
Subject: RFR: 8266796: Clean up the unnecessary code in the method
 UnsharedNameTable#fromUtf
In-Reply-To: <nP6VtleBvkfDhjDXy2odvYTsLPwaMaZPU9_5PNACGek=.7a98101c-eb1c-44c3-b782-77a7dc56f87d@github.com>
References: <nP6VtleBvkfDhjDXy2odvYTsLPwaMaZPU9_5PNACGek=.7a98101c-eb1c-44c3-b782-77a7dc56f87d@github.com>
Message-ID: <soV4Ya0cITaIAXNXm4WdWNmrunwBDiUQE9eAuW5yKFU=.52f4d4f8-46d4-444d-a7ee-d88578f65fae@github.com>

On Mon, 10 May 2021 03:31:09 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This little patch cleans up the redundant code. Please see the code below. 
> 
> 
>         while (element != null) {
>             if (element == null) {
>                 break;
>             }
> 
> 
> The `while (element != null)` has already checked the `element`. So the `if (element == null)` is redundant and unnecessary.
> 
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From gli at openjdk.java.net  Mon May 10 14:06:54 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 10 May 2021 14:06:54 GMT
Subject: RFR: 8266796: Clean up the unnecessary code in the method
 UnsharedNameTable#fromUtf
In-Reply-To: <soV4Ya0cITaIAXNXm4WdWNmrunwBDiUQE9eAuW5yKFU=.52f4d4f8-46d4-444d-a7ee-d88578f65fae@github.com>
References: <nP6VtleBvkfDhjDXy2odvYTsLPwaMaZPU9_5PNACGek=.7a98101c-eb1c-44c3-b782-77a7dc56f87d@github.com>
 <soV4Ya0cITaIAXNXm4WdWNmrunwBDiUQE9eAuW5yKFU=.52f4d4f8-46d4-444d-a7ee-d88578f65fae@github.com>
Message-ID: <SIFxWGiIy_qDA1I-YsNXxbGiciVaJ7fiybU5Tjch-zk=.b362f021-6084-4762-91a9-76e15ea4dc19@github.com>

On Mon, 10 May 2021 14:00:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> This little patch cleans up the redundant code. Please see the code below. 
>> 
>> 
>>         while (element != null) {
>>             if (element == null) {
>>                 break;
>>             }
>> 
>> 
>> The `while (element != null)` has already checked the `element`. So the `if (element == null)` is redundant and unnecessary.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Looks good

@mcimadamore Thanks for your review. Could I get your help to sponsor this patch?

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

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

From gli at openjdk.java.net  Mon May 10 14:30:59 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 10 May 2021 14:30:59 GMT
Subject: Integrated: 8266796: Clean up the unnecessary code in the method
 UnsharedNameTable#fromUtf
In-Reply-To: <nP6VtleBvkfDhjDXy2odvYTsLPwaMaZPU9_5PNACGek=.7a98101c-eb1c-44c3-b782-77a7dc56f87d@github.com>
References: <nP6VtleBvkfDhjDXy2odvYTsLPwaMaZPU9_5PNACGek=.7a98101c-eb1c-44c3-b782-77a7dc56f87d@github.com>
Message-ID: <kQQ4ypzPjuIvOLciyIuWvXWIixKam5lgXr_aJYs5g5Q=.032f09ca-c6d1-4452-9f55-9494c81b9102@github.com>

On Mon, 10 May 2021 03:31:09 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This little patch cleans up the redundant code. Please see the code below. 
> 
> 
>         while (element != null) {
>             if (element == null) {
>                 break;
>             }
> 
> 
> The `while (element != null)` has already checked the `element`. So the `if (element == null)` is redundant and unnecessary.
> 
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 5d761fcf
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d761fcffd6eea1c5be35d2ddec1479eccb85750
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8266796: Clean up the unnecessary code in the method UnsharedNameTable#fromUtf

Reviewed-by: mcimadamore

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

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

From lgxbslgx at gmail.com  Mon May 10 15:20:55 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Mon, 10 May 2021 23:20:55 +0800
Subject: [Investigation] The relationship between the compile policies and
 the stop policies
In-Reply-To: <2cc777cb-1a96-e877-567b-4cd5dcfd0ece@oracle.com>
References: <CAPSsVqiZAytonV2PsSS1Z09P5Z5eU96N3PAkkS0yQQNi_zt8uA@mail.gmail.com>
 <2cc777cb-1a96-e877-567b-4cd5dcfd0ece@oracle.com>
Message-ID: <CAPSsVqinxRNVOfncHKZhiux_PP0_-RXV9QQ687Ld=qJAUjdesw@mail.gmail.com>

Hi Maurizio,

Thank you for your reply.
I agree with you that ATTR_ONLY and CHECK_ONLY should be removed.

I issued JDK-8266819[1] to track it just now. I would submit a patch to
solve it later.

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

Best Regards,
-- Guoxiong


On Mon, May 10, 2021 at 5:42 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I think your analysis is correct.
>
> The issue started to appear when we removed and consolidated unused hidden
> option (JDK-8148808).
>
> But the general issue is that policies such as ATTR_ONLY and CHECK_ONLY
> _predate_ the shouldStop options, with which they do overlap significantly.
>
> I believe that policies such ATTR_ONLY (stops after Attr) and CHECK_ONLY
> (stops after Flow) should be removed - and shouldStop should be used
> instead, since it's equally expressive.
>
> In the future, we might want to evaluate whether there is a need for a
> "dry-run" option, to run javac, emit all possible checks but don't generate
> any classfiles - but for now shouldStop should be usable in that respect.
>
> Maurizio
>
>
> On 09/05/2021 12:02, Guoxiong Li wrote:
>
> Hi all,
>
> When I read the code of the
> `com.sun.tools.javac.main.JavaCompiler#JavaCompiler(Context context)`, I
> found the following strange code.
>
> ```
>         if (options.isSet("should-stop.at") &&
>             CompileState.valueOf(options.get("should-stop.at")) ==
> CompileState.ATTR)
>             compilePolicy = CompilePolicy.ATTR_ONLY;
>         else
>             compilePolicy =
> CompilePolicy.decode(options.get("compilePolicy"));
> ```
>
> It means that if the `should-stop.at` is `ATTR`, the compile policy will
> be `ATTR_ONLY`. It may be not right. Because `should-stop.at` is the same
> as `should-stop.ifError`. If no error occurs, the compilation should
> continue. But the `ATTR_ONLY` means that the compilation always finishes
> after `ATTR`. Therefore, I think the `should-stop.at=ATTR` is not equal
> to `compilePolicy=ATTR_ONLY`.
>
> I searched the submit log of these code. I found these codes were
> submitted at JDK-8148808 [1]. Please see the following snippet of the
> patch[2] of JDK-8148808.
>
> ```
>
> -        attrParseOnly = options.isSet("-attrparseonly");         encoding      = options.get(ENCODING);         lineDebugInfo = options.isUnset(G_CUSTOM) ||                         options.isSet(G_CUSTOM, "lines");@@ -405,7 +403,8 @@          verboseCompilePolicy = options.isSet("verboseCompilePolicy"); -        if (attrParseOnly)+        if (options.isSet("shouldStopPolicy") &&+            CompileState.valueOf(options.get("shouldStopPolicy")) == CompileState.ATTR)             compilePolicy = CompilePolicy.ATTR_ONLY;         else             compilePolicy = CompilePolicy.decode(options.get("compilePolicy"));
>
> ```
>
> It removed the option `-attrparseonly` and used `shouldStopPolicy` to
> replace `-attrparseonly`.(FYI: `shouldStopPolicy` was changed to `
> should-stop.at` in another patch.)
> Based on the logic of the code above, the original developer might think
> that the following two expressions are the same:
>
> *1. options.isSet("-attrparseonly")*
> *2. options.isSet("shouldStopPolicy") *
> *    && CompileState.valueOf(options.get("shouldStopPolicy")) ==
> CompileState.ATTR)*
>
> Actually it is not the same. The first expression may be same as the
> following expression:
>
> *options.isSet("should-stop.ifError") *
> *&& CompileState.valueOf(options.get("should-stop.ifError")) ==
> CompileState.ATTR)*
> *&& options.isSet("should-stop.ifNoError") *
> *&& CompileState.valueOf(options.get("should-stop.ifNoError")) ==
> CompileState.ATTR)*
>
> Anyway, I don't think it is a good idea to mix the compile policies and
> the stop policies. So we should only keep this line:
>
> ```
>             compilePolicy =
> CompilePolicy.decode(options.get("compilePolicy"));
> ```
>
> and remove the following codes:
>
> ```
>         if (options.isSet("should-stop.at") &&
>             CompileState.valueOf(options.get("should-stop.at")) ==
> CompileState.ATTR)
>             compilePolicy = CompilePolicy.ATTR_ONLY;
>         else
> ```
>
> What's your opinion? Especially, should we mix the compile policies and
> the stop policies? Should there be a relationship between the compile
> policies and the stop policies?
> Any idea is appreciated. Thank you.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8148808
> [2] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07
>
> Best Regards,
> -- Guoxiong
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210510/f25827e6/attachment-0001.htm>

From cushon at google.com  Mon May 10 23:33:07 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 10 May 2021 16:33:07 -0700
Subject: RFR: 8261088: Repeatable annotations without @Target cannot have
 containers that target module declarations
In-Reply-To: <CAL4Qsgs+rPxO-z5BK44h_ZX86JXpVFXoQ76Pyj8P3fSACB6MsQ@mail.gmail.com>
References: <5aDBzJlzTWVrxfvLJfya21s-8t2j299igPflTCLRRHc=.bdd1767a-5cb7-4c65-be6c-292bb17ab418@github.com>
 <CAL4Qsgs+rPxO-z5BK44h_ZX86JXpVFXoQ76Pyj8P3fSACB6MsQ@mail.gmail.com>
Message-ID: <CAL4QsgtgZcjFLu2XwMorefPEO2oSKdXqss=wqGsgfxrrsRpSBA@mail.gmail.com>

Any takers?

I think this is a relatively low-risk (and admittedly low-priority) change,
but it also has some code health value in that it deduplicates logic
related to @Target-less annotations.

There are currently two different lists of default @Target elements (one of
which is used for handling repeatable annotations, one for non-repeatable
annotations), and the lists are out of sync. Fixing this may reduce the
risk that they get further out of sync as new element kinds are added.

On Wed, Apr 21, 2021 at 10:31 AM Liam Miller-Cushon <cushon at google.com>
wrote:

> Hello, is there any additional feedback on this change or the associated
> CSR (JDK-8261181 <https://bugs.openjdk.java.net/browse/JDK-8261181>)?
>
> On Thu, Feb 4, 2021 at 12:59 PM Liam Miller-Cushon <
> cushon at openjdk.java.net> wrote:
>
>> Please review this fix to consolidate handling of default `@Target`s for
>> repeated annotations, and permit repeatable annotations without an
>> `@Target` to have container annotations that explicitly target `MODULE`.
>>
>> -------------
>>
>> Commit messages:
>>  - 8261088: Repeatable annotations without @Target cannot have containers
>> that target module declarations
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/2412/files
>>  Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2412&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8261088
>>   Stats: 88 lines in 4 files changed: 66 ins; 16 del; 6 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/2412.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk
>> pull/2412/head:pull/2412
>>
>> PR: https://git.openjdk.java.net/jdk/pull/2412
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210510/803cf240/attachment.htm>

From gli at openjdk.java.net  Tue May 11 00:50:52 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 00:50:52 GMT
Subject: RFR: 8266819: Separate the stop policies from the compile policies
 completely
Message-ID: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>

Hi all,

This patch removes the compile policies `ATTR_ONLY` and `CHECK_ONLY` so that the compile policies can be separated from the stop policies. And some corresponding tests need to be adjusted, too.

Please see [JDK-8266819](https://bugs.openjdk.java.net/browse/JDK-8266819) and the [original discussion](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-May/016759.html) for more information.

Thank you for taking the time to review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - 8266819: Separate the stop policies from the compile policies completely

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

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

From gli at openjdk.java.net  Tue May 11 01:49:17 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 01:49:17 GMT
Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of
 intersection type in cast
In-Reply-To: <xpJJ3Evrr6AXV68JqbKkY2RFrKsdn8a3YbSgWyyYou8=.63bc2026-df3f-4424-964f-3a37a46f760c@github.com>
References: <xpJJ3Evrr6AXV68JqbKkY2RFrKsdn8a3YbSgWyyYou8=.63bc2026-df3f-4424-964f-3a37a46f760c@github.com>
Message-ID: <ur2w5hb3TICrX8Co08t8SEBrX8biJqxFTJ8pDvQNmDU=.3e011c38-4bdb-4c32-92ee-e49f84b1ff88@github.com>

On Thu, 8 Apr 2021 16:29:04 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Before the phase `desugar`, the demo `(C1 & I1) o` has **one** type-cast sub-tree, `JCTypeIntersection C1&I1`, at the syntax tree. After the phase `desugar`, the `(C1 & I1) o` becomes **three** type-cast sub-trees: `JCTypeIntersection C1&I1`, `I1`, `C1`. So at phase `Gen`, `javac` generates **three** `checkcast` according to the **three** type-cast sub-trees which causes this bug.
> 
> This patch doesn't generate `checkcast` when the type is `JCTypeIntersection` so that the problem can be solved. And a corresponding test case is added.
> 
> Another way to solve this issue is that the `TransTypes` of  the `desugar` should be modified and **two** type-cast sub-trees should be generated instead of **three**. But this way may change more code than my original patch and may cause other regression.
> 
> Thank you for taking the time to review.
> 
> Best Regards.
> --Guoxiong

Ping. Could I ask your help to review this patch? Thanks a lot.

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

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

From gli at openjdk.java.net  Tue May 11 01:51:12 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 01:51:12 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v3]
In-Reply-To: <AYhHO6bn3z23gOJyC1UFlrxvPXs2QHjpJeUj2M3AQ_c=.a3147bd3-7706-4d6f-b665-3dcd4f989122@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
 <AYhHO6bn3z23gOJyC1UFlrxvPXs2QHjpJeUj2M3AQ_c=.a3147bd3-7706-4d6f-b665-3dcd4f989122@github.com>
Message-ID: <NcHTzmMq_CCXj6hKt80axp5GxEt-Pj8V_RxpzPtwJoE=.3fece60e-481d-4452-94f6-ca8bc3a37b86@github.com>

On Fri, 23 Apr 2021 12:01:31 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated.
>>  
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> 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 four additional commits since the last revision:
> 
>  - Use meaningful class name
>  - Merge branch 'master' into JDK-8241187
>  - Revise method and test.
>  - 8241187: ToolBox::grep should allow for negative filtering

Ping. Could I ask your help to review this patch? Thanks a lot.

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

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

From gli at openjdk.java.net  Tue May 11 01:53:41 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 01:53:41 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v3]
In-Reply-To: <4iAX0F9xrfxgTuIxYl1JvUgFqc7Rr6V4BCecemCyXGk=.7f15e598-e1f4-4fa4-9814-e9b22eccc48b@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
 <4iAX0F9xrfxgTuIxYl1JvUgFqc7Rr6V4BCecemCyXGk=.7f15e598-e1f4-4fa4-9814-e9b22eccc48b@github.com>
Message-ID: <XulNSAYjgrWoLvrK7yzkw2YLirPJbSISIwTwE7KJjcs=.769b23cc-df91-4d72-a4fc-67e62c8ef58e@github.com>

On Fri, 23 Apr 2021 12:41:13 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.
>> 
>> This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> 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 four additional commits since the last revision:
> 
>  - Use meaningful class name and update copyright
>  - Merge branch 'master' into JDK-8226216
>  - Modify legal header. Fix typo.
>  - 8226216: parameter modifiers are not visible to javac plugins across compilation boundaries

Ping. Could I ask your help to review this patch? Thanks a lot.

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

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

From gli at openjdk.java.net  Tue May 11 02:18:08 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 02:18:08 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v3]
In-Reply-To: <lajA6WApDfLggTsVmhk52OwIrWkzIeyZwL80sE7T-OE=.31e3e37c-b7fd-4a22-89f9-4315bf99415f@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <lajA6WApDfLggTsVmhk52OwIrWkzIeyZwL80sE7T-OE=.31e3e37c-b7fd-4a22-89f9-4315bf99415f@github.com>
Message-ID: <L7bT_5vLuiKcIzlUw7QWOElStcNEpbBwCEESH1ZM0KM=.19e2b4a5-37d1-4f77-9435-ebc384131545@github.com>

On Thu, 22 Apr 2021 17:43:06 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
>> so that the output of --help-extra is kept clean and concise.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Update copyright
>  - Merge branch 'master' into JDK-8230623
>  - Remove the content in documentation javac.1
>  - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint

Ping. 

This issue may block [JDK-8266239](https://bugs.openjdk.java.net/browse/JDK-8266239).
Could I ask your help to review this patch? Thanks a lot.

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

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

From gli at openjdk.java.net  Tue May 11 02:41:16 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 02:41:16 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v4]
In-Reply-To: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
Message-ID: <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>

> Hi all,
> 
> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
> so that the output of --help-extra is kept clean and concise.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8230623
 - Update copyright
 - Merge branch 'master' into JDK-8230623
 - Remove the content in documentation javac.1
 - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint

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

Changes: https://git.openjdk.java.net/jdk/pull/1758/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1758&range=03
  Stats: 62 lines in 4 files changed: 32 ins; 22 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1758.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1758/head:pull/1758

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

From vromero at openjdk.java.net  Tue May 11 03:41:42 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 11 May 2021 03:41:42 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v3]
In-Reply-To: <AYhHO6bn3z23gOJyC1UFlrxvPXs2QHjpJeUj2M3AQ_c=.a3147bd3-7706-4d6f-b665-3dcd4f989122@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
 <AYhHO6bn3z23gOJyC1UFlrxvPXs2QHjpJeUj2M3AQ_c=.a3147bd3-7706-4d6f-b665-3dcd4f989122@github.com>
Message-ID: <HCfjdzotPoGnyqdcN2giOM3c4llYvovfmGJUeQ_wcsA=.3749de3e-553a-4324-a1a6-1ba3335115fe@github.com>

On Fri, 23 Apr 2021 12:01:31 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated.
>>  
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> 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 four additional commits since the last revision:
> 
>  - Use meaningful class name
>  - Merge branch 'master' into JDK-8241187
>  - Revise method and test.
>  - 8241187: ToolBox::grep should allow for negative filtering

looks good to me with minor suggestion

test/langtools/tools/lib/toolbox/ToolBox.java line 208:

> 206:      * @return the strings matching(or not matching) the regular expression
> 207:      */
> 208:     public List<String> grep(Pattern pattern, List<String> lines, boolean invert) {

what about?


    public List<String> grep(Pattern pattern, List<String> lines, boolean invert) {
        return lines.stream()
                .filter(s -> invert ? !pattern.matcher(s).find() : pattern.matcher(s).find())
                .collect(Collectors.toList());
    }

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

Marked as reviewed by vromero (Reviewer).

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

From github.com+26887752+jaroslavtulach at openjdk.java.net  Tue May 11 03:50:10 2021
From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach)
Date: Tue, 11 May 2021 03:50:10 GMT
Subject: RFR: JDK-8266877: Missing local debug information when debugging
 JEP-330
Message-ID: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>

I am polishing support for [JEP-330](https://openjdk.java.net/jeps/330) in NetBeans ([PR-2938](https://github.com/apache/netbeans/pull/2938)) and I have problems with debugging. Local variables aren't visible as the compiler doesn't pass `-g` option when compiling the main class. I'd like to see 

![obrazek](https://user-images.githubusercontent.com/26887752/117578440-a876e000-b0ee-11eb-85b6-3c998f71879f.png)

however, that requires one to pass `-g` option to the compiler somehow. As far as I can say there is no such way and hence I decided to create this pull request. If I invoke:

$ java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y x.java

it detects JDWP is on and adds `-g` to the compiler arguments. Is this an acceptable improvement? The alternative is to avoid using JEP-330 when debugging and rather generate `.class` by invoking `javac` and then run it as usual, but I'd rather rely on JEP-330 and avoid creation of the `.class` file.

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

Commit messages:
 - Recognizing also -Xrunjdwp: option
 - When jdwp agentlib is on, compile JEP-330's main class with -g option

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

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

From robilad at openjdk.java.net  Tue May 11 03:50:11 2021
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Tue, 11 May 2021 03:50:11 GMT
Subject: RFR: JDK-8266877: Missing local debug information when debugging
 JEP-330
In-Reply-To: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
References: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
Message-ID: <OfTKZjlyfg9iNySCi78qSXJpuU5ERJIg7RrG_hw8GDg=.a905ffa4-b47f-4e7f-b46b-017d93e5ffff@github.com>

On Sun, 9 May 2021 15:51:29 GMT, Jaroslav Tulach <github.com+26887752+JaroslavTulach at openjdk.org> wrote:

> I am polishing support for [JEP-330](https://openjdk.java.net/jeps/330) in NetBeans ([PR-2938](https://github.com/apache/netbeans/pull/2938)) and I have problems with debugging. Local variables aren't visible as the compiler doesn't pass `-g` option when compiling the main class. I'd like to see 
> 
> ![obrazek](https://user-images.githubusercontent.com/26887752/117578440-a876e000-b0ee-11eb-85b6-3c998f71879f.png)
> 
> however, that requires one to pass `-g` option to the compiler somehow. As far as I can say there is no such way and hence I decided to create this pull request. If I invoke:
> 
> $ java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y x.java
> 
> it detects JDWP is on and adds `-g` to the compiler arguments. Is this an acceptable improvement? The alternative is to avoid using JEP-330 when debugging and rather generate `.class` by invoking `javac` and then run it as usual, but I'd rather rely on JEP-330 and avoid creation of the `.class` file.

@JaroslavTulach, I've added your GitHub account to the set of verified accounts for OpenJDK.

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

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

From alanb at openjdk.java.net  Tue May 11 03:50:11 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 03:50:11 GMT
Subject: RFR: JDK-8266877: Missing local debug information when debugging
 JEP-330
In-Reply-To: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
References: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
Message-ID: <C-J_FTaf4mKCIfXbr9RIlOmJJGrK-dmS3F656sPDIHo=.b01b688c-25c3-48ed-aa53-d60f06b1eeea@github.com>

On Sun, 9 May 2021 15:51:29 GMT, Jaroslav Tulach <github.com+26887752+JaroslavTulach at openjdk.org> wrote:

> I am polishing support for [JEP-330](https://openjdk.java.net/jeps/330) in NetBeans ([PR-2938](https://github.com/apache/netbeans/pull/2938)) and I have problems with debugging. Local variables aren't visible as the compiler doesn't pass `-g` option when compiling the main class. I'd like to see 
> 
> ![obrazek](https://user-images.githubusercontent.com/26887752/117578440-a876e000-b0ee-11eb-85b6-3c998f71879f.png)
> 
> however, that requires one to pass `-g` option to the compiler somehow. As far as I can say there is no such way and hence I decided to create this pull request. If I invoke:
> 
> $ java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y x.java
> 
> it detects JDWP is on and adds `-g` to the compiler arguments. Is this an acceptable improvement? The alternative is to avoid using JEP-330 when debugging and rather generate `.class` by invoking `javac` and then run it as usual, but I'd rather rely on JEP-330 and avoid creation of the `.class` file.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 347:

> 345:                     if (opt.startsWith("-agentlib:jdwp")) {
> 346:                         javacOpts.add("-g");
> 347:                     }

The JDWP agent does expose an agent property for tools for the server=y case but it wouldn't be appropriate for the source launcher to look for that. So checking for a CLI option is probably okay, just needs to be  "-agentlib:jdwp=" to avoid matching other agents prefixed with "jdwp". Also check for "-Xrunjdwp:" too because -Xrun is still used.

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

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

From github.com+26887752+jaroslavtulach at openjdk.java.net  Tue May 11 03:50:12 2021
From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach)
Date: Tue, 11 May 2021 03:50:12 GMT
Subject: RFR: JDK-8266877: Missing local debug information when debugging
 JEP-330
In-Reply-To: <C-J_FTaf4mKCIfXbr9RIlOmJJGrK-dmS3F656sPDIHo=.b01b688c-25c3-48ed-aa53-d60f06b1eeea@github.com>
References: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
 <C-J_FTaf4mKCIfXbr9RIlOmJJGrK-dmS3F656sPDIHo=.b01b688c-25c3-48ed-aa53-d60f06b1eeea@github.com>
Message-ID: <FuJ0kvX4Ab_coQzZzrPGj1ZEm4N3rX9ZC2NCck2zhgk=.f46b9f0e-913a-4dd0-b971-137ee344e276@github.com>

On Mon, 10 May 2021 06:09:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I am polishing support for [JEP-330](https://openjdk.java.net/jeps/330) in NetBeans ([PR-2938](https://github.com/apache/netbeans/pull/2938)) and I have problems with debugging. Local variables aren't visible as the compiler doesn't pass `-g` option when compiling the main class. I'd like to see 
>> 
>> ![obrazek](https://user-images.githubusercontent.com/26887752/117578440-a876e000-b0ee-11eb-85b6-3c998f71879f.png)
>> 
>> however, that requires one to pass `-g` option to the compiler somehow. As far as I can say there is no such way and hence I decided to create this pull request. If I invoke:
>> 
>> $ java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y x.java
>> 
>> it detects JDWP is on and adds `-g` to the compiler arguments. Is this an acceptable improvement? The alternative is to avoid using JEP-330 when debugging and rather generate `.class` by invoking `javac` and then run it as usual, but I'd rather rely on JEP-330 and avoid creation of the `.class` file.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 347:
> 
>> 345:                     if (opt.startsWith("-agentlib:jdwp")) {
>> 346:                         javacOpts.add("-g");
>> 347:                     }
> 
> The JDWP agent does expose an agent property for tools for the server=y case but it wouldn't be appropriate for the source launcher to look for that. So checking for a CLI option is probably okay, just needs to be  "-agentlib:jdwp=" to avoid matching other agents prefixed with "jdwp". Also check for "-Xrunjdwp:" too because -Xrun is still used.

Done in 48ecf90

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

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

From github.com+54611912+apa2527 at openjdk.java.net  Tue May 11 03:55:55 2021
From: github.com+54611912+apa2527 at openjdk.java.net (=?UTF-8?B?4Lib4Lie4LiZ4Lie4Lix4LiK4Lij4LmM?= =?UTF-8?B?IA==?= =?UTF-8?B?4Lia4Lij4Lij4Lie4LiI4Lix4LiZ4LiX4Lij4LmM?=)
Date: Tue, 11 May 2021 03:55:55 GMT
Subject: RFR: JDK-8266877: Missing local debug information when debugging
 JEP-330
In-Reply-To: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
References: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
Message-ID: <Sjq-r5I-SZCAAEW-9WDevvrW6URcyInNHKia3lKAvIo=.6d40006e-8dbf-4482-9116-b11b75f2d161@github.com>

On Sun, 9 May 2021 15:51:29 GMT, Jaroslav Tulach <github.com+26887752+JaroslavTulach at openjdk.org> wrote:

> I am polishing support for [JEP-330](https://openjdk.java.net/jeps/330) in NetBeans ([PR-2938](https://github.com/apache/netbeans/pull/2938)) and I have problems with debugging. Local variables aren't visible as the compiler doesn't pass `-g` option when compiling the main class. I'd like to see 
> 
> ![obrazek](https://user-images.githubusercontent.com/26887752/117578440-a876e000-b0ee-11eb-85b6-3c998f71879f.png)
> 
> however, that requires one to pass `-g` option to the compiler somehow. As far as I can say there is no such way and hence I decided to create this pull request. If I invoke:
> 
> $ java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y x.java
> 
> it detects JDWP is on and adds `-g` to the compiler arguments. Is this an acceptable improvement? The alternative is to avoid using JEP-330 when debugging and rather generate `.class` by invoking `javac` and then run it as usual, but I'd rather rely on JEP-330 and avoid creation of the `.class` file.

Marked as reviewed by APA2527 at github.com (no known OpenJDK username).

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

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

From jjg at openjdk.java.net  Tue May 11 03:59:16 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 11 May 2021 03:59:16 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v3]
In-Reply-To: <AYhHO6bn3z23gOJyC1UFlrxvPXs2QHjpJeUj2M3AQ_c=.a3147bd3-7706-4d6f-b665-3dcd4f989122@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
 <AYhHO6bn3z23gOJyC1UFlrxvPXs2QHjpJeUj2M3AQ_c=.a3147bd3-7706-4d6f-b665-3dcd4f989122@github.com>
Message-ID: <uPAqDeOKQeWpGSAJ4pbPLJ9zGY-tsj52dd9D9xatn4o=.6e1a2c80-e4f5-4765-9ab7-a3c953092695@github.com>

On Fri, 23 Apr 2021 12:01:31 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated.
>>  
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> 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 four additional commits since the last revision:
> 
>  - Use meaningful class name
>  - Merge branch 'master' into JDK-8241187
>  - Revise method and test.
>  - 8241187: ToolBox::grep should allow for negative filtering

Changes requested by jjg (Reviewer).

test/langtools/tools/lib/toolbox/ToolBox.java line 192:

> 190:      * @param invert identify positive or negative filtering
> 191:      *               true: negative filtering, return the unmatched strings
> 192:      *               false: positive filtering, return the matched strings

This is not a particularly well-formed javadoc comment.  Imagine the output if you were to run the file through javadoc.

Suggest:

Filters a list of strings according to the given regular expression,
returning either the strings that match or the strings that do not match.
@param regex the regular expression
@param lines the strings to be filtered
@param invert if true, return the lines that do not match; otherwise if false, return the lines that do match.


The `invert` parameter feels "inverted" leading to a "double negative".

Maybe it would be better to call the parameter "match" and invert the sense, so the doc comment reads:


Filters a list of strings according to the given regular expression,
returning either the strings that match or the strings that do not match.
@param regex the regular expression
@param lines the strings to be filtered
@param match if true, return the lines that match; otherwise if false, return the lines that do not match.

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

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

From gli at openjdk.java.net  Tue May 11 05:34:22 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 05:34:22 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v4]
In-Reply-To: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
Message-ID: <hLBpG8kxipjPXH46_stbCQeEIpNGpiJhcws_yoK8NGc=.354e421b-3741-43f6-bd58-2b5a792d1bad@github.com>

> Hi all,
> 
> This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated.
>  
> Thank you for taking the time to review.
> 
> Best Regards.

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

  Revise comments. Adjust parameter. Clean code.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1934/files
  - new: https://git.openjdk.java.net/jdk/pull/1934/files/f1ae6684..9058e6f9

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

  Stats: 34 lines in 2 files changed: 4 ins; 10 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1934/head:pull/1934

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

From gli at openjdk.java.net  Tue May 11 05:39:04 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 05:39:04 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v3]
In-Reply-To: <HCfjdzotPoGnyqdcN2giOM3c4llYvovfmGJUeQ_wcsA=.3749de3e-553a-4324-a1a6-1ba3335115fe@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
 <AYhHO6bn3z23gOJyC1UFlrxvPXs2QHjpJeUj2M3AQ_c=.a3147bd3-7706-4d6f-b665-3dcd4f989122@github.com>
 <HCfjdzotPoGnyqdcN2giOM3c4llYvovfmGJUeQ_wcsA=.3749de3e-553a-4324-a1a6-1ba3335115fe@github.com>
Message-ID: <RutHdYr8Sn0uwcD2J92CBQiHRx2A9y20D_LG9AmXZsk=.fb3931ab-659a-4c3b-a535-cc950b49435c@github.com>

On Tue, 11 May 2021 03:37:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> 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 four additional commits since the last revision:
>> 
>>  - Use meaningful class name
>>  - Merge branch 'master' into JDK-8241187
>>  - Revise method and test.
>>  - 8241187: ToolBox::grep should allow for negative filtering
>
> looks good to me with minor suggestion

@vicente-romero-oracle @jonathan-gibbons Thanks for your review. I revised the code according to your suggestion.

> test/langtools/tools/lib/toolbox/ToolBox.java line 208:
> 
>> 206:      * @return the strings matching(or not matching) the regular expression
>> 207:      */
>> 208:     public List<String> grep(Pattern pattern, List<String> lines, boolean invert) {
> 
> what about?
> 
> 
>     public List<String> grep(Pattern pattern, List<String> lines, boolean invert) {
>         return lines.stream()
>                 .filter(s -> invert ? !pattern.matcher(s).find() : pattern.matcher(s).find())
>                 .collect(Collectors.toList());
>     }

Putting the `invert` into method `filter` may cause a little performance influence. Is it similar to `loop`? 
Because this is the test code, I adopt your suggestion.

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

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

From gli at openjdk.java.net  Tue May 11 05:39:14 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 05:39:14 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v3]
In-Reply-To: <uPAqDeOKQeWpGSAJ4pbPLJ9zGY-tsj52dd9D9xatn4o=.6e1a2c80-e4f5-4765-9ab7-a3c953092695@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
 <AYhHO6bn3z23gOJyC1UFlrxvPXs2QHjpJeUj2M3AQ_c=.a3147bd3-7706-4d6f-b665-3dcd4f989122@github.com>
 <uPAqDeOKQeWpGSAJ4pbPLJ9zGY-tsj52dd9D9xatn4o=.6e1a2c80-e4f5-4765-9ab7-a3c953092695@github.com>
Message-ID: <QgmouGA1EXugbBox7DJ20kAj0JaSkQ-HPJkLWkWh-9E=.53b12440-bd0d-4262-aabd-7cb583bec470@github.com>

On Tue, 11 May 2021 03:56:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> 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 four additional commits since the last revision:
>> 
>>  - Use meaningful class name
>>  - Merge branch 'master' into JDK-8241187
>>  - Revise method and test.
>>  - 8241187: ToolBox::grep should allow for negative filtering
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 192:
> 
>> 190:      * @param invert identify positive or negative filtering
>> 191:      *               true: negative filtering, return the unmatched strings
>> 192:      *               false: positive filtering, return the matched strings
> 
> This is not a particularly well-formed javadoc comment.  Imagine the output if you were to run the file through javadoc.
> 
> Suggest:
> 
> Filters a list of strings according to the given regular expression,
> returning either the strings that match or the strings that do not match.
> @param regex the regular expression
> @param lines the strings to be filtered
> @param invert if true, return the lines that do not match; otherwise if false, return the lines that do match.
> 
> 
> The `invert` parameter feels "inverted" leading to a "double negative".
> 
> Maybe it would be better to call the parameter "match" and invert the sense, so the doc comment reads:
> 
> 
> Filters a list of strings according to the given regular expression,
> returning either the strings that match or the strings that do not match.
> @param regex the regular expression
> @param lines the strings to be filtered
> @param match if true, return the lines that match; otherwise if false, return the lines that do not match.

Fixed.

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

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

From alanb at openjdk.java.net  Tue May 11 05:45:56 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 05:45:56 GMT
Subject: RFR: JDK-8266877: Missing local debug information when debugging
 JEP-330
In-Reply-To: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
References: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
Message-ID: <nexRGtTaRbnrMdWjZ2-TNR38LjPrPIalVdS_B5uC7GA=.67c391b8-ab9a-4dfd-ad72-947ec7b85fb5@github.com>

On Sun, 9 May 2021 15:51:29 GMT, Jaroslav Tulach <github.com+26887752+JaroslavTulach at openjdk.org> wrote:

> I am polishing support for [JEP-330](https://openjdk.java.net/jeps/330) in NetBeans ([PR-2938](https://github.com/apache/netbeans/pull/2938)) and I have problems with debugging. Local variables aren't visible as the compiler doesn't pass `-g` option when compiling the main class. I'd like to see 
> 
> ![obrazek](https://user-images.githubusercontent.com/26887752/117578440-a876e000-b0ee-11eb-85b6-3c998f71879f.png)
> 
> however, that requires one to pass `-g` option to the compiler somehow. As far as I can say there is no such way and hence I decided to create this pull request. If I invoke:
> 
> $ java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y x.java
> 
> it detects JDWP is on and adds `-g` to the compiler arguments. Is this an acceptable improvement? The alternative is to avoid using JEP-330 when debugging and rather generate `.class` by invoking `javac` and then run it as usual, but I'd rather rely on JEP-330 and avoid creation of the `.class` file.

Marked as reviewed by alanb (Reviewer).

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

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

From jlahoda at openjdk.java.net  Tue May 11 10:09:40 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 11 May 2021 10:09:40 GMT
Subject: Integrated: 8263452: Javac slow compilation due to algorithmic
 complexity
In-Reply-To: <E08ZDwDImMWNy_8BhR31z2ijeDxKf_ErShsAs3gfLnk=.43946497-a910-4774-9220-e56d7d04f699@github.com>
References: <E08ZDwDImMWNy_8BhR31z2ijeDxKf_ErShsAs3gfLnk=.43946497-a910-4774-9220-e56d7d04f699@github.com>
Message-ID: <rC1asScaowKftLGXejC2J-CwQ-BFt5fGxRqxtGPQ6ZU=.25e6005f-4c45-49c2-be43-6d537604f28d@github.com>

On Thu, 15 Apr 2021 16:30:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a class that extends its enclosing class. There are a few places in javac where javac does some actions for the supertype and enclosing class, doing these actions twice in this scenario. If the enclosing class also extends its enclosing class, and its enclosing type does as well, etc., these checks are done for the enclosing classes, and the number of actions grows exponentially.
> 
> Even though this seems like a rare case, we can improve javac by avoiding redoing the checks that were already done. There are two parts:
> -`Check.checkNonCyclicDecl` will not record the hierarchy is acyclic if a supertype uses a full-qualified name, as it considers the hierarchy to be "partial", as it only considers hierarchies non-partial if all super AST nodes are filled with class symbols. The proposed solution is to not mark the hierarchy as partial if a part of the FQN is attributed as a package symbol. As a side tweak, the cycle detector is now proposed to be a Set rather than a List, to improve lookup times.
> -in `attribClass`, first the superclass and enclosing class of the current class are attributed, but these are done even if already done, and in the case of the class hierarchy described here these no-op attributions can be done very many times. The proposed fix is to do the attribution of super/enclosing only once.

This pull request has now been integrated.

Changeset: 8468001f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8468001f8885c0cb2e7db2254eacca857eff2378
Stats:     107 lines in 4 files changed: 101 ins; 0 del; 6 mod

8263452: Javac slow compilation due to algorithmic complexity

Reviewed-by: vromero, jfranck

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

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

From mcimadamore at openjdk.java.net  Tue May 11 10:25:59 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 11 May 2021 10:25:59 GMT
Subject: RFR: 8266819: Separate the stop policies from the compile
 policies completely
In-Reply-To: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
References: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
Message-ID: <CxUfqzpb794abrcmRu1Z8xK1ghvqpNoho1qkDpAH0ME=.222c2399-b139-4cda-82a6-e86012027e2f@github.com>

On Tue, 11 May 2021 00:43:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the compile policies `ATTR_ONLY` and `CHECK_ONLY` so that the compile policies can be separated from the stop policies. And some corresponding tests need to be adjusted, too.
> 
> Please see [JDK-8266819](https://bugs.openjdk.java.net/browse/JDK-8266819) and the [original discussion](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-May/016759.html) for more information.
> 
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

It looks good - note that since this issue changes the set of command line options, it needs a CSR:

https://wiki.openjdk.java.net/display/csr/CSR+FAQs

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

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

From github.com+592810+efge at openjdk.java.net  Tue May 11 10:52:57 2021
From: github.com+592810+efge at openjdk.java.net (Florent Guillaume)
Date: Tue, 11 May 2021 10:52:57 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v4]
In-Reply-To: <hLBpG8kxipjPXH46_stbCQeEIpNGpiJhcws_yoK8NGc=.354e421b-3741-43f6-bd58-2b5a792d1bad@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
 <hLBpG8kxipjPXH46_stbCQeEIpNGpiJhcws_yoK8NGc=.354e421b-3741-43f6-bd58-2b5a792d1bad@github.com>
Message-ID: <y_b0FpPCO97-83077SXhV2tBqBqtfgo5LlYiEkrYD8U=.3bd2e47b-d218-42ba-9426-2c6692b5a322@github.com>

On Tue, 11 May 2021 05:34:22 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated.
>>  
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise comments. Adjust parameter. Clean code.

test/langtools/tools/lib/toolbox/ToolBox.java line 210:

> 208:     public List<String> grep(Pattern pattern, List<String> lines, boolean match) {
> 209:         return lines.stream()
> 210:                 .filter(s -> match ? pattern.matcher(s).find() : !pattern.matcher(s).find())

`s -> pattern.matcher(s).find() ^ !match` would avoid repeating the expression

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

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

From jlahoda at openjdk.java.net  Tue May 11 10:54:16 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 11 May 2021 10:54:16 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v3]
In-Reply-To: <4iAX0F9xrfxgTuIxYl1JvUgFqc7Rr6V4BCecemCyXGk=.7f15e598-e1f4-4fa4-9814-e9b22eccc48b@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
 <4iAX0F9xrfxgTuIxYl1JvUgFqc7Rr6V4BCecemCyXGk=.7f15e598-e1f4-4fa4-9814-e9b22eccc48b@github.com>
Message-ID: <mwpIlxvG3-KQPAtiS8cdF0w9ZGVvnzjHAzyZWy5hfFY=.38422575-c1b4-4626-a8d0-319ebf571acb@github.com>

On Fri, 23 Apr 2021 12:41:13 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.
>> 
>> This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> 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 four additional commits since the last revision:
> 
>  - Use meaningful class name and update copyright
>  - Merge branch 'master' into JDK-8226216
>  - Modify legal header. Fix typo.
>  - 8226216: parameter modifiers are not visible to javac plugins across compilation boundaries

test/langtools/tools/javac/classreader/ParameterModifiersAcrossCompilationBoundaries.java line 87:

> 85:                                         TypeElement typeElement = elements.getTypeElement("B");
> 86:                                         for (Element m : typeElement.getEnclosedElements()) {
> 87:                                             if (m instanceof ExecutableElement) {

Since this is a test, not so huge deal, but it might be better to do filtering using `ElementFilter.methodsIn` - it is easier to use than `Element.getKind()`, and safer than `instanceof` (which is not very much safe for `Element`s).

test/langtools/tools/javac/classreader/ParameterModifiersAcrossCompilationBoundaries.java line 148:

> 146:                 .options("--processor-module-path", "plugin", "-Xplugin:P",
> 147:                          "-parameters", "-classpath", "test")
> 148:                 .files("test/B.java")

Does the test really test the ClassReader behavior? It seems B is always originating in the source, and the test is looking at a parameter from the B file? Maybe the idea was `test/A.java` would be used here?

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

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

From github.com+592810+efge at openjdk.java.net  Tue May 11 12:38:11 2021
From: github.com+592810+efge at openjdk.java.net (Florent Guillaume)
Date: Tue, 11 May 2021 12:38:11 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v4]
In-Reply-To: <y_b0FpPCO97-83077SXhV2tBqBqtfgo5LlYiEkrYD8U=.3bd2e47b-d218-42ba-9426-2c6692b5a322@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
 <hLBpG8kxipjPXH46_stbCQeEIpNGpiJhcws_yoK8NGc=.354e421b-3741-43f6-bd58-2b5a792d1bad@github.com>
 <y_b0FpPCO97-83077SXhV2tBqBqtfgo5LlYiEkrYD8U=.3bd2e47b-d218-42ba-9426-2c6692b5a322@github.com>
Message-ID: <wzijgtzm95dH2I6FJj5CwHpN3JzxJQ0pkY4z4FEROgE=.0518a061-4157-4a08-a076-860e42d61178@github.com>

On Tue, 11 May 2021 10:49:53 GMT, Florent Guillaume <github.com+592810+efge at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise comments. Adjust parameter. Clean code.
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 210:
> 
>> 208:     public List<String> grep(Pattern pattern, List<String> lines, boolean match) {
>> 209:         return lines.stream()
>> 210:                 .filter(s -> match ? pattern.matcher(s).find() : !pattern.matcher(s).find())
> 
> `s -> pattern.matcher(s).find() ^ !match` would avoid repeating the expression

Or probably even simpler `s -> pattern.matcher(s).find() == match`

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

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

From gli at openjdk.java.net  Tue May 11 13:26:24 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 13:26:24 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v5]
In-Reply-To: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
Message-ID: <kOWu80LsBwrGGxMFrVhnBOc6Up4PN2y-cBZEvtHYLsA=.7a1753e9-bc5c-48b8-8c79-f070d8ae30f4@github.com>

> Hi all,
> 
> This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated.
>  
> Thank you for taking the time to review.
> 
> Best Regards.

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

  Clean the code.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1934/files
  - new: https://git.openjdk.java.net/jdk/pull/1934/files/9058e6f9..cffa2391

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

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

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

From gli at openjdk.java.net  Tue May 11 13:26:25 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 13:26:25 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v4]
In-Reply-To: <wzijgtzm95dH2I6FJj5CwHpN3JzxJQ0pkY4z4FEROgE=.0518a061-4157-4a08-a076-860e42d61178@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
 <hLBpG8kxipjPXH46_stbCQeEIpNGpiJhcws_yoK8NGc=.354e421b-3741-43f6-bd58-2b5a792d1bad@github.com>
 <y_b0FpPCO97-83077SXhV2tBqBqtfgo5LlYiEkrYD8U=.3bd2e47b-d218-42ba-9426-2c6692b5a322@github.com>
 <wzijgtzm95dH2I6FJj5CwHpN3JzxJQ0pkY4z4FEROgE=.0518a061-4157-4a08-a076-860e42d61178@github.com>
Message-ID: <VVfymHBBbeBrt_q_imt4F7_bmr6IbtCRBj7PFlPW_jk=.af50ebe7-da66-4e47-a584-6b6ce840dc2e@github.com>

On Tue, 11 May 2021 12:34:43 GMT, Florent Guillaume <github.com+592810+efge at openjdk.org> wrote:

>> test/langtools/tools/lib/toolbox/ToolBox.java line 210:
>> 
>>> 208:     public List<String> grep(Pattern pattern, List<String> lines, boolean match) {
>>> 209:         return lines.stream()
>>> 210:                 .filter(s -> match ? pattern.matcher(s).find() : !pattern.matcher(s).find())
>> 
>> `s -> pattern.matcher(s).find() ^ !match` would avoid repeating the expression
>
> Or probably even simpler `s -> pattern.matcher(s).find() == match`

Good idea. Fixed.

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

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

From jlahoda at openjdk.java.net  Tue May 11 13:42:32 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 11 May 2021 13:42:32 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch
 (Preview)
Message-ID: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>

This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
https://bugs.openjdk.java.net/browse/JDK-8213076

The current draft of the specification is here:
http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html

A summary of notable parts of the patch:
-to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
-to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
-in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
-Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
-TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
-nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.

The specdiff for the change is here (to be updated):
http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

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

Commit messages:
 - Trailing whitespaces.
 - Cleanup, reflecting review comments.
 - Merge branch 'master' into JDK-8262891
 - JDK-8262891: Compiler implementation for Pattern Matching for switch

Changes: https://git.openjdk.java.net/jdk/pull/3863/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262891
  Stats: 3927 lines in 70 files changed: 3636 ins; 97 del; 194 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863

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

From mcimadamore at openjdk.java.net  Tue May 11 13:42:50 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 11 May 2021 13:42:50 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <pk0mBpekpLd-AELuqFEQSLgKamNrMwuqf3n3Eg4J67Y=.634e1d3d-93d8-420a-aaf9-4a91f06d7e6b@github.com>

On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening.

In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 100:

> 98:      *                       the {@code NameAndType} of the {@code InvokeDynamic}
> 99:      *                       structure and is stacked automatically by the VM.
> 100:      * @param labels non-null case labels - {@code String} and {@code Integer} constants

Can these types be mixed? E.g. can I pass, as static args: `42`, `Runnable.class`, `"hello"` ? If not, should be document, and throw?

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 102:

> 100:      * @param labels non-null case labels - {@code String} and {@code Integer} constants
> 101:      *                        and {@code Class} instances
> 102:      * @return the index into {@code labels} of the target value, if the target

Doesn't return an index. Returns a CallSite which, when invoked with an argument of type E (where E is the type of the target expression), returns the index into...

src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 306:

> 304: 
> 305:     /**
> 306:      * Visits an GuardPatternTree node.

Suggestion:

     * Visits a GuardPatternTree node.

src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 316:

> 314: 
> 315:     /**
> 316:      * Visits an AndPatternTree node.

Is this comment correct?

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

> 1683:                         log.error(DiagnosticFlag.SOURCE_LEVEL, selector.pos(),
> 1684:                                   Feature.PATTERN_SWITCH.error(this.sourceName));
> 1685:                         allowPatternSwitch = true;

I assume this logic is to show only one error in case we're compiling multiple methods with pattern switches and preview features are not enabled? Is this consistent with what happens with other preview features though?

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

> 1723:                                     log.error(DiagnosticFlag.SOURCE_LEVEL, expr.pos(),
> 1724:                                               Feature.CASE_NULL.error(this.sourceName));
> 1725:                                     allowCaseNull = true;

Same here about error recovery and minimize messages - if this is what we'd like to do, perhaps centralizing the check in Preview would be better (so that e.g. we'd return that a given preview feature is not supported only once).

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

> 1788:                         if (isTotal) {
> 1789:                             if (hasTotalPattern) {
> 1790:                                 log.error(pat.pos(), Errors.DuplicateTotalPattern);

Hard to explain - but a lot of the code here feels more like it belongs to `Flow` than to `Attr`. E.g. these "duplicateXYZ" labels really want to say "unreachable code", I think. Is there a strong reason as to why all this code shouldn't (apart from code computing bindings) move to Flow? Seems that the logic is partially duplicated anyway...

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

> 1859:         return null;
> 1860:     }
> 1861:     private Pair<Type, Boolean> primaryType(JCPattern pat) {

Maybe a record here would lead for better code (no boxing of Boolean, but, more importantly, better field names for fst/snd). More generally, now that we have records I think we should think twice before using Pairs :-)

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

> 755:         }
> 756: 
> 757:         private TypeSymbol patternType(JCPattern p) {

If we need to keep duplicated code, this could move to TreeInfo

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

> 755:         }
> 756: 
> 757:         private TypeSymbol patternType(JCPattern p) {

If we need to keep duplicated code, this could move to TreeInfo

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

> 2915:         void reportEffectivelyFinalError(DiagnosticPosition pos, Symbol sym) {
> 2916:             String subKey = switch (currentTree.getTag()) {
> 2917:                 case LAMBDA -> "lambda";

Can we make the switch return the fragment constant (e.g. Fragments.XYZ) rather than a String which is then re-wrapped?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3649:

> 3647:         if (!enumSwitch && !stringSwitch && !selector.type.isPrimitive() &&
> 3648:             cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) {
> 3649:             //a switch over a boxed primitive, with a null case. Pick two constants that are

Is this comment correct? If we're here, can't this be just any pattern switch?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3729:

> 3727:         if (cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) {
> 3728:             //for enum switches with case null, do:
> 3729:             //switch ($selector != null ? $mapVar[$selector.ordinal()] : -1) {...}

Very  clever trick to handle away null treatment with just an extra default label. I wonder if this logic isn't big enough to deserve its own `visitXYZSwitch` method, as we do for strings and enums in switch. It seems asymmetric that we do some bits of null handling here (in certain cases) but then enum switches will deal with null in a different way. We should probably test what kind of switch we're dealing with earlier, and then branch out to completely disjoint pieces of code, each with its own null handling

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MatchBindingsComputer.java line 124:

> 122:         // e.T = union(x.T, y.T)
> 123:         // e.F = intersection(x.F, y.F) (error recovery)
> 124:         List<BindingSymbol> bindingsWhenTrue =

Is this duplicate code for MatchBindingComputer::binary(AND) ? If so, should at least the impl delegate to that?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 193:

> 191:                     : tree.expr.type;
> 192:             VarSymbol prevCurrentValue = currentValue;
> 193:             try {

IIUC, the changes here are to handle recursion of pattern in the instanceof case - e.g. `x instanceof (Foo foo)`. If so, it would be nice to have that reflected in the comment above.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 305:

> 303:                 selector = make.Ident(temp);
> 304:             } else {
> 305:                 List<Type> staticArgTypes = List.of(syms.methodHandleLookupType,

I guess strategy here is to convert the various labels into loadable constants and then pass them up to the bootstrap method which will give us back an int, which we'll use for a plain switch. If so, all this needs to be documented somehow.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 368:

> 366:                         JCContinue continueSwitch = make.Continue(null);
> 367:                         continueSwitch.target = tree;
> 368:                         c.stats = c.stats.prepend(make.If(makeUnary(Tag.NOT, test).setType(syms.booleanType),

I assume this is code which "resumes" to the following `case` if the pattern doesn't match. I guess in most cases the bootstrap method would do the check anyway - but I suppose that with guards, the bootstrap method, alone, cannot guarantee the match. Also, it seems like this requires backend support for `continue` in switch. Again, all this needs to be better documented, it's pretty hard to infer all this by looking at the code.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 776:

> 774:         } else {
> 775:             JCPattern pattern;
> 776:             JCExpression e = parsedType == null ? term(EXPR | TYPE | NOLAMBDA/* | NOINVOCATION*/) : parsedType;

what's up with NO_INVOCATION?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3004:

> 3002:                 JCCaseLabel label = parseCaseLabel();
> 3003: 
> 3004:                 //TODO: final

What does this `todo` refers to?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3078:

> 3076:                 }
> 3077:                 Token twoBack;
> 3078:                 boolean pattern = S.token(lookahead - 1).kind == IDENTIFIER && ((twoBack = S.token(lookahead - 2)).kind == IDENTIFIER || twoBack.kind == GT || twoBack.kind == GTGT || twoBack.kind == GTGTGT);

tricky - but I think correct.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3085:

> 3083:                 }
> 3084:             }
> 3085:             //XXX: modifiers!

Another todo here

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

> 499: 
> 500: compiler.err.pattern.dominated=\
> 501:     this pattern is dominated by a preceding pattern

Not sure whether the concept of "dominance" is the one that will work best here. As I said elsewhere, this is, morally, unreachable code.

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

> 518: 
> 519: compiler.err.multiple.patterns=\
> 520:     multiple pattern declarations

This text is very terse and doesn't really say what's wrong with the code. I think the point here is that we don't want code like this:


case String s, Integer i: ...

because this is morally:


case String s:
case Integer i: ...

which is, again, fall-through to a pattern. Maybe, just reusing the same "fall-through" message would be ok here?

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

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

From jlahoda at openjdk.java.net  Tue May 11 13:42:54 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 11 May 2021 13:42:54 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: <pk0mBpekpLd-AELuqFEQSLgKamNrMwuqf3n3Eg4J67Y=.634e1d3d-93d8-420a-aaf9-4a91f06d7e6b@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <pk0mBpekpLd-AELuqFEQSLgKamNrMwuqf3n3Eg4J67Y=.634e1d3d-93d8-420a-aaf9-4a91f06d7e6b@github.com>
Message-ID: <hXVv9BOBEnNlwfSHlOgMNcBH0wlSzqnVUWqBOHQUlgM=.de1d5a40-2c0f-4ca9-a32a-54cc494f3eed@github.com>

On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>> 
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening.
> 
> In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well.

@mcimadamore, thanks a lot for the comments! I tried to reflect most of them in https://github.com/openjdk/jdk/pull/3863/commits/1a5a424139a52d0f93e16980c6b42cf29dd908ef - please let me know how that looks. Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1790:
> 
>> 1788:                         if (isTotal) {
>> 1789:                             if (hasTotalPattern) {
>> 1790:                                 log.error(pat.pos(), Errors.DuplicateTotalPattern);
> 
> Hard to explain - but a lot of the code here feels more like it belongs to `Flow` than to `Attr`. E.g. these "duplicateXYZ" labels really want to say "unreachable code", I think. Is there a strong reason as to why all this code shouldn't (apart from code computing bindings) move to Flow? Seems that the logic is partially duplicated anyway...

`Attr` was always checking duplicated constants and duplicated default, so checking for pattern dominance (which could be seen as an extension to duplicate constant labels) and total patterns (which is an extension to duplicated default) here seemed reasonable. We also have a couple of other similar checks performed by `Attr`, like duplicated statement labels, or that exception types in multicatch are disjoint. These are checks that don't need DA/DU, while I think `Flow` does mostly checks that require DA/DU.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3649:
> 
>> 3647:         if (!enumSwitch && !stringSwitch && !selector.type.isPrimitive() &&
>> 3648:             cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) {
>> 3649:             //a switch over a boxed primitive, with a null case. Pick two constants that are
> 
> Is this comment correct? If we're here, can't this be just any pattern switch?

Patterns switches are resolved before Lower, so in Lower there should be no pattern switches. I'll add a comment in this sense at an appropriate place.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 501:
> 
>> 499: 
>> 500: compiler.err.pattern.dominated=\
>> 501:     this pattern is dominated by a preceding pattern
> 
> Not sure whether the concept of "dominance" is the one that will work best here. As I said elsewhere, this is, morally, unreachable code.

The specification uses "dominance", so it seemed appropriate to use the same term that is used by the specification. We can say "unreachable code", of course, but it will not be consistent with what the specification says, and also with what we do for duplicate constant labels. Also considering code like:

switch (o) {
     case A a -> {}
     case B b -> {} //error on this line
}


It may not be obvious why the code is "unreachable", while saying "dominated" might be more helpful/clear.

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

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

From mcimadamore at openjdk.java.net  Tue May 11 13:42:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 11 May 2021 13:42:55 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: <pk0mBpekpLd-AELuqFEQSLgKamNrMwuqf3n3Eg4J67Y=.634e1d3d-93d8-420a-aaf9-4a91f06d7e6b@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <pk0mBpekpLd-AELuqFEQSLgKamNrMwuqf3n3Eg4J67Y=.634e1d3d-93d8-420a-aaf9-4a91f06d7e6b@github.com>
Message-ID: <P3B2kERUeGHJzK9hJFQCx4EM8ltSl148c_cgSJ9tt4M=.7a9fdbd2-9aae-4e8c-8740-55421066f10e@github.com>

On Tue, 4 May 2021 20:35:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>> 
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 102:
> 
>> 100:      * @param labels non-null case labels - {@code String} and {@code Integer} constants
>> 101:      *                        and {@code Class} instances
>> 102:      * @return the index into {@code labels} of the target value, if the target
> 
> Doesn't return an index. Returns a CallSite which, when invoked with an argument of type E (where E is the type of the target expression), returns the index into...

It should also mention that the handle returned accepts a start index (which is used by the continue logic)

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

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

From erikj at openjdk.java.net  Tue May 11 13:56:03 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 11 May 2021 13:56:03 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <5tkFlMzpxFP1UFGuwI7u0mpFCt_hExf6SLwQVCJnfJs=.8878adb9-f423-408a-9a62-41334467e49f@github.com>

On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

make/CompileInterimLangtools.gmk line 52:

> 50: 
> 51: $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
> 52:     FILES := $(TOPDIR)/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java $(TOPDIR)/src/java.base/share/classes/jdk/internal/javac/NoPreview.java, \

Please break this line (adding 4 additional space indent from the original line). Otherwise build changes ok.

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

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

From gli at openjdk.java.net  Tue May 11 14:02:07 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 14:02:07 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v4]
In-Reply-To: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
Message-ID: <qjsXrpWggqqcu8RA1LSnC7e7O-dVzCYYKFBXhNU6ENw=.6503c33a-110f-44ee-b2a2-e357fb624a52@github.com>

> Hi all,
> 
> javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.
> 
> This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

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

  Revise test code.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1890/files
  - new: https://git.openjdk.java.net/jdk/pull/1890/files/6fb16609..560f0abb

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

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

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

From gli at openjdk.java.net  Tue May 11 14:02:18 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 14:02:18 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v3]
In-Reply-To: <mwpIlxvG3-KQPAtiS8cdF0w9ZGVvnzjHAzyZWy5hfFY=.38422575-c1b4-4626-a8d0-319ebf571acb@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
 <4iAX0F9xrfxgTuIxYl1JvUgFqc7Rr6V4BCecemCyXGk=.7f15e598-e1f4-4fa4-9814-e9b22eccc48b@github.com>
 <mwpIlxvG3-KQPAtiS8cdF0w9ZGVvnzjHAzyZWy5hfFY=.38422575-c1b4-4626-a8d0-319ebf571acb@github.com>
Message-ID: <ULVEfKKLfFDBCjhi0M8CVEw0iIBULHRrkFR4QKe9P14=.335130a7-a10f-467e-ad7e-a6efe4eef354@github.com>

On Tue, 11 May 2021 10:48:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 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 four additional commits since the last revision:
>> 
>>  - Use meaningful class name and update copyright
>>  - Merge branch 'master' into JDK-8226216
>>  - Modify legal header. Fix typo.
>>  - 8226216: parameter modifiers are not visible to javac plugins across compilation boundaries
>
> test/langtools/tools/javac/classreader/ParameterModifiersAcrossCompilationBoundaries.java line 87:
> 
>> 85:                                         TypeElement typeElement = elements.getTypeElement("B");
>> 86:                                         for (Element m : typeElement.getEnclosedElements()) {
>> 87:                                             if (m instanceof ExecutableElement) {
> 
> Since this is a test, not so huge deal, but it might be better to do filtering using `ElementFilter.methodsIn` - it is easier to use than `Element.getKind()`, and safer than `instanceof` (which is not very much safe for `Element`s).

Thanks for you suggestion. I revised the code by using `ElementFilter.methodsIn`.

> test/langtools/tools/javac/classreader/ParameterModifiersAcrossCompilationBoundaries.java line 148:
> 
>> 146:                 .options("--processor-module-path", "plugin", "-Xplugin:P",
>> 147:                          "-parameters", "-classpath", "test")
>> 148:                 .files("test/B.java")
> 
> Does the test really test the ClassReader behavior? It seems B is always originating in the source, and the test is looking at a parameter from the B file? Maybe the idea was `test/A.java` would be used here?

It should be `test/A.java`. Fixed.

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

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

From jlahoda at openjdk.java.net  Tue May 11 14:21:21 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 11 May 2021 14:21:21 GMT
Subject: RFR: JDK-8266281: Assign Symbols to the package selector expression
Message-ID: <xWNPLS6n7zC4or8l9seQDNRNPpS_CuprDLH8D3cU3UA=.808a3a79-bc70-42dc-b29a-9a5081d73cb5@github.com>

The proposal in this patch is that package names in the package clause would be attributed with the appropriate PackageSymbols. So when using Trees.getElement on an AST node of some part of the package name, a sensible PackageSymbol would be returned.

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

Commit messages:
 - JDK-8266281: Assign Symbols to the package selector expression

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

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

From github.com+828220+forax at openjdk.java.net  Tue May 11 14:24:54 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 11 May 2021 14:24:54 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <mLL5AQQXZYIkiQxlHXFEcTXFn7MXRsPVCaUZ_ohjNUg=.0c79a47f-8773-409b-9c09-c9051afb62ff@github.com>

On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 77:

> 75:     }
> 76: 
> 77:     private static<T extends CallSite> MethodHandle typeInitHook(T receiver) {

There is no point to have a type parameter here,

  private static MethodHandle typeInitHook(CallSite receiver) {

will work the same

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 131:

> 129: 
> 130:     private static void verifyLabel(Object label) {
> 131:         if (Objects.isNull(label)) {

`if (label == true) {` is more readable as said in the javadoc of `Objects.isNull`

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

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

From gli at openjdk.java.net  Tue May 11 15:45:57 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 15:45:57 GMT
Subject: RFR: 8266819: Separate the stop policies from the compile
 policies completely
In-Reply-To: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
References: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
Message-ID: <VIDDMMR4Dc8Q4p9AeUx_YB4SRFBFqsijxRzYpfmmTOw=.74a0dea5-6f2b-42fc-92ea-5ddde42dd165@github.com>

On Tue, 11 May 2021 00:43:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the compile policies `ATTR_ONLY` and `CHECK_ONLY` so that the compile policies can be separated from the stop policies. And some corresponding tests need to be adjusted, too.
> 
> Please see [JDK-8266819](https://bugs.openjdk.java.net/browse/JDK-8266819) and the [original discussion](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-May/016759.html) for more information.
> 
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

I created the CSR. Please see [JDK-8266920](https://bugs.openjdk.java.net/browse/JDK-8266920).

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

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

From maurizio.cimadamore at oracle.com  Tue May 11 16:08:13 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 11 May 2021 17:08:13 +0100
Subject: RFR: 8266819: Separate the stop policies from the compile
 policies completely
In-Reply-To: <VIDDMMR4Dc8Q4p9AeUx_YB4SRFBFqsijxRzYpfmmTOw=.74a0dea5-6f2b-42fc-92ea-5ddde42dd165@github.com>
References: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
 <VIDDMMR4Dc8Q4p9AeUx_YB4SRFBFqsijxRzYpfmmTOw=.74a0dea5-6f2b-42fc-92ea-5ddde42dd165@github.com>
Message-ID: <66bd7089-9326-89ff-9dd8-7fe3f3b45b59@oracle.com>

I've added a description re. compatibility risk, and also added myself 
as reviewer. You can finalize.

Also, please use the `/csr` PR command on github, which will link the PR 
to the CSR.

Thanks
Maurizio

On 11/05/2021 16:45, Guoxiong Li wrote:
> On Tue, 11 May 2021 00:43:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:
>
>> Hi all,
>>
>> This patch removes the compile policies `ATTR_ONLY` and `CHECK_ONLY` so that the compile policies can be separated from the stop policies. And some corresponding tests need to be adjusted, too.
>>
>> Please see [JDK-8266819](https://bugs.openjdk.java.net/browse/JDK-8266819) and the [original discussion](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-May/016759.html) for more information.
>>
>> Thank you for taking the time to review.
>>
>> Best Regards,
>> -- Guoxiong
> I created the CSR. Please see [JDK-8266920](https://bugs.openjdk.java.net/browse/JDK-8266920).
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/3961

From jlahoda at openjdk.java.net  Tue May 11 16:20:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 11 May 2021 16:20:04 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v4]
In-Reply-To: <qjsXrpWggqqcu8RA1LSnC7e7O-dVzCYYKFBXhNU6ENw=.6503c33a-110f-44ee-b2a2-e357fb624a52@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
 <qjsXrpWggqqcu8RA1LSnC7e7O-dVzCYYKFBXhNU6ENw=.6503c33a-110f-44ee-b2a2-e357fb624a52@github.com>
Message-ID: <Wvzvj4bfXjjHDcJjRMm6CQwRgEHtwIiH0D2_Ns_6NOE=.6db68c9c-6abb-457b-a2dc-bbd4cd94e674@github.com>

On Tue, 11 May 2021 14:02:07 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.
>> 
>> This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise test code.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From gli at openjdk.java.net  Tue May 11 16:24:57 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 11 May 2021 16:24:57 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v4]
In-Reply-To: <Wvzvj4bfXjjHDcJjRMm6CQwRgEHtwIiH0D2_Ns_6NOE=.6db68c9c-6abb-457b-a2dc-bbd4cd94e674@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
 <qjsXrpWggqqcu8RA1LSnC7e7O-dVzCYYKFBXhNU6ENw=.6503c33a-110f-44ee-b2a2-e357fb624a52@github.com>
 <Wvzvj4bfXjjHDcJjRMm6CQwRgEHtwIiH0D2_Ns_6NOE=.6db68c9c-6abb-457b-a2dc-bbd4cd94e674@github.com>
Message-ID: <85ceSzyfpq8gHF24DucGzLiJ22Pgy_mfAJlbDVGTTAA=.f2b28aa4-fe43-40de-86ed-ff013dbe0d2d@github.com>

On Tue, 11 May 2021 16:17:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise test code.
>
> Looks good to me.

@lahodaj Thanks for your review. Could I get your help to sponsor this patch?

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

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

From jjg at openjdk.java.net  Wed May 12 01:06:01 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 12 May 2021 01:06:01 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v4]
In-Reply-To: <VVfymHBBbeBrt_q_imt4F7_bmr6IbtCRBj7PFlPW_jk=.af50ebe7-da66-4e47-a584-6b6ce840dc2e@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
 <hLBpG8kxipjPXH46_stbCQeEIpNGpiJhcws_yoK8NGc=.354e421b-3741-43f6-bd58-2b5a792d1bad@github.com>
 <y_b0FpPCO97-83077SXhV2tBqBqtfgo5LlYiEkrYD8U=.3bd2e47b-d218-42ba-9426-2c6692b5a322@github.com>
 <wzijgtzm95dH2I6FJj5CwHpN3JzxJQ0pkY4z4FEROgE=.0518a061-4157-4a08-a076-860e42d61178@github.com>
 <VVfymHBBbeBrt_q_imt4F7_bmr6IbtCRBj7PFlPW_jk=.af50ebe7-da66-4e47-a584-6b6ce840dc2e@github.com>
Message-ID: <GfbGCeHyXFQLq2FRA2eYC5KSBl-WVZ7N7lx66jJLoO8=.ff0c55cf-dbbc-4a74-8b56-0246dbd2a63a@github.com>

On Tue, 11 May 2021 13:21:28 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Or probably even simpler `s -> pattern.matcher(s).find() == match`
>
> Good idea. Fixed.

The first form is too cryptic. The second form is OK.

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

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

From gli at openjdk.java.net  Wed May 12 01:06:03 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 12 May 2021 01:06:03 GMT
Subject: Integrated: 8241187: ToolBox::grep should allow for negative filtering
In-Reply-To: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
Message-ID: <qh2RlTggMWSJbKiE2Mqi0rZSph35MvZWqZc6dBVk-bc=.54e57099-bde5-4a34-a19c-da8eecb37ee0@github.com>

On Mon, 4 Jan 2021 17:17:58 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated.
>  
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: ed32e02c
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed32e02c05affbc7d8d1b628fef7e7c32d54c735
Stats:     104 lines in 2 files changed: 99 ins; 0 del; 5 mod

8241187: ToolBox::grep should allow for negative filtering

Reviewed-by: vromero

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

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

From gli at openjdk.java.net  Wed May 12 14:36:05 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 12 May 2021 14:36:05 GMT
Subject: Integrated: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries
In-Reply-To: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
Message-ID: <mtnNBQY6fMQB86RaXPMszs83EpGoJ25mYV7XZN9evyg=.2b0701d9-fd25-435b-930c-5f00215284bb@github.com>

On Thu, 24 Dec 2020 16:02:19 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.
> 
> This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: accbfeaf
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/accbfeaf22ea5374292a657ddabb67b22eada6bc
Stats:     168 lines in 2 files changed: 167 ins; 0 del; 1 mod

8226216: parameter modifiers are not visible to javac plugins across compilation boundaries

Reviewed-by: jlahoda

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

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

From vromero at openjdk.java.net  Wed May 12 20:43:28 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 12 May 2021 20:43:28 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context
Message-ID: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>

javac breaks with NPE if compiles this code:


public class LocalClasses {
    public static void main(String[] args) {
        int i = 5;
        class Local {
            static void m() {
                System.out.println("Value of i = " + i);
            }
        }
        Local.m();
    }
} 


actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:

`com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.

TIA

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

Commit messages:
 - 8263614: Referring to non-final variable from a static member embedded in a local class generates an NPE while compiling

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

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

From gli at openjdk.java.net  Thu May 13 00:59:52 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 13 May 2021 00:59:52 GMT
Subject: RFR: 8266819: Separate the stop policies from the compile
 policies completely
In-Reply-To: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
References: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
Message-ID: <XBDQ3ywMfCN7AO0IJpzjxdyCOzjRyx5wj5WuDnJb1jw=.6c0560a0-a3a1-405f-8986-3ea6eaef0736@github.com>

On Tue, 11 May 2021 00:43:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the compile policies `ATTR_ONLY` and `CHECK_ONLY` so that the compile policies can be separated from the stop policies. And some corresponding tests need to be adjusted, too.
> 
> Please see [JDK-8266819](https://bugs.openjdk.java.net/browse/JDK-8266819) and the [original discussion](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-May/016759.html) for more information.
> 
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

FYI: The CSR was approved.

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

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

From mcimadamore at openjdk.java.net  Thu May 13 09:27:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 09:27:53 GMT
Subject: RFR: 8266819: Separate the stop policies from the compile
 policies completely
In-Reply-To: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
References: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
Message-ID: <8xXDdd8k3EQc6ZjQchcvs-nzgCu1GdaL868xIUPkPbQ=.e90a35b0-4c28-414e-88be-658a4c4886ff@github.com>

On Tue, 11 May 2021 00:43:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the compile policies `ATTR_ONLY` and `CHECK_ONLY` so that the compile policies can be separated from the stop policies. And some corresponding tests need to be adjusted, too.
> 
> Please see [JDK-8266819](https://bugs.openjdk.java.net/browse/JDK-8266819) and the [original discussion](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-May/016759.html) for more information.
> 
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Changes look good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From gli at openjdk.java.net  Thu May 13 09:34:55 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 13 May 2021 09:34:55 GMT
Subject: RFR: 8266819: Separate the stop policies from the compile
 policies completely
In-Reply-To: <8xXDdd8k3EQc6ZjQchcvs-nzgCu1GdaL868xIUPkPbQ=.e90a35b0-4c28-414e-88be-658a4c4886ff@github.com>
References: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
 <8xXDdd8k3EQc6ZjQchcvs-nzgCu1GdaL868xIUPkPbQ=.e90a35b0-4c28-414e-88be-658a4c4886ff@github.com>
Message-ID: <YjBKP-vOk0c4x48q_SbM7WyeFxs7Gu5n-Gf6W4VcMCU=.c16f5ca6-8f85-46d4-9fb5-446f63f9308e@github.com>

On Thu, 13 May 2021 09:24:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the compile policies `ATTR_ONLY` and `CHECK_ONLY` so that the compile policies can be separated from the stop policies. And some corresponding tests need to be adjusted, too.
>> 
>> Please see [JDK-8266819](https://bugs.openjdk.java.net/browse/JDK-8266819) and the [original discussion](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-May/016759.html) for more information.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Changes look good

@mcimadamore Thank you for your review. Could I get your help to sponsor this patch?

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

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

From gli at openjdk.java.net  Thu May 13 10:25:59 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 13 May 2021 10:25:59 GMT
Subject: Integrated: 8266819: Separate the stop policies from the compile
 policies completely
In-Reply-To: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
References: <AS1HECaNSWqiIUq7S6rSeIU_ywCSoG45RP3eF9PGnIs=.59ed3ef6-b4d3-4483-9a97-754c3cb06d2a@github.com>
Message-ID: <EgARBgK2CrWzDiTI-zABk08B0Awz7-h88-sneAshjtg=.e64ca4a6-86fc-48c7-937e-058149abb09b@github.com>

On Tue, 11 May 2021 00:43:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the compile policies `ATTR_ONLY` and `CHECK_ONLY` so that the compile policies can be separated from the stop policies. And some corresponding tests need to be adjusted, too.
> 
> Please see [JDK-8266819](https://bugs.openjdk.java.net/browse/JDK-8266819) and the [original discussion](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-May/016759.html) for more information.
> 
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 17ceef97
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/17ceef97c3df2326d585b2a298e5daa5dcfe3d99
Stats:     48 lines in 9 files changed: 3 ins; 27 del; 18 mod

8266819: Separate the stop policies from the compile policies completely

Reviewed-by: mcimadamore

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

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

From mcimadamore at openjdk.java.net  Thu May 13 11:50:54 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 11:50:54 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context
In-Reply-To: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
Message-ID: <P4IXDhcAKW_wzPHs9ws-1JmXbFejY9_R_XJyvLsHtSw=.49315b88-e08d-4b13-943a-80c4817ea5c4@github.com>

On Wed, 12 May 2021 20:37:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac breaks with NPE if compiles this code:
> 
> 
> public class LocalClasses {
>     public static void main(String[] args) {
>         int i = 5;
>         class Local {
>             static void m() {
>                 System.out.println("Value of i = " + i);
>             }
>         }
>         Local.m();
>     }
> } 
> 
> 
> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
> 
> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
> 
> TIA

This is a tricky area, so I played a little with the (unchanged) code, to get an idea of what was wrong. It seems to me that the behavior of `Resolve::findVar` (other methods are probably the same) is as follows:

0. set `staticOnly` to `true` is the current env is static
1. look in local variable of current env
2. look in fields of current env
3. if a field is found and the field is compatible with `staticOnly` return that, otherwise issue a static error
4. go back to (1) with the enclosing env, setting `staticOnly` if a static member is found

This doesn't seem *too* bad - but there is an issue, e.g. in the example mentioned in the JBS issue: we look into locals (step 1) regardless of the value of `isStatic`. This leads to issue, because it doesn't make sense to "find" a local variable in an enclosing scope if the type from which the search started is a static type.

To rectify this issue, I came up with the following, relatively minimal fix:


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
index 3d4859d1b88..cdc129e8ad6 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
@@ -1510,13 +1510,16 @@ public class Resolve {
         boolean staticOnly = false;
         while (env1.outer != null) {
             Symbol sym = null;
-            if (isStatic(env1)) staticOnly = true;
             for (Symbol s : env1.info.scope.getSymbolsByName(name)) {
                 if (s.kind == VAR && (s.flags_field & SYNTHETIC) == 0) {
                     sym = s;
+                    if (staticOnly) {
+                        return new StaticError(sym);
+                    }
                     break;
                 }
             }
+            if (isStatic(env1)) staticOnly = true;
             if (sym == null) {
                 sym = findField(env1, env1.enclClass.sym.type, name, env1.enclClass.sym);
             }


The idea here is that, whatever symbol is found during step (1), if `staticOnly` is set, we should just disregard it and throw a static error instead (as done for the field lookup in (3). This seems to fix the issue in JBS, and seems to pass all javac test.

It is likely that, as in your patch, similar changes would be needed for other routines such as `Resolve::findType`/`findTypeVar`.

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

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

From jlahoda at openjdk.java.net  Thu May 13 13:54:40 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 13 May 2021 13:54:40 GMT
Subject: RFR: JDK-8267041: javac crash when creating lambda with capture
 inside a switch expression
Message-ID: <nc4bIsEExqm0FF9o1WqJCjWPQGNIDV6e4bflxci78SA=.7f9eb8cc-37c9-4ea2-8f56-a91e94ebb2d9@github.com>

Variables declared inside switch expressions used as initializers to fields have the field as their owner. We need to make sure they are captured by `LambdaToMethod` - there were a few places where the checks were missing, leading to a crash later during code generation.

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

Commit messages:
 - JDK-8267041: javac crash when creating lambda with capture inside a switch expression

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

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

From vromero at openjdk.java.net  Thu May 13 15:09:15 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 13 May 2021 15:09:15 GMT
Subject: RFR: JDK-8267041: javac crash when creating lambda with capture
 inside a switch expression
In-Reply-To: <nc4bIsEExqm0FF9o1WqJCjWPQGNIDV6e4bflxci78SA=.7f9eb8cc-37c9-4ea2-8f56-a91e94ebb2d9@github.com>
References: <nc4bIsEExqm0FF9o1WqJCjWPQGNIDV6e4bflxci78SA=.7f9eb8cc-37c9-4ea2-8f56-a91e94ebb2d9@github.com>
Message-ID: <rdI-V6basWkaLNgMdif4fD555ze7bshPitgPi_k572c=.d440e8b3-39e6-4d99-a19d-f1885d67e812@github.com>

On Thu, 13 May 2021 13:46:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Variables declared inside switch expressions used as initializers to fields have the field as their owner. We need to make sure they are captured by `LambdaToMethod` - there were a few places where the checks were missing, leading to a crash later during code generation.

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

> 1354:             if (context() != null && lambdaIdentSymbolFilter(tree.sym)) {
> 1355:                 if (tree.sym.kind == VAR &&
> 1356:                         (tree.sym.owner.kind == MTH || tree.sym.owner.kind == VAR) &&

just curious: why wasn't this code stressed before? I mean it should be possible to stress it without switch expressions right?

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

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

From mcimadamore at openjdk.java.net  Thu May 13 15:22:14 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 15:22:14 GMT
Subject: RFR: JDK-8267041: javac crash when creating lambda with capture
 inside a switch expression
In-Reply-To: <rdI-V6basWkaLNgMdif4fD555ze7bshPitgPi_k572c=.d440e8b3-39e6-4d99-a19d-f1885d67e812@github.com>
References: <nc4bIsEExqm0FF9o1WqJCjWPQGNIDV6e4bflxci78SA=.7f9eb8cc-37c9-4ea2-8f56-a91e94ebb2d9@github.com>
 <rdI-V6basWkaLNgMdif4fD555ze7bshPitgPi_k572c=.d440e8b3-39e6-4d99-a19d-f1885d67e812@github.com>
Message-ID: <S-RuqufnHS7zxKqKPAqpeF8dRdNsjNgmeYy2KHAYNyc=.1372eb70-81db-429d-a063-e34e11f62312@github.com>

On Thu, 13 May 2021 15:05:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Variables declared inside switch expressions used as initializers to fields have the field as their owner. We need to make sure they are captured by `LambdaToMethod` - there were a few places where the checks were missing, leading to a crash later during code generation.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1356:
> 
>> 1354:             if (context() != null && lambdaIdentSymbolFilter(tree.sym)) {
>> 1355:                 if (tree.sym.kind == VAR &&
>> 1356:                         (tree.sym.owner.kind == MTH || tree.sym.owner.kind == VAR) &&
> 
> just curious: why wasn't this code stressed before? I mean it should be possible to stress it without switch expressions right?

Uhm - don't we always try to create a block/synthetic method symbol for owner of variables declared inside initializers? I think the case where this happens is lambda expression parameters - which can occur in field initializers. The parameters should point to some "init block" as their owner, not the var. Shouldn't switch behave the same? (having variables being owner of other variables breaks invariants in the code).

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

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

From vromero at openjdk.java.net  Thu May 13 16:43:22 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 13 May 2021 16:43:22 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context
In-Reply-To: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
Message-ID: <hicQ96apB7B7-RYCkFjY4_gDGBbfIq52o4ofb_D4KXU=.3327f34c-1f73-447e-9fc5-2f6db3979228@github.com>

On Wed, 12 May 2021 20:37:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac breaks with NPE if compiles this code:
> 
> 
> public class LocalClasses {
>     public static void main(String[] args) {
>         int i = 5;
>         class Local {
>             static void m() {
>                 System.out.println("Value of i = " + i);
>             }
>         }
>         Local.m();
>     }
> } 
> 
> 
> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
> 
> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
> 
> TIA

thanks Maurizio for taking the time to dig deeper into this issue. Your patch is elegant but we will need some additional changes if we decide to go through that path, for example the compiler is accepting this code with your patch instead of issuing an error:


class C<T> {
    int field = 0;
    <U> void foo(int param) {
        int localVar = 1;
        class Local {
            static void m() {
                U u;
            }
        }
    }
}

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

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

From github.com+828220+forax at openjdk.java.net  Thu May 13 19:29:38 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 13 May 2021 19:29:38 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <kUASbxN5c7Nct6-6bB85z1qPX2fLN8SxstFVGcu-oO8=.b3e26931-8053-4795-8ad3-8e16a3914867@github.com>

On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 127:

> 125:         Stream.of(labels).forEach(SwitchBootstraps::verifyLabel);
> 126: 
> 127:         return new TypeSwitchCallSite(invocationType, labels);

See why below

  MethodHandle target = MethodHandles.insertArguments(DO_SWITCH, 2, labels);
  return new ConstantCallsite(target);

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 134:

> 132:             throw new IllegalArgumentException("null label found");
> 133:         }
> 134:         if (label.getClass() != Class.class &&

store `label.getClass` in a local variable,
it's too bad that you can no use pattern matching here :)

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 141:

> 139:     }
> 140: 
> 141:     static class TypeSwitchCallSite extends ConstantCallSite {

That's weird, having a callsite extending MutableCallSite is expected but having a callsite extending constant callsite is useless because you can not change it after being constructed.

As an interesting trivia, the VM does not store the CallSite returned by the BSM, but only the target inside it.
So there is no point of keeping a ConstantCallSite around.  

So `doSwitch()` should be static and takes the array of Object[] as parameter, will array will be injected with an insertArguments().

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 157:

> 155:             Class<?> targetClass = target.getClass();
> 156:             for (int i = startIndex; i < labels.length; i++) {
> 157:                 if (labels[i] instanceof Class<?>) {

label[i] should be stored is a local variable and
using `instanceof Class<?> c` (like the other instanceof below) will make the code more readable

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

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

From vromero at openjdk.java.net  Thu May 13 20:37:37 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 13 May 2021 20:37:37 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context [v2]
In-Reply-To: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
Message-ID: <sZLJ3i3dxB24MhI_HFK6bXYCvvy-GIUaIqxutIh6zbY=.11b4f54d-e823-4096-af8e-3b6219adb2d1@github.com>

> javac breaks with NPE if compiles this code:
> 
> 
> public class LocalClasses {
>     public static void main(String[] args) {
>         int i = 5;
>         class Local {
>             static void m() {
>                 System.out.println("Value of i = " + i);
>             }
>         }
>         Local.m();
>     }
> } 
> 
> 
> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
> 
> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
> 
> TIA

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

  update after review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4004/files
  - new: https://git.openjdk.java.net/jdk/pull/4004/files/5db3450c..c062667b

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

  Stats: 42 lines in 1 file changed: 18 ins; 16 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4004/head:pull/4004

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

From vromero at openjdk.java.net  Thu May 13 20:37:37 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 13 May 2021 20:37:37 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context
In-Reply-To: <P4IXDhcAKW_wzPHs9ws-1JmXbFejY9_R_XJyvLsHtSw=.49315b88-e08d-4b13-943a-80c4817ea5c4@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
 <P4IXDhcAKW_wzPHs9ws-1JmXbFejY9_R_XJyvLsHtSw=.49315b88-e08d-4b13-943a-80c4817ea5c4@github.com>
Message-ID: <OkFK7ho8Y3V0ezc0R45vPpsWjc4lSTpulnAxEpJ-0bA=.f3ea0c5e-4363-4f4a-bef9-51604e1e281b@github.com>

On Thu, 13 May 2021 11:47:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> javac breaks with NPE if compiles this code:
>> 
>> 
>> public class LocalClasses {
>>     public static void main(String[] args) {
>>         int i = 5;
>>         class Local {
>>             static void m() {
>>                 System.out.println("Value of i = " + i);
>>             }
>>         }
>>         Local.m();
>>     }
>> } 
>> 
>> 
>> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
>> 
>> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
>> 
>> TIA
>
> This is a tricky area, so I played a little with the (unchanged) code, to get an idea of what was wrong. It seems to me that the behavior of `Resolve::findVar` (other methods are probably the same) is as follows:
> 
> 0. set `staticOnly` to `true` is the current env is static
> 1. look in local variable of current env
> 2. look in fields of current env
> 3. if a field is found and the field is compatible with `staticOnly` return that, otherwise issue a static error
> 4. go back to (1) with the enclosing env, setting `staticOnly` if a static member is found
> 
> This doesn't seem *too* bad - but there is an issue, e.g. in the example mentioned in the JBS issue: we look into locals (step 1) regardless of the value of `isStatic`. This leads to issue, because it doesn't make sense to "find" a local variable in an enclosing scope if the type from which the search started is a static type.
> 
> To rectify this issue, I came up with the following, relatively minimal fix:
> 
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> index 3d4859d1b88..cdc129e8ad6 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> @@ -1510,13 +1510,16 @@ public class Resolve {
>          boolean staticOnly = false;
>          while (env1.outer != null) {
>              Symbol sym = null;
> -            if (isStatic(env1)) staticOnly = true;
>              for (Symbol s : env1.info.scope.getSymbolsByName(name)) {
>                  if (s.kind == VAR && (s.flags_field & SYNTHETIC) == 0) {
>                      sym = s;
> +                    if (staticOnly) {
> +                        return new StaticError(sym);
> +                    }
>                      break;
>                  }
>              }
> +            if (isStatic(env1)) staticOnly = true;
>              if (sym == null) {
>                  sym = findField(env1, env1.enclClass.sym.type, name, env1.enclClass.sym);
>              }
> 
> 
> The idea here is that, whatever symbol is found during step (1), if `staticOnly` is set, we should just disregard it and throw a static error instead (as done for the field lookup in (3). Also, the initialization of `staticOnly` in (0) is moved after (1) (because we have to search parameter of the current method, at least once). This seems to fix the issue in JBS, and seems to pass all javac test.
> 
> It is likely that, as in your patch, similar changes would be needed for other routines such as `Resolve::findType`/`findTypeVar`.

@mcimadamore, I have uploaded another commit which builds on your patch and adds a small change to Resolve::findTypeVar, thanks

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

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

From mcimadamore at openjdk.java.net  Thu May 13 20:37:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 20:37:40 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context [v2]
In-Reply-To: <sZLJ3i3dxB24MhI_HFK6bXYCvvy-GIUaIqxutIh6zbY=.11b4f54d-e823-4096-af8e-3b6219adb2d1@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
 <sZLJ3i3dxB24MhI_HFK6bXYCvvy-GIUaIqxutIh6zbY=.11b4f54d-e823-4096-af8e-3b6219adb2d1@github.com>
Message-ID: <ZV4ym1_4Ui48ogDRgChvi-gNqvX08G4B7d8ENXyNXrY=.e3d25f1d-f189-4346-81a6-0affa17ba0db@github.com>

On Thu, 13 May 2021 20:08:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> javac breaks with NPE if compiles this code:
>> 
>> 
>> public class LocalClasses {
>>     public static void main(String[] args) {
>>         int i = 5;
>>         class Local {
>>             static void m() {
>>                 System.out.println("Value of i = " + i);
>>             }
>>         }
>>         Local.m();
>>     }
>> } 
>> 
>> 
>> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
>> 
>> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update after review comments

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

> 2327:                     (sym.owner.kind == MTH &&
> 2328:                     currentEnv != originalEnv &&
> 2329:                         (!isInnerClassOfMethod(sym.owner, originalEnv.tree.hasTag(CLASSDEF) ?

Can't you do a similar approach here and use staticOnly to rule out tvars?

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

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

From mcimadamore at openjdk.java.net  Thu May 13 20:37:45 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 20:37:45 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context [v2]
In-Reply-To: <ZV4ym1_4Ui48ogDRgChvi-gNqvX08G4B7d8ENXyNXrY=.e3d25f1d-f189-4346-81a6-0affa17ba0db@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
 <sZLJ3i3dxB24MhI_HFK6bXYCvvy-GIUaIqxutIh6zbY=.11b4f54d-e823-4096-af8e-3b6219adb2d1@github.com>
 <ZV4ym1_4Ui48ogDRgChvi-gNqvX08G4B7d8ENXyNXrY=.e3d25f1d-f189-4346-81a6-0affa17ba0db@github.com>
Message-ID: <PrwueFsr5DfYTtwb-n9uSXR8Euq26Fy9vvPiW7aEvMo=.e857cdc8-5d9f-4996-887f-8a959d68e1ce@github.com>

On Thu, 13 May 2021 20:07:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update after review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2329:
> 
>> 2327:                     (sym.owner.kind == MTH &&
>> 2328:                     currentEnv != originalEnv &&
>> 2329:                         (!isInnerClassOfMethod(sym.owner, originalEnv.tree.hasTag(CLASSDEF) ?
> 
> Can't you do a similar approach here and use staticOnly to rule out tvars?

I think you can go in findType, move the assignment to staticOnly to *after* the call to findTypeVar - then you can drop all type var symbol you find with staticOnly = true.

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

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

From vromero at openjdk.java.net  Thu May 13 21:41:31 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 13 May 2021 21:41:31 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context [v2]
In-Reply-To: <PrwueFsr5DfYTtwb-n9uSXR8Euq26Fy9vvPiW7aEvMo=.e857cdc8-5d9f-4996-887f-8a959d68e1ce@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
 <sZLJ3i3dxB24MhI_HFK6bXYCvvy-GIUaIqxutIh6zbY=.11b4f54d-e823-4096-af8e-3b6219adb2d1@github.com>
 <ZV4ym1_4Ui48ogDRgChvi-gNqvX08G4B7d8ENXyNXrY=.e3d25f1d-f189-4346-81a6-0affa17ba0db@github.com>
 <PrwueFsr5DfYTtwb-n9uSXR8Euq26Fy9vvPiW7aEvMo=.e857cdc8-5d9f-4996-887f-8a959d68e1ce@github.com>
Message-ID: <56Qo5_x-m2W7zBY3dIRWeO0kLrlUhxCIzYKq10FCbP8=.943be23d-f143-453b-887a-725cf3e10230@github.com>

On Thu, 13 May 2021 20:08:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2329:
>> 
>>> 2327:                     (sym.owner.kind == MTH &&
>>> 2328:                     currentEnv != originalEnv &&
>>> 2329:                         (!isInnerClassOfMethod(sym.owner, originalEnv.tree.hasTag(CLASSDEF) ?
>> 
>> Can't you do a similar approach here and use staticOnly to rule out tvars?
>
> I think you can go in findType, move the assignment to staticOnly to *after* the call to findTypeVar - then you can drop all type var symbol you find with staticOnly = true.

I think that type variables are trickier than local variables and probably won't be as easy to tame. I tried several combinations of the patch below which I think is what you have in mind:


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
index 70ea875a4b3..832a8ba8ede 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
@@ -2316,29 +2316,6 @@ public class Resolve {
         return bestSoFar;
     }
 
-    Symbol findTypeVar(Env<AttrContext> currentEnv, Env<AttrContext> originalEnv, Name name, boolean staticOnly) {
-        for (Symbol sym : currentEnv.info.scope.getSymbolsByName(name)) {
-            if (sym.kind == TYP) {
-                if (staticOnly &&
-                    sym.type.hasTag(TYPEVAR) &&
-                    ((sym.owner.kind == TYP) ||
-                    // are we trying to access a TypeVar defined in a method from a local static type: interface, enum or record?
-                    allowRecords &&
-                    (sym.owner.kind == MTH &&
-                    currentEnv != originalEnv &&
-                        (!isInnerClassOfMethod(sym.owner, originalEnv.tree.hasTag(CLASSDEF) ?
-                        ((JCClassDecl)originalEnv.tree).sym :
-                        originalEnv.enclClass.sym) ||
-                        originalEnv.info.staticLevel > currentEnv.info.staticLevel)
-                    ))) {
-                    return new StaticError(sym);
-                }
-                return sym;
-            }
-        }
-        return typeNotFound;
-    }
-
     boolean isInnerClassOfMethod(Symbol msym, Symbol csym) {
         while (csym.owner != msym) {
             if (csym.isStatic()) return false;
@@ -2358,18 +2335,25 @@ public class Resolve {
         Symbol sym;
         boolean staticOnly = false;
         for (Env<AttrContext> env1 = env; env1.outer != null; env1 = env1.outer) {
-            if (isStatic(env1)) staticOnly = true;
             // First, look for a type variable and the first member type
-            final Symbol tyvar = findTypeVar(env1, env, name, staticOnly);
+            Symbol tyvar = typeNotFound;
+            for (Symbol s : env1.info.scope.getSymbolsByName(name)) {
+                if (s.kind == TYP) {
+                    tyvar = s;
+                }
+            }
             sym = findImmediateMemberType(env1, env1.enclClass.sym.type,
                                           name, env1.enclClass.sym);
-
+            if (isStatic(env1)) staticOnly = true;
             // Return the type variable if we have it, and have no
             // immediate member, OR the type variable is for a method.
             if (tyvar != typeNotFound) {
                 if (env.baseClause || sym == typeNotFound ||
                     (tyvar.kind == TYP && tyvar.exists() &&
                      tyvar.owner.kind == MTH)) {
+                    if (staticOnly) {
+                        return new StaticError(tyvar);
+                    }
                     return tyvar;
                 }
             }


if the line: `if (isStatic(env1)) staticOnly = true;` is left in the position it appears in the patch above then valid code like:


    public static <A> List<A> nil() {
        return (List<A>)EMPTY_LIST;
    }

will stop being accepted as the type variable is being accessed from a static context, but this case is kosher. On the other hand if line `if (isStatic(env1)) staticOnly = true;` if moved after the if block:


if (tyvar != typeNotFound) {


then the compiler will accept the code below when it should fail:


import java.util.Collection;
class Test<T extends Collection> {
    static void test(T t) { t.iterator(); }
}

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

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

From mcimadamore at openjdk.java.net  Fri May 14 13:07:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 14 May 2021 13:07:41 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context [v2]
In-Reply-To: <sZLJ3i3dxB24MhI_HFK6bXYCvvy-GIUaIqxutIh6zbY=.11b4f54d-e823-4096-af8e-3b6219adb2d1@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
 <sZLJ3i3dxB24MhI_HFK6bXYCvvy-GIUaIqxutIh6zbY=.11b4f54d-e823-4096-af8e-3b6219adb2d1@github.com>
Message-ID: <lQOC-yeXvlLAK9oi8hVkEUNdJ2poRvm_8lnZb7EroNA=.c16da5d1-1351-49f0-90d9-5b6c9c86061e@github.com>

On Thu, 13 May 2021 20:37:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> javac breaks with NPE if compiles this code:
>> 
>> 
>> public class LocalClasses {
>>     public static void main(String[] args) {
>>         int i = 5;
>>         class Local {
>>             static void m() {
>>                 System.out.println("Value of i = " + i);
>>             }
>>         }
>>         Local.m();
>>     }
>> } 
>> 
>> 
>> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
>> 
>> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update after review comments

I'm doing more investigation. The code for resolving types is definitively complex. It seems to me that the complexity comes from 3 problems:

Problem 1:


class Foo<T> {
static T t;
}


Here the env for `t` has ` scope which can see T.

Problem 2:


class Foo<T> {
static void m() {
   T t;
}
}


Here the env for `m` has ` scope which can see T.

Problem 3:


class Foo {
static <Z> void m() {
   Z z;
}
}


This should obviously work, although, in compiler terms, there's not much difference between (3) and (2).

I'm currently looking into all the changes made in this area in recent times, and see if there's an easier path to support all this.

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

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

From mcimadamore at openjdk.java.net  Fri May 14 13:33:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 14 May 2021 13:33:55 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context [v2]
In-Reply-To: <sZLJ3i3dxB24MhI_HFK6bXYCvvy-GIUaIqxutIh6zbY=.11b4f54d-e823-4096-af8e-3b6219adb2d1@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
 <sZLJ3i3dxB24MhI_HFK6bXYCvvy-GIUaIqxutIh6zbY=.11b4f54d-e823-4096-af8e-3b6219adb2d1@github.com>
Message-ID: <IiLsbXjbUATH7SJQaii5okzToNHci2cVZd17H-VFToQ=.0f38100e-3dbc-400f-9c31-05fe928ca1fc@github.com>

On Thu, 13 May 2021 20:37:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> javac breaks with NPE if compiles this code:
>> 
>> 
>> public class LocalClasses {
>>     public static void main(String[] args) {
>>         int i = 5;
>>         class Local {
>>             static void m() {
>>                 System.out.println("Value of i = " + i);
>>             }
>>         }
>>         Local.m();
>>     }
>> } 
>> 
>> 
>> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
>> 
>> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update after review comments

This is what I came up with:


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
index 86f68f94efd..a325a08459f 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
@@ -1488,30 +1488,24 @@ public class Resolve {
         boolean staticOnly = false;
         while (env1.outer != null) {
             Symbol sym = null;
-            if (isStatic(env1)) staticOnly = true;
             for (Symbol s : env1.info.scope.getSymbolsByName(name)) {
                 if (s.kind == VAR && (s.flags_field & SYNTHETIC) == 0) {
                     sym = s;
+                    if (staticOnly) {
+                        return new StaticError(sym);
+                    }
                     break;
                 }
             }
+            if (isStatic(env1)) staticOnly = true;
             if (sym == null) {
                 sym = findField(env1, env1.enclClass.sym.type, name, env1.enclClass.sym);
             }
             if (sym.exists()) {
                 if (staticOnly &&
-                   (sym.flags() & STATIC) == 0 &&
-                    sym.kind == VAR &&
-                        // if it is a field
-                        (sym.owner.kind == TYP ||
-                        // or it is a local variable but it is not declared inside of the static local type
-                        // then error
-                        allowRecords &&
-                        (sym.owner.kind == MTH) &&
-                        env1 != env &&
-                        !isInnerClassOfMethod(sym.owner, env.tree.hasTag(CLASSDEF) ?
-                                ((JCClassDecl)env.tree).sym :
-                                env.enclClass.sym)))
+                        sym.kind == VAR &&
+                        sym.owner.kind == TYP &&
+                        (sym.flags() & STATIC) == 0)
                     return new StaticError(sym);
                 else
                     return sym;
@@ -2313,35 +2307,22 @@ public class Resolve {
         return bestSoFar;
     }
 
-    Symbol findTypeVar(Env<AttrContext> currentEnv, Env<AttrContext> originalEnv, Name name, boolean staticOnly) {
-        for (Symbol sym : currentEnv.info.scope.getSymbolsByName(name)) {
+    Symbol findTypeVar(Env<AttrContext> env, Name name, boolean staticOnly) {
+        for (Symbol sym : env.info.scope.getSymbolsByName(name)) {
             if (sym.kind == TYP) {
-                if (staticOnly &&
-                    sym.type.hasTag(TYPEVAR) &&
-                    ((sym.owner.kind == TYP) ||
-                    // are we trying to access a TypeVar defined in a method from a local static type: interface, enum or record?
-                    allowRecords &&
-                    (sym.owner.kind == MTH &&
-                    currentEnv != originalEnv &&
-                    !isInnerClassOfMethod(sym.owner, originalEnv.tree.hasTag(CLASSDEF) ?
-                            ((JCClassDecl)originalEnv.tree).sym :
-                            originalEnv.enclClass.sym)))) {
+                if (sym.type.hasTag(TYPEVAR) &&
+                        (staticOnly || (isStatic(env) && sym.owner.kind == TYP)))
+                    // if staticOnly is set, it means that we have recursed through a static declaration,
+                    // so type variable symbols should not be accessible. If staticOnly is unset, but
+                    // we are in a static declaration (field or method), we should not allow type-variables
+                    // defined in the enclosing class to "leak" into this context.
                     return new StaticError(sym);
-                }
                 return sym;
             }
         }
         return typeNotFound;
     }
 
-    boolean isInnerClassOfMethod(Symbol msym, Symbol csym) {
-        while (csym.owner != msym) {
-            if (csym.isStatic()) return false;
-            csym = csym.owner.enclClass();
-        }
-        return (csym.owner == msym && !csym.isStatic());
-    }
-
     /** Find an unqualified type symbol.
      *  @param env       The current environment.
      *  @param name      The type's name.
@@ -2353,9 +2334,9 @@ public class Resolve {
         Symbol sym;
         boolean staticOnly = false;
         for (Env<AttrContext> env1 = env; env1.outer != null; env1 = env1.outer) {
-            if (isStatic(env1)) staticOnly = true;
             // First, look for a type variable and the first member type
-            final Symbol tyvar = findTypeVar(env1, env, name, staticOnly);
+            final Symbol tyvar = findTypeVar(env1, name, staticOnly);
+            if (isStatic(env1)) staticOnly = true;
             sym = findImmediateMemberType(env1, env1.enclClass.sym.type,
                                           name, env1.enclClass.sym);
 ```
 
 It reverts some of the code changes made for records, and reverts the code to a simpler state (the isInnerClassOfMethod) is no longer needed. This passes all tests, including the modified RecordCompilationTests.

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

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

From mcimadamore at openjdk.java.net  Fri May 14 14:44:56 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 14 May 2021 14:44:56 GMT
Subject: RFR: 8267162 Add jtreg test group definitions for langtools
Message-ID: <Lz5FA8fNf4wsnNykSnkcslTOdIIRVnMl-_ZUG5gsnKA=.fb781ded-e612-4f7d-b65d-a459c285ce99@github.com>

This patch adds test group definitions for langtools, so that langtools tests can be more easily discovered when running make.

For instance, with this patch, typing:


$ make run-test-langtools_


and then hit tab (on Linux) reveals the following possible completions:


run-test-langtools_all                   run-test-langtools_javac                 run-test-langtools_javadoc               run-test-langtools_javap                 run-test-langtools_jdeprscan             run-test-langtools_jdeps                 run-test-langtools_jshell                run-test-langtools_jshell_unstable       run-test-langtools_sjavac
run-test-langtools_all-only              run-test-langtools_javac-only            run-test-langtools_javadoc-only          run-test-langtools_javap-only            run-test-langtools_jdeprscan-only        run-test-langtools_jdeps-only            run-test-langtools_jshell-only           run-test-langtools_jshell_unstable-only  run-test-langtools_sjavac-only


(the `-only` targets are added by make - the others are the ones added by this patch).

I've added a group for every major tool:

* javac
* javadoc
* jshell
* javap
* jdeps
* jdeprscan
* sjavac

Plus a target (`langtools_all`) which runs all langtools test. For every tool target, the group also run shared tests (e.g. the coding rules tests).

I also reorganized tier1 and tier2 groups a little: both tiers were referring to a group of jshell tests which is less stable than the others, so has been moved to tier2. Instead of repeating the list of test twice, I've defined away the list of unstable test in a group, `langtools_jshell_unstable` and then defined tier1 as `langtools_all - langtools_jshell_unstable` while tier2 is defined as simply `langtools_jshell_unstable`.

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

Commit messages:
 - Add test groups for langtools
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/4033/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4033&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267162
  Stats: 65 lines in 1 file changed: 43 ins; 15 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4033.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4033/head:pull/4033

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

From jjg at openjdk.java.net  Fri May 14 15:15:39 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 14 May 2021 15:15:39 GMT
Subject: RFR: 8267162 Add jtreg test group definitions for langtools
In-Reply-To: <Lz5FA8fNf4wsnNykSnkcslTOdIIRVnMl-_ZUG5gsnKA=.fb781ded-e612-4f7d-b65d-a459c285ce99@github.com>
References: <Lz5FA8fNf4wsnNykSnkcslTOdIIRVnMl-_ZUG5gsnKA=.fb781ded-e612-4f7d-b65d-a459c285ce99@github.com>
Message-ID: <RRAihl69aSOloUWYOBt_EhiWMga47HUrlFIu4u9N0jI=.592f18f8-820e-423f-86ef-b03edcea47cd@github.com>

On Fri, 14 May 2021 14:36:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds test group definitions for langtools, so that langtools tests can be more easily discovered when running make.
> 
> For instance, with this patch, typing:
> 
> 
> $ make run-test-langtools_
> 
> 
> and then hit tab (on Linux) reveals the following possible completions:
> 
> 
> run-test-langtools_all                   run-test-langtools_javac                 run-test-langtools_javadoc               run-test-langtools_javap                 run-test-langtools_jdeprscan             run-test-langtools_jdeps                 run-test-langtools_jshell                run-test-langtools_jshell_unstable       run-test-langtools_sjavac
> run-test-langtools_all-only              run-test-langtools_javac-only            run-test-langtools_javadoc-only          run-test-langtools_javap-only            run-test-langtools_jdeprscan-only        run-test-langtools_jdeps-only            run-test-langtools_jshell-only           run-test-langtools_jshell_unstable-only  run-test-langtools_sjavac-only
> 
> 
> (the `-only` targets are added by make - the others are the ones added by this patch).
> 
> I've added a group for every major tool:
> 
> * javac
> * javadoc
> * jshell
> * javap
> * jdeps
> * jdeprscan
> * sjavac
> 
> Plus a target (`langtools_all`) which runs all langtools test. For every tool target, the group also run shared tests (e.g. the coding rules tests).
> 
> I also reorganized tier1 and tier2 groups a little: both tiers were referring to a group of jshell tests which is less stable than the others, so has been moved to tier2. Instead of repeating the list of test twice, I've defined away the list of unstable test in a group, `langtools_jshell_unstable` and then defined tier1 as `langtools_all - langtools_jshell_unstable` while tier2 is defined as simply `langtools_jshell_unstable`.

There's a symbol at the end that may indicate no final newline. If so, maybe you should add one.

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

Marked as reviewed by jjg (Reviewer).

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

From vromero at openjdk.java.net  Fri May 14 15:25:58 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 14 May 2021 15:25:58 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context [v3]
In-Reply-To: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
Message-ID: <C5ZZFfT7FWDYtU7_pJQ5gJ4g-apeeQkIYvXoIKiVzbc=.88c45706-05e2-47ab-bdc5-21116b651143@github.com>

> javac breaks with NPE if compiles this code:
> 
> 
> public class LocalClasses {
>     public static void main(String[] args) {
>         int i = 5;
>         class Local {
>             static void m() {
>                 System.out.println("Value of i = " + i);
>             }
>         }
>         Local.m();
>     }
> } 
> 
> 
> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
> 
> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
> 
> TIA

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

  patch suggested by Maurizio

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4004/files
  - new: https://git.openjdk.java.net/jdk/pull/4004/files/c062667b..073e42e2

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

  Stats: 38 lines in 1 file changed: 1 ins; 25 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4004/head:pull/4004

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

From mcimadamore at openjdk.java.net  Fri May 14 16:46:05 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 14 May 2021 16:46:05 GMT
Subject: RFR: 8267162 Add jtreg test group definitions for langtools [v2]
In-Reply-To: <Lz5FA8fNf4wsnNykSnkcslTOdIIRVnMl-_ZUG5gsnKA=.fb781ded-e612-4f7d-b65d-a459c285ce99@github.com>
References: <Lz5FA8fNf4wsnNykSnkcslTOdIIRVnMl-_ZUG5gsnKA=.fb781ded-e612-4f7d-b65d-a459c285ce99@github.com>
Message-ID: <mCr-d9Av1OMFQjpA2qc-PB_t24H0EEwu2e22y_RWptM=.622f068a-0663-4951-98e3-c9742bda2cee@github.com>

> This patch adds test group definitions for langtools, so that langtools tests can be more easily discovered when running make.
> 
> For instance, with this patch, typing:
> 
> 
> $ make run-test-langtools_
> 
> 
> and then hit tab (on Linux) reveals the following possible completions:
> 
> 
> run-test-langtools_all                   run-test-langtools_javac                 run-test-langtools_javadoc               run-test-langtools_javap                 run-test-langtools_jdeprscan             run-test-langtools_jdeps                 run-test-langtools_jshell                run-test-langtools_jshell_unstable       run-test-langtools_sjavac
> run-test-langtools_all-only              run-test-langtools_javac-only            run-test-langtools_javadoc-only          run-test-langtools_javap-only            run-test-langtools_jdeprscan-only        run-test-langtools_jdeps-only            run-test-langtools_jshell-only           run-test-langtools_jshell_unstable-only  run-test-langtools_sjavac-only
> 
> 
> (the `-only` targets are added by make - the others are the ones added by this patch).
> 
> I've added a group for every major tool:
> 
> * javac
> * javadoc
> * jshell
> * javap
> * jdeps
> * jdeprscan
> * sjavac
> 
> Plus a target (`langtools_all`) which runs all langtools test. For every tool target, the group also run shared tests (e.g. the coding rules tests).
> 
> I also reorganized tier1 and tier2 groups a little: both tiers were referring to a group of jshell tests which is less stable than the others, so has been moved to tier2. Instead of repeating the list of test twice, I've defined away the list of unstable test in a group, `langtools_jshell_unstable` and then defined tier1 as `langtools_all - langtools_jshell_unstable` while tier2 is defined as simply `langtools_jshell_unstable`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add trailing newline

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4033/files
  - new: https://git.openjdk.java.net/jdk/pull/4033/files/ae569487..a5d1cb05

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

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

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

From jjg at openjdk.java.net  Fri May 14 21:05:01 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 14 May 2021 21:05:01 GMT
Subject: RFR: JDK-8267187: Remove deprecated constructor for Log
Message-ID: <rGHgCvTm9YL8WG3-PCba65WnJz6kEZ13yfMn2qV9K38=.c0d45414-efba-406a-888e-316265587614@github.com>

In the course of other work, I came across this deprecated constructor in Log which just existed for a public entry point in javadoc which has already been removed.

There is one remaining use in javadoc, which can be changed to use an alternate non-deprecated constructor.

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

Commit messages:
 - JDK-8267187: Remove deprecated constructor for Log

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

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

From iris at openjdk.java.net  Fri May 14 21:16:51 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 14 May 2021 21:16:51 GMT
Subject: RFR: JDK-8267187: Remove deprecated constructor for Log
In-Reply-To: <rGHgCvTm9YL8WG3-PCba65WnJz6kEZ13yfMn2qV9K38=.c0d45414-efba-406a-888e-316265587614@github.com>
References: <rGHgCvTm9YL8WG3-PCba65WnJz6kEZ13yfMn2qV9K38=.c0d45414-efba-406a-888e-316265587614@github.com>
Message-ID: <b7mgPkmyqTKqhqoSorpBIa_Hw2QToLsZU8stXQCDr80=.68a72a28-a4a1-4ff7-aff0-81424c916223@github.com>

On Fri, 14 May 2021 20:49:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> In the course of other work, I came across this deprecated constructor in Log which just existed for a public entry point in javadoc which has already been removed.
> 
> There is one remaining use in javadoc, which can be changed to use an alternate non-deprecated constructor.

Marked as reviewed by iris (Reviewer).

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

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

From eastig at amazon.co.uk  Sat May 15 22:05:03 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Sat, 15 May 2021 22:05:03 -0000
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow
Message-ID: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com>

Hi,

Please review the backport of JDK-8177068 to 11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177068
Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a3c63a9dfb2c

The original patch does not apply cleanly to 11u. In the original patch, file DeferredAttr.java, calls of ?attribSpeculative? to be changed have the argument AttributionMode.SPECULATIVE. The original patch does not change this. In 11u ?attribSpeculative? does not have the parameter AttributionMode. I changed the affected calls to 11u API.

11u  webrev: http://cr.openjdk.java.net/~eastigeevich/8177068/webrev.00/

Tested: Amazon Linux 2 x86_64, tier1, tier2, langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java
Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153

Thanks,
Evgeny




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.


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

From eastig at amazon.co.uk  Sat May 15 22:51:07 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Sat, 15 May 2021 22:51:07 -0000
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow
Message-ID: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com>

Hi,

Please review the backport of JDK-8177068 to 11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177068
Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a3c63a9dfb2c

The original patch does not apply cleanly to 11u. In the original patch, file DeferredAttr.java, calls of ?attribSpeculative? to be changed have the argument AttributionMode.SPECULATIVE. The original patch does not change this. In 11u ?attribSpeculative? does not have the parameter AttributionMode. I changed the affected calls to 11u API.

11u  webrev: http://cr.openjdk.java.net/~eastigeevich/8177068/webrev.00/

Tested: Amazon Linux 2 x86_64, tier1, tier2, langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java
Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153

Thanks,
Evgeny




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.


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

From raffaello.giulietti at gmail.com  Sat May 15 22:55:40 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Sat, 15 May 2021 22:55:40 -0000
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}(Internet mail)
In-Reply-To: <72184DF4-C63B-488F-8490-074247292022@tencent.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
 <72184DF4-C63B-488F-8490-074247292022@tencent.com>
Message-ID: <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>

Hi Jie,

I don't think that changing the spec of Math.pow() to be misaligned with 
IEEE 754 would be a wise option. IEEE is much more pervasive than Java. 
There are many aspects in IEEE that might be seen as questionable, but 
at least it is a widely adopted standard.

AFAIU, the only reason you would like to "optimize" the special case of 
y = 0.5 in pow(x, y) to return sqrt(x) is for performance, more accuracy 
and some kind of consistency.

But then, why not a special case for y = 0.25 as sqrt(sqrt(x))?
And what about y = 0.75? Should this be translated to sqrt(sqrt(pow(x, 3)))?
What about y = 1.0 / 3.0? Should this become cbrt(x)?
And why not consider y = 2.0 / 3.0 in a special rule: cbrt(x * x)?

You see, the special cases can quickly become unmanageable. Also, 
special rules would produce results which are "discontinuous" with 
nearby exponents, like y = 0.5000000000000001.

That's probably why IEEE doesn't propose translation rules for finite 
numerical exponents that are not integers, except when x is a special value.


Greetings
Raffaello



On 2021-04-12 13:44, jiefu(??) wrote:
> Hi Andrew H, Andrew D, and Raffaello,
> 
> Thank you all for your kind reply and helpful comments.
> 
> Now I got where the rules come from.
> But I don't think the IEEE standars are reasonable to specify conflits rules.
> Maybe, these computations should be open to be implementation dependent.
> 
> (If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java.
> We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right?
> And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> ?On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
> 
>      Hi Jie,
>      
>      the behavior you report is the one specified by the standard IEEE 754.
>      Java follows this standard as closely as it can.
>      
>      The standard says that
>      * squareRoot(-0) = -0
>      * squareRoot(-?) = NaN
>      
>      Also, the standard has a long lists of special cases for pow(x, y),
>      among them:
>      * pow(?0, y) is +0 for finite y > 0 and not an odd integer
>      * pow(-?, y) is +? for finite y > 0 and not an odd integer
>      
>      Thus, the conflicts you observe originate in following the standard, not
>      by special Java rules.
>      
>      Unfortunately, the IEEE standard does not explain the reasons for the
>      special rules. Some are obvious, some are not.
>      
>      
>      HTH
>      Raffaello
>      
>      
>      > Hi all,
>      >
>      > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
>      > ```
>      > Math.pow(-0.0, 0.5) = 0.0
>      > Math.sqrt(-0.0) = -0.0
>      >
>      > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
>      > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
>      > ```
>      >
>      > The reason is that both of pow and sqrt have special rules for these computations.
>      > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
>      > And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
>      > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
>      >
>      > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
>      >
>      > So why Java creates conflict special rules for them?
>      > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
>      >
>      > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
>      > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
>      >
>      > Thanks.
>      > Best regards,
>      > Jie
>      
>      
> 


From hichem_bourada at hotmail.fr  Sat May 15 22:59:06 2021
From: hichem_bourada at hotmail.fr (hichem bourada)
Date: Sat, 15 May 2021 22:59:06 -0000
Subject: Follow-up bug report on compiler JDK-8254571
Message-ID: <PAXPR08MB6477B06E313257DE01E2534689929@PAXPR08MB6477.eurprd08.prod.outlook.com>

Hi
I have submitted a compiler bug report reference: JDK-825457 since 2020-10-09, and I want to know if it will be fixed for next java release, even though there is a workaround solution to avoid this compilation error my intellij idea does not show compiler error as javac.
Regards
Hichem BOURADA


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

From mernst at cs.washington.edu  Sat May 15 23:01:32 2021
From: mernst at cs.washington.edu (Michael Ernst)
Date: Sat, 15 May 2021 23:01:32 -0000
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
Message-ID: <CAAJCdQQZ6+CLw8gkeAr6vuT-8h5-p7tCzNUUHxCSjdWFn6d7jg@mail.gmail.com>

I concur with Alex:  an annotation defined without a @Target annotation
should be applicable to all contexts.
Some wording goofs have caused confusion about the intent and the effect,
but we have an opportunity now to clarify that.

Mike

On Wed, Feb 3, 2021 at 10:39 AM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Let me focus first on the design question of what a no- at Target
> annotation type "means". There's no particular reason why it _shouldn't_
> mean "all contexts". Mike gave good reasons why it should mean that. For
> the corner case of an annotation appearing in one of the ambiguous
> locations in source code, the annotation will appear in the class
> file/via reflection exactly as if someone had taken the perfectly
> legitimate course of spelling out @Target({METHOD, TYPE_USE}) -- the
> no- at Target case is not a secret door to behavior that's otherwise
> impossible or undesirable.
>
> (We could have said "all contexts" for a no- at Target annotation type but
> then added a rule in 9.7.4 to special-case a no- at Target annotation that
> appears in an ambiguous location, e.g., to compile the annotation as if
> it was applicable only in declaration contexts. More compatibility with
> SE 8, but more complexity, and I don't think anyone really wants that.)
>
> Turning to the compatibility concern: yes, JDK-8231435 shouldn't have
> claimed behavioral compatibility. It was my error to not recognize what
> Mike was saying in "It is a behavior change from the current
> specification, but a small one that affects poorly-written programs that
> have no @Target meta-annotation." Still, at the end of the day, it's no
> more than a small behavioral incompatibility for annotation processors
> (they may see more type annotations than they did before), and one which
> was within the power of the annotation type's owner to induce anyway
> (annotation processors that look for type annotations can reasonably be
> expected to ignore type annotations in places they don't care about).
>
> I have cc'd Mike in case he wants to add anything further, but the
> design intent of "all contexts" still looks reasonable to me.
>
> Alex
>
> On 2/3/2021 5:29 AM, Joel Borggren-Franck wrote:
> > Hi Alex,
> >
> > Looking at  the class file, and therefore reflection, there is a
> difference between ?all declaration contexts? and ?all contexts,
> declaration + type?. For the 5 ambiguous locations we would have to produce
> type annotation attributes if there is an annotation present whose
> declaration lack @Target. While this may or may not be desirable, and I?m
> leaning towards not, it is surely significant as it would change the
> semantics of reflective annotation processors in use.
> >
> > cheers
> > /Joel
> >
> >> On 2 Feb 2021, at 19:50, Alex Buckley <alex.buckley at oracle.com> wrote:
> >>
> >> I initially proposed "all declaration contexts" as the smallest
> possible streamlining of the SE 7-oriented rule defined in SE 8. It would
> have ensured that legacy annotation types without @Target were locked out
> of the new world of type uses enabled in SE 8 by JSR 308. As it turned out,
> my conservative approach was unnecessary because Mike was fine with
> admitting those legacy annotation types for type uses via the "all
> contexts" rule. In the real world, "all declaration contexts" versus "all
> declaration contexts + all type contexts" is a distinction without a
> difference (that is, an insignificant distinction) -- we're best off
> adopting the latter rule, phrased simply as "all contexts".
> >>
> >> Alex
> >>
> >> On 2/2/2021 3:44 AM, Guoxiong Li wrote:
> >>> On Tue, 2 Feb 2021 09:28:59 GMT, Joel Borggr?n-Franck <
> jfranck at openjdk.org> wrote:
> >>>>> Thanks for the comments,
> >>>>>
> >>>>> @jbf I'll add a more focused test. For the bug, the original
> discussion in
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
> is specifically about annotations without an explicit `@Target` applying to
> `MODULE`, I don't think there's anything that needs to be done for
> [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) besides
> supporting `MODULE`, would you still prefer a separate bug?
> >>>>>
> >>>>> @jddarcy note that there was already a spec change related to this
> in [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) and
> the spec bug mentions "this expansion is source, binary, and behaviorally
> compatible", should I still file a CSR?
> >>>>
> >>>>  From this follow up here:
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html
> my interpretation is that this bug was intended to widen it to all
> contexts, including type use. This has been changed in JLS but not in the
> normative javadoc and also not in the compiler. I believe we should keep
> declarations only, and back out the change to JLS.
> >>> Maybe we should collect the concrete information about this problem.
> Here are some materials that I know.
> >>> Order by time:
> >>> - 2019.08 **Werner Dietl** launched the discussion. [1]
> >>> - 2019.09 After the discussion between **Alex Buckley** and **Michael
> Ernst**, an initiative result came out.[2]
> >>> - 2019.09 Two JBS issues were filed. [3][4]
> >>> - 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the
> compiler code and javadoc were not fixed. [5][6]
> >>> - 2020.10 **Christian Stein** created another issue about it. [7]
> >>> - 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
> >>> - 2020.10 **Joel Borggr?n-Franck** restarted the discussion about the
> specification. [9]
> >>> - 2020.12 Because the JDK16 was nearly at RDP1, we decided to only fix
> JDK-8254023. And other work left to JDk17.  [7][10][11]
> >>> - 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
> >>> - **Now, we need to discuss the problem(unify the specification,
> implement and javadoc) that JDK16 has left.**[11]
> >>> [1]
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
> >>> [2]
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
> >>> [3] https://bugs.openjdk.java.net/browse/JDK-8231435
> >>> [4] https://bugs.openjdk.java.net/browse/JDK-8231436
> >>> [5]
> https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
> >>> [6]
> https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
> >>> [7] https://bugs.openjdk.java.net/browse/JDK-8254023
> >>> [8] https://github.com/openjdk/jdk/pull/622
> >>> [9]
> https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
> >>> [10] http://openjdk.java.net/projects/jdk/16/
> >>> [11]
> https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
> >>> [12] https://github.com/openjdk/jdk16/pull/34
> >>> -------------
> >>> PR: https://git.openjdk.java.net/jdk/pull/2303
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210515/fde049d8/attachment.htm>

From msokolov at gmail.com  Sat May 15 23:03:43 2021
From: msokolov at gmail.com (Michael Sokolov)
Date: Sat, 15 May 2021 23:03:43 -0000
Subject: javac reports broken HTML on multiline mailto links
In-Reply-To: <CAM21Rt9eOgXWA8dq6HUwJPW7nFpnPp7YcdQKHYRMaMmMGyEmpA@mail.gmail.com>
References: <CAM21Rt9eOgXWA8dq6HUwJPW7nFpnPp7YcdQKHYRMaMmMGyEmpA@mail.gmail.com>
Message-ID: <CAGUSZHCOZNVDrbqHWtUtxVzQ+ZzTsfv3PL4czD=Baw06dsZxjg@mail.gmail.com>

Ugh the mailto: breaks it? Seems like a bug to me. Maybe the javadoc parser
tries to validate the content of an href attribute?

On Wed, Dec 23, 2020, 5:39 AM Dawid Weiss <dawid.weiss at gmail.com> wrote:

> Hello and Merry Christmas,
>
> I discovered this odd javac behavior with jdk8 up to jdk15 (didn't
> check the latest head). This source file (note the anchor tag over
> multiple lines):
>
> /**
>  * Lucene internals or asking for help on <a
>  * href="mailto:java-user at lucene.apache.org">java-user at lucene.apache.org
> </a>
>   */
> public class Breaks {}
>
> When compiled with
>
> javac -Xdoclint:all/protected Breaks.java
>
> generates this:
>
> Breaks.java:2: error: malformed HTML
>  * Lucene internals or asking for help on <a
>                                           ^
> Breaks.java:3: error: bad use of '>'
>  * href="mailto:java-user at lucene.apache.org">java-user at lucene.apache.org
> </a>
>                                             ^
> Breaks.java:3: error: unexpected end tag: </a>
>  * href="mailto:java-user at lucene.apache.org">java-user at lucene.apache.org
> </a>
>                                                                         ^
> What's interesting is that the following two alternatives compile just
> fine:
>
> /**
>  * Lucene internals or asking for help on <a
>  * href="http://lucene.apache.org">java-user at lucene.apache.org</a>
>   */
> public class Passes {}
>
> /**
>  * Lucene internals or asking for help on <a
> href="mailto:java-user at lucene.apache.org">java-user at lucene.apache.org</a>
> to figure out why.
>   */
> public class Passes2 {}
>
> Is it just me or all these should compile just fine?...
>
> Dawid
>
> [1] Just in case mail clients attempt to reformat the pasted examples,
> here's a gist with
> the sources:
> https://gist.github.com/dweiss/c1c9f218c6a8e5d2f253193806a9f472
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org
> For additional commands, e-mail: dev-help at lucene.apache.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210515/580b51d4/attachment.htm>

From harold.seigel at oracle.com  Sat May 15 23:11:49 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Sat, 15 May 2021 23:11:49 -0000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
Message-ID: <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>

Hi David,

Thanks for looking at this.

The intent was for method Class.permittedSubclasses() to be implemented 
similarly to Class.getNestMembers().? Are you suggesting that a security 
manager check be added to permittedSubclasses() similar to the security 
manager check in getNestMembers()?

Thanks, Harold

On 11/18/2020 12:31 AM, David Holmes wrote:
> Hi Vincente,
>
> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>> Please review the code for the second iteration of sealed classes. In 
>> this iteration we are:
>>
>> - Enhancing narrowing reference conversion to allow for stricter 
>> checking of cast conversions with respect to sealed type hierarchies.
>> - Also local classes are not considered when determining implicitly 
>> declared permitted direct subclasses of a sealed class or sealed 
>> interface
>
> The major change here seems to be that getPermittedSubclasses() now 
> returns actual Class objects instead of ClassDesc. My recollection 
> from earlier discussions here was that the use of ClassDesc was very 
> deliberate as the permitted subclasses may not actually exist and 
> there may be security concerns with returning them!
>
> Cheers,
> David
> -----
>
>> -------------
>>
>> Commit messages:
>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>> pull/1227/head:pull/1227
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1227
>>


From jjg at openjdk.java.net  Sun May 16 15:49:51 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sun, 16 May 2021 15:49:51 GMT
Subject: RFR: 8267162 Add jtreg test group definitions for langtools [v2]
In-Reply-To: <mCr-d9Av1OMFQjpA2qc-PB_t24H0EEwu2e22y_RWptM=.622f068a-0663-4951-98e3-c9742bda2cee@github.com>
References: <Lz5FA8fNf4wsnNykSnkcslTOdIIRVnMl-_ZUG5gsnKA=.fb781ded-e612-4f7d-b65d-a459c285ce99@github.com>
 <mCr-d9Av1OMFQjpA2qc-PB_t24H0EEwu2e22y_RWptM=.622f068a-0663-4951-98e3-c9742bda2cee@github.com>
Message-ID: <mVHiOz3b-bjeCejLnDLB0qhdUkULAWCRIwVOL0kk9UU=.92ffbc6b-2391-4c8c-80f1-3d057e4a3cab@github.com>

On Fri, 14 May 2021 16:46:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds test group definitions for langtools, so that langtools tests can be more easily discovered when running make.
>> 
>> For instance, with this patch, typing:
>> 
>> 
>> $ make run-test-langtools_
>> 
>> 
>> and then hit tab (on Linux) reveals the following possible completions:
>> 
>> 
>> run-test-langtools_all                   run-test-langtools_javac                 run-test-langtools_javadoc               run-test-langtools_javap                 run-test-langtools_jdeprscan             run-test-langtools_jdeps                 run-test-langtools_jshell                run-test-langtools_jshell_unstable       run-test-langtools_sjavac
>> run-test-langtools_all-only              run-test-langtools_javac-only            run-test-langtools_javadoc-only          run-test-langtools_javap-only            run-test-langtools_jdeprscan-only        run-test-langtools_jdeps-only            run-test-langtools_jshell-only           run-test-langtools_jshell_unstable-only  run-test-langtools_sjavac-only
>> 
>> 
>> (the `-only` targets are added by make - the others are the ones added by this patch).
>> 
>> I've added a group for every major tool:
>> 
>> * javac
>> * javadoc
>> * jshell
>> * javap
>> * jdeps
>> * jdeprscan
>> * sjavac
>> 
>> Plus a target (`langtools_all`) which runs all langtools test. For every tool target, the group also run shared tests (e.g. the coding rules tests).
>> 
>> I also reorganized tier1 and tier2 groups a little: both tiers were referring to a group of jshell tests which is less stable than the others, so has been moved to tier2. Instead of repeating the list of test twice, I've defined away the list of unstable test in a group, `langtools_jshell_unstable` and then defined tier1 as `langtools_all - langtools_jshell_unstable` while tier2 is defined as simply `langtools_jshell_unstable`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add trailing newline

Marked as reviewed by jjg (Reviewer).

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

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

From gli at openjdk.java.net  Mon May 17 02:23:45 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 17 May 2021 02:23:45 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v4]
In-Reply-To: <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
Message-ID: <06LNR_l30ouumqNdnBBq8LcR7BIrDqSmU8LItScvyOo=.7da7980b-2d6e-4539-9268-e5edf1944307@github.com>

On Tue, 11 May 2021 02:41:16 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
>> so that the output of --help-extra is kept clean and concise.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8230623
>  - Update copyright
>  - Merge branch 'master' into JDK-8230623
>  - Remove the content in documentation javac.1
>  - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint

Ping.

May I ask your help to review this patch? Thanks a lot.

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

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

From jlahoda at openjdk.java.net  Mon May 17 11:32:38 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 17 May 2021 11:32:38 GMT
Subject: RFR: 8267119: switch expressions lack support for deferred
 type-checking
Message-ID: <kSB8sAx3aIMGFBgBo8QnzuWpgPKhkcgwtZc9ivPZUVg=.7f86f549-d44e-44d3-a376-7af81c11bc74@github.com>

Similarly to lambdas with block body looking at expression in return statements, we need `CheckStuckPolicy` to look at all `yield` values in a switch expression, to determine the types correctly, as pointed out in the bugreport.

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

Commit messages:
 - 8267119: switch expressions lack support for deferred type-checking

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

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

From mcimadamore at openjdk.java.net  Mon May 17 11:59:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 17 May 2021 11:59:40 GMT
Subject: RFR: 8267119: switch expressions lack support for deferred
 type-checking
In-Reply-To: <kSB8sAx3aIMGFBgBo8QnzuWpgPKhkcgwtZc9ivPZUVg=.7f86f549-d44e-44d3-a376-7af81c11bc74@github.com>
References: <kSB8sAx3aIMGFBgBo8QnzuWpgPKhkcgwtZc9ivPZUVg=.7f86f549-d44e-44d3-a376-7af81c11bc74@github.com>
Message-ID: <XT3UEVi91BkmZPn-GXKRHL6EGOi-UJAgFXJxmSjygj0=.23e36072-d117-4afc-b968-05859c02325a@github.com>

On Mon, 17 May 2021 11:22:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Similarly to lambdas with block body looking at expression in return statements, we need `CheckStuckPolicy` to look at all `yield` values in a switch expression, to determine the types correctly, as pointed out in the bugreport.

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon May 17 12:58:37 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 17 May 2021 12:58:37 GMT
Subject: Integrated: 8267162 Add jtreg test group definitions for langtools
In-Reply-To: <Lz5FA8fNf4wsnNykSnkcslTOdIIRVnMl-_ZUG5gsnKA=.fb781ded-e612-4f7d-b65d-a459c285ce99@github.com>
References: <Lz5FA8fNf4wsnNykSnkcslTOdIIRVnMl-_ZUG5gsnKA=.fb781ded-e612-4f7d-b65d-a459c285ce99@github.com>
Message-ID: <8Dwgq-1oHaNdYZ6clSSe56JMASXFYP2fk4a09GLj3Mw=.5b5536a1-0a50-4bb3-a1e3-ce8bf4d7ee71@github.com>

On Fri, 14 May 2021 14:36:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds test group definitions for langtools, so that langtools tests can be more easily discovered when running make.
> 
> For instance, with this patch, typing:
> 
> 
> $ make run-test-langtools_
> 
> 
> and then hit tab (on Linux) reveals the following possible completions:
> 
> 
> run-test-langtools_all                   run-test-langtools_javac                 run-test-langtools_javadoc               run-test-langtools_javap                 run-test-langtools_jdeprscan             run-test-langtools_jdeps                 run-test-langtools_jshell                run-test-langtools_jshell_unstable       run-test-langtools_sjavac
> run-test-langtools_all-only              run-test-langtools_javac-only            run-test-langtools_javadoc-only          run-test-langtools_javap-only            run-test-langtools_jdeprscan-only        run-test-langtools_jdeps-only            run-test-langtools_jshell-only           run-test-langtools_jshell_unstable-only  run-test-langtools_sjavac-only
> 
> 
> (the `-only` targets are added by make - the others are the ones added by this patch).
> 
> I've added a group for every major tool:
> 
> * javac
> * javadoc
> * jshell
> * javap
> * jdeps
> * jdeprscan
> * sjavac
> 
> Plus a target (`langtools_all`) which runs all langtools test. For every tool target, the group also run shared tests (e.g. the coding rules tests).
> 
> I also reorganized tier1 and tier2 groups a little: both tiers were referring to a group of jshell tests which is less stable than the others, so has been moved to tier2. Instead of repeating the list of test twice, I've defined away the list of unstable test in a group, `langtools_jshell_unstable` and then defined tier1 as `langtools_all - langtools_jshell_unstable` while tier2 is defined as simply `langtools_jshell_unstable`.

This pull request has now been integrated.

Changeset: dd5a84c6
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dd5a84c68c4f6128c3568c6f4fc1302c6aaadf01
Stats:     65 lines in 1 file changed: 43 ins; 15 del; 7 mod

8267162: Add jtreg test group definitions for langtools

Reviewed-by: jjg

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

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

From asotona at openjdk.java.net  Mon May 17 13:18:58 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 17 May 2021 13:18:58 GMT
Subject: RFR: 8264561: javap get NegativeArraySizeException on bad instruction
Message-ID: <T6V2bnDOXukrEvmc40phG-vfqATdeltkj-Go_IdswDo=.1d8dd5bf-bee1-4f26-8f15-b51980ae8f9f@github.com>

Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH bytecode instructions resulting to negative array allocation with NegativeArraySizeException, which is reported to user with stack trace and as serious internal error.

The fix in c.s.t.classfile.Instruction is checking for negative array size of corrupted TABLESWITCH or LOOKUPSWITCH bytecode and throwing j.l.IllegalStateException instead of the NegativeArraySizeException.
 
Another part of the fix in c.s.t.javap.CodeWriter is catching j.l.IllegalStateException and reporting it as error in the analyzed bytecode, instead of passing it up and causing serious internal javap error.

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

Commit messages:
 - 8264561: javap get NegativeArraySizeException on bad instruction

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

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

From vromero at openjdk.java.net  Mon May 17 14:50:40 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 17 May 2021 14:50:40 GMT
Subject: RFR: 8264561: javap get NegativeArraySizeException on bad
 instruction
In-Reply-To: <T6V2bnDOXukrEvmc40phG-vfqATdeltkj-Go_IdswDo=.1d8dd5bf-bee1-4f26-8f15-b51980ae8f9f@github.com>
References: <T6V2bnDOXukrEvmc40phG-vfqATdeltkj-Go_IdswDo=.1d8dd5bf-bee1-4f26-8f15-b51980ae8f9f@github.com>
Message-ID: <fQTkRsO80wCJBo30VoFCF1zeGXV6VMDDqZ1OshCqAPo=.93e4b5ad-ccf6-45a1-bc3d-fb1a568f7ee2@github.com>

On Mon, 17 May 2021 13:11:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH bytecode instructions resulting to negative array allocation with NegativeArraySizeException, which is reported to user with stack trace and as serious internal error.
> 
> The fix in c.s.t.classfile.Instruction is checking for negative array size of corrupted TABLESWITCH or LOOKUPSWITCH bytecode and throwing j.l.IllegalStateException instead of the NegativeArraySizeException.
>  
> Another part of the fix in c.s.t.javap.CodeWriter is catching j.l.IllegalStateException and reporting it as error in the analyzed bytecode, instead of passing it up and causing serious internal javap error.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon May 17 15:01:37 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 17 May 2021 15:01:37 GMT
Subject: RFR: 8263614: javac allows local variables to be accessed from a
 static context [v3]
In-Reply-To: <C5ZZFfT7FWDYtU7_pJQ5gJ4g-apeeQkIYvXoIKiVzbc=.88c45706-05e2-47ab-bdc5-21116b651143@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
 <C5ZZFfT7FWDYtU7_pJQ5gJ4g-apeeQkIYvXoIKiVzbc=.88c45706-05e2-47ab-bdc5-21116b651143@github.com>
Message-ID: <xHSVASz9IfT2PZvYs-oWAbZCuYQVy4BTfkP_5fkdYlE=.e6a50a24-8dab-4ac5-b977-f4ea3423a91a@github.com>

On Fri, 14 May 2021 15:25:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> javac breaks with NPE if compiles this code:
>> 
>> 
>> public class LocalClasses {
>>     public static void main(String[] args) {
>>         int i = 5;
>>         class Local {
>>             static void m() {
>>                 System.out.println("Value of i = " + i);
>>             }
>>         }
>>         Local.m();
>>     }
>> } 
>> 
>> 
>> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
>> 
>> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch suggested by Maurizio

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From vromero at openjdk.java.net  Mon May 17 15:07:34 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 17 May 2021 15:07:34 GMT
Subject: Integrated: 8263614: javac allows local variables to be accessed from
 a static context
In-Reply-To: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
References: <dbCVQmJTna2hP7AS9E1FatJQrVLOnatjGoOdfOoYImo=.5c226e40-6f08-4c6b-8bcb-054f094441ce@github.com>
Message-ID: <otf5S1rqzoByxJ9HuaDcJpAk01Qab5iZumBtqYF3hzQ=.5b71d350-df3f-4c5c-8991-73528ba5cea4@github.com>

On Wed, 12 May 2021 20:37:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac breaks with NPE if compiles this code:
> 
> 
> public class LocalClasses {
>     public static void main(String[] args) {
>         int i = 5;
>         class Local {
>             static void m() {
>                 System.out.println("Value of i = " + i);
>             }
>         }
>         Local.m();
>     }
> } 
> 
> 
> actually the compiler should issue a compiling error as local variable `i` is being accessed from a static context. Please review this fix to address this issue. Some notes:
> 
> `com.sun.tools.javac.comp.AttrContext.staticLevel` keeps a the number of nested static contexts but this calculation doesn't consider static type declarations. This is because static declaration doesn't introduce a static context. But if they have a static modifier, even if implicit as it is for local records, then this affects what variables, type variables, etc are accessible from the body of the static type declaration. For this reason I have used an `adjusted` static level that takes static type declarations into account.
> 
> TIA

This pull request has now been integrated.

Changeset: b8856b1c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b8856b1c47895eae0a5563ee1a8ac454863ee0a6
Stats:     115 lines in 2 files changed: 79 ins; 24 del; 12 mod

8263614: javac allows local variables to be accessed from a static context

Reviewed-by: mcimadamore

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

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

From asotona at openjdk.java.net  Mon May 17 15:27:39 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 17 May 2021 15:27:39 GMT
Subject: Integrated: 8264561: javap get NegativeArraySizeException on bad
 instruction
In-Reply-To: <T6V2bnDOXukrEvmc40phG-vfqATdeltkj-Go_IdswDo=.1d8dd5bf-bee1-4f26-8f15-b51980ae8f9f@github.com>
References: <T6V2bnDOXukrEvmc40phG-vfqATdeltkj-Go_IdswDo=.1d8dd5bf-bee1-4f26-8f15-b51980ae8f9f@github.com>
Message-ID: <shTI3flAB2--fg0SH6DV-pftzMAfSlmMGdYyl0BHHQA=.0f9e5875-976c-4db7-b2df-754a233e6705@github.com>

On Mon, 17 May 2021 13:11:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH bytecode instructions resulting to negative array allocation with NegativeArraySizeException, which is reported to user with stack trace and as serious internal error.
> 
> The fix in c.s.t.classfile.Instruction is checking for negative array size of corrupted TABLESWITCH or LOOKUPSWITCH bytecode and throwing j.l.IllegalStateException instead of the NegativeArraySizeException.
>  
> Another part of the fix in c.s.t.javap.CodeWriter is catching j.l.IllegalStateException and reporting it as error in the analyzed bytecode, instead of passing it up and causing serious internal javap error.

This pull request has now been integrated.

Changeset: cf97252f
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cf97252f3fd4e7bdb57271b92dd2866101d4a94b
Stats:     5 lines in 2 files changed: 4 ins; 0 del; 1 mod

8264561: javap get NegativeArraySizeException on bad instruction

Reviewed-by: vromero

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

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

From hannesw at openjdk.java.net  Mon May 17 17:03:02 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 17 May 2021 17:03:02 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link
Message-ID: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>

The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature").

I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". 

A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). 

Here's a list of what references now cause what error messages:

 - `#foo(int`     `unterminated signature`
 - `#foo((int))`   `unexpected parenthesis`
 - `#foo(int))`   `unexpected parenthesis`
 - `#foo(int)x`   `unexpected parenthesis`
 - `F<T`        `unterminated signature`
 - `F<T>>`    `unexpected input`

I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature".

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

Commit messages:
 - JDK-8264181: javadoc tool Incorrect error message about malformed link

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

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

From hohensee at amazon.com  Mon May 17 18:11:22 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 17 May 2021 18:11:22 +0000
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow
In-Reply-To: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com>
References: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com>
Message-ID: <6E00186C-5E38-4539-BE95-5392549B0625@amazon.com>

Hi, Evgeny.

I reviewed this backport last month and tagged the issue. Waiting on maintainer (Christoph?) approval.

Thanks,
Paul

From: compiler-dev <compiler-dev-retn at openjdk.java.net> on behalf of "Astigeevich, Evgeny" <eastig at amazon.co.uk>
Date: Saturday, May 15, 2021 at 3:05 PM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Cc: "compiler-dev at openjdk.java.net" <compiler-dev at openjdk.java.net>
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow

Hi,

Please review the backport of JDK-8177068 to 11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177068
Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a3c63a9dfb2c

The original patch does not apply cleanly to 11u. In the original patch, file DeferredAttr.java, calls of ?attribSpeculative? to be changed have the argument AttributionMode.SPECULATIVE. The original patch does not change this. In 11u ?attribSpeculative? does not have the parameter AttributionMode. I changed the affected calls to 11u API.

11u  webrev: http://cr.openjdk.java.net/~eastigeevich/8177068/webrev.00/

Tested: Amazon Linux 2 x86_64, tier1, tier2, langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java
Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153

Thanks,
Evgeny




Amazon Development Centre (London) Ltd.Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



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

From christoph.langer at sap.com  Mon May 17 18:23:37 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 17 May 2021 18:23:37 +0000
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow
In-Reply-To: <6E00186C-5E38-4539-BE95-5392549B0625@amazon.com>
References: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com>
 <6E00186C-5E38-4539-BE95-5392549B0625@amazon.com>
Message-ID: <AM4PR02MB3138152939C22C7117FAE5A18A2D9@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Paul,

you not only requested approval. You also got it and then pushed (on 21st of April). ??

I guess Evgeny?s mail popped up again on the mailing list for some reason?

Cheers
Christoph

From: compiler-dev <compiler-dev-retn at openjdk.java.net> On Behalf Of Hohensee, Paul
Sent: Montag, 17. Mai 2021 20:11
To: Astigeevich, Evgeny <eastig at amazon.co.uk>; jdk-updates-dev at openjdk.java.net
Cc: compiler-dev at openjdk.java.net
Subject: Re: [11u] RFR 8177068: incomplete classpath causes NPE in Flow

Hi, Evgeny.

I reviewed this backport last month and tagged the issue. Waiting on maintainer (Christoph?) approval.

Thanks,
Paul

From: compiler-dev <compiler-dev-retn at openjdk.java.net<mailto:compiler-dev-retn at openjdk.java.net>> on behalf of "Astigeevich, Evgeny" <eastig at amazon.co.uk<mailto:eastig at amazon.co.uk>>
Date: Saturday, May 15, 2021 at 3:05 PM
To: "jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>" <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Cc: "compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>" <compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>>
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow

Hi,

Please review the backport of JDK-8177068 to 11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177068
Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a3c63a9dfb2c

The original patch does not apply cleanly to 11u. In the original patch, file DeferredAttr.java, calls of ?attribSpeculative? to be changed have the argument AttributionMode.SPECULATIVE. The original patch does not change this. In 11u ?attribSpeculative? does not have the parameter AttributionMode. I changed the affected calls to 11u API.

11u  webrev: http://cr.openjdk.java.net/~eastigeevich/8177068/webrev.00/

Tested: Amazon Linux 2 x86_64, tier1, tier2, langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java
Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153

Thanks,
Evgeny




Amazon Development Centre (London) Ltd.Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.


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

From hohensee at amazon.com  Mon May 17 18:30:49 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 17 May 2021 18:30:49 +0000
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow
Message-ID: <CEE44242-E850-4D42-89B5-760FD4F1BCA0@amazon.com>

That?s what I get for not actually looking at the issue before responding? :)

From: "Langer, Christoph" <christoph.langer at sap.com>
Date: Monday, May 17, 2021 at 11:24 AM
To: "Hohensee, Paul" <hohensee at amazon.com>, "Astigeevich, Evgeny" <eastig at amazon.co.uk>, "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Cc: "compiler-dev at openjdk.java.net" <compiler-dev at openjdk.java.net>
Subject: RE: [11u] RFR 8177068: incomplete classpath causes NPE in Flow

Hi Paul,

you not only requested approval. You also got it and then pushed (on 21st of April). ??

I guess Evgeny?s mail popped up again on the mailing list for some reason?

Cheers
Christoph

From: compiler-dev <compiler-dev-retn at openjdk.java.net> On Behalf Of Hohensee, Paul
Sent: Montag, 17. Mai 2021 20:11
To: Astigeevich, Evgeny <eastig at amazon.co.uk>; jdk-updates-dev at openjdk.java.net
Cc: compiler-dev at openjdk.java.net
Subject: Re: [11u] RFR 8177068: incomplete classpath causes NPE in Flow

Hi, Evgeny.

I reviewed this backport last month and tagged the issue. Waiting on maintainer (Christoph?) approval.

Thanks,
Paul

From: compiler-dev <compiler-dev-retn at openjdk.java.net<mailto:compiler-dev-retn at openjdk.java.net>> on behalf of "Astigeevich, Evgeny" <eastig at amazon.co.uk<mailto:eastig at amazon.co.uk>>
Date: Saturday, May 15, 2021 at 3:05 PM
To: "jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>" <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Cc: "compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>" <compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>>
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow

Hi,

Please review the backport of JDK-8177068 to 11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177068
Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a3c63a9dfb2c

The original patch does not apply cleanly to 11u. In the original patch, file DeferredAttr.java, calls of ?attribSpeculative? to be changed have the argument AttributionMode.SPECULATIVE. The original patch does not change this. In 11u ?attribSpeculative? does not have the parameter AttributionMode. I changed the affected calls to 11u API.

11u  webrev: http://cr.openjdk.java.net/~eastigeevich/8177068/webrev.00/

Tested: Amazon Linux 2 x86_64, tier1, tier2, langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java
Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153

Thanks,
Evgeny




Amazon Development Centre (London) Ltd.Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



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

From prappo at openjdk.java.net  Mon May 17 18:37:40 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 17 May 2021 18:37:40 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link
In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
Message-ID: <ZX5VPKiYUopITcv9bXyHEnMNx0Iw9H1uk8PHkMbR_8U=.18d55534-2057-46a8-a77b-92a7181f0547@github.com>

On Mon, 17 May 2021 16:54:07 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature").
> 
> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". 
> 
> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). 
> 
> Here's a list of what references now cause what error messages:
> 
>  - `#foo(int`     `unterminated signature`
>  - `#foo((int))`   `unexpected parenthesis`
>  - `#foo(int))`   `unexpected parenthesis`
>  - `#foo(int)x`   `unexpected parenthesis`
>  - `F<T`        `unterminated signature`
>  - `F<T>>`    `unexpected input`
> 
> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature".

1. I think this error is a counterintuitive:

       #foo(int)x
       error: unexpected parenthesis

It's `x` that is unexpected, not the parenthesis. It looks correct here, but only coincidentally:

       #foo(int))
       error: unexpected parenthesis

2. The latter case in your list, `F<T>>`, yields "unexpected text", not "unexpected input".
3. Why is there an asymmetry between wording for angle brackets and that of parenthesis?

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

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

From jlahoda at openjdk.java.net  Mon May 17 19:04:11 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 17 May 2021 19:04:11 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v2]
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <mhBOzAzWHkiIJvxHDZ3OFw21CAkl-t3Hq_63iOglgFU=.863816f0-f2ec-4066-bf38-acc6ad606fd0@github.com>

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Reflecting recent spec changes.
 - Reflecting review comments.
 - Reflecting review comments on SwitchBootstraps.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3863/files
  - new: https://git.openjdk.java.net/jdk/pull/3863/files/5e663d70..54ba974e

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

  Stats: 544 lines in 18 files changed: 431 ins; 68 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863

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

From jlahoda at openjdk.java.net  Mon May 17 19:04:11 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 17 May 2021 19:04:11 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v2]
In-Reply-To: <pk0mBpekpLd-AELuqFEQSLgKamNrMwuqf3n3Eg4J67Y=.634e1d3d-93d8-420a-aaf9-4a91f06d7e6b@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <pk0mBpekpLd-AELuqFEQSLgKamNrMwuqf3n3Eg4J67Y=.634e1d3d-93d8-420a-aaf9-4a91f06d7e6b@github.com>
Message-ID: <qC_1oBQ0rjrNJjosu_auqMsE6WBCupIGSyWv4tf7QfQ=.bf2ed70a-35e9-474b-8e17-644d126a175c@github.com>

On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Reflecting recent spec changes.
>>  - Reflecting review comments.
>>  - Reflecting review comments on SwitchBootstraps.
>
> Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening.
> 
> In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well.

@mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested changes in recent commits (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 ).

I've also tried to update the implementation for the latest spec changes here:
https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b

The spec changes are: total patterns are nullable; pattern matching ("new") statement switches must be complete (as switch expressions).

Any further feedback is welcome!

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

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

From github.com+828220+forax at openjdk.java.net  Mon May 17 19:21:41 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 17 May 2021 19:21:41 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v2]
In-Reply-To: <mhBOzAzWHkiIJvxHDZ3OFw21CAkl-t3Hq_63iOglgFU=.863816f0-f2ec-4066-bf38-acc6ad606fd0@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <mhBOzAzWHkiIJvxHDZ3OFw21CAkl-t3Hq_63iOglgFU=.863816f0-f2ec-4066-bf38-acc6ad606fd0@github.com>
Message-ID: <4O-2pD_4PUl_DRDCLvPO6nNwOvqN-j0GvQzogPTJ0hE=.d5009f6b-72a8-4a96-80b9-4a3a73178e1e@github.com>

On Mon, 17 May 2021 19:04:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>> 
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Reflecting recent spec changes.
>  - Reflecting review comments.
>  - Reflecting review comments on SwitchBootstraps.

It's not clear to me if it's the first change and several will follow or not.

The code looks good but the metaprotocol is not the right one IMO,
i would prefer the one we discuss in April
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-April/002992.html

But this can be tackle in another PR

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

Marked as reviewed by forax at github.com (no known OpenJDK username).

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

From weijun at openjdk.java.net  Mon May 17 22:01:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:49 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>

Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).

With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).

To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:

1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.

Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.

Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.

Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.

There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).

3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).

2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:

rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
 ```

The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

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

Commit messages:
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - test for nio
 - test for hotspot-runtime
 - test for security
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0

Changes: https://git.openjdk.java.net/jdk/pull/4071/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267184
  Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

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

From weijun at openjdk.java.net  Mon May 17 22:01:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:52 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for
 Removal
Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>

Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).

The code change is divided into 3 commits. Please review them one by one.

1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal

The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.

Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.

Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

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

Commit messages:
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266459
  Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From weijun at openjdk.java.net  Mon May 17 22:01:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <jYnPM3TGZaiZyNdO1TqYy5zWEHeqaEJH6dbp1xhiIHI=.213bd236-b2df-44d8-8f34-a963a3ffdfb6@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration.

Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 

+ @SuppressWarnings("removal")


There are also 7 cases where an existing annotation is updated

================= 2 ====================
- @SuppressWarnings("deprecation")
+ @SuppressWarnings({"removal","deprecation"})
================= 1 ====================
- @SuppressWarnings("Convert2Lambda")
+ @SuppressWarnings({"removal","Convert2Lambda"})
================= 1 ====================
- @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"})
+ @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"})
================= 1 ====================
- @SuppressWarnings("deprecation") // Use of RMISecurityManager
+ @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager
================= 1 ====================
- @SuppressWarnings("unchecked")     /*To suppress warning from line 1374*/
+ @SuppressWarnings({"removal","unchecked"})     /*To suppress warning from line 1374*/
================= 1 ====================
- @SuppressWarnings("fallthrough")
+ @SuppressWarnings({"removal","fallthrough"})


All other cases are new annotation embedded inline:

================= 7 ====================
- AccessControlContext acc) {
+ @SuppressWarnings("removal") AccessControlContext acc) {
================= 4 ====================
- AccessControlContext acc,
+ @SuppressWarnings("removal") AccessControlContext acc,
================= 3 ====================
- AccessControlContext context,
+ @SuppressWarnings("removal") AccessControlContext context,
================= 3 ====================
- AccessControlContext acc)
+ @SuppressWarnings("removal") AccessControlContext acc)
================= 2 ====================
- try (InputStream stream = AccessController.doPrivileged(pa)) {
+ try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) {
================= 2 ====================
- AccessControlContext context, Permission... perms) {
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
================= 2 ====================
- } catch (java.security.AccessControlException e) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException e) {
================= 2 ====================
- } catch (AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") AccessControlException ace) {
================= 2 ====================
- AccessControlContext context)
+ @SuppressWarnings("removal") AccessControlContext context)
================= 2 ====================
- AccessControlContext acc) throws LoginException {
+ @SuppressWarnings("removal") AccessControlContext acc) throws LoginException {
================= 2 ====================
- } catch (AccessControlException e) {
+ } catch (@SuppressWarnings("removal") AccessControlException e) {
================= 1 ====================
- public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- DomainCombiner combiner,
+ @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- } catch (java.security.AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) {
================= 1 ====================
- private static File checkFile(File f, SecurityManager sm) {
+ private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static File checkFile(File file, SecurityManager sm) {
+ private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm,
+ private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm,
================= 1 ====================
- ProtectionDomain[] getProtectDomains(AccessControlContext context);
+ ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- SecureCallbackHandler(java.security.AccessControlContext acc,
+ SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc,
================= 1 ====================
- private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- private void checkMemberAccess(SecurityManager sm, int which,
+ private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which,
================= 1 ====================
- private static File[] checkFiles(Stream<File> filesStream, SecurityManager sm) {
+ private static File[] checkFiles(Stream<File> filesStream, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- Thread(Runnable target, AccessControlContext acc) {
+ Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public ProtectionDomain[] getProtectDomains(AccessControlContext context) {
+ public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext stack,
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext stack,
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext(ProtectionDomain caller, DomainCombiner combiner,
+ AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- public URLClassPath(URL[] urls, AccessControlContext acc) {
+ public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- URLClassLoader(URL[] urls, AccessControlContext acc) {
+ URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public static void setSecurityManager(SecurityManager sm) {
+ public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- try (DataInputStream dis = new DataInputStream(new InflaterInputStream(
+ try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream(
================= 1 ====================
- try (FileInputStream fis = AccessController.doPrivileged(
+ try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged(
================= 1 ====================
- FactoryURLClassLoader(URL[] urls, AccessControlContext acc) {
+ FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- Thread newThreadWithAcc(Runnable target, AccessControlContext acc);
+ Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc);
================= 1 ====================
- SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) {
+ SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) {
================= 1 ====================
- private PolicyDelegate(PolicySpi spi, Provider p,
+ private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p,
================= 1 ====================
- DomainCombiner combiner) {
+ @SuppressWarnings("removal") DomainCombiner combiner) {
================= 1 ====================
- PrivilegedRunnable(Runnable r, AccessControlContext acc) {
+ PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private static File[] checkFiles(Stream<File> fs, SecurityManager sm) {
+ private static File[] checkFiles(Stream<File> fs, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private void checkSpecifyHandler(SecurityManager sm) {
+ private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- String serverPrincipal, AccessControlContext acc)
+ String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc)
================= 1 ====================
- public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) {
+ public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- try (InputStream is = AccessController.doPrivileged(new PrivilegedAction<InputStream>() {
+ try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction<InputStream>() {
================= 1 ====================
- public EventFileStream(AccessControlContext acc, Path path) throws IOException {
+ public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException {
================= 1 ====================
- AccessControlContext context, Permission... perms)
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
================= 1 ====================
- private static void privateCheckPackageAccess(SecurityManager s, Class<?> clazz) {
+ private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class<?> clazz) {
================= 1 ====================
- AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List<Configuration> configurations) throws IOException {
+ AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List<Configuration> configurations) throws IOException {
================= 1 ====================
- private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl,
+ private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl,
================= 1 ====================
- AccessControlContext context) {
+ @SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- public PrivilegedExecutor(Executor executor, AccessControlContext acc) {
+ public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
+ private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
================= 1 ====================
- try (BufferedReader bufferedReader =
+ try (@SuppressWarnings("removal") BufferedReader bufferedReader =
================= 1 ====================
- private static void privateCheckProxyPackageAccess(SecurityManager s, Class<?> clazz) {
+ private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class<?> clazz) {


**That's all**.

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

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

From erikj at openjdk.java.net  Mon May 17 22:30:56 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 17 May 2021 22:30:56 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <wihzX2vMKBxcpu3CE2BaQNZ1jyXj8e2Fbps1z0CJMlU=.e234b050-b1b0-4280-b764-9a409d5cf428@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Makefile change looks ok.

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

Marked as reviewed by erikj (Reviewer).

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

From dholmes at openjdk.java.net  Tue May 18 05:01:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 18 May 2021 05:01:46 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <JhTe209ZxiIMoOvppz7-1xRxGS2Rb-YiyJnD7OzZDp0=.73ed4efc-2751-4746-b5d2-1bfd327574a6@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Changes to hotspot-* and serviceability look good.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From alanb at openjdk.java.net  Tue May 18 05:51:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 05:51:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Marked as reviewed by alanb (Reviewer).

The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.

test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.

test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.

For uses using ProcessTools then it seems to be very random.

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

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

From alanb at openjdk.java.net  Tue May 18 06:33:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 06:33:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

src/java.base/share/classes/java/lang/SecurityManager.java line 315:

> 313:  *
> 314:  * @since   1.0
> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a

Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

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

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

From hannesw at openjdk.java.net  Tue May 18 06:59:39 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 18 May 2021 06:59:39 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link
In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
Message-ID: <IWD-2XhFlq1PKO6gH-EJ9AlRIX6uGq8y8Ur8dBttVik=.3e1b83f3-0b83-4e93-bb64-e57ad2ce8723@github.com>

On Mon, 17 May 2021 16:54:07 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature").
> 
> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". 
> 
> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). 
> 
> Here's a list of what references now cause what error messages:
> 
>  - `#foo(int`     `unterminated signature`
>  - `#foo((int))`   `unexpected parenthesis`
>  - `#foo(int))`   `unexpected parenthesis`
>  - `#foo(int)x`   `unexpected parenthesis`
>  - `F<T`        `unterminated signature`
>  - `F<T>>`    `unexpected input`
> 
> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature".

Thanks for reviewing, Pavel!

>     1. I think this error is a counterintuitive:
>        ```
>        #foo(int)x
>        error: unexpected parenthesis
>        ```
> 
> 
> It's `x` that is unexpected, not the parenthesis. It looks correct here, but only coincidentally:
> 
> ```
>    #foo(int))
>    error: unexpected parenthesis
> ```

Yes, you can look at it both ways, either there is a closing parenthesis where it shouldn't be, or there is text following a correctly placed closing parenthesis. We tend to see one or the other depending on whether the text up to the closing parenthesis looks like a proper signature, but it's not as clear to the parser. 

I still like the more specific message. We can use a more generic "unexpected text" message, but I think it is less useful.

>     1. The latter case in your list, `F<T>>`, yields "unexpected text", not "unexpected input".

That's my mistake, the resource key ends with `unexpected.input` but the English message is "unexpected text".

>     2. Why is there an asymmetry between wording for angle brackets and that of parenthesis?

See my answer to point 1, I like the message to be as specific as possible.

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

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

From hannesw at openjdk.java.net  Tue May 18 07:05:42 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 18 May 2021 07:05:42 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link
In-Reply-To: <IWD-2XhFlq1PKO6gH-EJ9AlRIX6uGq8y8Ur8dBttVik=.3e1b83f3-0b83-4e93-bb64-e57ad2ce8723@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
 <IWD-2XhFlq1PKO6gH-EJ9AlRIX6uGq8y8Ur8dBttVik=.3e1b83f3-0b83-4e93-bb64-e57ad2ce8723@github.com>
Message-ID: <QiEq4QXo1OgxBiso-JHGrJkdSpEmr2NT43NOJ5X3_OY=.ddf214f1-f57b-4d59-aac3-b3d11ef4c6b4@github.com>

On Tue, 18 May 2021 06:56:51 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> I still like the more specific message. We can use a more generic "unexpected text" message, but I think it is less useful.

Maybe something like "unexpected text after parenthesis"?

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

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

From prappo at openjdk.java.net  Tue May 18 09:06:42 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 18 May 2021 09:06:42 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link
In-Reply-To: <IWD-2XhFlq1PKO6gH-EJ9AlRIX6uGq8y8Ur8dBttVik=.3e1b83f3-0b83-4e93-bb64-e57ad2ce8723@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
 <IWD-2XhFlq1PKO6gH-EJ9AlRIX6uGq8y8Ur8dBttVik=.3e1b83f3-0b83-4e93-bb64-e57ad2ce8723@github.com>
Message-ID: <GYiinytXTUshXrcSPPszxH7c7Qrys30ypoWV_NIsCOw=.ae1d9c25-0c51-494e-bfbf-9af8399ae8b4@github.com>

On Tue, 18 May 2021 06:56:51 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Yes, you can look at it both ways, either there is a closing parenthesis where it shouldn't be, or there is text following a correctly placed closing parenthesis. We tend to see one or the other depending on whether the text up to the closing parenthesis looks like a proper signature, but it's not as clear to the parser.

I'd expect the parser to report the leftmost problematic character.

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

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

From jlahoda at openjdk.java.net  Tue May 18 10:00:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 18 May 2021 10:00:10 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v3]
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <JsNH1aiqARDPNYYIrMUxPsbmzlVWHBz9c6y-akutjg4=.008b9733-7523-4252-8e9a-cecfa6d4d158@github.com>

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

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

  Avoiding fall-through from the total case to a synthetic default but changing total patterns to default.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3863/files
  - new: https://git.openjdk.java.net/jdk/pull/3863/files/54ba974e..5fa8005a

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

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

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

From mcimadamore at openjdk.java.net  Tue May 18 11:15:51 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 May 2021 11:15:51 GMT
Subject: RFR: 8267312: Resolve should use generated diagnostic factories
Message-ID: <VubPi6l8BPTxtaXcluhpZ31T09EuG-dEf4ni15sHYHU=.77ee87e2-1850-4f57-90da-e053634cc61c@github.com>

This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g.


# 0: message segment
compiler.err.prob.found.req=...
# 0: message segment
compiler.misc.prob.found.req=...
# 0: message segment, 1: type, 2: type
compiler.warn.prob.found.req=...


To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise.

This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code:


/**
         * compiler.err.prob.found.req=\
         *    incompatible types: {0}
         */
        public static Error ProbFoundReq(Fragment arg0) {
            return new Error("compiler", "prob.found.req", arg0) {
                public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) {
                    return switch (kind) {
                        case ERROR -> this;
                        case WARNING -> throw new AssertionError("Unsupported kind: " + kind);
                        case FRAGMENT -> Fragments.ProbFoundReq(arg0);
                        case NOTE -> throw new AssertionError("Unsupported kind: " + kind);
                    };
                }
            };
        }


As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload.

With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories.

The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this.

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

Commit messages:
 - Add newlines after factory method/field declaration
 - Simplify code in Resolve
 - Tweak ClassGenerator
 - Merge branch 'master' into resolve_error_diags
 - Polish properties generation code
 - Kind of works
 - Sharpen signature of compiler.properties
 - Initial cleanup; some issues:

Changes: https://git.openjdk.java.net/jdk/pull/4089/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4089&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267312
  Stats: 248 lines in 6 files changed: 109 ins; 37 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4089.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4089/head:pull/4089

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

From dfuchs at openjdk.java.net  Tue May 18 11:33:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 18 May 2021 11:33:44 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too.

test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:

> 32:  * @run clean NotificationEmissionTest
> 33:  * @run build NotificationEmissionTest
> 34:  * @run main NotificationEmissionTest 1

This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

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

Marked as reviewed by dfuchs (Reviewer).

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

From mcimadamore at openjdk.java.net  Tue May 18 12:22:51 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 May 2021 12:22:51 GMT
Subject: RFR: 8267312: Resolve should use generated diagnostic factories
In-Reply-To: <VubPi6l8BPTxtaXcluhpZ31T09EuG-dEf4ni15sHYHU=.77ee87e2-1850-4f57-90da-e053634cc61c@github.com>
References: <VubPi6l8BPTxtaXcluhpZ31T09EuG-dEf4ni15sHYHU=.77ee87e2-1850-4f57-90da-e053634cc61c@github.com>
Message-ID: <-wUi6zR9vjizDIttawHUOORW3tLmbZFc7Idx1A3Favs=.f0771ae2-3aa1-4536-b5d4-8e66b8d230ba@github.com>

On Tue, 18 May 2021 11:07:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g.
> 
> 
> # 0: message segment
> compiler.err.prob.found.req=...
> # 0: message segment
> compiler.misc.prob.found.req=...
> # 0: message segment, 1: type, 2: type
> compiler.warn.prob.found.req=...
> 
> 
> To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise.
> 
> This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code:
> 
> 
> /**
>          * compiler.err.prob.found.req=\
>          *    incompatible types: {0}
>          */
>         public static Error ProbFoundReq(Fragment arg0) {
>             return new Error("compiler", "prob.found.req", arg0) {
>                 public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) {
>                     return switch (kind) {
>                         case ERROR -> this;
>                         case WARNING -> throw new AssertionError("Unsupported kind: " + kind);
>                         case FRAGMENT -> Fragments.ProbFoundReq(arg0);
>                         case NOTE -> throw new AssertionError("Unsupported kind: " + kind);
>                     };
>                 }
>             };
>         }
> 
> 
> As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload.
> 
> With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories.
> 
> The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this.

make/langtools/tools/propertiesparser/resources/templates.properties line 53:

> 51:     {0}public static {1} {2}({3}) '{'\n\
> 52:     {4}\n\
> 53:     '}\n'

This could probably just use text blocks and replacements - I'll leave that for another day.

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

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

From mullan at openjdk.java.net  Tue May 18 12:44:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 12:44:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
Message-ID: <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>

On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
> 
>> 313:  *
>> 314:  * @since   1.0
>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
> 
> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

It includes both:
![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

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

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

From mcimadamore at openjdk.java.net  Tue May 18 13:01:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 May 2021 13:01:57 GMT
Subject: RFR: 8267317: Remove DeferredTypeCompleter
Message-ID: <vGhbXyJXRjnmDMF7n10LkEF6bJ5Ukxlmno7Jg7KW-dw=.b1fa88a7-6f9d-4e36-a449-1713360f0715@github.com>

This pathc removes DeferredTypeCompleter, which seems like a dubious abstraction. In its place there is now a `complete` method on `DeferredType` which is overridden by `ArgumentType`. The only problematic usage is from `StructuralStuckChecker`, but after inspecting the code I realized that the only side effect this code expected from calling `DeferredType::check` was to set the deferred type mode to `SPECULATIVE`, which we can easily do inline.

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

Commit messages:
 - All tests pass

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

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

From mcimadamore at openjdk.java.net  Tue May 18 13:08:05 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 May 2021 13:08:05 GMT
Subject: RFR: 8267317: Remove DeferredTypeCompleter [v2]
In-Reply-To: <vGhbXyJXRjnmDMF7n10LkEF6bJ5Ukxlmno7Jg7KW-dw=.b1fa88a7-6f9d-4e36-a449-1713360f0715@github.com>
References: <vGhbXyJXRjnmDMF7n10LkEF6bJ5Ukxlmno7Jg7KW-dw=.b1fa88a7-6f9d-4e36-a449-1713360f0715@github.com>
Message-ID: <vF8o2mSkNIPDOgQFPF6YxTHQ35T8SyjhiCwszzVYfZE=.64427a71-015b-4f51-862d-9de8c22c7196@github.com>

> This pathc removes DeferredTypeCompleter, which seems like a dubious abstraction. In its place there is now a `complete` method on `DeferredType` which is overridden by `ArgumentType`. The only problematic usage is from `StructuralStuckChecker`, but after inspecting the code I realized that the only side effect this code expected from calling `DeferredType::check` was to set the deferred type mode to `SPECULATIVE`, which we can easily do inline.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant assigment of DeferredType::mode

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4091/files
  - new: https://git.openjdk.java.net/jdk/pull/4091/files/c2d4e38c..b0f9ac59

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

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

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

From weijun at openjdk.java.net  Tue May 18 14:01:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:01:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>
Message-ID: <LP-JXhyiYZ4-yfHkeHX7Rqt-1AnCPesIf4uK5ycC8B4=.4459bddf-cc61-4c92-9b5e-4e046ede8a90@github.com>

On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:
> 
>> 32:  * @run clean NotificationEmissionTest
>> 33:  * @run build NotificationEmissionTest
>> 34:  * @run main NotificationEmissionTest 1
> 
> This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR.

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

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

From weijun at openjdk.java.net  Tue May 18 14:07:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:07:38 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>
Message-ID: <z9kXH2Zm9AgECH3iihoXcgKisBj7HQMYB7SBmr98Hek=.c0ba0d9d-f3ea-427c-97a1-8de5843c0698@github.com>

On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.
> 
> test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.
> 
> test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.
> 
> For uses using ProcessTools then it seems to be very random.

I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks.

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

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

From asotona at openjdk.java.net  Tue May 18 14:19:59 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 18 May 2021 14:19:59 GMT
Subject: RFR: 8248843: java in source-file mode suggests javac-only options
Message-ID: <8NKQP6iQM2BZ6BdJucN3wVFokZeO5bPIp8u19oE98sI=.22615f9d-bde2-4e70-9ff8-37b150b390ec@github.com>

`java` in source-file mode (see JEP 330) displays compiler notes suggesting `recompile with -Xdiags:verbose to get full output`. 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 `-Xdiags:verbose` are out of their scope.

This patch prevents displaying `Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output` suggestion in `java` source-file mode by implicitly enabling `-Xdiags:verbose` 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.

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

Commit messages:
 - 8248843: java in source-file mode suggests javac-only options

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

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

From vromero at openjdk.java.net  Tue May 18 14:40:17 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 18 May 2021 14:40:17 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an intersection
 type
Message-ID: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>

Please review this PR which is adding a field to JCVariableDecl, the need I see for this is that when we declare a local variable using `var` as in:


import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

@Target({ElementType.TYPE_USE, ElementType.LOCAL_VARIABLE})
@interface A {}

class Test {
    void t() {
        @A var c = g(1, 1L);
    }

    <X> X g(X a, X b) {
        return a;
    }
}

the only clue the compiler uses to know that the local variable was declared using `var` is that field JCVariableDecl::vartype is null, but this field is set to an inferred type at some point and from that point on there is no way to know for sure that the original AST had a `var`. Unfortunately there is code that keeps asking for that implicit type declaration afterwards and thus making uninformed decisions as in: TypeAnnotations.TypeAnnotationPositions::visitVarDef, where the compiler is implementing a portion of section: `9.7.4 Where Annotations May Appear` of the spec. In particular how to deal with annotations applied to local variables declared with `var`. This case is interesting because the same annotation works as a declaration annotation and as a type annotation. If it were only a type annotation then the compiler would have issued an error before getting to TypeAnnotations.TypeAnnotationPositions::visitVarDef, precisely at Check::validateAnnotation, see that Check::getAppl
 icableTargets has a special case for local variables declared using `var`. But again given that the annotation in the example above is applicable as a type and as a declaration annotation, it will seep up to the metadata info associated to the local variable symbol, and that is fine. What is not OK is that as the compiler has no clue that the AST was originally declared using `var` that it tries to type annotate the type of the local variable.

This patch is also renaming a method in `JCVariableDecl`, previous name was `isImplicitlyTyped` which was basically checking if the `vartype` field was null and was renamed to `nullVarType` and a new one was added named: `declaredUsingVar` which won't change its returned value during the lifetime of a JCVariableDecl AST.

TIA

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

Commit messages:
 - 8261205: AssertionError: Cannot add metadata to an intersection type

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

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

From mcimadamore at openjdk.java.net  Tue May 18 14:58:39 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 May 2021 14:58:39 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type
In-Reply-To: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
Message-ID: <HewuEzd_ADp5orqKOe567W8gpY4DQJ-koJSmtRSuu7A=.1e6f87e0-3725-44c5-bcc1-b1280c28b903@github.com>

On Tue, 18 May 2021 14:32:30 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is adding a field to `JCVariableDecl`, the need I see for this is that when we declare a local variable using `var` as in:
> 
> 
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Target;
> 
> @Target({ElementType.TYPE_USE, ElementType.LOCAL_VARIABLE})
> @interface A {}
> 
> class Test {
>     void t() {
>         @A var c = g(1, 1L);
>     }
> 
>     <X> X g(X a, X b) {
>         return a;
>     }
> }
> 
> the only clue the compiler has to know that the local variable was declared using `var` is that field `JCVariableDecl::vartype` is null, but this field is set to an inferred type at some point during the compilation and from that point on there is no way to know for sure that the original AST had a `var` or not. Unfortunately there is code that keeps asking if the local variable was implicitly typed or not, after field `JCVariableDecl::vartype` has been written, and thus making uninformed decisions as in: TypeAnnotations.TypeAnnotationPositions::visitVarDef, where the compiler is implementing a portion of section: `9.7.4 Where Annotations May Appear` of the spec (JLS16). In particular the portion that defines how to deal with annotations applied to local variables declared with `var`.
> 
> The test case above is interesting because the same annotation works as a declaration annotation **and** as a type annotation. If it were only a type annotation then the compiler would have issued an error before getting to `TypeAnnotations.TypeAnnotationPositions::visitVarDef`, precisely at `Check::validateAnnotation`, see that `Check::getApplicableTargets` has a special case for local variables declared using `var`. But again given that the annotation in the example above is applicable as a type and as a declaration annotation, it will seep down to the metadata info associated to the local variable symbol, and that is fine. What is not kosher is that as the compiler has no clue that the AST was originally declared using `var` that it then tries to type-annotate the type of the local variable. This change is thus making sure that that information is preserved.
> 
> This patch is also renaming a method in `JCVariableDecl`, its previous name was `isImplicitlyTyped` which was basically checking if the `vartype` field was `null` and was renamed to `nullVarType`, `hasNullVarType` could be an option too, and a new method was added: `declaredUsingVar` which won't change its returned value during the lifetime of a JCVariableDecl AST.
> 
> TIA

What happens if we just use `declaredUsingVar` everywhere? Shouldn't that be the "right" way to do it?

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

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

From alanb at openjdk.java.net  Tue May 18 15:22:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 15:22:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
 <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
Message-ID: <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>> 
>>> 313:  *
>>> 314:  * @since   1.0
>>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
>> 
>> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?
>
> It includes both:
> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

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

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

From vromero at openjdk.java.net  Tue May 18 15:32:38 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 18 May 2021 15:32:38 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type
In-Reply-To: <HewuEzd_ADp5orqKOe567W8gpY4DQJ-koJSmtRSuu7A=.1e6f87e0-3725-44c5-bcc1-b1280c28b903@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
 <HewuEzd_ADp5orqKOe567W8gpY4DQJ-koJSmtRSuu7A=.1e6f87e0-3725-44c5-bcc1-b1280c28b903@github.com>
Message-ID: <ASSxtz4skYHm65bP8dnttC7iWxpgL_LeU4M-ht-qTGY=.703e0e8b-75db-4412-8f5a-1029481165cc@github.com>

On Tue, 18 May 2021 14:55:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What happens if we just use declaredUsingVar everywhere? Shouldn't that be the "right" way to do it?

yep I also considered that but then realized that parameters of implicit lambdas also have its vartype set to null until the compiler infers a type for them, so the implicitly-typed set and the declared using `var` set have an intersection but are not the same, I preferred to keep the previous API for the different clients, just with a tweak in the method name, and add a new method to reflect the fact that there is a difference between being explicitly typed and being declared using `var`

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

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

From mullan at openjdk.java.net  Tue May 18 15:49:38 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 15:49:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
 <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
 <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>
Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com>

On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It includes both:
>> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)
>
> Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP.

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

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

From darcy at openjdk.java.net  Tue May 18 16:29:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 18 May 2021 16:29:47 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <UN8g8sgK7nXvYjtZiSBUhCaU-0qEb8b7Y2OzhxgtOzY=.08a47c9a-a7a5-4a0e-8919-19d71fc19a4f@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by darcy (Reviewer).

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

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

From chegar at openjdk.java.net  Tue May 18 16:38:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 18 May 2021 16:38:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <LgbU-sI0tWPZUqtoQA3U69H6-_YB1kKmqgTckkVcrlo=.0d7b35c2-aec5-41be-ab62-459a9ae8c7dd@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The changes in the net area look fine.

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

Marked as reviewed by chegar (Reviewer).

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

From naoto at openjdk.java.net  Tue May 18 16:45:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 18 May 2021 16:45:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <NQ4IhVZC8LudCe-a1JsSFd95dtttKo46bw2iK0DkiQA=.1139a6e3-8acc-4099-b9ab-c599fdca20d2@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Reviewed i18n/java.time/charset. They all look good.

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

Marked as reviewed by naoto (Reviewer).

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

From jjg at openjdk.java.net  Tue May 18 17:23:04 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 18 May 2021 17:23:04 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void
Message-ID: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>

Please review a simple fix to treat `war` as a void element.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into wbr
 - JDK-8266856: Make <wbr> element void

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

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

From joehw at openjdk.java.net  Tue May 18 17:30:39 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 18 May 2021 17:30:39 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <Ep1azxH_vnemjxbvBu6HprCKjwMcG1nzTozdYIA1RtU=.e8be0928-e09f-483e-a775-06bbcce8be8c@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

java.xml changes look good. Thanks.

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

Marked as reviewed by joehw (Reviewer).

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

From vromero at openjdk.java.net  Tue May 18 17:39:40 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 18 May 2021 17:39:40 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void
In-Reply-To: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
Message-ID: <Be6qxiWJQ0g8B1L3r6BuzV93HcL0FpOObl8_MIzBf-8=.2ce15795-4907-45cd-af58-256021ef57ea@github.com>

On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple fix to treat `war` as a void element.

test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java line 154:

> 152:      * </template>
> 153:      * <p>Test current time is <time>10:00</time> at night</p>
> 154:      * <p>Test<wbr>text</p>

this is a positive test shouldnt we have negative tests too?

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

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

From alanb at openjdk.java.net  Tue May 18 17:39:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 17:39:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/security/AccessController.java line 877:

> 875:     @CallerSensitive
> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

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

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

From mchung at openjdk.java.net  Tue May 18 17:43:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:43:39 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <L_strZt1H9X1vdJh8AYRIWExhJMfmODbsj-N8xQkvYw=.1e46863a-db33-4d33-bbe4-645f0c52b349@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I reviewed non-client areas.  Looks okay.

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

Marked as reviewed by mchung (Reviewer).

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

From mchung at openjdk.java.net  Tue May 18 17:53:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:53:51 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <jVoctx_UzYbZpnzVpQJ-kVkDSiW8wpixKMGGDicrAfk=.e36178c6-303c-489c-813b-37842a110503@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by mchung (Reviewer).

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

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

From prappo at openjdk.java.net  Tue May 18 18:00:45 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 18 May 2021 18:00:45 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void
In-Reply-To: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
Message-ID: <FVfmDSxD9UzdKiaM4YegpYtyaOj6m_hksAEihEe2zjE=.3ca4533b-79c1-4c86-8efb-5f1b732db02f@github.com>

On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple fix to treat `war` as a void element.

I wonder if we could teach JavaDoc types that model HTML that void elements do not require end tags. Before this change, WBR required an end tag despite being void: https://github.com/jonathan-gibbons/jdk/blob/8a96c703771224990504cd258dd737e10d325f68/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java#L954-L968

Failing that, we could have a test to catch such inconsistencies.

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

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

From weijun at openjdk.java.net  Tue May 18 18:42:26 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 18:42:26 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
Message-ID: <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>

On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/security/AccessController.java line 877:
> 
>> 875:     @CallerSensitive
>> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
> 
> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`.

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

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

From weijun at openjdk.java.net  Tue May 18 21:13:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:13:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
 <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>
Message-ID: <NsAoXUFxz2QHQKrDb3O1Ls1jKyXBkfbmB9AubjXUDus=.6a87197e-b3bf-4971-a48e-6e7f008c9135@github.com>

On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessController.java line 877:
>> 
>>> 875:     @CallerSensitive
>>> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
>>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
>> 
>> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.
>
> I'll try to update my auto-annotating program.

Turns out this only happens in this class:

$ rg '^\s*@SuppressWarnings("removal").*?,.'
src/java.base/share/classes/java/security/AccessController.java:449:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:514:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:877:                                     @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

I'll fix them manually.

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

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

From weijun at openjdk.java.net  Tue May 18 21:21:45 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:21:45 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Sean, Phil and Alan

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a

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

  Stats: 9 lines in 3 files changed: 4 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From weijun at openjdk.java.net  Tue May 18 21:44:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:44:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  adjust order of VM options

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad

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

  Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

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

From vromero at openjdk.java.net  Tue May 18 21:55:18 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 18 May 2021 21:55:18 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type [v2]
In-Reply-To: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
Message-ID: <X_7dGFXrx-ZkFL7aQuBP25JRcUJxsfKu7zJxvf0Xgvo=.bc446546-73f6-417b-bf2d-e3218a131890@github.com>

> Please review this PR which is adding a field to `JCVariableDecl`, the need I see for this is that when we declare a local variable using `var` as in:
> 
> 
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Target;
> 
> @Target({ElementType.TYPE_USE, ElementType.LOCAL_VARIABLE})
> @interface A {}
> 
> class Test {
>     void t() {
>         @A var c = g(1, 1L);
>     }
> 
>     <X> X g(X a, X b) {
>         return a;
>     }
> }
> 
> the only clue the compiler has to know that the local variable was declared using `var` is that field `JCVariableDecl::vartype` is null, but this field is set to an inferred type at some point during the compilation and from that point on there is no way to know for sure that the original AST had a `var` or not. Unfortunately there is code that keeps asking if the local variable was implicitly typed or not, after field `JCVariableDecl::vartype` has been written, and thus making uninformed decisions as in: TypeAnnotations.TypeAnnotationPositions::visitVarDef, where the compiler is implementing a portion of section: `9.7.4 Where Annotations May Appear` of the spec (JLS16). In particular the portion that defines how to deal with annotations applied to local variables declared with `var`.
> 
> The test case above is interesting because the same annotation works as a declaration annotation **and** as a type annotation. If it were only a type annotation then the compiler would have issued an error before getting to `TypeAnnotations.TypeAnnotationPositions::visitVarDef`, precisely at `Check::validateAnnotation`, see that `Check::getApplicableTargets` has a special case for local variables declared using `var`. But again given that the annotation in the example above is applicable as a type and as a declaration annotation, it will seep down to the metadata info associated to the local variable symbol, and that is fine. What is not kosher is that as the compiler has no clue that the AST was originally declared using `var` that it then tries to type-annotate the type of the local variable. This change is thus making sure that that information is preserved.
> 
> This patch is also renaming a method in `JCVariableDecl`, its previous name was `isImplicitlyTyped` which was basically checking if the `vartype` field was `null` and was renamed to `nullVarType`, `hasNullVarType` could be an option too, and a new method was added: `declaredUsingVar` which won't change its returned value during the lifetime of a JCVariableDecl AST.
> 
> TIA

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

  changes after offline comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4095/files
  - new: https://git.openjdk.java.net/jdk/pull/4095/files/a9eb9533..dbedc864

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

  Stats: 33 lines in 5 files changed: 17 ins; 1 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4095.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4095/head:pull/4095

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

From vromero at openjdk.java.net  Tue May 18 22:02:48 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 18 May 2021 22:02:48 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type [v2]
In-Reply-To: <X_7dGFXrx-ZkFL7aQuBP25JRcUJxsfKu7zJxvf0Xgvo=.bc446546-73f6-417b-bf2d-e3218a131890@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
 <X_7dGFXrx-ZkFL7aQuBP25JRcUJxsfKu7zJxvf0Xgvo=.bc446546-73f6-417b-bf2d-e3218a131890@github.com>
Message-ID: <x6g2UOwIPMov7BjJCd-lantUT2BYRj17FRT36DjXuog=.cf64e1f2-5461-484d-b0fd-6840556e2aa4@github.com>

On Tue, 18 May 2021 21:55:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR which is adding a field to `JCVariableDecl`, the need I see for this is that when we declare a local variable using `var` as in:
>> 
>> 
>> import java.lang.annotation.ElementType;
>> import java.lang.annotation.Target;
>> 
>> @Target({ElementType.TYPE_USE, ElementType.LOCAL_VARIABLE})
>> @interface A {}
>> 
>> class Test {
>>     void t() {
>>         @A var c = g(1, 1L);
>>     }
>> 
>>     <X> X g(X a, X b) {
>>         return a;
>>     }
>> }
>> 
>> the only clue the compiler has to know that the local variable was declared using `var` is that field `JCVariableDecl::vartype` is null, but this field is set to an inferred type at some point during the compilation and from that point on there is no way to know for sure that the original AST had a `var` or not. Unfortunately there is code that keeps asking if the local variable was implicitly typed or not, after field `JCVariableDecl::vartype` has been written, and thus making uninformed decisions as in: TypeAnnotations.TypeAnnotationPositions::visitVarDef, where the compiler is implementing a portion of section: `9.7.4 Where Annotations May Appear` of the spec (JLS16). In particular the portion that defines how to deal with annotations applied to local variables declared with `var`.
>> 
>> The test case above is interesting because the same annotation works as a declaration annotation **and** as a type annotation. If it were only a type annotation then the compiler would have issued an error before getting to `TypeAnnotations.TypeAnnotationPositions::visitVarDef`, precisely at `Check::validateAnnotation`, see that `Check::getApplicableTargets` has a special case for local variables declared using `var`. But again given that the annotation in the example above is applicable as a type and as a declaration annotation, it will seep down to the metadata info associated to the local variable symbol, and that is fine. What is not kosher is that as the compiler has no clue that the AST was originally declared using `var` that it then tries to type-annotate the type of the local variable. This change is thus making sure that that information is preserved.
>> 
>> This patch is also renaming a method in `JCVariableDecl`, its previous name was `isImplicitlyTyped` which was basically checking if the `vartype` field was `null` and was renamed to `nullVarType`, `hasNullVarType` could be an option too, and a new method was added: `declaredUsingVar` which won't change its returned value during the lifetime of a JCVariableDecl AST.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes after offline comments

I have uploaded a new commit, after an offline comment from Maurizio, he is correct that: given that lambda parameters also have a null type, they will be classified as "declared with var". This commit gets back to the original method name `JCVarDeclaration::isImplicitlyTyped` which will be `true` for local variables declared with `var` and for parameters of implicit lambdas.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java line 47:

> 45: import static com.sun.tools.javac.code.Kinds.Kind.*;
> 46: import static com.sun.tools.javac.code.TypeTag.TYPEVAR;
> 47: import static com.sun.tools.javac.tree.JCTree.Tag.VARDEF;

the import removal changes have been introduced by intelliJ

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

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

From iris at openjdk.java.net  Tue May 18 22:45:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 18 May 2021 22:45:39 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void
In-Reply-To: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
Message-ID: <lMsW4OfigjI1Z3yafD4_ZpV2UQa8ivpE0KiEr5HpirY=.057096ca-4259-4e92-a3f8-ca3d89e6a681@github.com>

On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple fix to treat `war` as a void element.

Marked as reviewed by iris (Reviewer).

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

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

From jjg at openjdk.java.net  Tue May 18 23:30:42 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 18 May 2021 23:30:42 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void
In-Reply-To: <Be6qxiWJQ0g8B1L3r6BuzV93HcL0FpOObl8_MIzBf-8=.2ce15795-4907-45cd-af58-256021ef57ea@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <Be6qxiWJQ0g8B1L3r6BuzV93HcL0FpOObl8_MIzBf-8=.2ce15795-4907-45cd-af58-256021ef57ea@github.com>
Message-ID: <H5Fqdv6TNI2TtFOXTGaDh3PtMgE0ZrcDmF-GHHVcMio=.db5a1171-6af9-4630-be36-ce847c6bfcfe@github.com>

On Tue, 18 May 2021 17:36:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review a simple fix to treat `war` as a void element.
>
> test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java line 154:
> 
>> 152:      * </template>
>> 153:      * <p>Test current time is <time>10:00</time> at night</p>
>> 154:      * <p>Test<wbr>text</p>
> 
> this is a positive test shouldnt we have negative tests too?

I guess I felt this was close to a `noreg-trivial` change to an element that is rarely used, at least in doc comments. The only reason there's a test at at is because it is a holdover from the HTML5 conversion.

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

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

From jjg at openjdk.java.net  Tue May 18 23:50:40 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 18 May 2021 23:50:40 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void
In-Reply-To: <FVfmDSxD9UzdKiaM4YegpYtyaOj6m_hksAEihEe2zjE=.3ca4533b-79c1-4c86-8efb-5f1b732db02f@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <FVfmDSxD9UzdKiaM4YegpYtyaOj6m_hksAEihEe2zjE=.3ca4533b-79c1-4c86-8efb-5f1b732db02f@github.com>
Message-ID: <4mjIMLrxK1oiJjDi3StlMTZuUvXFrOQzDglnBZlqd2s=.73967117-bd13-4d9b-8596-b6081612f7d0@github.com>

On Tue, 18 May 2021 17:57:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I wonder if we could teach JavaDoc types that model HTML that void elements do not require end tags. Before this change, WBR required an end tag despite being void: https://github.com/jonathan-gibbons/jdk/blob/8a96c703771224990504cd258dd737e10d325f68/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java#L954-L968
> 
> Failing that, we could have a test to catch such inconsistencies.

I'm not sure I completely understand your question.

There are two different distinct type systems in play.

1. There is doclint's HtmlTag, which provides declarations and properties for *checking* HTML.
2. There is the Standard Doclet's TagName, which provides declarations and properties for *writing* HTML.

For better or worse, these two systems are distinct and do not fully overlap. The set of tags is different, and the properties you need when parsing/checking are somewhat different from those needed when generating HTML.
And while it is easier to imagine merging them now than 6 months ago (they used to be in separate modules)
it would still be a big architectural change to try and merge them, and way bigger than the current problem warrants.

The output case was OK, as shown in the link you gave. It was the input side that was broken, and that is now fixed.

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

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

From gli at openjdk.java.net  Wed May 19 06:49:00 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 19 May 2021 06:49:00 GMT
Subject: RFR: 8267355: Adjust the parameters of the method UnicodeReader#digit
Message-ID: <hfojQZVqeSjb4zY1PZL8RZ63iDEXEvMa6abtm2cR_JQ=.cbd022b8-f174-4df5-89d5-1b2c6c3c0c5b@github.com>

Hi all,

This patch removes the parameter `int pos` of the method `UnicodeReader#digit`. Several places which use the method `UnicodeReader#digit` are adjusted, too.

Thank you for taking the time to review.

---

A related issue for comments.

After merging this patch, the methods `JavaTokenizer#scanLitChar` and `JavaTokenizer#scanDigits` also have the unused parameters `int pos`. It seems that they could be removed, too.
But I consider that the methods `scan***` of the class  `JavaTokenizer` have a context which may look ahead or back. So their parameters `int pos` may be used in the future. Maybe it is good to remain them.

What's your opionion? Any idea is appreciated.

---

Best Regards,
-- Guoxiong

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

Commit messages:
 - 8267355: Adjust the parameters of the method UnicodeReader#digit

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

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

From jlahoda at openjdk.java.net  Wed May 19 08:00:12 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 19 May 2021 08:00:12 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <kd1d0-0eSlREbuAiMe7jad_pbqEO11J6JiXqltlaPbo=.b5ce4502-2c2a-48aa-beae-b8091d93da76@github.com>

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

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

  Fixing various error-related bugs.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3863/files
  - new: https://git.openjdk.java.net/jdk/pull/3863/files/5fa8005a..0875377b

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

  Stats: 117 lines in 6 files changed: 94 ins; 13 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863

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

From mcimadamore at openjdk.java.net  Wed May 19 08:30:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 19 May 2021 08:30:43 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type [v2]
In-Reply-To: <X_7dGFXrx-ZkFL7aQuBP25JRcUJxsfKu7zJxvf0Xgvo=.bc446546-73f6-417b-bf2d-e3218a131890@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
 <X_7dGFXrx-ZkFL7aQuBP25JRcUJxsfKu7zJxvf0Xgvo=.bc446546-73f6-417b-bf2d-e3218a131890@github.com>
Message-ID: <TEf2MamUYLWaA-oyImsAVaVyWY9e3EOrR2EnloelcM0=.e1f1cca2-8a5e-45ca-8e02-d58cb32ddded@github.com>

On Tue, 18 May 2021 21:55:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR which is adding a field to `JCVariableDecl`, the need I see for this is that when we declare a local variable using `var` as in:
>> 
>> 
>> import java.lang.annotation.ElementType;
>> import java.lang.annotation.Target;
>> 
>> @Target({ElementType.TYPE_USE, ElementType.LOCAL_VARIABLE})
>> @interface A {}
>> 
>> class Test {
>>     void t() {
>>         @A var c = g(1, 1L);
>>     }
>> 
>>     <X> X g(X a, X b) {
>>         return a;
>>     }
>> }
>> 
>> the only clue the compiler has to know that the local variable was declared using `var` is that field `JCVariableDecl::vartype` is null, but this field is set to an inferred type at some point during the compilation and from that point on there is no way to know for sure that the original AST had a `var` or not. Unfortunately there is code that keeps asking if the local variable was implicitly typed or not, after field `JCVariableDecl::vartype` has been written, and thus making uninformed decisions as in: TypeAnnotations.TypeAnnotationPositions::visitVarDef, where the compiler is implementing a portion of section: `9.7.4 Where Annotations May Appear` of the spec (JLS16). In particular the portion that defines how to deal with annotations applied to local variables declared with `var`.
>> 
>> The test case above is interesting because the same annotation works as a declaration annotation **and** as a type annotation. If it were only a type annotation then the compiler would have issued an error before getting to `TypeAnnotations.TypeAnnotationPositions::visitVarDef`, precisely at `Check::validateAnnotation`, see that `Check::getApplicableTargets` has a special case for local variables declared using `var`. But again given that the annotation in the example above is applicable as a type and as a declaration annotation, it will seep down to the metadata info associated to the local variable symbol, and that is fine. What is not kosher is that as the compiler has no clue that the AST was originally declared using `var` that it then tries to type-annotate the type of the local variable. This change is thus making sure that that information is preserved.
>> 
>> This patch is also renaming a method in `JCVariableDecl`, its previous name was `isImplicitlyTyped` which was basically checking if the `vartype` field was `null` and was renamed to `nullVarType`, `hasNullVarType` could be an option too, and a new method was added: `declaredUsingVar` which won't change its returned value during the lifetime of a JCVariableDecl AST.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes after offline comments

Looks better - one question: what about `var` with annotations and lambda parameters? E.g. you can probably construct a similar example involving a lambda parameter - is this fix enough, or would the code path be slightly different?

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

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

From prappo at openjdk.java.net  Wed May 19 09:56:40 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 19 May 2021 09:56:40 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void
In-Reply-To: <4mjIMLrxK1oiJjDi3StlMTZuUvXFrOQzDglnBZlqd2s=.73967117-bd13-4d9b-8596-b6081612f7d0@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <FVfmDSxD9UzdKiaM4YegpYtyaOj6m_hksAEihEe2zjE=.3ca4533b-79c1-4c86-8efb-5f1b732db02f@github.com>
 <4mjIMLrxK1oiJjDi3StlMTZuUvXFrOQzDglnBZlqd2s=.73967117-bd13-4d9b-8596-b6081612f7d0@github.com>
Message-ID: <X89oyXNROLgBHW_Xb1G6x_ezGKsNxlk50iluYEYmq1I=.df21412a-3437-41ac-adeb-620d8dc68b12@github.com>

On Tue, 18 May 2021 23:48:14 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I'm not sure I completely understand your question.

I would like to have a mechanism to guard us from inconsistencies like this, is all. Consider adding something like the below white-box test.

<details>
<summary>Test</summary>


import jdk.javadoc.internal.doclets.formats.html.markup.HtmlTree;
import jdk.javadoc.internal.doclets.formats.html.markup.TagName;
import jdk.javadoc.internal.doclint.HtmlTag;

/*
 * @test
 * @bug 8266856
 * @modules jdk.javadoc/jdk.javadoc.internal.doclint
 *          jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.markup
 * @run main TestVoidHtmlElements
 */
public class TestVoidHtmlElements {

    public static void main(String[] args) {
        int checks = 0;
        for (HtmlTag htmlTag : HtmlTag.values()) {
            TagName tagName = tagNameOf(htmlTag);
            if (tagName == null) {
                continue;
            }
            checks++;
            boolean elementIsVoid = new HtmlTree(tagName).isVoid();
            boolean elementHasNoEndTag = htmlTag.endKind == HtmlTag.EndKind.NONE;
            if (elementIsVoid != elementHasNoEndTag) {
                throw new AssertionError(htmlTag + ", " + elementIsVoid + ", " + elementHasNoEndTag);
            }
        }
        if (checks == 0) { // suspicious
            throw new AssertionError();
        }
    }

    private static TagName tagNameOf(HtmlTag htmlTag) {
        TagName tagName;
        try {
            tagName = TagName.valueOf(htmlTag.name()); // map HtmlTag to TagName
        } catch (IllegalArgumentException ignored) {
            return null;
        }
        return tagName;
    }
}


</details>

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

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

From gli at openjdk.java.net  Wed May 19 10:09:03 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 19 May 2021 10:09:03 GMT
Subject: RFR: 8267361: JavaTokenizer reads octal numbers mistakenly
Message-ID: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>

Hi all,

When compiling the following code about the wrong octal number:


class Digit {
        int n = 079;
}


The javac would output the following error message:


Digit.java:2: error: integer number too large
        int n = 079;
                ^
1 error


This error message is unclear and not silimar to other wrong numbers.
Considering the following code about the wrong binary, hexadecimal and floating point numbers:


class Digit {
        double a = 9.f2;
        int n = 0b123;
        int n = 0x12r3;
}


The javac would output the silimar error message: `error: ';' expected`. The whole information is shown below.


Digit.java:2: error: ';' expected
        double a = 9.f2;
                      ^
Digit.java:3: error: ';' expected
        int n = 0b123;
                   ^
Digit.java:4: error: ';' expected
        int n = 0x12r3;
                    ^
Digit.java:4: error: <identifier> expected
        int n = 0x12r3;
                      ^
4 errors


Because the lexer(JavaTokenizer) incorrectly reads `079` as a token.
Then the parser(JavacParser) would throw the NumberFormatException when using the method Convert#string2int.
So the javac would output `integer number too large`.

The token  `079` is a wrong octal number token. And this is a issue of the lexer, but it is caught by the parser so that the unrelated error message is generated.

This patch fixes it and adds a corresponding test case.
Thank you for taking the time to review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - 8267361: JavaTokenizer reads octal numbers mistakenly

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

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

From hannesw at openjdk.java.net  Wed May 19 11:05:06 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 19 May 2021 11:05:06 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link [v2]
In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
Message-ID: <yGveCiPRey5fKgTXr9OMO2IpiLNFBEjYHkzwlzcOU7o=.36436449-c8ff-4b1f-9063-8644df584a16@github.com>

> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature").
> 
> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". 
> 
> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). 
> 
> Here's a list of what references now cause what error messages:
> 
>  - `#foo(int`     `unterminated signature`
>  - `#foo((int))`   `unexpected parenthesis`
>  - `#foo(int))`   `unexpected parenthesis`
>  - `#foo(int)x`   `unexpected parenthesis`
>  - `F<T`        `unterminated signature`
>  - `F<T>>`    `unexpected input`
> 
> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature".

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

  JDK-8264181: Change error message

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4068/files
  - new: https://git.openjdk.java.net/jdk/pull/4068/files/8c3ab58b..a122027e

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

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

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

From hannesw at openjdk.java.net  Wed May 19 11:08:39 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 19 May 2021 11:08:39 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link [v2]
In-Reply-To: <yGveCiPRey5fKgTXr9OMO2IpiLNFBEjYHkzwlzcOU7o=.36436449-c8ff-4b1f-9063-8644df584a16@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
 <yGveCiPRey5fKgTXr9OMO2IpiLNFBEjYHkzwlzcOU7o=.36436449-c8ff-4b1f-9063-8644df584a16@github.com>
Message-ID: <yGBRjkKqez7bGj6bTQ9thwRAtwXZvFJcdVwHEkw5ZNE=.dd05a71e-75aa-4bff-9e03-f277c258db5e@github.com>

On Wed, 19 May 2021 11:05:06 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature").
>> 
>> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". 
>> 
>> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). 
>> 
>> Here's a list of what references now cause what error messages:
>> 
>>  - `#foo(int`     `unterminated signature`
>>  - `#foo((int))`   `unexpected parenthesis`
>>  - `#foo(int))`   `unexpected parenthesis`
>>  - `#foo(int)x`   `unexpected parenthesis`
>>  - `F<T`        `unterminated signature`
>>  - `F<T>>`    `unexpected input`
>> 
>> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature".
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264181: Change error message

I changed the error message to "unexpected text after parenthesis".  This is a more informative variant of the existing "unexpected text" and always correct as the error is thrown when there is text following the first closing parenthesis.

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

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

From jlaskey at openjdk.java.net  Wed May 19 11:11:42 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 19 May 2021 11:11:42 GMT
Subject: RFR: 8267361: JavaTokenizer reads octal numbers mistakenly
In-Reply-To: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>
References: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>
Message-ID: <nHiOxMXU_EDvMw5j2Vcf6nSAH1rOBPH5YKRJPuzOxnI=.ce23d39b-0974-4550-b34a-36063b432a8a@github.com>

On Wed, 19 May 2021 10:01:19 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When compiling the following code about the wrong octal number:
> 
> 
> class Digit {
>         int n = 079;
> }
> 
> 
> The javac would output the following error message:
> 
> 
> Digit.java:2: error: integer number too large
>         int n = 079;
>                 ^
> 1 error
> 
> 
> This error message is unclear and not silimar to other wrong numbers.
> Considering the following code about the wrong binary, hexadecimal and floating point numbers:
> 
> 
> class Digit {
>         double a = 9.f2;
>         int n = 0b123;
>         int n = 0x12r3;
> }
> 
> 
> The javac would output the silimar error message: `error: ';' expected`. The whole information is shown below.
> 
> 
> Digit.java:2: error: ';' expected
>         double a = 9.f2;
>                       ^
> Digit.java:3: error: ';' expected
>         int n = 0b123;
>                    ^
> Digit.java:4: error: ';' expected
>         int n = 0x12r3;
>                     ^
> Digit.java:4: error: <identifier> expected
>         int n = 0x12r3;
>                       ^
> 4 errors
> 
> 
> Because the lexer(JavaTokenizer) incorrectly reads `079` as a token.
> Then the parser(JavacParser) would throw the NumberFormatException when using the method Convert#string2int.
> So the javac would output `integer number too large`.
> 
> The token  `079` is a wrong octal number token. And this is a issue of the lexer, but it is caught by the parser so that the unrelated error message is generated.
> 
> This patch fixes it and adds a corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

The fix is reasonable but I have a concern that more tests will start failing with the fix. Would you run `make test TEST=jdk_lang` and then maybe `make test-tier1` to make sure? You'll have to have jtreg installed and add `--with-jtreg=<path to jtreg home>` to your configuration. Thank you.

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

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

From gli at openjdk.java.net  Wed May 19 11:26:40 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 19 May 2021 11:26:40 GMT
Subject: RFR: 8267361: JavaTokenizer reads octal numbers mistakenly
In-Reply-To: <nHiOxMXU_EDvMw5j2Vcf6nSAH1rOBPH5YKRJPuzOxnI=.ce23d39b-0974-4550-b34a-36063b432a8a@github.com>
References: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>
 <nHiOxMXU_EDvMw5j2Vcf6nSAH1rOBPH5YKRJPuzOxnI=.ce23d39b-0974-4550-b34a-36063b432a8a@github.com>
Message-ID: <RcBuZ2Y3ZTym3V9o4df3Qk0idE6yBo_6NMur3xxhsa8=.b714fac5-1ac1-49fa-a3da-80faa903f27f@github.com>

On Wed, 19 May 2021 11:08:41 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Hi all,
>> 
>> When compiling the following code about the wrong octal number:
>> 
>> 
>> class Digit {
>>         int n = 079;
>> }
>> 
>> 
>> The javac would output the following error message:
>> 
>> 
>> Digit.java:2: error: integer number too large
>>         int n = 079;
>>                 ^
>> 1 error
>> 
>> 
>> This error message is unclear and not silimar to other wrong numbers.
>> Considering the following code about the wrong binary, hexadecimal and floating point numbers:
>> 
>> 
>> class Digit {
>>         double a = 9.f2;
>>         int n = 0b123;
>>         int n = 0x12r3;
>> }
>> 
>> 
>> The javac would output the silimar error message: `error: ';' expected`. The whole information is shown below.
>> 
>> 
>> Digit.java:2: error: ';' expected
>>         double a = 9.f2;
>>                       ^
>> Digit.java:3: error: ';' expected
>>         int n = 0b123;
>>                    ^
>> Digit.java:4: error: ';' expected
>>         int n = 0x12r3;
>>                     ^
>> Digit.java:4: error: <identifier> expected
>>         int n = 0x12r3;
>>                       ^
>> 4 errors
>> 
>> 
>> Because the lexer(JavaTokenizer) incorrectly reads `079` as a token.
>> Then the parser(JavacParser) would throw the NumberFormatException when using the method Convert#string2int.
>> So the javac would output `integer number too large`.
>> 
>> The token  `079` is a wrong octal number token. And this is a issue of the lexer, but it is caught by the parser so that the unrelated error message is generated.
>> 
>> This patch fixes it and adds a corresponding test case.
>> Thank you for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> The fix is reasonable but I have a concern that more tests will start failing with the fix. Would you run `make test TEST=jdk_lang` and then maybe `make test-tier1` to make sure? You'll have to have jtreg installed and add `--with-jtreg=<path to jtreg home>` to your configuration. Thank you.

@JimLaskey Thanks for your comment. I used the following command to test the `javac` locally before submitting this PR. All the tests passed.


make test TEST=test/langtools/tools/javac/ JOBS=4 CONF=linux-x86_64-server-release


The `Pre-submit tests` will test the `tier1`. We can wait for it to complete.

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

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

From gli at openjdk.java.net  Wed May 19 12:39:39 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 19 May 2021 12:39:39 GMT
Subject: RFR: 8267361: JavaTokenizer reads octal numbers mistakenly
In-Reply-To: <nHiOxMXU_EDvMw5j2Vcf6nSAH1rOBPH5YKRJPuzOxnI=.ce23d39b-0974-4550-b34a-36063b432a8a@github.com>
References: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>
 <nHiOxMXU_EDvMw5j2Vcf6nSAH1rOBPH5YKRJPuzOxnI=.ce23d39b-0974-4550-b34a-36063b432a8a@github.com>
Message-ID: <M5mKUIwJO6tbv-qlsfMUkpLzFpouxF1rsJNfpNtTIO0=.212a37cb-367f-40c0-bd51-220f4598273b@github.com>

On Wed, 19 May 2021 11:08:41 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Hi all,
>> 
>> When compiling the following code about the wrong octal number:
>> 
>> 
>> class Digit {
>>         int n = 079;
>> }
>> 
>> 
>> The javac would output the following error message:
>> 
>> 
>> Digit.java:2: error: integer number too large
>>         int n = 079;
>>                 ^
>> 1 error
>> 
>> 
>> This error message is unclear and not silimar to other wrong numbers.
>> Considering the following code about the wrong binary, hexadecimal and floating point numbers:
>> 
>> 
>> class Digit {
>>         double a = 9.f2;
>>         int n = 0b123;
>>         int n = 0x12r3;
>> }
>> 
>> 
>> The javac would output the silimar error message: `error: ';' expected`. The whole information is shown below.
>> 
>> 
>> Digit.java:2: error: ';' expected
>>         double a = 9.f2;
>>                       ^
>> Digit.java:3: error: ';' expected
>>         int n = 0b123;
>>                    ^
>> Digit.java:4: error: ';' expected
>>         int n = 0x12r3;
>>                     ^
>> Digit.java:4: error: <identifier> expected
>>         int n = 0x12r3;
>>                       ^
>> 4 errors
>> 
>> 
>> Because the lexer(JavaTokenizer) incorrectly reads `079` as a token.
>> Then the parser(JavacParser) would throw the NumberFormatException when using the method Convert#string2int.
>> So the javac would output `integer number too large`.
>> 
>> The token  `079` is a wrong octal number token. And this is a issue of the lexer, but it is caught by the parser so that the unrelated error message is generated.
>> 
>> This patch fixes it and adds a corresponding test case.
>> Thank you for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> The fix is reasonable but I have a concern that more tests will start failing with the fix. Would you run `make test TEST=jdk_lang` and then maybe `make test-tier1` to make sure? You'll have to have jtreg installed and add `--with-jtreg=<path to jtreg home>` to your configuration. Thank you.

@JimLaskey FYI: All the `Pre-submit tests` passed just now.

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

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

From jlaskey at openjdk.java.net  Wed May 19 12:43:45 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 19 May 2021 12:43:45 GMT
Subject: RFR: 8267361: JavaTokenizer reads octal numbers mistakenly
In-Reply-To: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>
References: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>
Message-ID: <B5ZY9UZRuwA2u5t9qVMbmhdHa2FXsP4tsf4zTdmEPqU=.018adb10-ba09-4717-a3c2-79da664baf2d@github.com>

On Wed, 19 May 2021 10:01:19 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When compiling the following code about the wrong octal number:
> 
> 
> class Digit {
>         int n = 079;
> }
> 
> 
> The javac would output the following error message:
> 
> 
> Digit.java:2: error: integer number too large
>         int n = 079;
>                 ^
> 1 error
> 
> 
> This error message is unclear and not silimar to other wrong numbers.
> Considering the following code about the wrong binary, hexadecimal and floating point numbers:
> 
> 
> class Digit {
>         double a = 9.f2;
>         int n = 0b123;
>         int n = 0x12r3;
> }
> 
> 
> The javac would output the silimar error message: `error: ';' expected`. The whole information is shown below.
> 
> 
> Digit.java:2: error: ';' expected
>         double a = 9.f2;
>                       ^
> Digit.java:3: error: ';' expected
>         int n = 0b123;
>                    ^
> Digit.java:4: error: ';' expected
>         int n = 0x12r3;
>                     ^
> Digit.java:4: error: <identifier> expected
>         int n = 0x12r3;
>                       ^
> 4 errors
> 
> 
> Because the lexer(JavaTokenizer) incorrectly reads `079` as a token.
> Then the parser(JavacParser) would throw the NumberFormatException when using the method Convert#string2int.
> So the javac would output `integer number too large`.
> 
> The token  `079` is a wrong octal number token. And this is a issue of the lexer, but it is caught by the parser so that the unrelated error message is generated.
> 
> This patch fixes it and adds a corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Marked as reviewed by jlaskey (Reviewer).

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

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

From gli at openjdk.java.net  Wed May 19 12:47:45 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 19 May 2021 12:47:45 GMT
Subject: RFR: 8267361: JavaTokenizer reads octal numbers mistakenly
In-Reply-To: <nHiOxMXU_EDvMw5j2Vcf6nSAH1rOBPH5YKRJPuzOxnI=.ce23d39b-0974-4550-b34a-36063b432a8a@github.com>
References: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>
 <nHiOxMXU_EDvMw5j2Vcf6nSAH1rOBPH5YKRJPuzOxnI=.ce23d39b-0974-4550-b34a-36063b432a8a@github.com>
Message-ID: <zs4TCePqy1A7-Zdwhnf1lXOZcgrtlHFDCdEWds5MjNQ=.11a4ce31-08c2-425e-8916-1c49c01da632@github.com>

On Wed, 19 May 2021 11:08:41 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Hi all,
>> 
>> When compiling the following code about the wrong octal number:
>> 
>> 
>> class Digit {
>>         int n = 079;
>> }
>> 
>> 
>> The javac would output the following error message:
>> 
>> 
>> Digit.java:2: error: integer number too large
>>         int n = 079;
>>                 ^
>> 1 error
>> 
>> 
>> This error message is unclear and not silimar to other wrong numbers.
>> Considering the following code about the wrong binary, hexadecimal and floating point numbers:
>> 
>> 
>> class Digit {
>>         double a = 9.f2;
>>         int n = 0b123;
>>         int n = 0x12r3;
>> }
>> 
>> 
>> The javac would output the silimar error message: `error: ';' expected`. The whole information is shown below.
>> 
>> 
>> Digit.java:2: error: ';' expected
>>         double a = 9.f2;
>>                       ^
>> Digit.java:3: error: ';' expected
>>         int n = 0b123;
>>                    ^
>> Digit.java:4: error: ';' expected
>>         int n = 0x12r3;
>>                     ^
>> Digit.java:4: error: <identifier> expected
>>         int n = 0x12r3;
>>                       ^
>> 4 errors
>> 
>> 
>> Because the lexer(JavaTokenizer) incorrectly reads `079` as a token.
>> Then the parser(JavacParser) would throw the NumberFormatException when using the method Convert#string2int.
>> So the javac would output `integer number too large`.
>> 
>> The token  `079` is a wrong octal number token. And this is a issue of the lexer, but it is caught by the parser so that the unrelated error message is generated.
>> 
>> This patch fixes it and adds a corresponding test case.
>> Thank you for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> The fix is reasonable but I have a concern that more tests will start failing with the fix. Would you run `make test TEST=jdk_lang` and then maybe `make test-tier1` to make sure? You'll have to have jtreg installed and add `--with-jtreg=<path to jtreg home>` to your configuration. Thank you.

@JimLaskey Thanks for your review. Could I get your help to sponsor this patch?

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

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

From gli at openjdk.java.net  Wed May 19 12:53:47 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 19 May 2021 12:53:47 GMT
Subject: Integrated: 8267361: JavaTokenizer reads octal numbers mistakenly
In-Reply-To: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>
References: <_ddEpPVWOQge_YmmL4cn23vzlgh0MjowaGVwiT7ZlmU=.a029a760-600c-4555-bd4b-68c8f3c9f342@github.com>
Message-ID: <gVvIm1WvDyQuAXuONIA5gp74pvP8ShIsAJwzWhNivo4=.e30f76e5-6b3d-4e17-b4a7-4f79f74a9c17@github.com>

On Wed, 19 May 2021 10:01:19 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When compiling the following code about the wrong octal number:
> 
> 
> class Digit {
>         int n = 079;
> }
> 
> 
> The javac would output the following error message:
> 
> 
> Digit.java:2: error: integer number too large
>         int n = 079;
>                 ^
> 1 error
> 
> 
> This error message is unclear and not silimar to other wrong numbers.
> Considering the following code about the wrong binary, hexadecimal and floating point numbers:
> 
> 
> class Digit {
>         double a = 9.f2;
>         int n = 0b123;
>         int n = 0x12r3;
> }
> 
> 
> The javac would output the silimar error message: `error: ';' expected`. The whole information is shown below.
> 
> 
> Digit.java:2: error: ';' expected
>         double a = 9.f2;
>                       ^
> Digit.java:3: error: ';' expected
>         int n = 0b123;
>                    ^
> Digit.java:4: error: ';' expected
>         int n = 0x12r3;
>                     ^
> Digit.java:4: error: <identifier> expected
>         int n = 0x12r3;
>                       ^
> 4 errors
> 
> 
> Because the lexer(JavaTokenizer) incorrectly reads `079` as a token.
> Then the parser(JavacParser) would throw the NumberFormatException when using the method Convert#string2int.
> So the javac would output `integer number too large`.
> 
> The token  `079` is a wrong octal number token. And this is a issue of the lexer, but it is caught by the parser so that the unrelated error message is generated.
> 
> This 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: e858dd61
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e858dd6197ace4fbd03a5291a43382f7621925ea
Stats:     89 lines in 2 files changed: 89 ins; 0 del; 0 mod

8267361: JavaTokenizer reads octal numbers mistakenly

Reviewed-by: jlaskey

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

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

From prappo at openjdk.java.net  Wed May 19 13:32:58 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 19 May 2021 13:32:58 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link [v2]
In-Reply-To: <yGveCiPRey5fKgTXr9OMO2IpiLNFBEjYHkzwlzcOU7o=.36436449-c8ff-4b1f-9063-8644df584a16@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
 <yGveCiPRey5fKgTXr9OMO2IpiLNFBEjYHkzwlzcOU7o=.36436449-c8ff-4b1f-9063-8644df584a16@github.com>
Message-ID: <Tz-ANYARLa4ucv6gWAgkBIFpcsgkQgbsdvxxFf4vlx0=.c7be4559-8282-4674-af3c-47df2189ebdd@github.com>

On Wed, 19 May 2021 11:05:06 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature").
>> 
>> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". 
>> 
>> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). 
>> 
>> Here's a list of what references now cause what error messages:
>> 
>>  - `#foo(int`     `unterminated signature`
>>  - `#foo((int))`   `unexpected parenthesis`
>>  - `#foo(int))`   `unexpected parenthesis`
>>  - `#foo(int)x`   `unexpected parenthesis`
>>  - `F<T`        `unterminated signature`
>>  - `F<T>>`    `unexpected input`
>> 
>> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature".
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264181: Change error message

Thanks for updating the error message, Hannes. This PR adds tests for 2 out of 6 items from your list. I think it makes sense to ensure that the remaining 4 items are also tested. I can see that one more item is covered by the existing RefBadParens. That said, I couldn't find tests that cover these 3 cases:

    #foo(int
    #foo(int)x
    F<T

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

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

From weijun at openjdk.java.net  Wed May 19 13:47:54 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:54 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>
Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com>

On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from Sean, Phil and Alan

A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks.

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

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

From weijun at openjdk.java.net  Wed May 19 13:47:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f

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

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

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

From duke at openjdk.java.net  Wed May 19 15:50:44 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 15:50:44 GMT
Subject: Withdrawn: 8241356: Use a more reliable way to encode Symbol flags
In-Reply-To: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
Message-ID: <0cdjiuSuy37cJp7SH1ogwlz5bRqvxI9YRKMsimK4kNY=.54c34a52-fb82-4266-8057-feba255d38a3@github.com>

On Fri, 29 Jan 2021 17:31:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

This pull request has been closed without being integrated.

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

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

From hannesw at openjdk.java.net  Wed May 19 16:03:19 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 19 May 2021 16:03:19 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link [v3]
In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
Message-ID: <LK9ZyugosNY21XBJFlFbh6zbjPdbpXgWi49R4UzTfeY=.52ac8a18-e97e-4bfe-8bb4-1ca96b307969@github.com>

> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature").
> 
> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". 
> 
> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). 
> 
> Here's a list of what references now cause what error messages:
> 
>  - `#foo(int`     `unterminated signature`
>  - `#foo((int))`   `unexpected parenthesis`
>  - `#foo(int))`   `unexpected parenthesis`
>  - `#foo(int)x`   `unexpected parenthesis`
>  - `F<T`        `unterminated signature`
>  - `F<T>>`    `unexpected input`
> 
> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature".

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

  JDK-8264181: Add test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4068/files
  - new: https://git.openjdk.java.net/jdk/pull/4068/files/a122027e..733e42f0

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

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

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

From hannesw at openjdk.java.net  Wed May 19 16:07:40 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 19 May 2021 16:07:40 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link [v2]
In-Reply-To: <Tz-ANYARLa4ucv6gWAgkBIFpcsgkQgbsdvxxFf4vlx0=.c7be4559-8282-4674-af3c-47df2189ebdd@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
 <yGveCiPRey5fKgTXr9OMO2IpiLNFBEjYHkzwlzcOU7o=.36436449-c8ff-4b1f-9063-8644df584a16@github.com>
 <Tz-ANYARLa4ucv6gWAgkBIFpcsgkQgbsdvxxFf4vlx0=.c7be4559-8282-4674-af3c-47df2189ebdd@github.com>
Message-ID: <2RipvnELjX30txxGR0h2gZTxEerxHhOBH5bRf_g5_rY=.e324f18a-88a1-40a8-92f7-a99b36395d7d@github.com>

On Wed, 19 May 2021 13:29:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> ```
> #foo(int
> #foo(int)x
> F<T
> ```

Missing closing parenthesis is tested in `UnterminatedSignature`. I've added `UnterminatedSignature1` for the missing right angle bracket case. Text after closing parens is handled in `RefBadParens1` (it doesn't matter which character follows the closing parenthesis; I changed the test reference to look more like the one above).

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

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

From prappo at openjdk.java.net  Wed May 19 16:37:43 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 19 May 2021 16:37:43 GMT
Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about
 malformed link [v3]
In-Reply-To: <LK9ZyugosNY21XBJFlFbh6zbjPdbpXgWi49R4UzTfeY=.52ac8a18-e97e-4bfe-8bb4-1ca96b307969@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
 <LK9ZyugosNY21XBJFlFbh6zbjPdbpXgWi49R4UzTfeY=.52ac8a18-e97e-4bfe-8bb4-1ca96b307969@github.com>
Message-ID: <fY6EjunBbTNl6kYJ0ZazVSwQvx0h_Y0mOFswkKyFka8=.601e3987-18fb-4dd4-8de9-a3b944b4d5bf@github.com>

On Wed, 19 May 2021 16:03:19 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature").
>> 
>> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". 
>> 
>> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). 
>> 
>> Here's a list of what references now cause what error messages:
>> 
>>  - `#foo(int`     `unterminated signature`
>>  - `#foo((int))`   `unexpected parenthesis`
>>  - `#foo(int))`   `unexpected parenthesis`
>>  - `#foo(int)x`   `unexpected parenthesis`
>>  - `F<T`        `unterminated signature`
>>  - `F<T>>`    `unexpected input`
>> 
>> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature".
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264181: Add test

Marked as reviewed by prappo (Reviewer).

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

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

From hannesw at openjdk.java.net  Wed May 19 17:20:41 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 19 May 2021 17:20:41 GMT
Subject: Integrated: JDK-8264181: javadoc tool Incorrect error message about
 malformed link
In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com>
Message-ID: <RONntJWsGb3hd5_Bsq0lGdQDXAYiLeIcTRluZLUlKZY=.3436f6c8-ba28-4a99-bb6d-88c98d2b5dbc@github.com>

On Mon, 17 May 2021 16:54:07 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature").
> 
> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". 
> 
> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). 
> 
> Here's a list of what references now cause what error messages:
> 
>  - `#foo(int`     `unterminated signature`
>  - `#foo((int))`   `unexpected parenthesis`
>  - `#foo(int))`   `unexpected parenthesis`
>  - `#foo(int)x`   `unexpected parenthesis`
>  - `F<T`        `unterminated signature`
>  - `F<T>>`    `unexpected input`
> 
> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature".

This pull request has now been integrated.

Changeset: 66ab6d86
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/66ab6d86d1f4d636aef697bc4c4443b901d2cb6b
Stats:     99 lines in 5 files changed: 97 ins; 0 del; 2 mod

8264181: javadoc tool Incorrect error message about malformed link

Reviewed-by: prappo

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

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

From prr at openjdk.java.net  Wed May 19 18:16:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:16:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <fiq_yIbqC9QRDEcRvYChJl6aWrZvnOxZM4uuDdwYDek=.bbe622b3-b90a-4441-bb0c-ead59bca50d2@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

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

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

From prr at openjdk.java.net  Wed May 19 18:19:49 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:19:49 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <hfPqSTPSSpxjLndppmuJovqQVW7q2UXmBhzI8sIGDJg=.bdef2a7d-72bd-49ac-b7f6-9ca56ce3cd1e@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This change is so large that github won't even display the list of files so I can't jump to where I want to go !
And when I try to scroll I get just a blank page.

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

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

From prr at openjdk.java.net  Wed May 19 18:29:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:29:41 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.desktop/share/classes/java/awt/Component.java line 217:

> 215:  * @author      Sami Shaio
> 216:  */
> 217: @SuppressWarnings("removal")

Why is this placed on the *entire class* ??
This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

src/java.desktop/share/classes/java/awt/Container.java line 97:

> 95:  * @since     1.0
> 96:  */
> 97: @SuppressWarnings("removal")

Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.

Where else are you adding this to entire classes instead of the specific site ?

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

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

From jjg at openjdk.java.net  Wed May 19 18:36:43 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 19 May 2021 18:36:43 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void
In-Reply-To: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
Message-ID: <9fEIR6QDcFeoz-DTKjOho0muVQuJSz4b0OHEKzjCB3Q=.c8e8d120-5f7b-4072-a09a-25e804732947@github.com>

On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple fix to treat `wbr` as a void element.

Since you've written the test, I'll include it, but it does seem like "overkill" for void elements and "inadequate" for other aspects.

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

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

From weijun at openjdk.java.net  Wed May 19 18:41:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:41:44 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
Message-ID: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>

On Wed, 19 May 2021 18:26:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 217:
> 
>> 215:  * @author      Sami Shaio
>> 216:  */
>> 217: @SuppressWarnings("removal")
> 
> Why is this placed on the *entire class* ??
> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is

        s = java.security.AccessController.doPrivileged(
                                                        new GetPropertyAction("awt.image.redrawrate"));

> src/java.desktop/share/classes/java/awt/Container.java line 97:
> 
>> 95:  * @since     1.0
>> 96:  */
>> 97: @SuppressWarnings("removal")
> 
> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
> 
> Where else are you adding this to entire classes instead of the specific site ?

Similar as the one above, it's because of

    static {
        // Don't lazy-read because every app uses invalidate()
        isJavaAwtSmartInvalidate = AccessController.doPrivileged(
                new GetBooleanAction("java.awt.smartInvalidate"));
    }

> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
>> 57:                 ProcessCommunicator
>> 58:                         .executeChildProcess(Consumer.class, new String[0]);
>> 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout.

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

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

From weijun at openjdk.java.net  Wed May 19 18:46:46 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:46:46 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
Message-ID: <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>

On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Container.java line 97:
>> 
>>> 95:  * @since     1.0
>>> 96:  */
>>> 97: @SuppressWarnings("removal")
>> 
>> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
>> 
>> Where else are you adding this to entire classes instead of the specific site ?
>
> Similar as the one above, it's because of
> 
>     static {
>         // Don't lazy-read because every app uses invalidate()
>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>                 new GetBooleanAction("java.awt.smartInvalidate"));
>     }

We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

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

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

From weijun at openjdk.java.net  Wed May 19 18:51:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:51:43 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>
Message-ID: <P1n8uhHy1IqLsvr2AH5wQb1wuBkGPofCg2TFvelA4sQ=.1cbb03a5-084d-4548-be7c-fa66b9968f87@github.com>

On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Similar as the one above, it's because of
>> 
>>     static {
>>         // Don't lazy-read because every app uses invalidate()
>>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>>                 new GetBooleanAction("java.awt.smartInvalidate"));
>>     }
>
> We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations.

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

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

From jjg at openjdk.java.net  Wed May 19 18:58:17 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 19 May 2021 18:58:17 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v2]
In-Reply-To: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
Message-ID: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com>

> Please review a simple fix to treat `wbr` as a void element.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  add test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4098/files
  - new: https://git.openjdk.java.net/jdk/pull/4098/files/e933ce21..32c1c7ed

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

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

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

From jjg at openjdk.java.net  Wed May 19 19:04:44 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 19 May 2021 19:04:44 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v2]
In-Reply-To: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com>
Message-ID: <iJdx7vm-KNCXIFUDxaSPMC9wnTCM5ueJoMzq4MuNKuU=.0da79194-bf14-452c-b891-553528798b53@github.com>

On Wed, 19 May 2021 18:58:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a simple fix to treat `wbr` as a void element.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

Added test.
Further out, we should try and come up with a javadoc-internal HTML package  that contains
   the intersection of  (the union of the requirements of doclint and the HTML doclet) and the HTML specification, as defined by WhatWG
... meaning, there are some common aspects that can be shared, and that there are some aspects that are specific to doclint and to the HmlDoclet.

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

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

From vromero at openjdk.java.net  Wed May 19 19:05:27 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 May 2021 19:05:27 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type [v3]
In-Reply-To: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
Message-ID: <xxWk9jKI0if3VeAM8YaH7cGbXdPIQgpVHg5RgHDTudU=.ab4426ce-f6e0-4d71-8c1b-00f19c813515@github.com>

> Please review this PR which is adding a field to `JCVariableDecl`, the need I see for this is that when we declare a local variable using `var` as in:
> 
> 
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Target;
> 
> @Target({ElementType.TYPE_USE, ElementType.LOCAL_VARIABLE})
> @interface A {}
> 
> class Test {
>     void t() {
>         @A var c = g(1, 1L);
>     }
> 
>     <X> X g(X a, X b) {
>         return a;
>     }
> }
> 
> the only clue the compiler has to know that the local variable was declared using `var` is that field `JCVariableDecl::vartype` is null, but this field is set to an inferred type at some point during the compilation and from that point on there is no way to know for sure that the original AST had a `var` or not. Unfortunately there is code that keeps asking if the local variable was implicitly typed or not, after field `JCVariableDecl::vartype` has been written, and thus making uninformed decisions as in: TypeAnnotations.TypeAnnotationPositions::visitVarDef, where the compiler is implementing a portion of section: `9.7.4 Where Annotations May Appear` of the spec (JLS16). In particular the portion that defines how to deal with annotations applied to local variables declared with `var`.
> 
> The test case above is interesting because the same annotation works as a declaration annotation **and** as a type annotation. If it were only a type annotation then the compiler would have issued an error before getting to `TypeAnnotations.TypeAnnotationPositions::visitVarDef`, precisely at `Check::validateAnnotation`, see that `Check::getApplicableTargets` has a special case for local variables declared using `var`. But again given that the annotation in the example above is applicable as a type and as a declaration annotation, it will seep down to the metadata info associated to the local variable symbol, and that is fine. What is not kosher is that as the compiler has no clue that the AST was originally declared using `var` that it then tries to type-annotate the type of the local variable. This change is thus making sure that that information is preserved.
> 
> This patch is also renaming a method in `JCVariableDecl`, its previous name was `isImplicitlyTyped` which was basically checking if the `vartype` field was `null` and was renamed to `nullVarType`, `hasNullVarType` could be an option too, and a new method was added: `declaredUsingVar` which won't change its returned value during the lifetime of a JCVariableDecl AST.
> 
> TIA

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - forgot to uncomment a line in the test
 - fix the same issue for implicit lambda params declared with var

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4095/files
  - new: https://git.openjdk.java.net/jdk/pull/4095/files/dbedc864..0552cd4f

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

  Stats: 190 lines in 4 files changed: 141 ins; 47 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4095.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4095/head:pull/4095

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

From vromero at openjdk.java.net  Wed May 19 19:05:28 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 May 2021 19:05:28 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type [v2]
In-Reply-To: <TEf2MamUYLWaA-oyImsAVaVyWY9e3EOrR2EnloelcM0=.e1f1cca2-8a5e-45ca-8e02-d58cb32ddded@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
 <X_7dGFXrx-ZkFL7aQuBP25JRcUJxsfKu7zJxvf0Xgvo=.bc446546-73f6-417b-bf2d-e3218a131890@github.com>
 <TEf2MamUYLWaA-oyImsAVaVyWY9e3EOrR2EnloelcM0=.e1f1cca2-8a5e-45ca-8e02-d58cb32ddded@github.com>
Message-ID: <vu1fTnWh8xShZ3NMAjP-7iuGNefVTDihwJB9_iwGF5U=.99132498-f7a0-49c3-8d65-66ec6579c5da@github.com>

On Wed, 19 May 2021 08:27:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks better - one question: what about `var` with annotations and lambda parameters? E.g. you can probably construct a similar example involving a lambda parameter - is this fix enough, or would the code path be slightly different?

good catch! I have modified the patch to include the case for lambda parameters declared with `var`, I also removed the initial test and added a new one that not only makes sure that the code compiles, it also checks that no type annotations are represented in the class file

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

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

From vromero at openjdk.java.net  Wed May 19 19:34:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 May 2021 19:34:44 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v2]
In-Reply-To: <H5Fqdv6TNI2TtFOXTGaDh3PtMgE0ZrcDmF-GHHVcMio=.db5a1171-6af9-4630-be36-ce847c6bfcfe@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <Be6qxiWJQ0g8B1L3r6BuzV93HcL0FpOObl8_MIzBf-8=.2ce15795-4907-45cd-af58-256021ef57ea@github.com>
 <H5Fqdv6TNI2TtFOXTGaDh3PtMgE0ZrcDmF-GHHVcMio=.db5a1171-6af9-4630-be36-ce847c6bfcfe@github.com>
Message-ID: <MX-x9_kmEBl4HjU_z_TwWPp-ISB0VdkPe31WcbRr75E=.65d9b621-fa2d-4961-a176-42d8b6ade790@github.com>

On Tue, 18 May 2021 23:28:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java line 154:
>> 
>>> 152:      * </template>
>>> 153:      * <p>Test current time is <time>10:00</time> at night</p>
>>> 154:      * <p>Test<wbr>text</p>
>> 
>> this is a positive test shouldnt we have negative tests too?
>
> I guess I felt this was close to a `noreg-trivial` change to an element that is rarely used, at least in doc comments. The only reason there's a test at all is because it is a holdover from the HTML5 conversion.

got it, sounds good

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

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

From vromero at openjdk.java.net  Wed May 19 19:34:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 May 2021 19:34:44 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v2]
In-Reply-To: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com>
Message-ID: <XkJQLyCbgpGsnQBL6b1Df9WSY6n2HXo6K4TdF9TUgv0=.f0646c0d-df35-471f-ab07-d002c734df4b@github.com>

On Wed, 19 May 2021 18:58:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a simple fix to treat `wbr` as a void element.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

Marked as reviewed by vromero (Reviewer).

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

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

From prr at openjdk.java.net  Wed May 19 19:34:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 19:34:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>

On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>> 
>>> 215:  * @author      Sami Shaio
>>> 216:  */
>>> 217: @SuppressWarnings("removal")
>> 
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.
>
> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
> 
>         s = java.security.AccessController.doPrivileged(
>                                                         new GetPropertyAction("awt.image.redrawrate"));

That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
You can define a static private method to contain this and call it from the static initializer block.
Much better than applying the annotation to an entire class.

--- a/src/java.desktop/share/classes/java/awt/Component.java
+++ b/src/java.desktop/share/classes/java/awt/Component.java
@@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
      */
     static boolean isInc;
     static int incRate;
+
+    private static void initIncRate() {
+        String s = java.security.AccessController.doPrivileged(
+                                 new GetPropertyAction("awt.image.incrementaldraw"));
+        isInc = (s == null || s.equals("true"));
+
+        s = java.security.AccessController.doPrivileged(
+                          new GetPropertyAction("awt.image.redrawrate"));
+        incRate = (s != null) ? Integer.parseInt(s) : 100;
+    }
+
     static {
         /* ensure that the necessary native libraries are loaded */
         Toolkit.loadLibraries();
@@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
         if (!GraphicsEnvironment.isHeadless()) {
             initIDs();
         }
-
-        String s = java.security.AccessController.doPrivileged(
-                                                               new GetPropertyAction("awt.image.incrementaldraw"));
-        isInc = (s == null || s.equals("true"));
-
-        s = java.security.AccessController.doPrivileged(
-                                                        new GetPropertyAction("awt.image.redrawrate"));
-        incRate = (s != null) ? Integer.parseInt(s) : 100;
+        initIncRate();
     }

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

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

From mullan at openjdk.java.net  Wed May 19 20:33:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 19 May 2021 20:33:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
Message-ID: <faOe6m8bn6J0ZmXT2mXeQnXapiwOqEixCz4qYhAXRSk=.ec7435aa-b851-4be2-88d2-f122f3fea099@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The changes to the security tests look good.

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

Marked as reviewed by mullan (Reviewer).

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

From vromero at openjdk.java.net  Wed May 19 20:44:20 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 May 2021 20:44:20 GMT
Subject: RFR: 8265319: implement Sealed Classes as a standard feature in
 Java, javax.lang.model changes [v4]
In-Reply-To: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
References: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
Message-ID: <c_N9J_EnegPoBpBCmZlp0bbkA8_3i1PiD1Iqcx69m-U=.fa6125a5-ab60-4701-af7a-5d5915d5dd1a@github.com>

> Please review the changes needed in javax.lang.model API to make Sealed Classes a final feature in Java. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265320)
> 
> Thanks,
> 
> note: this PR is related to [PR-3526](https://github.com/openjdk/jdk/pull/3526)

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

 - Merge branch 'master' into JDK-8265319
 - Merge branch 'master' into JDK-8265319
 - Merge branch 'master' into JDK-8265319
 - 8265319: implement Sealed Classes as a standard feature in Java, javax.lang.model changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3528/files
  - new: https://git.openjdk.java.net/jdk/pull/3528/files/43cf1dbb..bd77eaa8

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

  Stats: 40144 lines in 1123 files changed: 19391 ins; 13080 del; 7673 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3528.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3528/head:pull/3528

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

From vromero at openjdk.java.net  Wed May 19 20:46:23 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 May 2021 20:46:23 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v8]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <gn205vZkb8GgZvBHBAvwtFDaSYM4R0DW7Azx_FZPEJQ=.8f160a78-48ee-4241-bc56-7d59d5dec735@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

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

 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - updating comment after review feedback
 - removing javax.lang.model changes
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - fixing failing regression tests
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/cc4f43fb...d220bc20

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/0208dcf0..d220bc20

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

  Stats: 40144 lines in 1123 files changed: 19391 ins; 13080 del; 7673 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526

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

From weijun at openjdk.java.net  Wed May 19 21:56:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 21:56:30 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
Message-ID: <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>

On Wed, 19 May 2021 19:31:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
>> 
>>         s = java.security.AccessController.doPrivileged(
>>                                                         new GetPropertyAction("awt.image.redrawrate"));
>
> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
> You can define a static private method to contain this and call it from the static initializer block.
> Much better than applying the annotation to an entire class.
> 
> --- a/src/java.desktop/share/classes/java/awt/Component.java
> +++ b/src/java.desktop/share/classes/java/awt/Component.java
> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>       */
>      static boolean isInc;
>      static int incRate;
> +
> +    private static void initIncRate() {
> +        String s = java.security.AccessController.doPrivileged(
> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
> +        isInc = (s == null || s.equals("true"));
> +
> +        s = java.security.AccessController.doPrivileged(
> +                          new GetPropertyAction("awt.image.redrawrate"));
> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +    }
> +
>      static {
>          /* ensure that the necessary native libraries are loaded */
>          Toolkit.loadLibraries();
> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>          if (!GraphicsEnvironment.isHeadless()) {
>              initIDs();
>          }
> -
> -        String s = java.security.AccessController.doPrivileged(
> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
> -        isInc = (s == null || s.equals("true"));
> -
> -        s = java.security.AccessController.doPrivileged(
> -                                                        new GetPropertyAction("awt.image.redrawrate"));
> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +        initIncRate();
>      }

Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

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

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

From prr at openjdk.java.net  Wed May 19 22:07:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 22:07:36 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
Message-ID: <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>

On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
>> You can define a static private method to contain this and call it from the static initializer block.
>> Much better than applying the annotation to an entire class.
>> 
>> --- a/src/java.desktop/share/classes/java/awt/Component.java
>> +++ b/src/java.desktop/share/classes/java/awt/Component.java
>> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>       */
>>      static boolean isInc;
>>      static int incRate;
>> +
>> +    private static void initIncRate() {
>> +        String s = java.security.AccessController.doPrivileged(
>> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
>> +        isInc = (s == null || s.equals("true"));
>> +
>> +        s = java.security.AccessController.doPrivileged(
>> +                          new GetPropertyAction("awt.image.redrawrate"));
>> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +    }
>> +
>>      static {
>>          /* ensure that the necessary native libraries are loaded */
>>          Toolkit.loadLibraries();
>> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>          if (!GraphicsEnvironment.isHeadless()) {
>>              initIDs();
>>          }
>> -
>> -        String s = java.security.AccessController.doPrivileged(
>> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
>> -        isInc = (s == null || s.equals("true"));
>> -
>> -        s = java.security.AccessController.doPrivileged(
>> -                                                        new GetPropertyAction("awt.image.redrawrate"));
>> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +        initIncRate();
>>      }
>
> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
I think it should all be taken care of as part of this proposed change.

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

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

From weijun at openjdk.java.net  Wed May 19 22:17:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 22:17:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>

On Wed, 19 May 2021 22:04:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.
>
> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
> I think it should all be taken care of as part of this proposed change.

I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

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

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

From prr at openjdk.java.net  Wed May 19 23:53:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 23:53:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
Message-ID: <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>

On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
I already pasted the patch for Component.java and it took about 60 seconds to do that.
Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.

I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

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

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

From mcimadamore at openjdk.java.net  Thu May 20 00:45:30 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 00:45:30 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type [v3]
In-Reply-To: <xxWk9jKI0if3VeAM8YaH7cGbXdPIQgpVHg5RgHDTudU=.ab4426ce-f6e0-4d71-8c1b-00f19c813515@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
 <xxWk9jKI0if3VeAM8YaH7cGbXdPIQgpVHg5RgHDTudU=.ab4426ce-f6e0-4d71-8c1b-00f19c813515@github.com>
Message-ID: <7lxVSxsVQmcfCH2JRvAYABBy8FpUyu7VaeoZ0VhiKn4=.2f091b3e-7da3-4d08-8a42-7986556a9134@github.com>

On Wed, 19 May 2021 19:05:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR which is adding a field to `JCVariableDecl`, the need I see for this is that when we declare a local variable using `var` as in:
>> 
>> 
>> import java.lang.annotation.ElementType;
>> import java.lang.annotation.Target;
>> 
>> @Target({ElementType.TYPE_USE, ElementType.LOCAL_VARIABLE})
>> @interface A {}
>> 
>> class Test {
>>     void t() {
>>         @A var c = g(1, 1L);
>>     }
>> 
>>     <X> X g(X a, X b) {
>>         return a;
>>     }
>> }
>> 
>> the only clue the compiler has to know that the local variable was declared using `var` is that field `JCVariableDecl::vartype` is null, but this field is set to an inferred type at some point during the compilation and from that point on there is no way to know for sure that the original AST had a `var` or not. Unfortunately there is code that keeps asking if the local variable was implicitly typed or not, after field `JCVariableDecl::vartype` has been written, and thus making uninformed decisions as in: TypeAnnotations.TypeAnnotationPositions::visitVarDef, where the compiler is implementing a portion of section: `9.7.4 Where Annotations May Appear` of the spec (JLS16). In particular the portion that defines how to deal with annotations applied to local variables declared with `var`.
>> 
>> The test case above is interesting because the same annotation works as a declaration annotation **and** as a type annotation. If it were only a type annotation then the compiler would have issued an error before getting to `TypeAnnotations.TypeAnnotationPositions::visitVarDef`, precisely at `Check::validateAnnotation`, see that `Check::getApplicableTargets` has a special case for local variables declared using `var`. But again given that the annotation in the example above is applicable as a type and as a declaration annotation, it will seep down to the metadata info associated to the local variable symbol, and that is fine. What is not kosher is that as the compiler has no clue that the AST was originally declared using `var` that it then tries to type-annotate the type of the local variable. This change is thus making sure that that information is preserved.
>> 
>> This patch is also renaming a method in `JCVariableDecl`, its previous name was `isImplicitlyTyped` which was basically checking if the `vartype` field was `null` and was renamed to `nullVarType`, `hasNullVarType` could be an option too, and a new method was added: `declaredUsingVar` which won't change its returned value during the lifetime of a JCVariableDecl AST.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - forgot to uncomment a line in the test
>  - fix the same issue for implicit lambda params declared with var

Looks good - but I think there's an issue in the test?

Thumbs up!

test/langtools/tools/javac/annotations/typeAnnotations/VariablesDeclaredWithVarTest.java line 68:

> 66:             class Test {
> 67:                 void kaa() {
> 68:                     //@A var c = g(1, 1L);

Is this meant to be commented out?

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

PR: https://git.openjdk.java.net/jdk/pull/4095Marked as reviewed by mcimadamore (Reviewer).

From mcimadamore at openjdk.java.net  Thu May 20 00:45:31 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 00:45:31 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type [v3]
In-Reply-To: <7lxVSxsVQmcfCH2JRvAYABBy8FpUyu7VaeoZ0VhiKn4=.2f091b3e-7da3-4d08-8a42-7986556a9134@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
 <xxWk9jKI0if3VeAM8YaH7cGbXdPIQgpVHg5RgHDTudU=.ab4426ce-f6e0-4d71-8c1b-00f19c813515@github.com>
 <7lxVSxsVQmcfCH2JRvAYABBy8FpUyu7VaeoZ0VhiKn4=.2f091b3e-7da3-4d08-8a42-7986556a9134@github.com>
Message-ID: <lThs6ZXMfySdz3FdA8EaO1mVfSN8W_gqiWCkksxkej0=.210fdaba-1131-4181-95de-601f9ff8dca7@github.com>

On Thu, 20 May 2021 00:33:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - forgot to uncomment a line in the test
>>  - fix the same issue for implicit lambda params declared with var
>
> test/langtools/tools/javac/annotations/typeAnnotations/VariablesDeclaredWithVarTest.java line 68:
> 
>> 66:             class Test {
>> 67:                 void kaa() {
>> 68:                     //@A var c = g(1, 1L);
> 
> Is this meant to be commented out?

Ah ok, I see this is fixed now

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

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

From weijun at openjdk.java.net  Thu May 20 02:09:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:09:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
Message-ID: <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>

On Wed, 19 May 2021 23:50:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.
>
> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
> I already pasted the patch for Component.java and it took about 60 seconds to do that.
> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
> 
> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

I can make it a bug.

I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.

And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.

Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

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

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

From weijun at openjdk.java.net  Thu May 20 02:12:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:12:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
Message-ID: <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD_jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>

On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
>> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
>> I already pasted the patch for Component.java and it took about 60 seconds to do that.
>> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
>> 
>> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?
>
> I can make it a bug.
> 
> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
> 
> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
> 
> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

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

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

From prr at openjdk.java.net  Thu May 20 04:08:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:08:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD_jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>

On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I can make it a bug.
>> 
>> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
>> 
>> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
>> 
>> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.
>
> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

That is unfortunate, but nonetheless I think required to be done.
We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>From my point of view it is a blocker.

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

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

From prr at openjdk.java.net  Thu May 20 04:25:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:25:29 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
Message-ID: <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>

On Thu, 20 May 2021 04:05:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
> From my point of view it is a blocker.

The JEP isn't PTT for 17 so there's plenty of time isn't there ?

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

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

From alanb at openjdk.java.net  Thu May 20 07:08:35 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 07:08:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
Message-ID: <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>

On Thu, 20 May 2021 04:22:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>> From my point of view it is a blocker.
>
> The JEP isn't PTT for 17 so there's plenty of time isn't there ?

There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

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

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

From vromero at openjdk.java.net  Thu May 20 09:11:35 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 20 May 2021 09:11:35 GMT
Subject: Integrated: 8265319: implement Sealed Classes as a standard feature
 in Java, javax.lang.model changes
In-Reply-To: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
References: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
Message-ID: <dQk0nPF7WFqnvF6M7Y4BKjaf5G9IvfwIBhPznEoMIwk=.07bc1a25-c28d-42e1-bdd8-7923ce94bd15@github.com>

On Fri, 16 Apr 2021 01:56:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the changes needed in javax.lang.model API to make Sealed Classes a final feature in Java. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265320)
> 
> Thanks,
> 
> note: this PR is related to [PR-3526](https://github.com/openjdk/jdk/pull/3526)

This pull request has now been integrated.

Changeset: 31b98e12
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/31b98e129e6d3051c01775519792b2ba5745b275
Stats:     9 lines in 2 files changed: 0 ins; 6 del; 3 mod

8265319: implement Sealed Classes as a standard feature in Java, javax.lang.model changes

Reviewed-by: darcy, jlahoda

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

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

From vromero at openjdk.java.net  Thu May 20 09:14:33 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 20 May 2021 09:14:33 GMT
Subject: Integrated: 8260517: implement Sealed Classes as a standard feature
 in Java
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <sTNVHO4rsk9be3QkZ4EDY2Rw9GtH9X_tUqQOyRNb_L8=.8e8fd575-510d-4312-85ab-51379f9d685d@github.com>

On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

This pull request has now been integrated.

Changeset: 0fa9223f
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0fa9223f34bc33635079763362f42f0a5c53759b
Stats:     444 lines in 54 files changed: 51 ins; 275 del; 118 mod

8260517: implement Sealed Classes as a standard feature in Java

Co-authored-by: Harold Seigel <hseigel at openjdk.org>
Co-authored-by: Vicente Romero <vromero at openjdk.org>
Reviewed-by: dholmes, mcimadamore, jlahoda

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

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

From vromero at openjdk.java.net  Thu May 20 10:22:30 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 20 May 2021 10:22:30 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type [v3]
In-Reply-To: <lThs6ZXMfySdz3FdA8EaO1mVfSN8W_gqiWCkksxkej0=.210fdaba-1131-4181-95de-601f9ff8dca7@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
 <xxWk9jKI0if3VeAM8YaH7cGbXdPIQgpVHg5RgHDTudU=.ab4426ce-f6e0-4d71-8c1b-00f19c813515@github.com>
 <7lxVSxsVQmcfCH2JRvAYABBy8FpUyu7VaeoZ0VhiKn4=.2f091b3e-7da3-4d08-8a42-7986556a9134@github.com>
 <lThs6ZXMfySdz3FdA8EaO1mVfSN8W_gqiWCkksxkej0=.210fdaba-1131-4181-95de-601f9ff8dca7@github.com>
Message-ID: <Yxmy2nVLHyno_G50jjtCQbJuPAOOqRXq5r3lq_Ba7RM=.dcbd14b3-5788-4236-9b32-7039f0ce3359@github.com>

On Thu, 20 May 2021 00:42:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/langtools/tools/javac/annotations/typeAnnotations/VariablesDeclaredWithVarTest.java line 68:
>> 
>>> 66:             class Test {
>>> 67:                 void kaa() {
>>> 68:                     //@A var c = g(1, 1L);
>> 
>> Is this meant to be commented out?
>
> Ah ok, I see this is fixed now

yep, thanks for the review

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

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

From vromero at openjdk.java.net  Thu May 20 10:40:13 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 20 May 2021 10:40:13 GMT
Subject: RFR: 8261205: AssertionError: Cannot add metadata to an
 intersection type [v4]
In-Reply-To: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
Message-ID: <FGQWOWygzjtjwakiy6mnM-mB2fl5nZLRL4RY2eGdMRo=.754c3c50-97d6-4ea3-868c-64c6d95d53ed@github.com>

> Please review this PR which is adding a field to `JCVariableDecl`, the need I see for this is that when we declare a local variable using `var` as in:
> 
> 
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Target;
> 
> @Target({ElementType.TYPE_USE, ElementType.LOCAL_VARIABLE})
> @interface A {}
> 
> class Test {
>     void t() {
>         @A var c = g(1, 1L);
>     }
> 
>     <X> X g(X a, X b) {
>         return a;
>     }
> }
> 
> the only clue the compiler has to know that the local variable was declared using `var` is that field `JCVariableDecl::vartype` is null, but this field is set to an inferred type at some point during the compilation and from that point on there is no way to know for sure that the original AST had a `var` or not. Unfortunately there is code that keeps asking if the local variable was implicitly typed or not, after field `JCVariableDecl::vartype` has been written, and thus making uninformed decisions as in: TypeAnnotations.TypeAnnotationPositions::visitVarDef, where the compiler is implementing a portion of section: `9.7.4 Where Annotations May Appear` of the spec (JLS16). In particular the portion that defines how to deal with annotations applied to local variables declared with `var`.
> 
> The test case above is interesting because the same annotation works as a declaration annotation **and** as a type annotation. If it were only a type annotation then the compiler would have issued an error before getting to `TypeAnnotations.TypeAnnotationPositions::visitVarDef`, precisely at `Check::validateAnnotation`, see that `Check::getApplicableTargets` has a special case for local variables declared using `var`. But again given that the annotation in the example above is applicable as a type and as a declaration annotation, it will seep down to the metadata info associated to the local variable symbol, and that is fine. What is not kosher is that as the compiler has no clue that the AST was originally declared using `var` that it then tries to type-annotate the type of the local variable. This change is thus making sure that that information is preserved.
> 
> This patch is also renaming a method in `JCVariableDecl`, its previous name was `isImplicitlyTyped` which was basically checking if the `vartype` field was `null` and was renamed to `nullVarType`, `hasNullVarType` could be an option too, and a new method was added: `declaredUsingVar` which won't change its returned value during the lifetime of a JCVariableDecl AST.
> 
> TIA

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

 - Merge branch 'master' into JDK-8261205
 - forgot to uncomment a line in the test
 - fix the same issue for implicit lambda params declared with var
 - changes after offline comments
 - 8261205: AssertionError: Cannot add metadata to an intersection type

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4095/files
  - new: https://git.openjdk.java.net/jdk/pull/4095/files/0552cd4f..a8ee79c2

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

  Stats: 7068 lines in 344 files changed: 4367 ins; 1755 del; 946 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4095.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4095/head:pull/4095

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

From prappo at openjdk.java.net  Thu May 20 15:04:29 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 20 May 2021 15:04:29 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v2]
In-Reply-To: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com>
Message-ID: <AgamshB-tzjMcB_ZkOMp6xLcwx9QGTflfoORCLmnv4I=.c4ecc0d0-6270-4807-b0f1-68820152a4ae@github.com>

On Wed, 19 May 2021 18:58:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a simple fix to treat `wbr` as a void element.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

test/langtools/jdk/javadoc/doclet/testVoidHtmlElements/TestVoidHtmlElements.java line 57:

> 55:             } catch (IllegalArgumentException e) {
> 56:             }
> 57:         }

Why do you do the check twice?

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

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

From jjg at openjdk.java.net  Thu May 20 15:08:29 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 20 May 2021 15:08:29 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v2]
In-Reply-To: <NwmXERdoqy3CziRsL5rxfzRuH1Fr4DzpqU_ZnD4Sris=.6a2957d3-84a4-48c3-8bd8-b54e6aa60871@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com>
 <AgamshB-tzjMcB_ZkOMp6xLcwx9QGTflfoORCLmnv4I=.c4ecc0d0-6270-4807-b0f1-68820152a4ae@github.com>
 <NwmXERdoqy3CziRsL5rxfzRuH1Fr4DzpqU_ZnD4Sris=.6a2957d3-84a4-48c3-8bd8-b54e6aa60871@github.com>
Message-ID: <91YYyU3KL45SCVf9XiBt9-B3DrW29IQfTk3D5pJqSbw=.252e19aa-7f72-4c63-9eea-76b443b3923b@github.com>

On Thu, 20 May 2021 15:05:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testVoidHtmlElements/TestVoidHtmlElements.java line 57:
>> 
>>> 55:             } catch (IllegalArgumentException e) {
>>> 56:             }
>>> 57:         }
>> 
>> Why do you do the check twice?
>
> OK, I guess I don't need to ... I was thinking to do the checks "both ways", but I guess the intersection is the same both ways.

I'll replace the second check with a comment on the first

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

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

From jjg at openjdk.java.net  Thu May 20 15:08:29 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 20 May 2021 15:08:29 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v2]
In-Reply-To: <AgamshB-tzjMcB_ZkOMp6xLcwx9QGTflfoORCLmnv4I=.c4ecc0d0-6270-4807-b0f1-68820152a4ae@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com>
 <AgamshB-tzjMcB_ZkOMp6xLcwx9QGTflfoORCLmnv4I=.c4ecc0d0-6270-4807-b0f1-68820152a4ae@github.com>
Message-ID: <NwmXERdoqy3CziRsL5rxfzRuH1Fr4DzpqU_ZnD4Sris=.6a2957d3-84a4-48c3-8bd8-b54e6aa60871@github.com>

On Thu, 20 May 2021 15:01:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test
>
> test/langtools/jdk/javadoc/doclet/testVoidHtmlElements/TestVoidHtmlElements.java line 57:
> 
>> 55:             } catch (IllegalArgumentException e) {
>> 56:             }
>> 57:         }
> 
> Why do you do the check twice?

OK, I guess I don't need to ... I was thinking to do the checks "both ways", but I guess the intersection is the same both ways.

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

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

From jjg at openjdk.java.net  Thu May 20 15:23:40 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 20 May 2021 15:23:40 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v3]
In-Reply-To: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
Message-ID: <ps1hmDQulVjfL6NOB1BLiwT0o2tquBH28maBmuCgnJ8=.97ff9c4d-2028-4e06-acf5-4cb31857afb5@github.com>

> Please review a simple fix to treat `wbr` as a void element.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  update test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4098/files
  - new: https://git.openjdk.java.net/jdk/pull/4098/files/32c1c7ed..4e13a451

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

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

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

From prappo at openjdk.java.net  Thu May 20 15:23:40 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 20 May 2021 15:23:40 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v3]
In-Reply-To: <ps1hmDQulVjfL6NOB1BLiwT0o2tquBH28maBmuCgnJ8=.97ff9c4d-2028-4e06-acf5-4cb31857afb5@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <ps1hmDQulVjfL6NOB1BLiwT0o2tquBH28maBmuCgnJ8=.97ff9c4d-2028-4e06-acf5-4cb31857afb5@github.com>
Message-ID: <lluKvTsgDOpEhrbNEyns63tyfKCZter0oZ_JsfjwTq0=.502eee55-e84e-4793-8b55-4e3a4cf0db05@github.com>

On Thu, 20 May 2021 15:19:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a simple fix to treat `wbr` as a void element.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update test

Marked as reviewed by prappo (Reviewer).

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

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

From vromero at openjdk.java.net  Thu May 20 17:58:42 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 20 May 2021 17:58:42 GMT
Subject: Integrated: 8261205: AssertionError: Cannot add metadata to an
 intersection type
In-Reply-To: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
References: <PZ-KdB2CeSSKYQCAqUNHNs4JlGXrFpz1ePCKqjGXuoI=.8285cd52-6eed-4b37-9cd7-4902a6ae1031@github.com>
Message-ID: <ki4ngEectZcHjc9doWfABoMqeElK81D90FIF40kzi0c=.514b623b-e45d-40b4-98d1-f34b973c4322@github.com>

On Tue, 18 May 2021 14:32:30 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is adding a field to `JCVariableDecl`, the need I see for this is that when we declare a local variable using `var` as in:
> 
> 
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Target;
> 
> @Target({ElementType.TYPE_USE, ElementType.LOCAL_VARIABLE})
> @interface A {}
> 
> class Test {
>     void t() {
>         @A var c = g(1, 1L);
>     }
> 
>     <X> X g(X a, X b) {
>         return a;
>     }
> }
> 
> the only clue the compiler has to know that the local variable was declared using `var` is that field `JCVariableDecl::vartype` is null, but this field is set to an inferred type at some point during the compilation and from that point on there is no way to know for sure that the original AST had a `var` or not. Unfortunately there is code that keeps asking if the local variable was implicitly typed or not, after field `JCVariableDecl::vartype` has been written, and thus making uninformed decisions as in: TypeAnnotations.TypeAnnotationPositions::visitVarDef, where the compiler is implementing a portion of section: `9.7.4 Where Annotations May Appear` of the spec (JLS16). In particular the portion that defines how to deal with annotations applied to local variables declared with `var`.
> 
> The test case above is interesting because the same annotation works as a declaration annotation **and** as a type annotation. If it were only a type annotation then the compiler would have issued an error before getting to `TypeAnnotations.TypeAnnotationPositions::visitVarDef`, precisely at `Check::validateAnnotation`, see that `Check::getApplicableTargets` has a special case for local variables declared using `var`. But again given that the annotation in the example above is applicable as a type and as a declaration annotation, it will seep down to the metadata info associated to the local variable symbol, and that is fine. What is not kosher is that as the compiler has no clue that the AST was originally declared using `var` that it then tries to type-annotate the type of the local variable. This change is thus making sure that that information is preserved.
> 
> This patch is also renaming a method in `JCVariableDecl`, its previous name was `isImplicitlyTyped` which was basically checking if the `vartype` field was `null` and was renamed to `nullVarType`, `hasNullVarType` could be an option too, and a new method was added: `declaredUsingVar` which won't change its returned value during the lifetime of a JCVariableDecl AST.
> 
> TIA

This pull request has now been integrated.

Changeset: 81f39ed3
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81f39ed3e0176b75dee1c8db24041545bcc68a86
Stats:     173 lines in 7 files changed: 165 ins; 3 del; 5 mod

8261205: AssertionError: Cannot add metadata to an intersection type

Reviewed-by: mcimadamore

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

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

From kcr at openjdk.java.net  Thu May 20 18:31:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 20 May 2021 18:31:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine.

I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected.

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

Marked as reviewed by kcr (Author).

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

From iris at openjdk.java.net  Thu May 20 19:02:43 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 20 May 2021 19:02:43 GMT
Subject: RFR: JDK-8266856 Make <wbr> element void [v3]
In-Reply-To: <ps1hmDQulVjfL6NOB1BLiwT0o2tquBH28maBmuCgnJ8=.97ff9c4d-2028-4e06-acf5-4cb31857afb5@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
 <ps1hmDQulVjfL6NOB1BLiwT0o2tquBH28maBmuCgnJ8=.97ff9c4d-2028-4e06-acf5-4cb31857afb5@github.com>
Message-ID: <Gnf1fMabsUBA22C6SF-4BnB4yyH1CvK9uJ5xRd6WWNw=.551c3d6e-742e-4216-9eda-9d485ec14b26@github.com>

On Thu, 20 May 2021 15:23:40 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a simple fix to treat `wbr` as a void element.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update test

Marked as reviewed by iris (Reviewer).

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

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

From jjg at openjdk.java.net  Fri May 21 00:36:14 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 21 May 2021 00:36:14 GMT
Subject: Integrated: JDK-8266856 Make <wbr> element void
In-Reply-To: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
References: <yOe4Rdo5ETz7nowrXyhgb1x8r9uNI8UyCTc7d4yhMss=.f0a0b62b-1936-443a-9402-6c8aab086754@github.com>
Message-ID: <-TRi7ylzBJJFMiL2eFBQf5SLGPChhpVVcXnO3nHQbUY=.c0208e39-c6e9-437a-8c77-5e4513b02dd4@github.com>

On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple fix to treat `wbr` as a void element.

This pull request has now been integrated.

Changeset: e094f3f8
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e094f3f856f5f17d4be65b9f83ff493aa0280deb
Stats:     69 lines in 3 files changed: 66 ins; 0 del; 3 mod

8266856: Make <wbr> element void

Reviewed-by: prappo, iris, vromero

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

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

From jlahoda at openjdk.java.net  Fri May 21 14:13:47 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 21 May 2021 14:13:47 GMT
Subject: Integrated: 8267119: switch expressions lack support for deferred
 type-checking
In-Reply-To: <kSB8sAx3aIMGFBgBo8QnzuWpgPKhkcgwtZc9ivPZUVg=.7f86f549-d44e-44d3-a376-7af81c11bc74@github.com>
References: <kSB8sAx3aIMGFBgBo8QnzuWpgPKhkcgwtZc9ivPZUVg=.7f86f549-d44e-44d3-a376-7af81c11bc74@github.com>
Message-ID: <F2s0VR_GBr2-Sw-eug0w84Wa76EY16CyPPyBNdftzwY=.9ff266c7-7813-48ab-94f1-d8940bbdbcbd@github.com>

On Mon, 17 May 2021 11:22:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Similarly to lambdas with block body looking at expression in return statements, we need `CheckStuckPolicy` to look at all `yield` values in a switch expression, to determine the types correctly, as pointed out in the bugreport.

This pull request has now been integrated.

Changeset: ec8a8097
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec8a8097c309920982b0b8253a76c7c938f1f48d
Stats:     44 lines in 3 files changed: 39 ins; 0 del; 5 mod

8267119: switch expressions lack support for deferred type-checking

Reviewed-by: mcimadamore

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

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

From dfuchs at openjdk.java.net  Fri May 21 15:36:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:36:08 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.base/share/classes/java/lang/SecurityManager.java line 104:

> 102:  * method will throw an {@code UnsupportedOperationException}). If the
> 103:  * {@systemProperty java.security.manager} system property is set to the
> 104:  * special token "{@code allow}", then a security manager will not be set at

Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

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

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

From prr at openjdk.java.net  Fri May 21 18:03:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:03:01 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
 <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
Message-ID: <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>

On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
It is very straight forward to run the automated tests across all platforms these days.
I get the impression that no one is guaranteeing to do this straight after integration.
It sounds like it is up for deferral if time runs out.

The amount of follow-on work that I am hearing about here, and may be for tests, does not  make it sound
like this JEP is nearly as done as first presented.

If there was some expectation that groups responsible for an area would get involved with this
issue which I am assured was already known about, then why was it not raised before and made
part of the plan ?

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

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

From prr at openjdk.java.net  Fri May 21 18:31:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:31:01 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The client changes are fine except for the one misplaced (c)

test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:

> 1: /*
> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Probably the (c) update was meant to be on the .sh file that is actually modified.

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

Marked as reviewed by prr (Reviewer).

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

From weijun at openjdk.java.net  Fri May 21 19:50:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 19:50:15 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
 <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
Message-ID: <UgO9-C6Oo_ulIRbQWW6Jw5HEPeJHSAnpgfdXEfiQVNE=.bf8a2656-e9bf-4627-a37b-cc9ca84e6d1b@github.com>

On Fri, 21 May 2021 18:26:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust order of VM options
>
> test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Probably the (c) update was meant to be on the .sh file that is actually modified.

Oops, I'll back it out. Thanks.

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

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

From weijun at openjdk.java.net  Fri May 21 20:01:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:01:15 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v3]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <J7PKD_tgpaSH7oobcuRkh3qKFsr1wAPbxqEPaW7dJa0=.71e1df8c-8f2d-49b0-8a21-819907087678@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Phil
  
  reverted:

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578

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

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

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

From prr at openjdk.java.net  Fri May 21 20:46:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 20:46:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

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

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

From weijun at openjdk.java.net  Fri May 21 20:55:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:55:02 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>
Message-ID: <S-kozOfLwraS98p1UoWwwNGs-M6kfUYjtcFVwtnFChY=.13224ab0-59c6-42b9-be32-46d2599b7acf@github.com>

On Fri, 21 May 2021 20:43:05 GMT, Phil Race <prr at openjdk.org> wrote:

> I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
> 
> > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
> 
> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
> > 57:                 ProcessCommunicator
> > 58:                         .executeChildProcess(Consumer.class, new String[0]);
> > 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

I replied right in the thread but unfortunately GitHub does not display it at the end of page.

This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout.

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

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

From vromero at openjdk.java.net  Sat May 22 05:49:18 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 22 May 2021 05:49:18 GMT
Subject: RFR: 8258535: jvm.ClassReader should set the accessor to the
 corresponding record component
Message-ID: <hAtK8504xRurnV9I2UdXsil0R6nFgQKTlov7Fz056bk=.8e9e554c-a820-4b78-9e32-74c3beb6540b@github.com>

Please review this fix which addresses a bug in the records implementation. The issue is that when a record is read by jvm.ClassReader, the record components are not linked to its corresponding accessor. If users try to look for the accessor using javax.lang.model API, using an annotation processor for example, then they will find that the accessor is null.

TIA for the review

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

Commit messages:
 - 8258535: TypeElement#getRecordComponents no components for records from a different jar

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

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

From alanb at openjdk.java.net  Sat May 22 07:00:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 07:00:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
 <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
 <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>
Message-ID: <EY0wxSpTN5BT63blVVvIHQ69tvBmgDTXcSroIDhlhcA=.2e93e74b-33e5-444e-8bcb-c8ffc3621597@github.com>

On Fri, 21 May 2021 18:00:13 GMT, Phil Race <prr at openjdk.org> wrote:

> Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
> It is very straight forward to run the automated tests across all platforms these days.
> I get the impression that no one is guaranteeing to do this straight after integration.
> It sounds like it is up for deferral if time runs out.
> 
> The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound
> like this JEP is nearly as done as first presented.
> 
> If there was some expectation that groups responsible for an area would get involved with this
> issue which I am assured was already known about, then why was it not raised before and made
> part of the plan ?

Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR.  PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR.

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

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

From lgxbslgx at gmail.com  Sat May 22 12:10:15 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Sat, 22 May 2021 20:10:15 +0800
Subject: The difference between comment and document about the parser
In-Reply-To: <b5303faa-aa79-2918-332d-7db067419fef@oracle.com>
References: <CAPSsVqgQgsBcucZ7j5VpTHrqBALzxYWdntiCBHaDGXLVdfFNEA@mail.gmail.com>
 <3dfb1696-55d6-f380-ba5d-b3363e204588@oracle.com>
 <b5303faa-aa79-2918-332d-7db067419fef@oracle.com>
Message-ID: <CAPSsVqiVP7hmF0kKamyg4g51LuzcQ4NSjvCkPu-hoBc8KkLtfw@mail.gmail.com>

Hi Jon,

I read some more information about the parser and the code of the javac
parser recently.
It seems that the javac parser should be named the* LL(K) *parser precisely
instead of LL(1).
Because it looks ahead to more than one token.

I agree with you that both the document of the project `Compiler Grammar`
and the comment in JavacParser.java need to be revised or be clarified.

I will submit a PR to revise the comment in JavacParser.java later.

But I have never revised the document on the official website.
Could I get your help to direct me to the corresponding location and
sponsor me?

Best Regards,
-- Guoxiong


On Sun, Jan 24, 2021 at 3:50 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> For the comment in JavacParser.java, I suggest the phrase "with code
> derived systematically from an LL(1) grammar" is replaced by something like
> "according to the grammar described in the Java Language Specification",
> and for bonus points, possibly even give the URL
> https://docs.oracle.com/javase/specs/index.html. I would recommend not
> citing any specific version, because that would need to be updated on each
> release.  For additional pedantry, you could also include reference to the
> preview features, which are not part of JLS itself.
>
> -- Jon
> On 1/23/21 9:05 AM, Jonathan Gibbons wrote:
>
> Going back in the public record, I note that JLS 3rd Edition, chapter
> 18[1] says:
>
> *The grammar presented in this chapter is the basis for the reference
> implementation. Note that it is not an LL(1) grammar, though in many cases
> it minimizes the necessary look ahead.*
>
> -- Jon
>
> 1: https://docs.oracle.com/javase/specs/jls/se6/html/syntax.html
> On 1/22/21 12:49 AM, Guoxiong Li wrote:
>
> Hi all,
>
> The comment at class jdk.compiler/com.sun.tools.javac.parser.JavacParser
> states it as below.
>
> ```
> /** The parser maps a token sequence into an abstract syntax
>  *  tree. It operates by recursive descent, with code derived
>  *  systematically from an LL(1) grammar. For efficiency reasons, an
>  *  operator precedence scheme is used for parsing binary operation
>  *  expressions.
> ```
>
> And the document of the project `Compiler Grammar`[1] states it as below.
>
> > The parser that is currently in the javac compiler is a hand-written
> LALR parser.
>
> We can see that one is  LL(1) and another is LALR. I think the comment may
> be right.
> No matter which one is the right description, the difference is not
> acceptable and need to be unified.
>
> What is your opinion? Any idea is appreciated.
>
> [1] http://openjdk.java.net/projects/compiler-grammar/
>
> Best Regards.
>
> -- xiong
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210522/13af7206/attachment.htm>

From gli at openjdk.java.net  Sat May 22 14:00:12 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sat, 22 May 2021 14:00:12 GMT
Subject: RFR: 8267570: The comment of the class JavacParser is not appropriate
Message-ID: <XTjbZ1Gdsc3otEJij23ED9Qrxq7BUIoP-IxIEQ48EDw=.c0981b19-aa02-417b-aa0b-40ce684c28be@github.com>

Hi all,

The following comment of the class JavacParser is not appropriate.


It operates by recursive descent, with code derived
systematically from an LL(1) grammar.


>From the source code, the current javac parser looks like a LL(K) parser instead of LL(1).
This patch revises the comment so that developers won't be confused by it.

Thank you for taking the time to review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - 8267570: The comment of the class JavacParser is not appropriate

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

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

From jjg at openjdk.java.net  Sat May 22 16:44:09 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 22 May 2021 16:44:09 GMT
Subject: RFR: 8267570: The comment of the class JavacParser is not
 appropriate
In-Reply-To: <XTjbZ1Gdsc3otEJij23ED9Qrxq7BUIoP-IxIEQ48EDw=.c0981b19-aa02-417b-aa0b-40ce684c28be@github.com>
References: <XTjbZ1Gdsc3otEJij23ED9Qrxq7BUIoP-IxIEQ48EDw=.c0981b19-aa02-417b-aa0b-40ce684c28be@github.com>
Message-ID: <V8Rs6OtwnSdqxk9T2ggXJlVxy---HUB7OfW9BaSNpxA=.a9f1457e-b3cf-46c9-99e0-f48e307f8af0@github.com>

On Sat, 22 May 2021 13:51:10 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The following comment of the class JavacParser is not appropriate.
> 
> 
> It operates by recursive descent, with code derived
> systematically from an LL(1) grammar.
> 
> 
> From the source code, the current javac parser looks like a LL(K) parser instead of LL(1).
> This patch revises the comment so that developers won't be confused by it.
> 
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Changes requested by jjg (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 68:

> 66:  * The parser maps a token sequence into an abstract syntax tree.
> 67:  * The current javac parser is a hand-written recursive-descent parser.
> 68:  * It implements the grammar described in the Java Language Specification.

In general, temporal words (like "current") should be avoided as a matter of style.

I suggest:

The parser is a hand-written recursive-descent parser that
implements the grammar described in the Java Language Specification.

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

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

From gli at openjdk.java.net  Sun May 23 08:19:29 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 23 May 2021 08:19:29 GMT
Subject: RFR: 8267570: The comment of the class JavacParser is not
 appropriate [v2]
In-Reply-To: <XTjbZ1Gdsc3otEJij23ED9Qrxq7BUIoP-IxIEQ48EDw=.c0981b19-aa02-417b-aa0b-40ce684c28be@github.com>
References: <XTjbZ1Gdsc3otEJij23ED9Qrxq7BUIoP-IxIEQ48EDw=.c0981b19-aa02-417b-aa0b-40ce684c28be@github.com>
Message-ID: <Dw7NN_PC6osyMhm1P9ShfRqPwei2CRcrjMoJmLWANOY=.06306041-8385-4802-a798-596e32fa23c3@github.com>

> Hi all,
> 
> The following comment of the class JavacParser is not appropriate.
> 
> 
> It operates by recursive descent, with code derived
> systematically from an LL(1) grammar.
> 
> 
> From the source code, the current javac parser looks like a LL(K) parser instead of LL(1).
> This patch revises the comment so that developers won't be confused by it.
> 
> Thank you 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:

  Revise comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4153/files
  - new: https://git.openjdk.java.net/jdk/pull/4153/files/afc12850..c5f012a8

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

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

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

From gli at openjdk.java.net  Sun May 23 08:19:30 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 23 May 2021 08:19:30 GMT
Subject: RFR: 8267570: The comment of the class JavacParser is not
 appropriate [v2]
In-Reply-To: <V8Rs6OtwnSdqxk9T2ggXJlVxy---HUB7OfW9BaSNpxA=.a9f1457e-b3cf-46c9-99e0-f48e307f8af0@github.com>
References: <XTjbZ1Gdsc3otEJij23ED9Qrxq7BUIoP-IxIEQ48EDw=.c0981b19-aa02-417b-aa0b-40ce684c28be@github.com>
 <V8Rs6OtwnSdqxk9T2ggXJlVxy---HUB7OfW9BaSNpxA=.a9f1457e-b3cf-46c9-99e0-f48e307f8af0@github.com>
Message-ID: <bnvBFgHS2djpcRaL1QK875-ge-BidFiiOuiEj-hewyE=.a82a56b2-61de-434d-a86f-c22e872bf7f1@github.com>

On Sat, 22 May 2021 16:40:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise comment
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 68:
> 
>> 66:  * The parser maps a token sequence into an abstract syntax tree.
>> 67:  * The current javac parser is a hand-written recursive-descent parser.
>> 68:  * It implements the grammar described in the Java Language Specification.
> 
> In general, temporal words (like "current") should be avoided as a matter of style.
> 
> I suggest:
> 
> The parser is a hand-written recursive-descent parser that
> implements the grammar described in the Java Language Specification.

Fixed.

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

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

From mullan at openjdk.java.net  Sun May 23 16:40:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 23 May 2021 16:40:59 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
Message-ID: <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>

On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
> 
>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>> 103:  * {@systemProperty java.security.manager} system property is set to the
>> 104:  * special token "{@code allow}", then a security manager will not be set at
> 
> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs).

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

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

From gli at openjdk.java.net  Sun May 23 17:29:35 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 23 May 2021 17:29:35 GMT
Subject: RFR: 8267578: Remove unnecessary preview checks
Message-ID: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>

Hi all,

The following preview checks are unnecessary because they are standard features now.

Attr.java

        allowReifiableTypesInInstanceof =
                Feature.REIFIABLE_TYPES_INSTANCEOF.allowedInSource(source) &&
                (!preview.isPreview(Feature.REIFIABLE_TYPES_INSTANCEOF) || preview.isEnabled());


JavacParser.java

        this.allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
                Feature.SWITCH_EXPRESSION.allowedInSource(source);


Resolve.java

        allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
                Feature.SWITCH_EXPRESSION.allowedInSource(source);


It is good to remove them.
Thanks for review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - 8267578: Remove unnecessary preview checks

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

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

From jlaskey at openjdk.java.net  Sun May 23 17:50:07 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Sun, 23 May 2021 17:50:07 GMT
Subject: RFR: 8267578: Remove unnecessary preview checks
In-Reply-To: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
References: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
Message-ID: <NGTK_4RYg0QhXxPvQlLtDb5pg7N0XPzCSWv4e3fUtEE=.2e8c2554-f10b-47d0-b194-87fec463d8d7@github.com>

On Sun, 23 May 2021 11:04:56 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The following preview checks are unnecessary because they are standard features now.
> 
> Attr.java
> 
>         allowReifiableTypesInInstanceof =
>                 Feature.REIFIABLE_TYPES_INSTANCEOF.allowedInSource(source) &&
>                 (!preview.isPreview(Feature.REIFIABLE_TYPES_INSTANCEOF) || preview.isEnabled());
> 
> 
> JavacParser.java
> 
>         this.allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
> 
> 
> Resolve.java
> 
>         allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
> 
> 
> It is good to remove them.
> Thanks for review.
> 
> Best Regards,
> -- Guoxiong

These checks need to remain to allow the Javac compiler to generate code for earlier releases. Please close.

These checks need to remain to allow the Javac compiler to generate code for earlier releases. Please close.

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

Changes requested by jlaskey (Reviewer).

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

From gli at openjdk.java.net  Sun May 23 18:11:46 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 23 May 2021 18:11:46 GMT
Subject: RFR: 8267580: The method JavacParser#peekToken is wrong when the
 first parameter is not zero
Message-ID: <Uceqnubk-N9NQiOZadXWADvchCb4_XTYcyaQQB1-AOg=.952a6a51-fa8e-45b4-989a-860e711b737d@github.com>

Hi all,

The method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` succeeds only when the first parameter `lookahead` is zero. If the `lookahead` is not zero, it is wrong and returns unexpected result.

The parameter `kinds` should not be dereferenced by `lookahead` and should be always started at zero.

But currently, the method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` has not been used so that this issue doesn't effect the parser.

An alternative way:  remove the following methods, because they are not used.

    protected boolean peekToken(Predicate<TokenKind>... kinds)
    protected boolean peekToken(int lookahead, Predicate<TokenKind>... kinds) 


To test this patch, we can comment out the following methods  and  run the tests locally.
Note: some methods may need to add `@SuppressWarnings("unchecked")`.

    protected boolean peekToken(Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
        return peekToken(0, tk1, tk2, tk3);
    }

    protected boolean peekToken(int lookahead, Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
        return tk1.test(S.token(lookahead + 1).kind) &&
                tk2.test(S.token(lookahead + 2).kind) &&
                tk3.test(S.token(lookahead + 3).kind);
    }


Thanks for your review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - 8267580: The method JavacParser#peekToken is wrong when the first parameter is not zero

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

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

From jonathan.gibbons at oracle.com  Sun May 23 18:28:26 2021
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 23 May 2021 11:28:26 -0700
Subject: RFR: 8267578: Remove unnecessary preview checks
In-Reply-To: <NGTK_4RYg0QhXxPvQlLtDb5pg7N0XPzCSWv4e3fUtEE=.2e8c2554-f10b-47d0-b194-87fec463d8d7@github.com>
References: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
 <NGTK_4RYg0QhXxPvQlLtDb5pg7N0XPzCSWv4e3fUtEE=.2e8c2554-f10b-47d0-b194-87fec463d8d7@github.com>
Message-ID: <c5a9905c-b131-4e30-5ddc-7d7370e151b5@oracle.com>

Guoxiong,

To be clear, it is an overall requirement that in order to bootstrap-compile the JDK, we must be able to compile javac with the previously available release. Given the short interval between releases, this sometimes evaluates to a numerically 2-earlier release. For example, after we open up the repos for JDK 18 next month, JDK 17 will not be available until September, so we still need to compile javac with JDK 16 until then.

-- Jon


From jlahoda at openjdk.java.net  Mon May 24 06:38:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 24 May 2021 06:38:04 GMT
Subject: RFR: 8267578: Remove unnecessary preview checks
In-Reply-To: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
References: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
Message-ID: <HGBMy6zgOfIfB0P2n-egvw5rOt-CJj3rq4z578v7b-0=.ada49dec-5482-4db1-85ce-703c0bccbdaf@github.com>

On Sun, 23 May 2021 11:04:56 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The following preview checks are unnecessary because they are standard features now.
> 
> Attr.java
> 
>         allowReifiableTypesInInstanceof =
>                 Feature.REIFIABLE_TYPES_INSTANCEOF.allowedInSource(source) &&
>                 (!preview.isPreview(Feature.REIFIABLE_TYPES_INSTANCEOF) || preview.isEnabled());
> 
> 
> JavacParser.java
> 
>         this.allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
> 
> 
> Resolve.java
> 
>         allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
> 
> 
> It is good to remove them.
> Thanks for review.
> 
> Best Regards,
> -- Guoxiong

Looks good to me.

@JimLaskey - please note that javac does not support preview features from previous versions (as per JEP 12). So once a feature is made final, it is safe to remove the preview checks, AFAIK, it just was not done for these few cases.

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

Marked as reviewed by jlahoda (Reviewer).

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

From gli at openjdk.java.net  Mon May 24 07:25:09 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 24 May 2021 07:25:09 GMT
Subject: RFR: 8267578: Remove unnecessary preview checks
In-Reply-To: <NGTK_4RYg0QhXxPvQlLtDb5pg7N0XPzCSWv4e3fUtEE=.2e8c2554-f10b-47d0-b194-87fec463d8d7@github.com>
References: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
 <NGTK_4RYg0QhXxPvQlLtDb5pg7N0XPzCSWv4e3fUtEE=.2e8c2554-f10b-47d0-b194-87fec463d8d7@github.com>
Message-ID: <-Greyx6kMrZvUZi-92teMOuSnT1YiaaGPD7lRJ-8r_o=.fa022908-53f5-461b-b6e7-04ff428798a6@github.com>

On Sun, 23 May 2021 17:43:45 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Hi all,
>> 
>> The following preview checks are unnecessary because they are standard features now.
>> 
>> Attr.java
>> 
>>         allowReifiableTypesInInstanceof =
>>                 Feature.REIFIABLE_TYPES_INSTANCEOF.allowedInSource(source) &&
>>                 (!preview.isPreview(Feature.REIFIABLE_TYPES_INSTANCEOF) || preview.isEnabled());
>> 
>> 
>> JavacParser.java
>> 
>>         this.allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
>> 
>> 
>> Resolve.java
>> 
>>         allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
>> 
>> 
>> It is good to remove them.
>> Thanks for review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> These checks need to remain to allow the Javac compiler to generate code for earlier releases. Please close.

@JimLaskey @jonathan-gibbons @lahodaj Thanks for your comments and reviews.

This patch only cleans up the preview checks instead of something about releases.

The similar cleanup codes are common when we implement the standard feature. Please see the following two cases.

1. [8260517: implement Sealed Classes as a standard feature in Java](https://github.com/openjdk/jdk/commit/0fa9223)


-        this.allowSealedTypes = (!preview.isPreview(Feature.SEALED_CLASSES) || preview.isEnabled()) &&
-                Feature.SEALED_CLASSES.allowedInSource(source);
+        this.allowSealedTypes = Feature.SEALED_CLASSES.allowedInSource(source);


2. [8255013: implement Record Classes as a standard feature in Java, follow-up](https://github.com/openjdk/jdk/commit/8bde2f4)


-        this.allowRecords = (!preview.isPreview(Feature.RECORDS) || preview.isEnabled()) &&
-                Feature.RECORDS.allowedInSource(source);
+        this.allowRecords = Feature.RECORDS.allowedInSource(source);


We can consider that the codes of this patch were forgotten to cleanup during previous standard features.

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

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

From jlaskey at openjdk.java.net  Mon May 24 08:54:00 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 24 May 2021 08:54:00 GMT
Subject: RFR: 8267578: Remove unnecessary preview checks
In-Reply-To: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
References: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
Message-ID: <odSDeFTt1vV5S97kWi_R0LOuClqzF48Q4XbH3TEO7Xg=.45e207df-cccd-42ea-8b36-f84a678a3931@github.com>

On Sun, 23 May 2021 11:04:56 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The following preview checks are unnecessary because they are standard features now.
> 
> Attr.java
> 
>         allowReifiableTypesInInstanceof =
>                 Feature.REIFIABLE_TYPES_INSTANCEOF.allowedInSource(source) &&
>                 (!preview.isPreview(Feature.REIFIABLE_TYPES_INSTANCEOF) || preview.isEnabled());
> 
> 
> JavacParser.java
> 
>         this.allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
> 
> 
> Resolve.java
> 
>         allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
> 
> 
> It is good to remove them.
> Thanks for review.
> 
> Best Regards,
> -- Guoxiong

Apologies. I misread the nature of the change.

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

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

From mcimadamore at openjdk.java.net  Mon May 24 09:57:58 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 24 May 2021 09:57:58 GMT
Subject: RFR: 8267580: The method JavacParser#peekToken is wrong when the
 first parameter is not zero
In-Reply-To: <Uceqnubk-N9NQiOZadXWADvchCb4_XTYcyaQQB1-AOg=.952a6a51-fa8e-45b4-989a-860e711b737d@github.com>
References: <Uceqnubk-N9NQiOZadXWADvchCb4_XTYcyaQQB1-AOg=.952a6a51-fa8e-45b4-989a-860e711b737d@github.com>
Message-ID: <HRQASiswcPvsrfNQYV9qIa_tbhF-yTCn6kVqeAVCKWA=.236de4c3-5ae9-4be1-8e22-ea4f8093da8a@github.com>

On Sun, 23 May 2021 14:38:18 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` succeeds only when the first parameter `lookahead` is zero. If the `lookahead` is not zero, it is wrong and returns unexpected result.
> 
> The parameter `kinds` should not be dereferenced by `lookahead` and should be always started at zero.
> 
> But currently, the method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` has not been used so that this issue doesn't effect the parser.
> 
> An alternative way:  remove the following methods, because they are not used.
> 
>     protected boolean peekToken(Predicate<TokenKind>... kinds)
>     protected boolean peekToken(int lookahead, Predicate<TokenKind>... kinds) 
> 
> 
> To test this patch, we can comment out the following methods  and  run the tests locally.
> Note: some methods may need to add `@SuppressWarnings("unchecked")`.
> 
>     protected boolean peekToken(Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
>         return peekToken(0, tk1, tk2, tk3);
>     }
> 
>     protected boolean peekToken(int lookahead, Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
>         return tk1.test(S.token(lookahead + 1).kind) &&
>                 tk2.test(S.token(lookahead + 2).kind) &&
>                 tk3.test(S.token(lookahead + 3).kind);
>     }
> 
> 
> Thanks for your review.
> 
> Best Regards,
> -- Guoxiong

Looks good - I wonder if we could rewrite all the other routines in terms of this one, rather than having a bunch of different related methods bottoming out in the same code?

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

Marked as reviewed by mcimadamore (Reviewer).

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

From gli at openjdk.java.net  Mon May 24 10:18:22 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 24 May 2021 10:18:22 GMT
Subject: RFR: 8267580: The method JavacParser#peekToken is wrong when the
 first parameter is not zero
In-Reply-To: <HRQASiswcPvsrfNQYV9qIa_tbhF-yTCn6kVqeAVCKWA=.236de4c3-5ae9-4be1-8e22-ea4f8093da8a@github.com>
References: <Uceqnubk-N9NQiOZadXWADvchCb4_XTYcyaQQB1-AOg=.952a6a51-fa8e-45b4-989a-860e711b737d@github.com>
 <HRQASiswcPvsrfNQYV9qIa_tbhF-yTCn6kVqeAVCKWA=.236de4c3-5ae9-4be1-8e22-ea4f8093da8a@github.com>
Message-ID: <_DCmybEE-Y2hN9PqGzygyBK6psOG5zwidGyVGjaCjdY=.ca569c01-8903-4822-8c05-8c9f303601de@github.com>

On Mon, 24 May 2021 09:55:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> The method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` succeeds only when the first parameter `lookahead` is zero. If the `lookahead` is not zero, it is wrong and returns unexpected result.
>> 
>> The parameter `kinds` should not be dereferenced by `lookahead` and should be always started at zero.
>> 
>> But currently, the method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` has not been used so that this issue doesn't effect the parser.
>> 
>> An alternative way:  remove the following methods, because they are not used.
>> 
>>     protected boolean peekToken(Predicate<TokenKind>... kinds)
>>     protected boolean peekToken(int lookahead, Predicate<TokenKind>... kinds) 
>> 
>> 
>> To test this patch, we can comment out the following methods  and  run the tests locally.
>> Note: some methods may need to add `@SuppressWarnings("unchecked")`.
>> 
>>     protected boolean peekToken(Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
>>         return peekToken(0, tk1, tk2, tk3);
>>     }
>> 
>>     protected boolean peekToken(int lookahead, Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
>>         return tk1.test(S.token(lookahead + 1).kind) &&
>>                 tk2.test(S.token(lookahead + 2).kind) &&
>>                 tk3.test(S.token(lookahead + 3).kind);
>>     }
>> 
>> 
>> Thanks for your review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Looks good - I wonder if we could rewrite all the other routines in terms of this one, rather than having a bunch of different related methods bottoming out in the same code?

@mcimadamore Thank you for your review.

These similar overloaded methods seem like a common way at module `jdk.compiler` and even the whole JDK. Is it related to the performance or other aspects?

I don't think it is good to remove them in this patch. Maybe we should continue to discuss this issue at another thread which is like `Using varargs methods to replace existing similar overloaded methods`.

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

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

From mcimadamore at openjdk.java.net  Mon May 24 11:21:22 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 24 May 2021 11:21:22 GMT
Subject: RFR: 8267580: The method JavacParser#peekToken is wrong when the
 first parameter is not zero
In-Reply-To: <Uceqnubk-N9NQiOZadXWADvchCb4_XTYcyaQQB1-AOg=.952a6a51-fa8e-45b4-989a-860e711b737d@github.com>
References: <Uceqnubk-N9NQiOZadXWADvchCb4_XTYcyaQQB1-AOg=.952a6a51-fa8e-45b4-989a-860e711b737d@github.com>
Message-ID: <mGGt5cex6c8KPWRLqVeTOEzs494iUbVP1qLU865SCiU=.965b0ed4-6d2e-4311-a9ad-59294a3608de@github.com>

On Sun, 23 May 2021 14:38:18 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` succeeds only when the first parameter `lookahead` is zero. If the `lookahead` is not zero, it is wrong and returns unexpected result.
> 
> The parameter `kinds` should not be dereferenced by `lookahead` and should be always started at zero.
> 
> But currently, the method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` has not been used so that this issue doesn't effect the parser.
> 
> An alternative way:  remove the following methods, because they are not used.
> 
>     protected boolean peekToken(Predicate<TokenKind>... kinds)
>     protected boolean peekToken(int lookahead, Predicate<TokenKind>... kinds) 
> 
> 
> To test this patch, we can comment out the following methods  and  run the tests locally.
> Note: some methods may need to add `@SuppressWarnings("unchecked")`.
> 
>     protected boolean peekToken(Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
>         return peekToken(0, tk1, tk2, tk3);
>     }
> 
>     protected boolean peekToken(int lookahead, Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
>         return tk1.test(S.token(lookahead + 1).kind) &&
>                 tk2.test(S.token(lookahead + 2).kind) &&
>                 tk3.test(S.token(lookahead + 3).kind);
>     }
> 
> 
> Thanks for your review.
> 
> Best Regards,
> -- Guoxiong

I misread the patch. One method - `peekToken(Predicate<TokenKind>... kinds)` is already delegating to the one you fixed. And for the 1, 2, 3 token kind versions, one might argue that, by doing so we avoid array creation.

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

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

From gli at openjdk.java.net  Mon May 24 11:21:23 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 24 May 2021 11:21:23 GMT
Subject: Integrated: 8267580: The method JavacParser#peekToken is wrong when
 the first parameter is not zero
In-Reply-To: <Uceqnubk-N9NQiOZadXWADvchCb4_XTYcyaQQB1-AOg=.952a6a51-fa8e-45b4-989a-860e711b737d@github.com>
References: <Uceqnubk-N9NQiOZadXWADvchCb4_XTYcyaQQB1-AOg=.952a6a51-fa8e-45b4-989a-860e711b737d@github.com>
Message-ID: <V2Ylx7sIDaX-j0g8DpTEzrS-6V1zQWRNGvDG90qVHU4=.914b49b0-a0f2-45fe-8d65-574cd11d333b@github.com>

On Sun, 23 May 2021 14:38:18 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` succeeds only when the first parameter `lookahead` is zero. If the `lookahead` is not zero, it is wrong and returns unexpected result.
> 
> The parameter `kinds` should not be dereferenced by `lookahead` and should be always started at zero.
> 
> But currently, the method `JavacParser#peekToken(int lookahead, Predicate<TokenKind>... kinds)` has not been used so that this issue doesn't effect the parser.
> 
> An alternative way:  remove the following methods, because they are not used.
> 
>     protected boolean peekToken(Predicate<TokenKind>... kinds)
>     protected boolean peekToken(int lookahead, Predicate<TokenKind>... kinds) 
> 
> 
> To test this patch, we can comment out the following methods  and  run the tests locally.
> Note: some methods may need to add `@SuppressWarnings("unchecked")`.
> 
>     protected boolean peekToken(Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
>         return peekToken(0, tk1, tk2, tk3);
>     }
> 
>     protected boolean peekToken(int lookahead, Predicate<TokenKind> tk1, Predicate<TokenKind> tk2, Predicate<TokenKind> tk3) {
>         return tk1.test(S.token(lookahead + 1).kind) &&
>                 tk2.test(S.token(lookahead + 2).kind) &&
>                 tk3.test(S.token(lookahead + 3).kind);
>     }
> 
> 
> Thanks for your review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 54520fbf
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/54520fbf49bb6a7bdcff1a69a0bb46f842bdc054
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8267580: The method JavacParser#peekToken is wrong when the first parameter is not zero

Reviewed-by: mcimadamore

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

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

From jfranck at openjdk.java.net  Mon May 24 12:25:23 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 24 May 2021 12:25:23 GMT
Subject: RFR: 8258535: jvm.ClassReader should set the accessor to the
 corresponding record component
In-Reply-To: <hAtK8504xRurnV9I2UdXsil0R6nFgQKTlov7Fz056bk=.8e9e554c-a820-4b78-9e32-74c3beb6540b@github.com>
References: <hAtK8504xRurnV9I2UdXsil0R6nFgQKTlov7Fz056bk=.8e9e554c-a820-4b78-9e32-74c3beb6540b@github.com>
Message-ID: <grrP_LiVFUpFNa05mIK-6YnCraekDkxLvoA51WqHVoM=.099ba4c7-4496-49ff-8984-1493b88e78ae@github.com>

On Sat, 22 May 2021 05:40:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this fix which addresses a bug in the records implementation. The issue is that when a record is read by jvm.ClassReader, the record components are not linked to its corresponding accessor. If users try to look for the accessor using javax.lang.model API, using an annotation processor for example, then they will find that the accessor is null.
> 
> TIA for the review

Lgtm

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

Marked as reviewed by jfranck (Reviewer).

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

From gli at openjdk.java.net  Mon May 24 12:35:07 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 24 May 2021 12:35:07 GMT
Subject: Integrated: 8267578: Remove unnecessary preview checks
In-Reply-To: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
References: <Pt9hU6g_SQ4CPT-wnhutMCQmYBG8qHTsC0fnMuqi9zI=.bce99e53-dc0f-47ff-9481-4d2a9be8cec9@github.com>
Message-ID: <s8SSH8fTqiCnvse_EGWW_AldZbmpHAKXPGC7Bz9bL9A=.3d068b86-29b6-4e5f-97e4-a08bdbec9517@github.com>

On Sun, 23 May 2021 11:04:56 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The following preview checks are unnecessary because they are standard features now.
> 
> Attr.java
> 
>         allowReifiableTypesInInstanceof =
>                 Feature.REIFIABLE_TYPES_INSTANCEOF.allowedInSource(source) &&
>                 (!preview.isPreview(Feature.REIFIABLE_TYPES_INSTANCEOF) || preview.isEnabled());
> 
> 
> JavacParser.java
> 
>         this.allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
> 
> 
> Resolve.java
> 
>         allowYieldStatement = (!preview.isPreview(Feature.SWITCH_EXPRESSION) || preview.isEnabled()) &&
>                 Feature.SWITCH_EXPRESSION.allowedInSource(source);
> 
> 
> It is good to remove them.
> Thanks for review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: f4531661
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f4531661b55458554f907ba988eca22b72c72bf3
Stats:     10 lines in 3 files changed: 0 ins; 7 del; 3 mod

8267578: Remove unnecessary preview checks

Reviewed-by: jlahoda

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

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

From weijun at openjdk.java.net  Mon May 24 13:53:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  keep only one systemProperty tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4

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

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

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

From weijun at openjdk.java.net  Mon May 24 13:53:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:37 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
 <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>
Message-ID: <lPk0z6baFFN6QyO0FyiIGkTu9xxIRjx0mu2IET_Kl30=.94dea9d7-9715-41c9-8069-91b5b91a6390@github.com>

On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>> 
>>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>>> 103:  * {@systemProperty java.security.manager} system property is set to the
>>> 104:  * special token "{@code allow}", then a security manager will not be set at
>> 
>> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.
>
> Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too.

New commit pushed. There is only one `@systemProperty` tag now.

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

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

From weijun at openjdk.java.net  Mon May 24 14:05:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 14:05:08 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v4]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <ErcuQXTihK3DvF1qE6VRicIPIaRHK9upkv59SGzW_PA=.b5fbb915-d64e-42bc-b0ff-a02766c6ba9f@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang 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 20 additional commits since the last revision:

 - Merge branch 'master' into 8267184
 - feedback from Phil
   
   reverted:
 - adjust order of VM options
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0

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

  Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

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

From vromero at openjdk.java.net  Mon May 24 14:54:13 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 24 May 2021 14:54:13 GMT
Subject: Integrated: 8258535: jvm.ClassReader should set the accessor to the
 corresponding record component
In-Reply-To: <hAtK8504xRurnV9I2UdXsil0R6nFgQKTlov7Fz056bk=.8e9e554c-a820-4b78-9e32-74c3beb6540b@github.com>
References: <hAtK8504xRurnV9I2UdXsil0R6nFgQKTlov7Fz056bk=.8e9e554c-a820-4b78-9e32-74c3beb6540b@github.com>
Message-ID: <yCQeX2_lPoZU87OkUkM0EjzD_VQC9_I9ro4jBLeEIVI=.24465374-b5b9-41d7-b69d-1e034ef0fb53@github.com>

On Sat, 22 May 2021 05:40:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this fix which addresses a bug in the records implementation. The issue is that when a record is read by jvm.ClassReader, the record components are not linked to its corresponding accessor. If users try to look for the accessor using javax.lang.model API, using an annotation processor for example, then they will find that the accessor is null.
> 
> TIA for the review

This pull request has now been integrated.

Changeset: f5562f12
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f5562f1214478439899b803f80247d2347a00dab
Stats:     223 lines in 2 files changed: 222 ins; 0 del; 1 mod

8258535: jvm.ClassReader should set the accessor to the corresponding record component

Reviewed-by: jfranck

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

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

From weijun at openjdk.java.net  Mon May 24 17:02:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 17:02:13 GMT
Subject: Integrated: 8267184: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

This pull request has now been integrated.

Changeset: 640a2afd
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7
Stats:     1028 lines in 852 files changed: 252 ins; 9 del; 767 mod

8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr

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

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

From vromero at openjdk.java.net  Mon May 24 21:52:05 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 24 May 2021 21:52:05 GMT
Subject: RFR: 8248843: java in source-file mode suggests javac-only options
In-Reply-To: <8NKQP6iQM2BZ6BdJucN3wVFokZeO5bPIp8u19oE98sI=.22615f9d-bde2-4e70-9ff8-37b150b390ec@github.com>
References: <8NKQP6iQM2BZ6BdJucN3wVFokZeO5bPIp8u19oE98sI=.22615f9d-bde2-4e70-9ff8-37b150b390ec@github.com>
Message-ID: <41xwgtjL-vKQLJEn4TTMY9WonEO5qhVqcHn5eOXdggU=.75bbc1a2-01be-434d-bcaa-171bf5345c70@github.com>

On Tue, 18 May 2021 14:09:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `java` in source-file mode (see JEP 330) displays compiler notes suggesting `recompile with -Xdiags:verbose to get full output`. 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 `-Xdiags:verbose` are out of their scope.
> 
> This patch prevents displaying `Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output` suggestion in `java` source-file mode by implicitly enabling `-Xdiags:verbose` 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.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From prappo at openjdk.java.net  Mon May 24 22:37:37 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 24 May 2021 22:37:37 GMT
Subject: RFR: 8267633: Clarify documentation of (Doc)TreeScanner
Message-ID: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com>

When a method is said to be called "on an object", this means that the object is a receiver. When a method is said to be called "with an object", this means that the object is a parameter.

To scan an instance of (Doc)Tree, the "scan" method is called on the instance of (Doc)TreeScanner with that instance of (Doc)Tree.

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

Commit messages:
 - Change @link to @code similarly to DocTreePath
 - Initial commit

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

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

From jjg at openjdk.java.net  Mon May 24 22:37:38 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 24 May 2021 22:37:38 GMT
Subject: RFR: 8267633: Clarify documentation of (Doc)TreeScanner
In-Reply-To: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com>
References: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com>
Message-ID: <454lCcsCz6faWNA1kbcIbIq-4akeTm9kd4s7-T6J-7g=.1cda65a2-6582-4fbe-8f9f-b5555c804f53@github.com>

On Mon, 24 May 2021 21:05:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> When a method is said to be called "on an object", this means that the object is a receiver. When a method is said to be called "with an object", this means that the object is a parameter.
> 
> To scan an instance of (Doc)Tree, the "scan" method is called on the instance of (Doc)TreeScanner with that instance of (Doc)Tree.

OK.

I'm not entirely comfortable with the phrasing of  `call with` but I understand the issue with `call on`.

src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java line 44:

> 42:  * result of calling {@code scan} with that child. The child may be a simple node
> 43:  * or itself a list of nodes.
> 44:  * <li> If the node being visited has more than one child, the result will

Inconsistent space after `<li>`  (Since this is mostly a cleanup PR)

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

Marked as reviewed by jjg (Reviewer).

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

From vromero at openjdk.java.net  Mon May 24 23:23:10 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 24 May 2021 23:23:10 GMT
Subject: RFR: 8267317: Remove DeferredTypeCompleter [v2]
In-Reply-To: <vF8o2mSkNIPDOgQFPF6YxTHQ35T8SyjhiCwszzVYfZE=.64427a71-015b-4f51-862d-9de8c22c7196@github.com>
References: <vGhbXyJXRjnmDMF7n10LkEF6bJ5Ukxlmno7Jg7KW-dw=.b1fa88a7-6f9d-4e36-a449-1713360f0715@github.com>
 <vF8o2mSkNIPDOgQFPF6YxTHQ35T8SyjhiCwszzVYfZE=.64427a71-015b-4f51-862d-9de8c22c7196@github.com>
Message-ID: <bzsI76K8koWGH8_cZRuskDApPQIFv8FnI0tpCST5D68=.9fbca5db-ae77-435b-9886-6e2707188d19@github.com>

On Tue, 18 May 2021 13:08:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This pathc removes DeferredTypeCompleter, which seems like a dubious abstraction. In its place there is now a `complete` method on `DeferredType` which is overridden by `ArgumentType`. The only problematic usage is from `StructuralStuckChecker`, but after inspecting the code I realized that the only side effect this code expected from calling `DeferredType::check` was to set the deferred type mode to `SPECULATIVE`, which we can easily do inline.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant assigment of DeferredType::mode

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From asotona at openjdk.java.net  Tue May 25 04:56:11 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 25 May 2021 04:56:11 GMT
Subject: Integrated: 8248843: java in source-file mode suggests javac-only
 options
In-Reply-To: <8NKQP6iQM2BZ6BdJucN3wVFokZeO5bPIp8u19oE98sI=.22615f9d-bde2-4e70-9ff8-37b150b390ec@github.com>
References: <8NKQP6iQM2BZ6BdJucN3wVFokZeO5bPIp8u19oE98sI=.22615f9d-bde2-4e70-9ff8-37b150b390ec@github.com>
Message-ID: <VVmQP3WETlLI9P2QMvRoMM1_nhxRB-2qnQPnptJYWww=.c9f438ad-3dd8-44a5-8caf-accc9b110d38@github.com>

On Tue, 18 May 2021 14:09:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `java` in source-file mode (see JEP 330) displays compiler notes suggesting `recompile with -Xdiags:verbose to get full output`. 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 `-Xdiags:verbose` are out of their scope.
> 
> This patch prevents displaying `Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output` suggestion in `java` source-file mode by implicitly enabling `-Xdiags:verbose` 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.

This pull request has now been integrated.

Changeset: 31d0f0d8
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/31d0f0d895ef4039d2e96a8fb6e990e93eed4d41
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8248843: java in source-file mode suggests javac-only options

Reviewed-by: vromero

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

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

From prappo at openjdk.java.net  Tue May 25 09:09:25 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 25 May 2021 09:09:25 GMT
Subject: RFR: 8267633: Clarify documentation of (Doc)TreeScanner [v2]
In-Reply-To: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com>
References: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com>
Message-ID: <uiaFa2ipD2ifi79dNuCe0nN3aDg5RRUgbsf8rBcatuM=.325fcaa9-00f0-47b7-bde5-3ae0cfd45f3f@github.com>

> When a method is said to be called "on an object", this means that the object is a receiver. When a method is said to be called "with an object", this means that the object is a parameter.
> 
> To scan an instance of (Doc)Tree, the "scan" method is called on the instance of (Doc)TreeScanner with that instance of (Doc)Tree.

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

  Remove inconsistent whitespace in <li>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4174/files
  - new: https://git.openjdk.java.net/jdk/pull/4174/files/9f5ba184..27590231

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

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

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

From godin at openjdk.java.net  Tue May 25 09:32:03 2021
From: godin at openjdk.java.net (Evgeny Mandrikov)
Date: Tue, 25 May 2021 09:32:03 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <qC_1oBQ0rjrNJjosu_auqMsE6WBCupIGSyWv4tf7QfQ=.bf2ed70a-35e9-474b-8e17-644d126a175c@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <pk0mBpekpLd-AELuqFEQSLgKamNrMwuqf3n3Eg4J67Y=.634e1d3d-93d8-420a-aaf9-4a91f06d7e6b@github.com>
 <qC_1oBQ0rjrNJjosu_auqMsE6WBCupIGSyWv4tf7QfQ=.bf2ed70a-35e9-474b-8e17-644d126a175c@github.com>
Message-ID: <LW1D-F50stXwKipIdBT654Vvq5ln_9mytXEqVKk37eg=.c4ac2a74-e008-4d77-b1e9-dbc7c06c5286@github.com>

On Mon, 17 May 2021 19:01:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening.
>> 
>> In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well.
>
> @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested changes in recent commits (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 ).
> 
> I've also tried to update the implementation for the latest spec changes here:
> https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b
> 
> The spec changes are: total patterns are nullable; pattern matching ("new") statement switches must be complete (as switch expressions).
> 
> Any further feedback is welcome!

Hi @lahodaj  ?? ,

I tried `javac` built from this PR and for the following `Example.java`


class Example {
        void example(Object o) {
                switch (o) {
                case String s && s.length() == 0 ->
                        System.out.println("1st case");
                case String s && s.length() == 1 ->          // line 6
                        System.out.println("2nd case");      // line 7
                case String s ->                             // line 8
                        System.out.println("3rd case");      // line 9
                default ->                                   // line 10
                        System.out.println("default case");  // line 11
                }
        }
}


execution of


javac --enable-preview --release 17 Example.java
javap -v -p Example.class


produces


  void example(java.lang.Object);
    descriptor: (Ljava/lang/Object;)V
    flags: (0x0000)
    Code:
      stack=2, locals=7, args_size=2
         0: aload_1
         1: dup
         2: invokestatic  #7                  // Method java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object;
         5: pop
         6: astore_2
         7: iconst_0
         8: istore_3
         9: aload_2
        10: iload_3
        11: invokedynamic #13,  0             // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I
        16: tableswitch   { // 0 to 2
                       0: 44
                       1: 74
                       2: 105
                 default: 122
            }
        44: aload_2
        45: checkcast     #17                 // class java/lang/String
        48: astore        4
        50: aload         4
        52: invokevirtual #19                 // Method java/lang/String.length:()I
        55: ifeq          63
        58: iconst_1
        59: istore_3
        60: goto          9
        63: getstatic     #23                 // Field java/lang/System.out:Ljava/io/PrintStream;
        66: ldc           #29                 // String 1st case
        68: invokevirtual #31                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        71: goto          133
        74: aload_2
        75: checkcast     #17                 // class java/lang/String
        78: astore        5
        80: aload         5
        82: invokevirtual #19                 // Method java/lang/String.length:()I
        85: iconst_1
        86: if_icmpeq     94
        89: iconst_2
        90: istore_3
        91: goto          9
        94: getstatic     #23                 // Field java/lang/System.out:Ljava/io/PrintStream;
        97: ldc           #37                 // String 2nd case
        99: invokevirtual #31                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       102: goto          133
       105: aload_2
       106: checkcast     #17                 // class java/lang/String
       109: astore        6
       111: getstatic     #23                 // Field java/lang/System.out:Ljava/io/PrintStream;
       114: ldc           #39                 // String 3rd case
       116: invokevirtual #31                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       119: goto          133
       122: getstatic     #23                 // Field java/lang/System.out:Ljava/io/PrintStream;
       125: ldc           #41                 // String default case
       127: invokevirtual #31                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       130: goto          133
       133: return
      LineNumberTable:
        line 3: 0
        line 4: 44
        line 5: 63
        line 4: 71
        line 6: 74
        line 7: 94
        line 6: 102
        line 8: 105
        line 9: 111
        line 8: 119
        line 11: 122
        line 8: 130
        line 13: 133


I believe `LineNumberTable` entries `line 6: 102`, `line 8: 119` and `line 8: 130` should not be present.
Otherwise debugger misleadingly will be showing
line `6` after step from line `7`,
line `8` after step from line `9`
and even more misleadingly line `8` after step from line `11`.

This also affects [JaCoCo](https://github.com/jacoco/jacoco) Java Code Coverage tool (I'm one of its developers), which relies on LineNumberTable to provide code coverage highlighting and these entries cause misleading highlighting - partial coverage of line `8` when default case was not executed.

Should I create separate ticket about this in https://bugs.openjdk.java.net/ or this comment here is enough?

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

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

From forax at univ-mlv.fr  Tue May 25 11:42:52 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 25 May 2021 13:42:52 +0200 (CEST)
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <LW1D-F50stXwKipIdBT654Vvq5ln_9mytXEqVKk37eg=.c4ac2a74-e008-4d77-b1e9-dbc7c06c5286@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <pk0mBpekpLd-AELuqFEQSLgKamNrMwuqf3n3Eg4J67Y=.634e1d3d-93d8-420a-aaf9-4a91f06d7e6b@github.com>
 <qC_1oBQ0rjrNJjosu_auqMsE6WBCupIGSyWv4tf7QfQ=.bf2ed70a-35e9-474b-8e17-644d126a175c@github.com>
 <LW1D-F50stXwKipIdBT654Vvq5ln_9mytXEqVKk37eg=.c4ac2a74-e008-4d77-b1e9-dbc7c06c5286@github.com>
Message-ID: <2070914630.587750.1621942972319.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Evgeny Mandrikov" <godin at openjdk.java.net>
> ?: "build-dev" <build-dev at openjdk.java.net>, "compiler-dev" <compiler-dev at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>, "javadoc-dev" <javadoc-dev at openjdk.java.net>
> Envoy?: Mardi 25 Mai 2021 11:32:03
> Objet: Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4]

> On Mon, 17 May 2021 19:01:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:
> 
>>> Good work. There's a lot to take in here. I think overall, it holds up well - I
>>> like how case labels have been extended to accommodate for patterns. In the
>>> front-end, I think there are some questions over the split between Attr and
>>> Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis
>>> happens in Attr instead of Flow and I left some questions to make sure I
>>> understand what's happening.
>>> 
>>> In the backend it's mostly good work - but overall the structure of the code,
>>> both in Lower and in TransPattern is getting very difficult to follow, given
>>> there are many different kind of switches each with its own little twist
>>> attached to it. It would be nice, I think (maybe in a separate cleanup?) if the
>>> code paths serving the different switch kinds could be made more separate, so
>>> that, when reading the code we can worry only about one possible code shape.
>>> That would make the code easier to document as well.
>>
>> @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested
>> changes in recent commits
>> (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b
>> https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99
>> ).
>> 
>> I've also tried to update the implementation for the latest spec changes here:
>> https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b
>> 
>> The spec changes are: total patterns are nullable; pattern matching ("new")
>> statement switches must be complete (as switch expressions).
>> 
>> Any further feedback is welcome!
> 
> Hi @lahodaj  ?? ,
> 
> I tried `javac` built from this PR and for the following `Example.java`
> 
> 
> class Example {
>        void example(Object o) {
>                switch (o) {
>                case String s && s.length() == 0 ->
>                        System.out.println("1st case");
>                case String s && s.length() == 1 ->          // line 6
>                        System.out.println("2nd case");      // line 7
>                case String s ->                             // line 8
>                        System.out.println("3rd case");      // line 9
>                default ->                                   // line 10
>                        System.out.println("default case");  // line 11
>                }
>        }
> }
> 
> 
> execution of
> 
> 
> javac --enable-preview --release 17 Example.java
> javap -v -p Example.class
> 
> 
> produces
> 
> 
>  void example(java.lang.Object);
>    descriptor: (Ljava/lang/Object;)V
>    flags: (0x0000)
>    Code:
>      stack=2, locals=7, args_size=2
>         0: aload_1
>         1: dup
>         2: invokestatic  #7                  // Method
>         java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object;
>         5: pop
>         6: astore_2
>         7: iconst_0
>         8: istore_3
>         9: aload_2
>        10: iload_3
>        11: invokedynamic #13,  0             // InvokeDynamic
>        #0:typeSwitch:(Ljava/lang/Object;I)I
>        16: tableswitch   { // 0 to 2
>                       0: 44
>                       1: 74
>                       2: 105
>                 default: 122
>            }
>        44: aload_2
>        45: checkcast     #17                 // class java/lang/String
>        48: astore        4
>        50: aload         4
>        52: invokevirtual #19                 // Method java/lang/String.length:()I
>        55: ifeq          63
>        58: iconst_1
>        59: istore_3
>        60: goto          9
>        63: getstatic     #23                 // Field
>        java/lang/System.out:Ljava/io/PrintStream;
>        66: ldc           #29                 // String 1st case
>        68: invokevirtual #31                 // Method
>        java/io/PrintStream.println:(Ljava/lang/String;)V
>        71: goto          133
>        74: aload_2
>        75: checkcast     #17                 // class java/lang/String
>        78: astore        5
>        80: aload         5
>        82: invokevirtual #19                 // Method java/lang/String.length:()I
>        85: iconst_1
>        86: if_icmpeq     94
>        89: iconst_2
>        90: istore_3
>        91: goto          9
>        94: getstatic     #23                 // Field
>        java/lang/System.out:Ljava/io/PrintStream;
>        97: ldc           #37                 // String 2nd case
>        99: invokevirtual #31                 // Method
>        java/io/PrintStream.println:(Ljava/lang/String;)V
>       102: goto          133
>       105: aload_2
>       106: checkcast     #17                 // class java/lang/String
>       109: astore        6
>       111: getstatic     #23                 // Field
>       java/lang/System.out:Ljava/io/PrintStream;
>       114: ldc           #39                 // String 3rd case
>       116: invokevirtual #31                 // Method
>       java/io/PrintStream.println:(Ljava/lang/String;)V
>       119: goto          133
>       122: getstatic     #23                 // Field
>       java/lang/System.out:Ljava/io/PrintStream;
>       125: ldc           #41                 // String default case
>       127: invokevirtual #31                 // Method
>       java/io/PrintStream.println:(Ljava/lang/String;)V
>       130: goto          133
>       133: return
>      LineNumberTable:
>        line 3: 0
>        line 4: 44
>        line 5: 63
>        line 4: 71
>        line 6: 74
>        line 7: 94
>        line 6: 102
>        line 8: 105
>        line 9: 111
>        line 8: 119
>        line 11: 122
>        line 8: 130
>        line 13: 133
> 
> 
> I believe `LineNumberTable` entries `line 6: 102`, `line 8: 119` and `line 8:
> 130` should not be present.
> Otherwise debugger misleadingly will be showing
> line `6` after step from line `7`,
> line `8` after step from line `9`
> and even more misleadingly line `8` after step from line `11`.
> 
> This also affects [JaCoCo](https://github.com/jacoco/jacoco) Java Code Coverage
> tool (I'm one of its developers), which relies on LineNumberTable to provide
> code coverage highlighting and these entries cause misleading highlighting -
> partial coverage of line `8` when default case was not executed.
> 
> Should I create separate ticket about this in https://bugs.openjdk.java.net/ or
> this comment here is enough?

Also why invokedynamic take a constant int as second argument ?

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

R?mi

From mcimadamore at openjdk.java.net  Tue May 25 11:57:22 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 25 May 2021 11:57:22 GMT
Subject: Integrated: 8267317: Remove DeferredTypeCompleter
In-Reply-To: <vGhbXyJXRjnmDMF7n10LkEF6bJ5Ukxlmno7Jg7KW-dw=.b1fa88a7-6f9d-4e36-a449-1713360f0715@github.com>
References: <vGhbXyJXRjnmDMF7n10LkEF6bJ5Ukxlmno7Jg7KW-dw=.b1fa88a7-6f9d-4e36-a449-1713360f0715@github.com>
Message-ID: <1NPsawAVxikqKZ-A8hpiI4TvqCrCUL8JdwYdl9Kbg2Y=.330f7386-e981-425a-be2a-fc52e1ff5d54@github.com>

On Tue, 18 May 2021 12:54:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This pathc removes DeferredTypeCompleter, which seems like a dubious abstraction. In its place there is now a `complete` method on `DeferredType` which is overridden by `ArgumentType`. The only problematic usage is from `StructuralStuckChecker`, but after inspecting the code I realized that the only side effect this code expected from calling `DeferredType::check` was to set the deferred type mode to `SPECULATIVE`, which we can easily do inline.

This pull request has now been integrated.

Changeset: 86a8f442
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/86a8f4427139f983faa57b9174c90949628236ca
Stats:     80 lines in 2 files changed: 17 ins; 49 del; 14 mod

8267317: Remove DeferredTypeCompleter

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Tue May 25 12:22:56 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 25 May 2021 12:22:56 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <kd1d0-0eSlREbuAiMe7jad_pbqEO11J6JiXqltlaPbo=.b5ce4502-2c2a-48aa-beae-b8091d93da76@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <kd1d0-0eSlREbuAiMe7jad_pbqEO11J6JiXqltlaPbo=.b5ce4502-2c2a-48aa-beae-b8091d93da76@github.com>
Message-ID: <zxJ84dpG9ZYob_lEmnTLBL14TSWF135WqGfUnHA5yW8=.1d50935d-1555-48f5-9d4b-63cf7aaec7ad@github.com>

On Wed, 19 May 2021 08:00:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>> 
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing various error-related bugs.

Thanks Evgeny, I'll take a look.

@forax, do you mean why there is "0" in:
11: invokedynamic #13, 0
?

The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK.

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

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

From asotona at openjdk.java.net  Tue May 25 13:41:07 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 25 May 2021 13:41:07 GMT
Subject: RFR: 8263445: Duplicate key compiler.err.expected.module in
 compiler.properties
Message-ID: <mI59-g9xInq1zjWYT25QeTo4K4_Qa7_PIeYiM1VS8hc=.7d5cc8ed-3799-4d39-a2f6-36225997280c@github.com>

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties  contains duplicate key:
compiler.err.expected.module

This fix removes the first occurrence of the key to remove the duplicity and keep the actual content of the property.

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

Commit messages:
 - 8263445: Duplicate key compiler.err.expected.module in compiler.properties

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

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

From vromero at openjdk.java.net  Tue May 25 13:56:54 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 25 May 2021 13:56:54 GMT
Subject: RFR: 8263445: Duplicate key compiler.err.expected.module in
 compiler.properties
In-Reply-To: <mI59-g9xInq1zjWYT25QeTo4K4_Qa7_PIeYiM1VS8hc=.7d5cc8ed-3799-4d39-a2f6-36225997280c@github.com>
References: <mI59-g9xInq1zjWYT25QeTo4K4_Qa7_PIeYiM1VS8hc=.7d5cc8ed-3799-4d39-a2f6-36225997280c@github.com>
Message-ID: <rfJr23hLcpWzubNue0dEgW7wBQ35IyH8PKDnB0OtX5g=.1835d0b6-544a-4d25-9ff9-6ebf0e338089@github.com>

On Tue, 25 May 2021 13:34:18 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties  contains duplicate key:
> compiler.err.expected.module
> 
> This fix removes the first occurrence of the key to remove the duplicity and keep the actual content of the property.

looks good

Marked as reviewed by vromero (Reviewer).

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

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

From forax at openjdk.java.net  Tue May 25 14:16:59 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 25 May 2021 14:16:59 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <zxJ84dpG9ZYob_lEmnTLBL14TSWF135WqGfUnHA5yW8=.1d50935d-1555-48f5-9d4b-63cf7aaec7ad@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <kd1d0-0eSlREbuAiMe7jad_pbqEO11J6JiXqltlaPbo=.b5ce4502-2c2a-48aa-beae-b8091d93da76@github.com>
 <zxJ84dpG9ZYob_lEmnTLBL14TSWF135WqGfUnHA5yW8=.1d50935d-1555-48f5-9d4b-63cf7aaec7ad@github.com>
Message-ID: <sErDRIWm0FfZF_zLRh2Amk3VdL8wdzWlE3iNiaVdUfg=.dc4c5bb9-798a-45df-8992-aa0123313a32@github.com>

On Tue, 25 May 2021 12:20:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Thanks Evgeny, I'll take a look.
> 
> @forax, do you mean why there is "0" in:
> 11: invokedynamic #13, 0
> ?

Not this one, the one on the stack.

7: iconst_0   <---- this zero
8: istore_3
9: aload_2
10: iload_3
11: invokedynamic #13, 0 // InvokeDynamic
#0:typeSwitch:(Ljava/lang/Object;I)I

Why the descriptor is (Ljava/lang/Object;I)I instead of (Ljava/lang/Object;)I,
what is the semantics associated to that integer ?

> The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK.

I know that a little to well, i'm one of the guys behind the design of indy :)

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

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

From jlahoda at openjdk.java.net  Tue May 25 14:25:03 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 25 May 2021 14:25:03 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <sErDRIWm0FfZF_zLRh2Amk3VdL8wdzWlE3iNiaVdUfg=.dc4c5bb9-798a-45df-8992-aa0123313a32@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <kd1d0-0eSlREbuAiMe7jad_pbqEO11J6JiXqltlaPbo=.b5ce4502-2c2a-48aa-beae-b8091d93da76@github.com>
 <zxJ84dpG9ZYob_lEmnTLBL14TSWF135WqGfUnHA5yW8=.1d50935d-1555-48f5-9d4b-63cf7aaec7ad@github.com>
 <sErDRIWm0FfZF_zLRh2Amk3VdL8wdzWlE3iNiaVdUfg=.dc4c5bb9-798a-45df-8992-aa0123313a32@github.com>
Message-ID: <SJZxG9A2RhRTA_z48kygRbbraCSioxXaJ7OYBl10Xx8=.ff1c31d6-05cb-422f-b5d8-79893b0a0a73@github.com>

On Tue, 25 May 2021 14:13:55 GMT, R?mi Forax <forax at openjdk.org> wrote:

> > Thanks Evgeny, I'll take a look.
> > @forax, do you mean why there is "0" in:
> > 11: invokedynamic #13, 0
> > ?
> 
> Not this one, the one on the stack.
> 
> 7: iconst_0 <---- this zero
> 8: istore_3
> 9: aload_2
> 10: iload_3
> 11: invokedynamic #13, 0 // InvokeDynamic
> #0:typeSwitch:(Ljava/lang/Object;I)I
> 
> Why the descriptor is (Ljava/lang/Object;I)I instead of (Ljava/lang/Object;)I,
> what is the semantics associated to that integer ?

The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here:

class Example {
        void example(Object o) {
                switch (o) {
                case String s && s.length() == 0 ->
                        System.out.println("1st case");
                case String s && s.length() == 1 ->          // line 6
                        System.out.println("2nd case");      // line 7
                case String s ->                             // line 8
                        System.out.println("3rd case");      // line 9
                default ->                                   // line 10
                        System.out.println("default case");  // line 11
                }
        }
}


If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac.

> 
> > The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK.
> 
> I know that a little to well, i'm one of the guys behind the design of indy :)

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

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

From godin at openjdk.java.net  Tue May 25 14:25:02 2021
From: godin at openjdk.java.net (Evgeny Mandrikov)
Date: Tue, 25 May 2021 14:25:02 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <sErDRIWm0FfZF_zLRh2Amk3VdL8wdzWlE3iNiaVdUfg=.dc4c5bb9-798a-45df-8992-aa0123313a32@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <kd1d0-0eSlREbuAiMe7jad_pbqEO11J6JiXqltlaPbo=.b5ce4502-2c2a-48aa-beae-b8091d93da76@github.com>
 <zxJ84dpG9ZYob_lEmnTLBL14TSWF135WqGfUnHA5yW8=.1d50935d-1555-48f5-9d4b-63cf7aaec7ad@github.com>
 <sErDRIWm0FfZF_zLRh2Amk3VdL8wdzWlE3iNiaVdUfg=.dc4c5bb9-798a-45df-8992-aa0123313a32@github.com>
Message-ID: <D1-lDA3ixg2dc3SacVONBJG3rFHU397rgJSIlfMKWbw=.5fb70d63-bd12-485c-b271-07af6cb47358@github.com>

On Tue, 25 May 2021 14:13:55 GMT, R?mi Forax <forax at openjdk.org> wrote:

> 7: iconst_0 <---- this zero

@forax as far as I understood this will be a value of
parameter `startIndex` in `java.lang.runtime. SwitchBootstraps.doSwitch` ?? 
Please correct me @lahodaj if I'm wrong.

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

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

From prappo at openjdk.java.net  Tue May 25 14:27:04 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 25 May 2021 14:27:04 GMT
Subject: Integrated: 8267633: Clarify documentation of (Doc)TreeScanner
In-Reply-To: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com>
References: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com>
Message-ID: <pW5BlLhgozMdXauL1TRrhXzrNoReDYil_c6qxt_nGH8=.dd1aff4d-af56-4b7e-967e-f63e392f15b1@github.com>

On Mon, 24 May 2021 21:05:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> When a method is said to be called "on an object", this means that the object is a receiver. When a method is said to be called "with an object", this means that the object is a parameter.
> 
> To scan an instance of (Doc)Tree, the "scan" method is called on the instance of (Doc)TreeScanner with that instance of (Doc)Tree.

This pull request has now been integrated.

Changeset: 5a5b807e
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5a5b807e8e3b3148eea911ed1b2c9624b6846370
Stats:     12 lines in 3 files changed: 0 ins; 0 del; 12 mod

8267633: Clarify documentation of (Doc)TreeScanner

Reviewed-by: jjg

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

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

From jlahoda at openjdk.java.net  Tue May 25 14:30:57 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 25 May 2021 14:30:57 GMT
Subject: RFR: 8263445: Duplicate key compiler.err.expected.module in
 compiler.properties
In-Reply-To: <mI59-g9xInq1zjWYT25QeTo4K4_Qa7_PIeYiM1VS8hc=.7d5cc8ed-3799-4d39-a2f6-36225997280c@github.com>
References: <mI59-g9xInq1zjWYT25QeTo4K4_Qa7_PIeYiM1VS8hc=.7d5cc8ed-3799-4d39-a2f6-36225997280c@github.com>
Message-ID: <PnJKvemxr7BvQ4AwMh109J890N-MmFHstdVnVg_0eeE=.22986a48-1fce-41db-b41c-5e8694c69638@github.com>

On Tue, 25 May 2021 13:34:18 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties  contains duplicate key:
> compiler.err.expected.module
> 
> This fix removes the first occurrence of the key to remove the duplicity and keep the actual content of the property.

LGTM.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.java.net  Tue May 25 15:38:20 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 25 May 2021 15:38:20 GMT
Subject: RFR: 8267221: jshell feedback is incorrect when creating method with
 array varargs parameter
Message-ID: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>

When writing something like `void t(int[]... p) {}` into JShell, one gets:

jshell> void t(int[]... p) {}
|  created method t(int[])


Note the wrong parameter type `int[]` instead of `int[]...` or at least `int[][]`. The reason is that the span of the type is incorrect when the type is varargs. The proposed patch is an attempt to fix the span.

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

Commit messages:
 - 8267221: jshell feedback is incorrect when creating method with array varargs parameter

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

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

From gli at openjdk.java.net  Tue May 25 15:58:59 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 25 May 2021 15:58:59 GMT
Subject: RFR: 8267570: The comment of the class JavacParser is not
 appropriate [v2]
In-Reply-To: <V8Rs6OtwnSdqxk9T2ggXJlVxy---HUB7OfW9BaSNpxA=.a9f1457e-b3cf-46c9-99e0-f48e307f8af0@github.com>
References: <XTjbZ1Gdsc3otEJij23ED9Qrxq7BUIoP-IxIEQ48EDw=.c0981b19-aa02-417b-aa0b-40ce684c28be@github.com>
 <V8Rs6OtwnSdqxk9T2ggXJlVxy---HUB7OfW9BaSNpxA=.a9f1457e-b3cf-46c9-99e0-f48e307f8af0@github.com>
Message-ID: <8FzlUCxYHzR1depEOi2aHIA4y9EKl2iwLqRD5zovKDU=.e5178fde-c6c8-4d1f-814a-08f5c83a4784@github.com>

On Sat, 22 May 2021 16:41:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise comment
>
> Changes requested by jjg (Reviewer).

@jonathan-gibbons I revised the comment according to your suggestion. Thanks for your re-review.

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

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

From asotona at openjdk.java.net  Tue May 25 16:01:03 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 25 May 2021 16:01:03 GMT
Subject: Integrated: 8263445: Duplicate key compiler.err.expected.module in
 compiler.properties
In-Reply-To: <mI59-g9xInq1zjWYT25QeTo4K4_Qa7_PIeYiM1VS8hc=.7d5cc8ed-3799-4d39-a2f6-36225997280c@github.com>
References: <mI59-g9xInq1zjWYT25QeTo4K4_Qa7_PIeYiM1VS8hc=.7d5cc8ed-3799-4d39-a2f6-36225997280c@github.com>
Message-ID: <pQqK6E3oUFSCWGuArefK4Zo7CLvw2Q054BEycO-WFBk=.1169870d-1019-4261-8e70-bd1470dcf380@github.com>

On Tue, 25 May 2021 13:34:18 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties  contains duplicate key:
> compiler.err.expected.module
> 
> This fix removes the first occurrence of the key to remove the duplicity and keep the actual content of the property.

This pull request has now been integrated.

Changeset: 2ef2450a
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2ef2450aa6f560a0bcf6ab687b83c2f1d9e3c87e
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8263445: Duplicate key compiler.err.expected.module in compiler.properties

Reviewed-by: vromero, jlahoda

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

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

From forax at openjdk.java.net  Tue May 25 16:03:56 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 25 May 2021 16:03:56 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <SJZxG9A2RhRTA_z48kygRbbraCSioxXaJ7OYBl10Xx8=.ff1c31d6-05cb-422f-b5d8-79893b0a0a73@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <kd1d0-0eSlREbuAiMe7jad_pbqEO11J6JiXqltlaPbo=.b5ce4502-2c2a-48aa-beae-b8091d93da76@github.com>
 <zxJ84dpG9ZYob_lEmnTLBL14TSWF135WqGfUnHA5yW8=.1d50935d-1555-48f5-9d4b-63cf7aaec7ad@github.com>
 <sErDRIWm0FfZF_zLRh2Amk3VdL8wdzWlE3iNiaVdUfg=.dc4c5bb9-798a-45df-8992-aa0123313a32@github.com>
 <SJZxG9A2RhRTA_z48kygRbbraCSioxXaJ7OYBl10Xx8=.ff1c31d6-05cb-422f-b5d8-79893b0a0a73@github.com>
Message-ID: <ixF01yTPcsJviRMf4jgXxAD7WVFC7TKOy32o2sBvJTM=.ed738044-ab11-450b-858b-9f49d1531be4@github.com>

On Tue, 25 May 2021 14:22:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here:
> 
> ```
> class Example {
>         void example(Object o) {
>                 switch (o) {
>                 case String s && s.length() == 0 ->
>                         System.out.println("1st case");
>                 case String s && s.length() == 1 ->          // line 6
>                         System.out.println("2nd case");      // line 7
>                 case String s ->                             // line 8
>                         System.out.println("3rd case");      // line 9
>                 default ->                                   // line 10
>                         System.out.println("default case");  // line 11
>                 }
>         }
> }
> ```
> 
> If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac.

The problem with this design is that calling example("foo") forces the VM will do 6 checkcast String on "foo", and it doesn't work with sub-patterns. Desugaring the guards as static method like with lambdas seems more promising, indy can be called with the pairs [String, MethodHandle(s -> s.length() == 0)], [String, MethodHandle(s -> s.length() == 0)] and [_,_]  (with the guards passed as a constant method handles again like lambdas are desugared).
It means that the indy needs to capture all local variables that are used in the guards, instead of passing an int.

I believe that a translation using constant method handles for guards is far more efficient than using an int and a backward branch but it has a higher cost in term of runtime data structures.

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

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

From gli at openjdk.java.net  Tue May 25 16:07:59 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 25 May 2021 16:07:59 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v4]
In-Reply-To: <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
Message-ID: <4SqSbbf7o_QrbxqZMB1jwvtxAfYR4k_hzZE4drQcJgg=.f08cd72e-4bc9-450d-9ca7-5d8f498fa08a@github.com>

On Tue, 11 May 2021 02:41:16 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
>> so that the output of --help-extra is kept clean and concise.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8230623
>  - Update copyright
>  - Merge branch 'master' into JDK-8230623
>  - Remove the content in documentation javac.1
>  - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint

Ping again.

This issue began at Dec 2020. I would like to finish it at JDK 17.
Maybe it is good to integrate it before rampdown phase one(June 10, 2021).
What do you think about this issue? Thanks.

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

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

From jlahoda at openjdk.java.net  Tue May 25 16:17:59 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 25 May 2021 16:17:59 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <ixF01yTPcsJviRMf4jgXxAD7WVFC7TKOy32o2sBvJTM=.ed738044-ab11-450b-858b-9f49d1531be4@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <kd1d0-0eSlREbuAiMe7jad_pbqEO11J6JiXqltlaPbo=.b5ce4502-2c2a-48aa-beae-b8091d93da76@github.com>
 <zxJ84dpG9ZYob_lEmnTLBL14TSWF135WqGfUnHA5yW8=.1d50935d-1555-48f5-9d4b-63cf7aaec7ad@github.com>
 <sErDRIWm0FfZF_zLRh2Amk3VdL8wdzWlE3iNiaVdUfg=.dc4c5bb9-798a-45df-8992-aa0123313a32@github.com>
 <SJZxG9A2RhRTA_z48kygRbbraCSioxXaJ7OYBl10Xx8=.ff1c31d6-05cb-422f-b5d8-79893b0a0a73@github.com>
 <ixF01yTPcsJviRMf4jgXxAD7WVFC7TKOy32o2sBvJTM=.ed738044-ab11-450b-858b-9f49d1531be4@github.com>
Message-ID: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com>

On Tue, 25 May 2021 16:00:43 GMT, R?mi Forax <forax at openjdk.org> wrote:

> > The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here:
> > ```
> > class Example {
> >         void example(Object o) {
> >                 switch (o) {
> >                 case String s && s.length() == 0 ->
> >                         System.out.println("1st case");
> >                 case String s && s.length() == 1 ->          // line 6
> >                         System.out.println("2nd case");      // line 7
> >                 case String s ->                             // line 8
> >                         System.out.println("3rd case");      // line 9
> >                 default ->                                   // line 10
> >                         System.out.println("default case");  // line 11
> >                 }
> >         }
> > }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac.
> 
> The problem with this design is that calling example("foo") forces the VM will do 6 checkcast String on "foo", and it doesn't work with sub-patterns. Desugaring the guards as static method like with lambdas seems more promising, indy can be called with the pairs [String, MethodHandle(s -> s.length() == 0)], [String, MethodHandle(s -> s.length() == 0)] and [_,_] (with the guards passed as a constant method handles again like lambdas are desugared).
> It means that the indy needs to capture all local variables that are used in the guards, instead of passing an int.
> 
> I believe that a translation using constant method handles for guards is far more efficient than using an int and a backward branch but it has a higher cost in term of runtime data structures.

I'd like to note this is a preview feature - we can change the desugaring. At the same time, I don't think this does not work with sub-patterns (those can be easily desugared to guards, I think). Regarding efficiency, it may be a balance between classfile overhead (which will be higher if we need to desugar every guard to a separate method), and the possibility to tweak the matching at runtime.

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

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

From vromero at openjdk.java.net  Tue May 25 16:26:56 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 25 May 2021 16:26:56 GMT
Subject: RFR: 8267221: jshell feedback is incorrect when creating method
 with array varargs parameter
In-Reply-To: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>
References: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>
Message-ID: <D6TDknvDb4nXOOg99lea8qfjLHjCP_3PND6qN2bEri4=.32ad4ebe-75e5-4d13-8470-b1a5f617e17c@github.com>

On Tue, 25 May 2021 15:30:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When writing something like `void t(int[]... p) {}` into JShell, one gets:
> 
> jshell> void t(int[]... p) {}
> |  created method t(int[])
> 
> 
> Note the wrong parameter type `int[]` instead of `int[]...` or at least `int[][]`. The reason is that the span of the type is incorrect when the type is varargs. The proposed patch is an attempt to fix the span.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Tue May 25 21:43:58 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 25 May 2021 21:43:58 GMT
Subject: RFR: 8267312: Resolve should use generated diagnostic factories
In-Reply-To: <VubPi6l8BPTxtaXcluhpZ31T09EuG-dEf4ni15sHYHU=.77ee87e2-1850-4f57-90da-e053634cc61c@github.com>
References: <VubPi6l8BPTxtaXcluhpZ31T09EuG-dEf4ni15sHYHU=.77ee87e2-1850-4f57-90da-e053634cc61c@github.com>
Message-ID: <JnF5vksvgWgrbe8kyGI1Nrxa59zv5oA2rlMFshsnvx8=.4424921f-f48a-4c9c-a606-183514deff2a@github.com>

On Tue, 18 May 2021 11:07:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g.
> 
> 
> # 0: message segment
> compiler.err.prob.found.req=...
> # 0: message segment
> compiler.misc.prob.found.req=...
> # 0: message segment, 1: type, 2: type
> compiler.warn.prob.found.req=...
> 
> 
> To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise.
> 
> This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code:
> 
> 
> /**
>          * compiler.err.prob.found.req=\
>          *    incompatible types: {0}
>          */
>         public static Error ProbFoundReq(Fragment arg0) {
>             return new Error("compiler", "prob.found.req", arg0) {
>                 public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) {
>                     return switch (kind) {
>                         case ERROR -> this;
>                         case WARNING -> throw new AssertionError("Unsupported kind: " + kind);
>                         case FRAGMENT -> Fragments.ProbFoundReq(arg0);
>                         case NOTE -> throw new AssertionError("Unsupported kind: " + kind);
>                     };
>                 }
>             };
>         }
> 
> 
> As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload.
> 
> With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories.
> 
> The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this.

Some general comments about the generated code. I wonder if it would make sense to change the implementation of the toType() method which will fold common cases in the switch expression into a default case or generate a case label like: `case Type1, Type2 -> sameAction`. Another thing I found is that the generated code has "mirror" code I mean we have for example:


        public static final Fragment UncheckedCastToType = new Fragment("compiler", "unchecked.cast.to.type") {
            public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) {
                return switch (kind) {
                    case ERROR -> throw new AssertionError("Unsupported kind: " + kind);
                    case WARNING -> Warnings.UncheckedCastToType;
                    case FRAGMENT -> this;
                    case NOTE -> throw new AssertionError("Unsupported kind: " + kind);
                };
            }
        };

and

        public static final Warning UncheckedCastToType = new Warning("compiler", "unchecked.cast.to.type") {
            public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) {
                return switch (kind) {
                    case ERROR -> throw new AssertionError("Unsupported kind: " + kind);
                    case WARNING -> this;
                    case FRAGMENT -> Fragments.UncheckedCastToType;
                    case NOTE -> throw new AssertionError("Unsupported kind: " + kind);
                };
            }
        };


I wonder if what we really want to model is one factory that can fold both implementations into one. I know this is generated code which should be ready to use, but just thinking aloud, not sure if there are some abstractions that could be useful from the client code perspective. I wonder if we could build on method DiagnosticInfo::of to define one stop factories. But I guess that you already considered this option.

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

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

From prappo at openjdk.java.net  Tue May 25 21:43:51 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 25 May 2021 21:43:51 GMT
Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.**
Message-ID: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>

Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference

    com.sun.tools.javadoc.ClassDocImpl#findField

should've looked like this

    com.sun.tools.javadoc.main.ClassDocImpl#findField

Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed:

1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74
2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85

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

Commit messages:
 - Fix issues found by a repaired test
 - Address feedback
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/4192/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4192&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267708
  Stats: 24 lines in 6 files changed: 1 ins; 13 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4192.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4192/head:pull/4192

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

From jjg at openjdk.java.net  Tue May 25 21:44:13 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 25 May 2021 21:44:13 GMT
Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.**
In-Reply-To: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
References: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
Message-ID: <fB7IK0r-2SyBrZ-rRzuUCqb2EFstANkTLllLCIv07Z8=.c1c9bbdd-f8fb-4e87-9132-9cf812093d8d@github.com>

On Tue, 25 May 2021 17:32:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference
> 
>     com.sun.tools.javadoc.ClassDocImpl#findField
> 
> should've looked like this
> 
>     com.sun.tools.javadoc.main.ClassDocImpl#findField
> 
> Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed:
> 
> 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74
> 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85

The package references in the two tests you found should be updated to use `jdk.javadoc`.  That's already present for #2, so just delete the old package in #2, and change the package in #1.

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 627:

> 625:     }
> 626: 
> 627:     /** @see com.sun.tools.javadoc.ClassDocImpl#findField */

Is there an equivalent new-style method that should be used instead?

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 319:

> 317:      *      com.sun.tools.javadoc.Main.execute(String programName,
> 318:      *          PrintWriter errWriter, PrintWriter warnWriter, PrintWriter noticeWriter,
> 319:      *          String defaultDocletClassName, String... args)

It is generally bad form to have `@Deprecated` without `@deprecated`. In this case, separate ongoing work to cleanup `Messager` will eventually mean we can remove the method altogether.

If you really want to remove the reference to the old code, the `@deprecated` comment should be updated to "Still in use by javadoc's Mesager class." or some such.

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

Changes requested by jjg (Reviewer).

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

From prappo at openjdk.java.net  Tue May 25 21:44:20 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 25 May 2021 21:44:20 GMT
Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.**
In-Reply-To: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
References: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
Message-ID: <JkClJ-egmWaeDZtyA42TSKJRVwhOBiOuWgVZQYtvcc8=.893cc568-8954-4874-8884-1dde88616c66@github.com>

On Tue, 25 May 2021 17:32:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference
> 
>     com.sun.tools.javadoc.ClassDocImpl#findField
> 
> should've looked like this
> 
>     com.sun.tools.javadoc.main.ClassDocImpl#findField
> 
> Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed:
> 
> 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74
> 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85

1. Removed extinct packages
2. Removed `ignore("jdk/javadoc/internal/tool/Start", "versionRB")` since `Start.versionRB` was removed in JDK-8246078
3. Returned updated deprecation info.

When I fixed the location of javadoc, the NoStringToLower test found two issues it could not see before, both of which I then fixed.

I also note, that this method in DetectMutableStaticFields should perhaps use `String.startsWith` instead of `String.contains` in which case `packagesToSeekFor` should be also renamed to `packagePrefixesToSeekFor`:

    boolean shouldAnalyzePackage(String packageName) {
        for (String aPackage: packagesToSeekFor) {
            if (packageName.contains(aPackage)) {
                return true;
            }
        }
        return false;
    }

But if this is to be fixed, it should be done in a separate PR.

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

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

From jjg at openjdk.java.net  Tue May 25 21:44:32 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 25 May 2021 21:44:32 GMT
Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.**
In-Reply-To: <fB7IK0r-2SyBrZ-rRzuUCqb2EFstANkTLllLCIv07Z8=.c1c9bbdd-f8fb-4e87-9132-9cf812093d8d@github.com>
References: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
 <fB7IK0r-2SyBrZ-rRzuUCqb2EFstANkTLllLCIv07Z8=.c1c9bbdd-f8fb-4e87-9132-9cf812093d8d@github.com>
Message-ID: <qPX1dpPxg9Ud-9JDwCNyMk1nkZrKhGJ4a431ftCyfbU=.72213f71-3229-471d-a032-72763067a6c4@github.com>

On Tue, 25 May 2021 17:39:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference
>> 
>>     com.sun.tools.javadoc.ClassDocImpl#findField
>> 
>> should've looked like this
>> 
>>     com.sun.tools.javadoc.main.ClassDocImpl#findField
>> 
>> Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed:
>> 
>> 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74
>> 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 627:
> 
>> 625:     }
>> 626: 
>> 627:     /** @see com.sun.tools.javadoc.ClassDocImpl#findField */
> 
> Is there an equivalent new-style method that should be used instead?

The most likely justification for all these ClassDocImpl references is now in `ReferenceTree`.

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

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

From prappo at openjdk.java.net  Tue May 25 21:44:35 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 25 May 2021 21:44:35 GMT
Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.**
In-Reply-To: <qPX1dpPxg9Ud-9JDwCNyMk1nkZrKhGJ4a431ftCyfbU=.72213f71-3229-471d-a032-72763067a6c4@github.com>
References: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
 <fB7IK0r-2SyBrZ-rRzuUCqb2EFstANkTLllLCIv07Z8=.c1c9bbdd-f8fb-4e87-9132-9cf812093d8d@github.com>
 <qPX1dpPxg9Ud-9JDwCNyMk1nkZrKhGJ4a431ftCyfbU=.72213f71-3229-471d-a032-72763067a6c4@github.com>
Message-ID: <9Z4Vdedsl2rRdjx2qgBVBudc_kQcG6i9urM2Czjxx4I=.c48dde37-6195-4fc1-b43b-fc6eca04c588@github.com>

On Tue, 25 May 2021 17:46:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 627:
>> 
>>> 625:     }
>>> 626: 
>>> 627:     /** @see com.sun.tools.javadoc.ClassDocImpl#findField */
>> 
>> Is there an equivalent new-style method that should be used instead?
>
> The most likely justification for all these ClassDocImpl references is now in `ReferenceTree`.

A doc comment consisting solely of an `@see` tag has unclear semantics. The methods I removed such doc comments from are private and can be used only from their enclosing instance.

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

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

From jjg at openjdk.java.net  Tue May 25 22:21:21 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 25 May 2021 22:21:21 GMT
Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.**
In-Reply-To: <9Z4Vdedsl2rRdjx2qgBVBudc_kQcG6i9urM2Czjxx4I=.c48dde37-6195-4fc1-b43b-fc6eca04c588@github.com>
References: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
 <fB7IK0r-2SyBrZ-rRzuUCqb2EFstANkTLllLCIv07Z8=.c1c9bbdd-f8fb-4e87-9132-9cf812093d8d@github.com>
 <qPX1dpPxg9Ud-9JDwCNyMk1nkZrKhGJ4a431ftCyfbU=.72213f71-3229-471d-a032-72763067a6c4@github.com>
 <9Z4Vdedsl2rRdjx2qgBVBudc_kQcG6i9urM2Czjxx4I=.c48dde37-6195-4fc1-b43b-fc6eca04c588@github.com>
Message-ID: <c-WWx0tbWAn2VnD204a5g1OOLiu2ulMsEYV2KHjuk1E=.7c796415-5417-4cbe-b8c5-44cd30122949@github.com>

On Tue, 25 May 2021 18:49:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> The most likely justification for all these ClassDocImpl references is now in `ReferenceTree`.
>
> A doc comment consisting solely of an `@see` tag has unclear semantics. The methods I removed such doc comments from are private and can be used only from their enclosing instance.

Let me go do some archaeology. While the comments may have been substandard, I would still like to recall their intent.

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

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

From jjg at openjdk.java.net  Tue May 25 22:28:17 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 25 May 2021 22:28:17 GMT
Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.**
In-Reply-To: <c-WWx0tbWAn2VnD204a5g1OOLiu2ulMsEYV2KHjuk1E=.7c796415-5417-4cbe-b8c5-44cd30122949@github.com>
References: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
 <fB7IK0r-2SyBrZ-rRzuUCqb2EFstANkTLllLCIv07Z8=.c1c9bbdd-f8fb-4e87-9132-9cf812093d8d@github.com>
 <qPX1dpPxg9Ud-9JDwCNyMk1nkZrKhGJ4a431ftCyfbU=.72213f71-3229-471d-a032-72763067a6c4@github.com>
 <9Z4Vdedsl2rRdjx2qgBVBudc_kQcG6i9urM2Czjxx4I=.c48dde37-6195-4fc1-b43b-fc6eca04c588@github.com>
 <c-WWx0tbWAn2VnD204a5g1OOLiu2ulMsEYV2KHjuk1E=.7c796415-5417-4cbe-b8c5-44cd30122949@github.com>
Message-ID: <t-6CZsW5Ioqoja6hQAWfjdgsdhmpr4dBkbMYijLMO4E=.8ebcf45b-c66c-4efd-8530-83b136415b8e@github.com>

On Tue, 25 May 2021 22:17:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> A doc comment consisting solely of an `@see` tag has unclear semantics. The methods I removed such doc comments from are private and can be used only from their enclosing instance.
>
> Let me go do some archaeology. While the comments may have been substandard, I would still like to recall their intent.

The notable content of the comments on those `ClassDocImpl` methods is that they document (I hesitate to use the "specify" word) the search order, with the additional comment *Note that this is not necessarily what the compiler would do!*

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

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

From jjg at openjdk.java.net  Tue May 25 22:44:16 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 25 May 2021 22:44:16 GMT
Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.**
In-Reply-To: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
References: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
Message-ID: <LNs2cg9Qrj-AEdCahLFHB2TykOjiVz_jJRfydvgJAiw=.90e38c9b-61da-45a6-9ec0-4c07d6c3ab2a@github.com>

On Tue, 25 May 2021 17:32:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference
> 
>     com.sun.tools.javadoc.ClassDocImpl#findField
> 
> should've looked like this
> 
>     com.sun.tools.javadoc.main.ClassDocImpl#findField
> 
> Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed:
> 
> 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74
> 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85

See the updated review comments about removing the obsolete doc comments.

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

Marked as reviewed by jjg (Reviewer).

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

From jlahoda at openjdk.java.net  Wed May 26 11:15:17 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 26 May 2021 11:15:17 GMT
Subject: Integrated: 8267221: jshell feedback is incorrect when creating
 method with array varargs parameter
In-Reply-To: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>
References: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>
Message-ID: <TJbff7hiCiZgUU95hvGVheMumqEJahwLZh1UEIwt5i4=.10775896-5a07-4cf4-ab98-b4649751b899@github.com>

On Tue, 25 May 2021 15:30:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When writing something like `void t(int[]... p) {}` into JShell, one gets:
> 
> jshell> void t(int[]... p) {}
> |  created method t(int[])
> 
> 
> Note the wrong parameter type `int[]` instead of `int[]...` or at least `int[][]`. The reason is that the span of the type is incorrect when the type is varargs. The proposed patch is an attempt to fix the span.

This pull request has now been integrated.

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

8267221: jshell feedback is incorrect when creating method with array varargs parameter

Reviewed-by: vromero

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

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

From prappo at openjdk.java.net  Wed May 26 11:30:16 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 26 May 2021 11:30:16 GMT
Subject: Integrated: 8267708: Remove references to com.sun.tools.javadoc.**
In-Reply-To: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
References: <DxziNzLjsFc1QLNEskx1NtyXYXYGqzVcQEcnIXA3CPw=.39307c1d-bb04-466f-975a-bfc2553d1042@github.com>
Message-ID: <MHUmsNLecYJnWy84IKEFM53d2VnTY9iAIpjRKG9WG3M=.46811e9f-c532-4ddb-b9b6-ff2a2d0f14ef@github.com>

On Tue, 25 May 2021 17:32:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference
> 
>     com.sun.tools.javadoc.ClassDocImpl#findField
> 
> should've looked like this
> 
>     com.sun.tools.javadoc.main.ClassDocImpl#findField
> 
> Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed:
> 
> 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74
> 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85

This pull request has now been integrated.

Changeset: 4343997a
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4343997a1a2b38581488932f6a4971ce330bd467
Stats:     24 lines in 6 files changed: 1 ins; 13 del; 10 mod

8267708: Remove references to com.sun.tools.javadoc.**

This commit changes BaseOptions.java to fix the NoStringToLower test that failed after jdk.javadoc has been added to the list of package prefixes that NoStringToLower scans.

Reviewed-by: jjg

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

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

From mcimadamore at openjdk.java.net  Wed May 26 14:12:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 26 May 2021 14:12:15 GMT
Subject: RFR: 8267312: Resolve should use generated diagnostic factories
In-Reply-To: <JnF5vksvgWgrbe8kyGI1Nrxa59zv5oA2rlMFshsnvx8=.4424921f-f48a-4c9c-a606-183514deff2a@github.com>
References: <VubPi6l8BPTxtaXcluhpZ31T09EuG-dEf4ni15sHYHU=.77ee87e2-1850-4f57-90da-e053634cc61c@github.com>
 <JnF5vksvgWgrbe8kyGI1Nrxa59zv5oA2rlMFshsnvx8=.4424921f-f48a-4c9c-a606-183514deff2a@github.com>
Message-ID: <czQ_YFthMHryr5TSNc4UVOzuECjy9wpcFHxOz1a17DI=.5dd097cc-a3a0-4cc2-8a3c-26ad1bcc9e41@github.com>

On Tue, 25 May 2021 19:27:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Some general comments about the generated code. I wonder if it would make sense to change the implementation of the toType() method which will fold common cases in the switch expression into a default case or generate a case label like: `case Type1, Type2 -> sameAction`. 

I'll think about this - my first reaction is that the current strategy makes templating easier, but perhaps there's another way - e.g. by having a template for a single CASE statement, which can be parameterized on a number of labels.

> I wonder if what we really want to model is one factory that can fold both implementations into one. I know this is generated code which should be ready to use, but just thinking aloud, not sure if there are some abstractions that could be useful from the client code perspective. I wonder if we could build on method DiagnosticInfo::of to define one stop factories. But I guess that you already considered this option.

I guess what you are suggesting is that, instead of having a method for converting a diagnostic info to a different one (like we do now) we should have a method to create a diagnostic info with the right kind from the start.

This is definitively an option - one of the issues is that the current generated file is divided by kinds (e.g. CompilerProperties has nested classes like Errors, Warnings, Notes) - so if we added such factories, they'd have to live at the top level (e.g. CompilerProperties). If that's acceptable I can do that. To be clear, the proposed structure will end up like this:


class CompilerProperties {
      static class Errors {
             static DiagnosticInfo ProbFoundReq(...) = ... // like before this patch
             ...
       }
       static class Fragments {
             static DiagnosticInfo ProbFoundReq(...) = ... // like before this patch
             ...
       }
       
       // shared factories
       
       static DiagnosticInfo ProbFoundReq(DiagnosticType type, args...) {
           return switch (type) {
                case ERROR -> Errors.ProbFoundReq(args);
                case MISC -> Fragments.ProbFoundReq(args);
                default -> throw new AssertionError();
            };
       }
}


This would solve the problem you mention, and also avoid a redundant allocation in Resolve.java.

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

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

From jlahoda at openjdk.java.net  Wed May 26 17:52:36 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 26 May 2021 17:52:36 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v5]
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

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

 - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac.
 - Correcting LineNumberTable for rule switches.
 - Merging master into JDK-8262891
 - Fixing various error-related bugs.
 - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default.
 - Reflecting recent spec changes.
 - Reflecting review comments.
 - Reflecting review comments on SwitchBootstraps.
 - Trailing whitespaces.
 - Cleanup, reflecting review comments.
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501

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

Changes: https://git.openjdk.java.net/jdk/pull/3863/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=04
  Stats: 4551 lines in 77 files changed: 4235 ins; 119 del; 197 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863

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

From jlahoda at openjdk.java.net  Wed May 26 19:42:12 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 26 May 2021 19:42:12 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v5]
In-Reply-To: <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
Message-ID: <Ee-Q_pfMwqyejQWYTGkcfSqnYM3iQTclpDpDQZ-W8Wk=.fa3fd662-b6ad-408d-a69b-0fd950723052@github.com>

On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>> 
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac.
>  - Correcting LineNumberTable for rule switches.
>  - Merging master into JDK-8262891
>  - Fixing various error-related bugs.
>  - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default.
>  - Reflecting recent spec changes.
>  - Reflecting review comments.
>  - Reflecting review comments on SwitchBootstraps.
>  - Trailing whitespaces.
>  - Cleanup, reflecting review comments.
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501

In:
https://github.com/openjdk/jdk/pull/3863/commits/7d1abc141ecfecaf0798a2bad899705c116154e7

I've updated the code to produce better/more useful LineNumberTable for rule switches.

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

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

From forax at openjdk.java.net  Wed May 26 20:24:06 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 26 May 2021 20:24:06 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <kd1d0-0eSlREbuAiMe7jad_pbqEO11J6JiXqltlaPbo=.b5ce4502-2c2a-48aa-beae-b8091d93da76@github.com>
 <zxJ84dpG9ZYob_lEmnTLBL14TSWF135WqGfUnHA5yW8=.1d50935d-1555-48f5-9d4b-63cf7aaec7ad@github.com>
 <sErDRIWm0FfZF_zLRh2Amk3VdL8wdzWlE3iNiaVdUfg=.dc4c5bb9-798a-45df-8992-aa0123313a32@github.com>
 <SJZxG9A2RhRTA_z48kygRbbraCSioxXaJ7OYBl10Xx8=.ff1c31d6-05cb-422f-b5d8-79893b0a0a73@github.com>
 <ixF01yTPcsJviRMf4jgXxAD7WVFC7TKOy32o2sBvJTM=.ed738044-ab11-450b-858b-9f49d1531be4@github.com>
 <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com>
Message-ID: <p_E1mP-krPf59ewUwjWk5D2O-tmc8vmaa2xFVXP5yPk=.52b0a75d-15cc-480d-8253-997c5196b6ad@github.com>

On Tue, 25 May 2021 16:14:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I'd like to note this is a preview feature - we can change the desugaring. At the same time, I don't think this does not work with sub-patterns (those can be easily desugared to guards, I think).

Yes, but in that case the classcheck du to a sub-pattern matching will be either an instanceof or some other invokedynamic.
Having several indy will bloat the code and if we use instanceof, why not using instanceof all along the way.

> Regarding efficiency, it may be a balance between classfile overhead (which will be higher if we need to desugar every guard to a separate method), and the possibility to tweak the matching at runtime.

I fear more the 2 bytes length bytecode limit of a method than the constant pool length limit mostly because people are already using a bunch of lambdas to simulate pattern matching.

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

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

From jjg at openjdk.java.net  Thu May 27 00:27:06 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 27 May 2021 00:27:06 GMT
Subject: RFR: 8267570: The comment of the class JavacParser is not
 appropriate [v2]
In-Reply-To: <Dw7NN_PC6osyMhm1P9ShfRqPwei2CRcrjMoJmLWANOY=.06306041-8385-4802-a798-596e32fa23c3@github.com>
References: <XTjbZ1Gdsc3otEJij23ED9Qrxq7BUIoP-IxIEQ48EDw=.c0981b19-aa02-417b-aa0b-40ce684c28be@github.com>
 <Dw7NN_PC6osyMhm1P9ShfRqPwei2CRcrjMoJmLWANOY=.06306041-8385-4802-a798-596e32fa23c3@github.com>
Message-ID: <2AlzM_4ubQpKpsMFNmclQKKsFr48vSf_wGd5mQvjTrA=.a73cf920-ef49-4c2d-b5b3-0218662cc072@github.com>

On Sun, 23 May 2021 08:19:29 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> The following comment of the class JavacParser is not appropriate.
>> 
>> 
>> It operates by recursive descent, with code derived
>> systematically from an LL(1) grammar.
>> 
>> 
>> From the source code, the current javac parser looks like a LL(K) parser instead of LL(1).
>> This patch revises the comment so that developers won't be confused by it.
>> 
>> Thank you 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:
> 
>   Revise comment

Marked as reviewed by jjg (Reviewer).

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

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

From jjg at openjdk.java.net  Thu May 27 00:57:08 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 27 May 2021 00:57:08 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v4]
In-Reply-To: <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
Message-ID: <nK-JkgsGJsG6xco5ks7Rwi7K0UFmvP6R3kDaRfoV_7E=.f7f3a778-be89-48fd-b97c-d438e35314f5@github.com>

On Tue, 11 May 2021 02:41:16 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
>> so that the output of --help-extra is kept clean and concise.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8230623
>  - Update copyright
>  - Merge branch 'master' into JDK-8230623
>  - Remove the content in documentation javac.1
>  - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint

Approved, with some minor suggestions to improve the text in the resource file.

Thanks for hanging in there with this one.

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

> 173:     Warnings to enable or disable, separated by comma.\n\
> 174:     Precede a key by '-' to disable the specified warning.\n\
> 175:     Use option --help-lint to see the supported keys.

Suggest removing the word "option".
This does not affect the CSR.

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

> 294:     Print this help message
> 295: javac.opt.help.lint=\
> 296:     Print the supported keys of option -Xlint

Suggest: `Print the supported keys for -Xlint`
This does not affect the CSR.

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

> 296:     Print the supported keys of option -Xlint
> 297: javac.opt.help.lint.header=\
> 298:     The supported keys of option -Xlint are:

Suggest: `The supported keys for -Xlint are:`
This does not affect the CSR.

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

Marked as reviewed by jjg (Reviewer).

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

From darcy at openjdk.java.net  Thu May 27 01:34:23 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 27 May 2021 01:34:23 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v5]
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <BXE8OdT3ovZB8Gyg_ohpPuDGc94_p9ttPoCGyrlU-xc=.d6c50e64-9428-4a0a-bb7d-6ea1480e2858@github.com>

> 8244146: javac changes for JEP 306

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

 - Merge branch 'master' into 8244146
 - Merge branch 'master' into 8244146
 - Respond to review feedback.
 - Respond to review feedback.
 - Respond to review feedback.
 - Add explicit test for warning strictfp suppression.
 - Appease jcheck and enabled strictfp in ConstFold.
 - Follow Jan's suggestion for diagnostics timing.
 - Alternate attempt to get warning suppression working; direct annotations don't work.
 - Checkpoint with initial lint implementation and passing langtools regression tests.
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/e6302354...5ba408a2

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

Changes: https://git.openjdk.java.net/jdk/pull/3831/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=04
  Stats: 568 lines in 27 files changed: 529 ins; 7 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3831.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3831/head:pull/3831

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

From gli at openjdk.java.net  Thu May 27 07:33:07 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 27 May 2021 07:33:07 GMT
Subject: RFR: 8267570: The comment of the class JavacParser is not
 appropriate [v2]
In-Reply-To: <2AlzM_4ubQpKpsMFNmclQKKsFr48vSf_wGd5mQvjTrA=.a73cf920-ef49-4c2d-b5b3-0218662cc072@github.com>
References: <XTjbZ1Gdsc3otEJij23ED9Qrxq7BUIoP-IxIEQ48EDw=.c0981b19-aa02-417b-aa0b-40ce684c28be@github.com>
 <Dw7NN_PC6osyMhm1P9ShfRqPwei2CRcrjMoJmLWANOY=.06306041-8385-4802-a798-596e32fa23c3@github.com>
 <2AlzM_4ubQpKpsMFNmclQKKsFr48vSf_wGd5mQvjTrA=.a73cf920-ef49-4c2d-b5b3-0218662cc072@github.com>
Message-ID: <gbX0qYmXYWWye6xsmXZGMkt-CjWStFJn8CsP5SyZIWQ=.ccb77e79-9f12-4f07-84da-db338f651311@github.com>

On Thu, 27 May 2021 00:23:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise comment
>
> Marked as reviewed by jjg (Reviewer).

@jonathan-gibbons Thanks for your review. Could I get your help to sponsor this patch?

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

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

From gli at openjdk.java.net  Thu May 27 08:19:24 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 27 May 2021 08:19:24 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v5]
In-Reply-To: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
Message-ID: <IKiYA0UR4qI3IAOOkWCBjJubI47H_czdj4m3TXvPkZM=.88dce7b8-5a9f-4c95-af4c-f57f53abd68d@github.com>

> Hi all,
> 
> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
> so that the output of --help-extra is kept clean and concise.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

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

  Improve the text in the resource file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1758/files
  - new: https://git.openjdk.java.net/jdk/pull/1758/files/fe1ece10..7d35eb6a

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

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

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

From gli at openjdk.java.net  Thu May 27 08:19:29 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 27 May 2021 08:19:29 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v4]
In-Reply-To: <nK-JkgsGJsG6xco5ks7Rwi7K0UFmvP6R3kDaRfoV_7E=.f7f3a778-be89-48fd-b97c-d438e35314f5@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
 <nK-JkgsGJsG6xco5ks7Rwi7K0UFmvP6R3kDaRfoV_7E=.f7f3a778-be89-48fd-b97c-d438e35314f5@github.com>
Message-ID: <_SvxO6-Jwy_6kvOpC_bgyBB4t9L6KzSqMI8gH1savpY=.6e5ff5b3-906e-41cc-9f95-9de1180e5d0b@github.com>

On Thu, 27 May 2021 00:54:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8230623
>>  - Update copyright
>>  - Merge branch 'master' into JDK-8230623
>>  - Remove the content in documentation javac.1
>>  - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint
>
> Approved, with some minor suggestions to improve the text in the resource file.
> 
> Thanks for hanging in there with this one.

@jonathan-gibbons Thanks for your review. I revised the resource file according to your suggestions.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 175:
> 
>> 173:     Warnings to enable or disable, separated by comma.\n\
>> 174:     Precede a key by '-' to disable the specified warning.\n\
>> 175:     Use option --help-lint to see the supported keys.
> 
> Suggest removing the word "option".
> This does not affect the CSR.

Fixed.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 296:
> 
>> 294:     Print this help message
>> 295: javac.opt.help.lint=\
>> 296:     Print the supported keys of option -Xlint
> 
> Suggest: `Print the supported keys for -Xlint`
> This does not affect the CSR.

Fixed.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 298:
> 
>> 296:     Print the supported keys of option -Xlint
>> 297: javac.opt.help.lint.header=\
>> 298:     The supported keys of option -Xlint are:
> 
> Suggest: `The supported keys for -Xlint are:`
> This does not affect the CSR.

Fixed.

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

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

From jlahoda at openjdk.java.net  Thu May 27 09:48:13 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 27 May 2021 09:48:13 GMT
Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should use
 @implSpec
Message-ID: <mgZu4YgaF3hh0nw-YASt5P8yjIbxPC92lnOAVBPXp8Q=.a98a72a9-c915-4c61-8278-e5fbdf11d4b8@github.com>

As noted in:
https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316

Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far.

The CSR is started for review here:
https://bugs.openjdk.java.net/browse/JDK-8267838

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

Depends on: https://git.openjdk.java.net/jdk/pull/3863

Commit messages:
 - 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec

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

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

From amaembo at gmail.com  Thu May 27 10:22:48 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 27 May 2021 17:22:48 +0700
Subject: Class modifiers in Java 16
Message-ID: <CAE+3fjYusNNU0OttRHDqQWq_8xapMNKwDTzyxEEyZVxX1gng6A@mail.gmail.com>

Hello!

I want to clarify my understanding of Java 16 spec and the
corresponding compiler behavior regarding class modifiers (8.1.1)

1. static modifier
Java 15 spec 8.1.1 [1] says:
The modifier static pertains only to member classes (?8.5.1), not to
top level or local or anonymous classes.

Java 16 spec 8.1.1 [2] says:
The modifier static pertains only to member classes and local classes.
However, Java 16 spec 14.3 says:
It is a compile-time error if a local class or interface declaration
has the modifier static (?8.1.1).

Is it my bad understanding of English or there's some contradiction?
To me, 8.1.1 says that now, local classes can be declared as static
while 14.3 says the opposite thing.

2. public/private/protected on members of local/anonymous classes
Consider the following class:
class Test {
  void test() {
    class Local {
      public class X{}
      protected class Y{}
      private class Z{}
    }
    new Object() {
      public class X{}
      protected class Y{}
      private class Z{}
    };
  }
}
It's compilable without errors with javac 16, as well as javac
17-ea+6-358. However, javac 15 displays the following errors:

>"C:\Program Files\Java\jdk-15\bin\javac.exe" Test.java
Test.java:4: error: modifier public not allowed here
      public class X{}
             ^
Test.java:5: error: modifier protected not allowed here
      protected class Y{}
                ^
Test.java:6: error: modifier private not allowed here
      private class Z{}
              ^
Test.java:9: error: modifier public not allowed here
      public class X{}
             ^
Test.java:10: error: modifier protected not allowed here
      protected class Y{}
                ^
Test.java:11: error: modifier private not allowed here
      private class Z{}
              ^
6 errors

Is it the expected behavior change, a regression, or a fix of a
previously existing bug? I see the following change in spec [1], [2],
regarding private and protected:
Java 15: The access modifiers protected and private pertain only to
member classes within a directly enclosing class declaration
Java 16: The access modifiers protected and private pertain only to
member classes.

I'm not sure I understand how deletion of "within a directly enclosing
class declaration" changes the meaning. I think that member classes
are always within a directly enclosing class declaration. I also see
no spec changes about "public" modifier behavior. To me, it looks like
the behavior in Java 15 and older was incorrect and it was fixed in
Java 16. But probably I'm missing something?

Thank you in advance,
With best regards,
Tagir Valeev.

[1] https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-ClassModifier
[2] https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-ClassModifier
[3] https://docs.oracle.com/javase/specs/jls/se16/html/jls-14.html#jls-14.3

From mcimadamore at openjdk.java.net  Thu May 27 10:45:11 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 27 May 2021 10:45:11 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v5]
In-Reply-To: <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
Message-ID: <GOXtrop_JJ2jUDTPLBSC2CHvirA6JlyaNf1rjMThTdI=.40ff882f-4adb-4482-93a7-136dcf3299d1@github.com>

On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>> 
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac.
>  - Correcting LineNumberTable for rule switches.
>  - Merging master into JDK-8262891
>  - Fixing various error-related bugs.
>  - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default.
>  - Reflecting recent spec changes.
>  - Reflecting review comments.
>  - Reflecting review comments on SwitchBootstraps.
>  - Trailing whitespaces.
>  - Cleanup, reflecting review comments.
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501

Compiler changes look good

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

> 1655: 
> 1656:         try {
> 1657:             boolean enumSwitch = (seltype.tsym.flags() & Flags.ENUM) != 0;

This is getting convoluted enough that an enum on the AST (e.g. SwitchKind) might be helpful to save some of these classification properties - which I imagine we have to redo at some point later (e.g. in Lower/TransPattern). I'm ok with fixing in a followup issue.

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

Marked as reviewed by mcimadamore (Reviewer).

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

From prappo at openjdk.java.net  Thu May 27 11:59:03 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 27 May 2021 11:59:03 GMT
Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should
 use @implSpec
In-Reply-To: <mgZu4YgaF3hh0nw-YASt5P8yjIbxPC92lnOAVBPXp8Q=.a98a72a9-c915-4c61-8278-e5fbdf11d4b8@github.com>
References: <mgZu4YgaF3hh0nw-YASt5P8yjIbxPC92lnOAVBPXp8Q=.a98a72a9-c915-4c61-8278-e5fbdf11d4b8@github.com>
Message-ID: <iAFoB8ll8qlle1uczLdDVY9PXfzFmY-RCYWDG87SJbk=.bc845c61-5905-4aa5-8745-bc009f2183c5@github.com>

On Thu, 27 May 2021 09:41:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As noted in:
> https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316
> 
> Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far.
> 
> The CSR is started for review here:
> https://bugs.openjdk.java.net/browse/JDK-8267838

I wish we had a better class-level (Doc)TreeScanner doc comment. That would allow to avoid most of the repetition in method-level comments, the vast majority of which are there only to say that the children are scanned in left to right order.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 38:

> 36:  * nodes.
> 37:  *
> 38:  * @implSpec

1. Should the error-counting example in the immediately following paragraph belong to this `@implSpec` section?
2. Why is there no similar `@implSpec` section being added to the class-level doc comment of TreeScanner? If such a section is to be added, then should the identifier-counting example in the immediately following paragraph belong to that section?

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

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

From forax at univ-mlv.fr  Thu May 27 13:32:48 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 27 May 2021 15:32:48 +0200 (CEST)
Subject: Class modifiers in Java 16
In-Reply-To: <CAE+3fjYusNNU0OttRHDqQWq_8xapMNKwDTzyxEEyZVxX1gng6A@mail.gmail.com>
References: <CAE+3fjYusNNU0OttRHDqQWq_8xapMNKwDTzyxEEyZVxX1gng6A@mail.gmail.com>
Message-ID: <353152954.793844.1622122368158.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Tagir Valeev" <amaembo at gmail.com>
> ?: "compiler-dev" <compiler-dev at openjdk.java.net>, "amber-dev" <amber-dev at openjdk.java.net>
> Envoy?: Jeudi 27 Mai 2021 12:22:48
> Objet: Class modifiers in Java 16

> Hello!
> 
> I want to clarify my understanding of Java 16 spec and the
> corresponding compiler behavior regarding class modifiers (8.1.1)
> 
> 1. static modifier
> Java 15 spec 8.1.1 [1] says:
> The modifier static pertains only to member classes (?8.5.1), not to
> top level or local or anonymous classes.
> 
> Java 16 spec 8.1.1 [2] says:
> The modifier static pertains only to member classes and local classes.
> However, Java 16 spec 14.3 says:
> It is a compile-time error if a local class or interface declaration
> has the modifier static (?8.1.1).
> 
> Is it my bad understanding of English or there's some contradiction?
> To me, 8.1.1 says that now, local classes can be declared as static
> while 14.3 says the opposite thing.

In JEP 395, under "Static members of inner classes"
"We relax this restriction in order to allow an inner class to declare members that are either explicitly or implicitly static. In particular, this allows an inner class to declare a static member that is a record class."
that why 8.1.1 was modified.

Yes, the sentence in 14.3 seems wrong.

> Thank you in advance,
> With best regards,
> Tagir Valeev.

regards,
R?mi

> 
> [1]
> https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-ClassModifier
> [2]
> https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-ClassModifier
> [3] https://docs.oracle.com/javase/specs/jls/se16/html/jls-14.html#jls-14.3

From brian.goetz at oracle.com  Thu May 27 13:37:11 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 27 May 2021 09:37:11 -0400
Subject: Class modifiers in Java 16
In-Reply-To: <353152954.793844.1622122368158.JavaMail.zimbra@u-pem.fr>
References: <CAE+3fjYusNNU0OttRHDqQWq_8xapMNKwDTzyxEEyZVxX1gng6A@mail.gmail.com>
 <353152954.793844.1622122368158.JavaMail.zimbra@u-pem.fr>
Message-ID: <47D450F0-B71C-435F-BC96-34DFFBB496AB@oracle.com>

I think there?s a bit of preparing for the future here.  There?s the concepts (how static interacts with nesting) which is separate from which exact combinations of those concepts that the language currently supports.  We?re moving towards trying to get rid of the arbitrary nest-x-in-y rules, step 1 was defining the concepts separate from the arbitrary restrictions, but we haven?t lifted the restrictions yet.

> On May 27, 2021, at 9:32 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ----- Mail original -----
>> De: "Tagir Valeev" <amaembo at gmail.com>
>> ?: "compiler-dev" <compiler-dev at openjdk.java.net>, "amber-dev" <amber-dev at openjdk.java.net>
>> Envoy?: Jeudi 27 Mai 2021 12:22:48
>> Objet: Class modifiers in Java 16
> 
>> Hello!
>> 
>> I want to clarify my understanding of Java 16 spec and the
>> corresponding compiler behavior regarding class modifiers (8.1.1)
>> 
>> 1. static modifier
>> Java 15 spec 8.1.1 [1] says:
>> The modifier static pertains only to member classes (?8.5.1), not to
>> top level or local or anonymous classes.
>> 
>> Java 16 spec 8.1.1 [2] says:
>> The modifier static pertains only to member classes and local classes.
>> However, Java 16 spec 14.3 says:
>> It is a compile-time error if a local class or interface declaration
>> has the modifier static (?8.1.1).
>> 
>> Is it my bad understanding of English or there's some contradiction?
>> To me, 8.1.1 says that now, local classes can be declared as static
>> while 14.3 says the opposite thing.
> 
> In JEP 395, under "Static members of inner classes"
> "We relax this restriction in order to allow an inner class to declare members that are either explicitly or implicitly static. In particular, this allows an inner class to declare a static member that is a record class."
> that why 8.1.1 was modified.
> 
> Yes, the sentence in 14.3 seems wrong.
> 
>> Thank you in advance,
>> With best regards,
>> Tagir Valeev.
> 
> regards,
> R?mi
> 
>> 
>> [1]
>> https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-ClassModifier <https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-ClassModifier>
>> [2]
>> https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-ClassModifier <https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-ClassModifier>
>> [3] https://docs.oracle.com/javase/specs/jls/se16/html/jls-14.html#jls-14.3 <https://docs.oracle.com/javase/specs/jls/se16/html/jls-14.html#jls-14.3>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210527/affef59f/attachment-0001.htm>

From gli at openjdk.java.net  Thu May 27 14:09:09 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 27 May 2021 14:09:09 GMT
Subject: Integrated: 8230623: Extract command-line help for -Xlint sub-options
 to new --help-lint
In-Reply-To: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
Message-ID: <nCb7Qr0vyWZkVkVDutqNggqpblkM91YN-hdWd1pNbDY=.035dfe8d-32a5-4370-8bbe-c143e506b0be@github.com>

On Sun, 13 Dec 2020 14:20:45 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
> so that the output of --help-extra is kept clean and concise.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 10a6f5d6
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/10a6f5d637053395839002b6617f94f49d3701e7
Stats:     62 lines in 4 files changed: 32 ins; 22 del; 8 mod

8230623: Extract command-line help for -Xlint sub-options to new --help-lint

Reviewed-by: jjg

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

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

From gli at openjdk.java.net  Thu May 27 14:26:13 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 27 May 2021 14:26:13 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v4]
In-Reply-To: <nK-JkgsGJsG6xco5ks7Rwi7K0UFmvP6R3kDaRfoV_7E=.f7f3a778-be89-48fd-b97c-d438e35314f5@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
 <nK-JkgsGJsG6xco5ks7Rwi7K0UFmvP6R3kDaRfoV_7E=.f7f3a778-be89-48fd-b97c-d438e35314f5@github.com>
Message-ID: <6Gx3YekAU1Ujap6CC-C-OFOSVOQu2XCwxWKIeEubM_Q=.5125b48d-907a-4c5a-8d97-fc730b6150cf@github.com>

On Thu, 27 May 2021 00:54:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8230623
>>  - Update copyright
>>  - Merge branch 'master' into JDK-8230623
>>  - Remove the content in documentation javac.1
>>  - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint
>
> Approved, with some minor suggestions to improve the text in the resource file.
> 
> Thanks for hanging in there with this one.

@jonathan-gibbons The man documentation `javac.1` needs to be revised, too. Could I get your help to revise it? Thanks a lot.

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

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

From vromero at openjdk.java.net  Thu May 27 15:59:03 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 27 May 2021 15:59:03 GMT
Subject: RFR: 8267312: Resolve should use generated diagnostic factories
In-Reply-To: <czQ_YFthMHryr5TSNc4UVOzuECjy9wpcFHxOz1a17DI=.5dd097cc-a3a0-4cc2-8a3c-26ad1bcc9e41@github.com>
References: <VubPi6l8BPTxtaXcluhpZ31T09EuG-dEf4ni15sHYHU=.77ee87e2-1850-4f57-90da-e053634cc61c@github.com>
 <JnF5vksvgWgrbe8kyGI1Nrxa59zv5oA2rlMFshsnvx8=.4424921f-f48a-4c9c-a606-183514deff2a@github.com>
 <czQ_YFthMHryr5TSNc4UVOzuECjy9wpcFHxOz1a17DI=.5dd097cc-a3a0-4cc2-8a3c-26ad1bcc9e41@github.com>
Message-ID: <XqVl1D6MEg9b49SQDwiMT4H1obAHQrcghxrrVR6U4qU=.6c1a01f8-d79f-4ff3-9501-7fdad2c2ce1e@github.com>

On Wed, 26 May 2021 14:09:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Some general comments about the generated code. I wonder if it would make sense to change the implementation of the toType() method which will fold common cases in the switch expression into a default case or generate a case label like: `case Type1, Type2 -> sameAction`.
> 
> I'll think about this - my first reaction is that the current strategy makes templating easier, but perhaps there's another way - e.g. by having a template for a single CASE statement, which can be parameterized on a number of labels.

if templating is easier the way it is in your current proposal, I would keep it that way

> 
> > I wonder if what we really want to model is one factory that can fold both implementations into one. I know this is generated code which should be ready to use, but just thinking aloud, not sure if there are some abstractions that could be useful from the client code perspective. I wonder if we could build on method DiagnosticInfo::of to define one stop factories. But I guess that you already considered this option.
> 
> I guess what you are suggesting is that, instead of having a method for converting a diagnostic info to a different one (like we do now) we should have a method to create a diagnostic info with the right kind from the start.
> 
> This is definitively an option - one of the issues is that the current generated file is divided by kinds (e.g. CompilerProperties has nested classes like Errors, Warnings, Notes) - so if we added such factories, they'd have to live at the top level (e.g. CompilerProperties). If that's acceptable I can do that. To be clear, the proposed structure will end up like this:
> 
> ```
> class CompilerProperties {
>       static class Errors {
>              static DiagnosticInfo ProbFoundReq(...) = ... // like before this patch
>              ...
>        }
>        static class Fragments {
>              static DiagnosticInfo ProbFoundReq(...) = ... // like before this patch
>              ...
>        }
>        
>        // shared factories
>        
>        static DiagnosticInfo ProbFoundReq(DiagnosticType type, args...) {
>            return switch (type) {
>                 case ERROR -> Errors.ProbFoundReq(args);
>                 case MISC -> Fragments.ProbFoundReq(args);
>                 default -> throw new AssertionError();
>             };
>        }
> }
> ```
> 
> This would solve the problem you mention, and also avoid a redundant allocation in Resolve.java.

right I like the shared factories proposal, I think the generated code will be simpler

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

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

From prr at openjdk.java.net  Thu May 27 17:15:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:15:06 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>
Message-ID: <PVcp8pf1_KCxa_lAv-EYuhfoJ2XJ98AJmKrXQ6a_KEw=.4ce5565b-665e-4b2a-a240-3cfc6ef9e28d@github.com>

On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep only one systemProperty tag

Marked as reviewed by prr (Reviewer).

I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138

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

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

From godin at openjdk.java.net  Thu May 27 18:06:20 2021
From: godin at openjdk.java.net (Evgeny Mandrikov)
Date: Thu, 27 May 2021 18:06:20 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v5]
In-Reply-To: <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
Message-ID: <Q1wA_93L8_bQbaAjFOph__nbS-89QQegeDu0pX20uP0=.179bb7cf-a40d-4af1-8de2-268ca0df83df@github.com>

On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>> 
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac.
>  - Correcting LineNumberTable for rule switches.
>  - Merging master into JDK-8262891
>  - Fixing various error-related bugs.
>  - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default.
>  - Reflecting recent spec changes.
>  - Reflecting review comments.
>  - Reflecting review comments on SwitchBootstraps.
>  - Trailing whitespaces.
>  - Cleanup, reflecting review comments.
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501

> I've updated the code to produce better/more useful LineNumberTable for rule switches.

@lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries ?? 

----

However I also noticed that for


class Example {
        void example(String s) {
            switch (s) {
            case "a":
                System.out.println("a");
            }
        }
}


there is difference in frames before and after this PR


javap -v -p Example.class


diff is


         line 3: 0
         line 5: 60
         line 7: 68
-      StackMapTable: number_of_entries = 4
+      StackMapTable: number_of_entries = 5
         frame_type = 253 /* append */
-          offset_delta = 28
+          offset_delta = 4
           locals = [ class java/lang/String, int ]
+        frame_type = 23 /* same */
         frame_type = 10 /* same */
         frame_type = 20 /* same */
         frame_type = 249 /* chop */


and


java -cp asm-util-9.1.jar:asm-9.1.jar org.objectweb.asm.util.Textifier Example.class


diff is


+   L1
+   FRAME APPEND [java/lang/String I]
     ALOAD 2
     INVOKEVIRTUAL java/lang/String.hashCode ()I
     LOOKUPSWITCH
-      97: L1
-      default: L2
-   L1
-   FRAME APPEND [java/lang/String I]
+      97: L2
+      default: L3
+   L2
+   FRAME SAME


Don't know about importance of this, and whether this was expected, but decided to mention.

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

Marked as reviewed by godin (Author).

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

From forax at openjdk.java.net  Thu May 27 18:22:13 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 27 May 2021 18:22:13 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v5]
In-Reply-To: <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
Message-ID: <mrCttQ8gLfYiMI7Tw_NqBLPAz0K5bSWmSyQqtyJ6kjs=.776fad80-b212-48db-b431-1d32c3d012ac@github.com>

On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>> 
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac.
>  - Correcting LineNumberTable for rule switches.
>  - Merging master into JDK-8262891
>  - Fixing various error-related bugs.
>  - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default.
>  - Reflecting recent spec changes.
>  - Reflecting review comments.
>  - Reflecting review comments on SwitchBootstraps.
>  - Trailing whitespaces.
>  - Cleanup, reflecting review comments.
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501

> > I've updated the code to produce better/more useful LineNumberTable for rule switches.
> 
> @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries +1
> 
[...]
> Don't know about importance of this, and whether this was expected, but decided to mention.

Look likes a mistake for me, you only need a StackFrame in front of the call to invokedynamic if it's the target of a goto and in your example, there is no guard so no backward goto.

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

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

From godin at openjdk.java.net  Thu May 27 18:31:09 2021
From: godin at openjdk.java.net (Evgeny Mandrikov)
Date: Thu, 27 May 2021 18:31:09 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v5]
In-Reply-To: <mrCttQ8gLfYiMI7Tw_NqBLPAz0K5bSWmSyQqtyJ6kjs=.776fad80-b212-48db-b431-1d32c3d012ac@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
 <mrCttQ8gLfYiMI7Tw_NqBLPAz0K5bSWmSyQqtyJ6kjs=.776fad80-b212-48db-b431-1d32c3d012ac@github.com>
Message-ID: <oyJOkomrUOACdWPFAK5LPwh9glfhE88a3Mn7PY5cGNU=.1613f2ac-ccec-44e5-94a0-bc7d93afeff4@github.com>

On Thu, 27 May 2021 18:19:38 GMT, R?mi Forax <forax at openjdk.org> wrote:

>  in your example, there is no guard so no backward goto

@forax btw this example is not about switch pattern matching - it is about already existing string switch, where indy not involed ?? 


  void example(java.lang.String);
    descriptor: (Ljava/lang/String;)V
    flags: (0x0000)
    Code:
      stack=2, locals=4, args_size=2
         0: aload_1
         1: astore_2
         2: iconst_m1
         3: istore_3
         4: aload_2
         5: invokevirtual #7                  // Method java/lang/String.hashCode:()I
         8: lookupswitch  { // 1
                      97: 28
                 default: 39
            }
        28: aload_2
        29: ldc           #13                 // String a
        31: invokevirtual #15                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
        34: ifeq          39
        37: iconst_0
        38: istore_3
        39: iload_3
        40: lookupswitch  { // 1
                       0: 60
                 default: 68
            }
        60: getstatic     #19                 // Field java/lang/System.out:Ljava/io/PrintStream;
        63: ldc           #13                 // String a
        65: invokevirtual #25                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        68: return
      LineNumberTable:
        line 3: 0
        line 5: 60
        line 7: 68
      StackMapTable: number_of_entries = 5
        frame_type = 253 /* append */
          offset_delta = 4
          locals = [ class java/lang/String, int ]
        frame_type = 23 /* same */
        frame_type = 10 /* same */
        frame_type = 20 /* same */
        frame_type = 249 /* chop */
          offset_delta = 7

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From forax at univ-mlv.fr  Thu May 27 19:29:28 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 27 May 2021 21:29:28 +0200 (CEST)
Subject: Class modifiers in Java 16
In-Reply-To: <47D450F0-B71C-435F-BC96-34DFFBB496AB@oracle.com>
References: <CAE+3fjYusNNU0OttRHDqQWq_8xapMNKwDTzyxEEyZVxX1gng6A@mail.gmail.com>
 <353152954.793844.1622122368158.JavaMail.zimbra@u-pem.fr>
 <47D450F0-B71C-435F-BC96-34DFFBB496AB@oracle.com>
Message-ID: <2002102919.1523045.1622143768819.JavaMail.zimbra@u-pem.fr>

> De: "Brian Goetz" <brian.goetz at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Tagir Valeev" <amaembo at gmail.com>, "compiler-dev"
> <compiler-dev at openjdk.java.net>, "amber-dev" <amber-dev at openjdk.java.net>
> Envoy?: Jeudi 27 Mai 2021 15:37:11
> Objet: Re: Class modifiers in Java 16

> I think there?s a bit of preparing for the future here. There?s the concepts
> (how static interacts with nesting) which is separate from which exact
> combinations of those concepts that the language currently supports. We?re
> moving towards trying to get rid of the arbitrary nest-x-in-y rules, step 1 was
> defining the concepts separate from the arbitrary restrictions, but we haven?t
> lifted the restrictions yet.
BTW, why annotations are not allowed in any nested context local or not ? 
It's a PITA when writing unit tests, the annotations have always a scope too broad. 

R?mi 

>> On May 27, 2021, at 9:32 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>> ----- Mail original -----

>>> De: "Tagir Valeev" < [ mailto:amaembo at gmail.com | amaembo at gmail.com ] >
>>> ?: "compiler-dev" < [ mailto:compiler-dev at openjdk.java.net |
>>> compiler-dev at openjdk.java.net ] >, "amber-dev" < [
>>> mailto:amber-dev at openjdk.java.net | amber-dev at openjdk.java.net ] >
>>> Envoy?: Jeudi 27 Mai 2021 12:22:48
>>> Objet: Class modifiers in Java 16

>>> Hello!

>>> I want to clarify my understanding of Java 16 spec and the
>>> corresponding compiler behavior regarding class modifiers (8.1.1)

>>> 1. static modifier
>>> Java 15 spec 8.1.1 [1] says:
>>> The modifier static pertains only to member classes (?8.5.1), not to
>>> top level or local or anonymous classes.

>>> Java 16 spec 8.1.1 [2] says:
>>> The modifier static pertains only to member classes and local classes.
>>> However, Java 16 spec 14.3 says:
>>> It is a compile-time error if a local class or interface declaration
>>> has the modifier static (?8.1.1).

>>> Is it my bad understanding of English or there's some contradiction?
>>> To me, 8.1.1 says that now, local classes can be declared as static
>>> while 14.3 says the opposite thing.

>> In JEP 395, under "Static members of inner classes"
>> "We relax this restriction in order to allow an inner class to declare members
>> that are either explicitly or implicitly static. In particular, this allows an
>> inner class to declare a static member that is a record class."
>> that why 8.1.1 was modified.

>> Yes, the sentence in 14.3 seems wrong.

>>> Thank you in advance,
>>> With best regards,
>>> Tagir Valeev.

>> regards,
>> R?mi

>>> [1]
>>> [
>>> https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-ClassModifier
>>> |
>>> https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-ClassModifier
>>> ]
>>> [2]
>>> [
>>> https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-ClassModifier
>>> |
>>> https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-ClassModifier
>>> ]
>>> [3] [ https://docs.oracle.com/javase/specs/jls/se16/html/jls-14.html#jls-14.3 |
>>> https://docs.oracle.com/javase/specs/jls/se16/html/jls-14.html#jls-14.3 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210527/1b4ff6e0/attachment-0001.htm>

From forax at univ-mlv.fr  Thu May 27 19:35:10 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 27 May 2021 21:35:10 +0200 (CEST)
Subject: Class modifiers in Java 16
In-Reply-To: <2002102919.1523045.1622143768819.JavaMail.zimbra@u-pem.fr>
References: <CAE+3fjYusNNU0OttRHDqQWq_8xapMNKwDTzyxEEyZVxX1gng6A@mail.gmail.com>
 <353152954.793844.1622122368158.JavaMail.zimbra@u-pem.fr>
 <47D450F0-B71C-435F-BC96-34DFFBB496AB@oracle.com>
 <2002102919.1523045.1622143768819.JavaMail.zimbra@u-pem.fr>
Message-ID: <1287890296.1523938.1622144110958.JavaMail.zimbra@u-pem.fr>

>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "Tagir Valeev" <amaembo at gmail.com>, "compiler-dev"
>> <compiler-dev at openjdk.java.net>, "amber-dev" <amber-dev at openjdk.java.net>
>> Envoy?: Jeudi 27 Mai 2021 15:37:11
>> Objet: Re: Class modifiers in Java 16

>> I think there?s a bit of preparing for the future here. There?s the concepts
>> (how static interacts with nesting) which is separate from which exact
>> combinations of those concepts that the language currently supports. We?re
>> moving towards trying to get rid of the arbitrary nest-x-in-y rules, step 1 was
>> defining the concepts separate from the arbitrary restrictions, but we haven?t
>> lifted the restrictions yet.
> BTW, why annotations are not allowed in any nested context local or not ?

shelf correcting myself, there are allowed in nested class not nested methods. 

> It's a PITA when writing unit tests, the annotations have always a scope too
> broad.

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210527/72fe70b9/attachment.htm>

From weijun at openjdk.java.net  Thu May 27 20:16:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 27 May 2021 20:16:25 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04
  Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 28 02:01:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:01:19 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>
Message-ID: <hhtFKkkecHjmFc0a4jIaZsr7J9jfbBBCIl2z45lU8Rk=.f90b843b-b655-4106-83ee-dcfd9edfdee2@github.com>

On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From jonathan.gibbons at oracle.com  Fri May 28 03:55:53 2021
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 27 May 2021 20:55:53 -0700
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v4]
In-Reply-To: <6Gx3YekAU1Ujap6CC-C-OFOSVOQu2XCwxWKIeEubM_Q=.5125b48d-907a-4c5a-8d97-fc730b6150cf@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
 <nK-JkgsGJsG6xco5ks7Rwi7K0UFmvP6R3kDaRfoV_7E=.f7f3a778-be89-48fd-b97c-d438e35314f5@github.com>
 <6Gx3YekAU1Ujap6CC-C-OFOSVOQu2XCwxWKIeEubM_Q=.5125b48d-907a-4c5a-8d97-fc730b6150cf@github.com>
Message-ID: <f365db99-3965-dc60-420e-1c5760a8e825@oracle.com>


On 5/27/21 7:26 AM, Guoxiong Li wrote:
> On Thu, 27 May 2021 00:54:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
>
>>> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>>>
>>>   - Merge branch 'master' into JDK-8230623
>>>   - Update copyright
>>>   - Merge branch 'master' into JDK-8230623
>>>   - Remove the content in documentation javac.1
>>>   - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint
>> Approved, with some minor suggestions to improve the text in the resource file.
>>
>> Thanks for hanging in there with this one.
> @jonathan-gibbons The man documentation `javac.1` needs to be revised, too. Could I get your help to revise it? Thanks a lot.


This is already in progress for the upstream source file.? At some point 
there will be bulk update of all the *.1 files that need to be updated 
for 17.

-- Jon


>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1758

From jjg at openjdk.java.net  Fri May 28 04:19:09 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 28 May 2021 04:19:09 GMT
Subject: RFR: JDK-8266877: Missing local debug information when debugging
 JEP-330
In-Reply-To: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
References: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
Message-ID: <jbQkKvuxcmRmIhGLlwW69JZrwS90OqGIPLR2h0o9SHw=.67294d27-35a1-4fa5-a74f-e83937d3de99@github.com>

On Sun, 9 May 2021 15:51:29 GMT, Jaroslav Tulach <github.com+26887752+JaroslavTulach at openjdk.org> wrote:

> I am polishing support for [JEP-330](https://openjdk.java.net/jeps/330) in NetBeans ([PR-2938](https://github.com/apache/netbeans/pull/2938)) and I have problems with debugging. Local variables aren't visible as the compiler doesn't pass `-g` option when compiling the main class. I'd like to see 
> 
> ![obrazek](https://user-images.githubusercontent.com/26887752/117578440-a876e000-b0ee-11eb-85b6-3c998f71879f.png)
> 
> however, that requires one to pass `-g` option to the compiler somehow. As far as I can say there is no such way and hence I decided to create this pull request. If I invoke:
> 
> $ java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y x.java
> 
> it detects JDWP is on and adds `-g` to the compiler arguments. Is this an acceptable improvement? The alternative is to avoid using JEP-330 when debugging and rather generate `.class` by invoking `javac` and then run it as usual, but I'd rather rely on JEP-330 and avoid creation of the `.class` file.

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3939

From github.com+26887752+jaroslavtulach at openjdk.java.net  Fri May 28 04:19:10 2021
From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach)
Date: Fri, 28 May 2021 04:19:10 GMT
Subject: Integrated: JDK-8266877: Missing local debug information when
 debugging JEP-330
In-Reply-To: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
References: <TpPHgUjG3rwDAjLXV4PmeBbq7qLQ8ATRdnjJS0FiPd8=.5f048057-3fdf-4d9d-9c38-53dc7bebff08@github.com>
Message-ID: <gT3GrOLdtxrwvMwr2qI5tRjV4iLRogItxs5ktun9SMY=.3ccd653d-cd17-406c-809c-dc855e9db14f@github.com>

On Sun, 9 May 2021 15:51:29 GMT, Jaroslav Tulach <github.com+26887752+JaroslavTulach at openjdk.org> wrote:

> I am polishing support for [JEP-330](https://openjdk.java.net/jeps/330) in NetBeans ([PR-2938](https://github.com/apache/netbeans/pull/2938)) and I have problems with debugging. Local variables aren't visible as the compiler doesn't pass `-g` option when compiling the main class. I'd like to see 
> 
> ![obrazek](https://user-images.githubusercontent.com/26887752/117578440-a876e000-b0ee-11eb-85b6-3c998f71879f.png)
> 
> however, that requires one to pass `-g` option to the compiler somehow. As far as I can say there is no such way and hence I decided to create this pull request. If I invoke:
> 
> $ java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y x.java
> 
> it detects JDWP is on and adds `-g` to the compiler arguments. Is this an acceptable improvement? The alternative is to avoid using JEP-330 when debugging and rather generate `.class` by invoking `javac` and then run it as usual, but I'd rather rely on JEP-330 and avoid creation of the `.class` file.

This pull request has now been integrated.

Changeset: 6eb91145
Author:    Jaroslav Tulach <jaroslav.tulach at oracle.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6eb91145823275248d049f8557462f09270c0b36
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8266877: Missing local debug information when debugging JEP-330

Reviewed-by: alanb, jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/3939

From lgxbslgx at gmail.com  Fri May 28 10:12:03 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Fri, 28 May 2021 18:12:03 +0800
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v4]
In-Reply-To: <f365db99-3965-dc60-420e-1c5760a8e825@oracle.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <ZSKSrkDm5EKEfDEiclMUyc4iFktmJCGKTgRaV96GutQ=.b0d752b7-02b7-4003-957f-c8841caf6bc5@github.com>
 <nK-JkgsGJsG6xco5ks7Rwi7K0UFmvP6R3kDaRfoV_7E=.f7f3a778-be89-48fd-b97c-d438e35314f5@github.com>
 <6Gx3YekAU1Ujap6CC-C-OFOSVOQu2XCwxWKIeEubM_Q=.5125b48d-907a-4c5a-8d97-fc730b6150cf@github.com>
 <f365db99-3965-dc60-420e-1c5760a8e825@oracle.com>
Message-ID: <CAPSsVqghYcHx9BETepyrU9GcPgL8kBVXMRWppS6PCwDw5jmLBA@mail.gmail.com>

Got it. Thanks.

Best Regards,
-- Guoxiong

On Fri, May 28, 2021 at 11:56 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
> On 5/27/21 7:26 AM, Guoxiong Li wrote:
> > On Thu, 27 May 2021 00:54:25 GMT, Jonathan Gibbons <jjg at openjdk.org>
> wrote:
> >
> >>> Guoxiong Li has updated the pull request with a new target base due to
> a merge or a rebase. The pull request now contains five commits:
> >>>
> >>>   - Merge branch 'master' into JDK-8230623
> >>>   - Update copyright
> >>>   - Merge branch 'master' into JDK-8230623
> >>>   - Remove the content in documentation javac.1
> >>>   - 8230623: Extract command-line help for -Xlint sub-options to new
> --help-lint
> >> Approved, with some minor suggestions to improve the text in the
> resource file.
> >>
> >> Thanks for hanging in there with this one.
> > @jonathan-gibbons The man documentation `javac.1` needs to be revised,
> too. Could I get your help to revise it? Thanks a lot.
>
>
> This is already in progress for the upstream source file.  At some point
> there will be bulk update of all the *.1 files that need to be updated
> for 17.
>
> -- Jon
>
>
> >
> > -------------
> >
> > PR: https://git.openjdk.java.net/jdk/pull/1758
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210528/8def2faa/attachment.htm>

From jlahoda at openjdk.java.net  Fri May 28 11:08:42 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 28 May 2021 11:08:42 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v6]
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <9siiRgAecypi4U4cS7zXk2MwDk3EsPZwvUtEMaGTJz8=.ed45bb06-c5d8-4efd-a35a-7e8a566858dd@github.com>

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Avoiding unnecessary StackMap point.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3863/files
  - new: https://git.openjdk.java.net/jdk/pull/3863/files/fd748501..a57d306b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=04-05

  Stats: 76 lines in 2 files changed: 72 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863

PR: https://git.openjdk.java.net/jdk/pull/3863

From jlahoda at openjdk.java.net  Fri May 28 11:08:43 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 28 May 2021 11:08:43 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v5]
In-Reply-To: <oyJOkomrUOACdWPFAK5LPwh9glfhE88a3Mn7PY5cGNU=.1613f2ac-ccec-44e5-94a0-bc7d93afeff4@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
 <mrCttQ8gLfYiMI7Tw_NqBLPAz0K5bSWmSyQqtyJ6kjs=.776fad80-b212-48db-b431-1d32c3d012ac@github.com>
 <oyJOkomrUOACdWPFAK5LPwh9glfhE88a3Mn7PY5cGNU=.1613f2ac-ccec-44e5-94a0-bc7d93afeff4@github.com>
Message-ID: <xW-iZp0I49VM8c8XD4bI-bixO_JdI8Z6K5g8GOwz5qg=.ec6d56ee-401d-4163-921d-abc31a065a2a@github.com>

On Thu, 27 May 2021 18:28:13 GMT, Evgeny Mandrikov <godin at openjdk.org> wrote:

>>> > I've updated the code to produce better/more useful LineNumberTable for rule switches.
>>> 
>>> @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries +1
>>> 
>> [...]
>>> Don't know about importance of this, and whether this was expected, but decided to mention.
>> 
>> Look likes a mistake for me, you only need a StackFrame in front of the call to invokedynamic if it's the target of a goto and in your example, there is no guard so no backward goto.
>
>>  in your example, there is no guard so no backward goto
> 
> @forax btw this example is not about switch pattern matching - it is about already existing string switch, where indy not involed ?? 
> 
> 
>   void example(java.lang.String);
>     descriptor: (Ljava/lang/String;)V
>     flags: (0x0000)
>     Code:
>       stack=2, locals=4, args_size=2
>          0: aload_1
>          1: astore_2
>          2: iconst_m1
>          3: istore_3
>          4: aload_2
>          5: invokevirtual #7                  // Method java/lang/String.hashCode:()I
>          8: lookupswitch  { // 1
>                       97: 28
>                  default: 39
>             }
>         28: aload_2
>         29: ldc           #13                 // String a
>         31: invokevirtual #15                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
>         34: ifeq          39
>         37: iconst_0
>         38: istore_3
>         39: iload_3
>         40: lookupswitch  { // 1
>                        0: 60
>                  default: 68
>             }
>         60: getstatic     #19                 // Field java/lang/System.out:Ljava/io/PrintStream;
>         63: ldc           #13                 // String a
>         65: invokevirtual #25                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
>         68: return
>       LineNumberTable:
>         line 3: 0
>         line 5: 60
>         line 7: 68
>       StackMapTable: number_of_entries = 5
>         frame_type = 253 /* append */
>           offset_delta = 4
>           locals = [ class java/lang/String, int ]
>         frame_type = 23 /* same */
>         frame_type = 10 /* same */
>         frame_type = 20 /* same */
>         frame_type = 249 /* chop */
>           offset_delta = 7

@Godin thanks for noticing the unnecessary point in the StackMap! I've limited the entry to only be present for pattern matching switches, so ordinary switches should now look as before. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From jlahoda at openjdk.java.net  Fri May 28 11:36:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 28 May 2021 11:36:10 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v5]
In-Reply-To: <GOXtrop_JJ2jUDTPLBSC2CHvirA6JlyaNf1rjMThTdI=.40ff882f-4adb-4482-93a7-136dcf3299d1@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
 <KCxNdLyaC-9w0_EuqPDuUOmIwiV-0hFM3rDlJGrfJmg=.3ec768ff-66f9-4ed4-b776-2f44f9004633@github.com>
 <GOXtrop_JJ2jUDTPLBSC2CHvirA6JlyaNf1rjMThTdI=.40ff882f-4adb-4482-93a7-136dcf3299d1@github.com>
Message-ID: <NWBipJ0e9PgKX5YW66xMe8xcQQEFtIhwodKsQ42sw2E=.639e7ac2-a363-4329-8f41-fbb5dee668d7@github.com>

On Thu, 27 May 2021 10:38:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac.
>>  - Correcting LineNumberTable for rule switches.
>>  - Merging master into JDK-8262891
>>  - Fixing various error-related bugs.
>>  - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default.
>>  - Reflecting recent spec changes.
>>  - Reflecting review comments.
>>  - Reflecting review comments on SwitchBootstraps.
>>  - Trailing whitespaces.
>>  - Cleanup, reflecting review comments.
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1657:
> 
>> 1655: 
>> 1656:         try {
>> 1657:             boolean enumSwitch = (seltype.tsym.flags() & Flags.ENUM) != 0;
> 
> This is getting convoluted enough that an enum on the AST (e.g. SwitchKind) might be helpful to save some of these classification properties - which I imagine we have to redo at some point later (e.g. in Lower/TransPattern). I'm ok with fixing in a followup issue.

Thanks Maurizio. Yes, some of the logic is partly repeated elsewhere, but I need to investigate how to improve that. I've filled:
https://bugs.openjdk.java.net/browse/JDK-8267929

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From gli at openjdk.java.net  Fri May 28 12:36:27 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 28 May 2021 12:36:27 GMT
Subject: RFR: 8266239: Some duplicated javac command-line options have
 repeated effect
Message-ID: <UJabUDvvY1kArtsHt37QwftXns9v2rtOFCIw4TCIxuE=.42a6643e-5385-42ed-b4f7-f91e8880a914@github.com>

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

-------------

Commit messages:
 - 8266239: Some duplicated javac command-line options have repeated effect

Changes: https://git.openjdk.java.net/jdk/pull/4244/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4244&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266239
  Stats: 41 lines in 3 files changed: 39 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4244.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4244/head:pull/4244

PR: https://git.openjdk.java.net/jdk/pull/4244

From jlahoda at openjdk.java.net  Fri May 28 19:07:18 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 28 May 2021 19:07:18 GMT
Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should
 use @implSpec [v2]
In-Reply-To: <iAFoB8ll8qlle1uczLdDVY9PXfzFmY-RCYWDG87SJbk=.bc845c61-5905-4aa5-8745-bc009f2183c5@github.com>
References: <mgZu4YgaF3hh0nw-YASt5P8yjIbxPC92lnOAVBPXp8Q=.a98a72a9-c915-4c61-8278-e5fbdf11d4b8@github.com>
 <iAFoB8ll8qlle1uczLdDVY9PXfzFmY-RCYWDG87SJbk=.bc845c61-5905-4aa5-8745-bc009f2183c5@github.com>
Message-ID: <OWDk9mHGELHq6YfaxRg_MSg4diRi-Rgui9muvsatuuI=.704d0ac9-e46b-47f8-a8c3-d1f263594c87@github.com>

On Thu, 27 May 2021 11:26:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reordering @implSpec and example as suggested.
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 38:
> 
>> 36:  * nodes.
>> 37:  *
>> 38:  * @implSpec
> 
> 1. Should the error-counting example in the immediately following paragraph belong to this `@implSpec` section?
> 2. Why is there no similar `@implSpec` section being added to the class-level doc comment of TreeScanner? If such a section is to be added, then should the identifier-counting example in the immediately following paragraph belong to that section?

Thanks for the comment, Pavel. I've tried to do the changes in an update:
https://github.com/openjdk/jdk/pull/4223/commits/5c9f694fade7380fa1a7ae667cf4acd5be60c244

-------------

PR: https://git.openjdk.java.net/jdk/pull/4223

From jlahoda at openjdk.java.net  Fri May 28 19:07:17 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 28 May 2021 19:07:17 GMT
Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should
 use @implSpec [v2]
In-Reply-To: <mgZu4YgaF3hh0nw-YASt5P8yjIbxPC92lnOAVBPXp8Q=.a98a72a9-c915-4c61-8278-e5fbdf11d4b8@github.com>
References: <mgZu4YgaF3hh0nw-YASt5P8yjIbxPC92lnOAVBPXp8Q=.a98a72a9-c915-4c61-8278-e5fbdf11d4b8@github.com>
Message-ID: <OHATZh_uXmAFTwllloHl8ZAX8vdO41-Kj_G2qqem69U=.41b095fb-2cd9-49dc-8c8c-36002a6f3606@github.com>

> As noted in:
> https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316
> 
> Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far.
> 
> The CSR is started for review here:
> https://bugs.openjdk.java.net/browse/JDK-8267838

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reordering @implSpec and example as suggested.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4223/files
  - new: https://git.openjdk.java.net/jdk/pull/4223/files/d27a84a0..5c9f694f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4223&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4223&range=00-01

  Stats: 57 lines in 2 files changed: 29 ins; 28 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4223.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4223/head:pull/4223

PR: https://git.openjdk.java.net/jdk/pull/4223

From darcy at openjdk.java.net  Fri May 28 21:17:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 28 May 2021 21:17:18 GMT
Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should
 use @implSpec [v2]
In-Reply-To: <OHATZh_uXmAFTwllloHl8ZAX8vdO41-Kj_G2qqem69U=.41b095fb-2cd9-49dc-8c8c-36002a6f3606@github.com>
References: <mgZu4YgaF3hh0nw-YASt5P8yjIbxPC92lnOAVBPXp8Q=.a98a72a9-c915-4c61-8278-e5fbdf11d4b8@github.com>
 <OHATZh_uXmAFTwllloHl8ZAX8vdO41-Kj_G2qqem69U=.41b095fb-2cd9-49dc-8c8c-36002a6f3606@github.com>
Message-ID: <abypv9TkOqOhO56-TEnoRv0PkUJHJHTxfVNw6faOcIk=.2ceb1f4d-3625-4145-8669-1ff67e0e17ae@github.com>

On Fri, 28 May 2021 19:07:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> As noted in:
>> https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316
>> 
>> Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far.
>> 
>> The CSR is started for review here:
>> https://bugs.openjdk.java.net/browse/JDK-8267838
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reordering @implSpec and example as suggested.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4223

From prappo at openjdk.java.net  Fri May 28 21:37:17 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 28 May 2021 21:37:17 GMT
Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should
 use @implSpec [v2]
In-Reply-To: <OHATZh_uXmAFTwllloHl8ZAX8vdO41-Kj_G2qqem69U=.41b095fb-2cd9-49dc-8c8c-36002a6f3606@github.com>
References: <mgZu4YgaF3hh0nw-YASt5P8yjIbxPC92lnOAVBPXp8Q=.a98a72a9-c915-4c61-8278-e5fbdf11d4b8@github.com>
 <OHATZh_uXmAFTwllloHl8ZAX8vdO41-Kj_G2qqem69U=.41b095fb-2cd9-49dc-8c8c-36002a6f3606@github.com>
Message-ID: <atQJ5-uU470x3HGBFh__t-kmx9KB9SwE5-xsAyXRaW0=.aecbc4cd-d917-4e9b-92d5-d8b76bbf40a8@github.com>

On Fri, 28 May 2021 19:07:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> As noted in:
>> https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316
>> 
>> Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far.
>> 
>> The CSR is started for review here:
>> https://bugs.openjdk.java.net/browse/JDK-8267838
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reordering @implSpec and example as suggested.

Marked as reviewed by prappo (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4223

From darcy at openjdk.java.net  Sat May 29 19:03:38 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 29 May 2021 19:03:38 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v6]
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <pDWjMPpk5ORBMMY5vLnl9Zo8yoJMjRqu0UqdY61ByZE=.310801cb-ab21-4ded-8dcc-85b79358b03e@github.com>

> 8244146: javac changes for JEP 306

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Update GenericStringTest
 - Merge branch 'master' into 8244146
 - Merge branch 'master' into 8244146
 - Merge branch 'master' into 8244146
 - Respond to review feedback.
 - Respond to review feedback.
 - Respond to review feedback.
 - Add explicit test for warning strictfp suppression.
 - Appease jcheck and enabled strictfp in ConstFold.
 - Follow Jan's suggestion for diagnostics timing.
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/66274320...7fe6d5aa

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3831/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=05
  Stats: 571 lines in 28 files changed: 529 ins; 7 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3831.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3831/head:pull/3831

PR: https://git.openjdk.java.net/jdk/pull/3831

From amaembo at gmail.com  Sun May 30 04:48:13 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 30 May 2021 11:48:13 +0700
Subject: Class modifiers in Java 16
In-Reply-To: <47D450F0-B71C-435F-BC96-34DFFBB496AB@oracle.com>
References: <CAE+3fjYusNNU0OttRHDqQWq_8xapMNKwDTzyxEEyZVxX1gng6A@mail.gmail.com>
 <353152954.793844.1622122368158.JavaMail.zimbra@u-pem.fr>
 <47D450F0-B71C-435F-BC96-34DFFBB496AB@oracle.com>
Message-ID: <CAE+3fjY18URnUHpYgin_UCjF_U=zydRjb3HgFbcJEvpPX1oNbw@mail.gmail.com>

Thank you for the answers. Judging from the javac behavior, 'static'
modifier on local classes is still not allowed, so the sentence 8.1.1
is wrong, as for Java 16.

What about my second question, access modifiers? Is this intended
change to allow them inside local/anonymous classes?

With best regards,
Tagir Valeev.

On Thu, May 27, 2021 at 8:37 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> I think there?s a bit of preparing for the future here.  There?s the concepts (how static interacts with nesting) which is separate from which exact combinations of those concepts that the language currently supports.  We?re moving towards trying to get rid of the arbitrary nest-x-in-y rules, step 1 was defining the concepts separate from the arbitrary restrictions, but we haven?t lifted the restrictions yet.
>
> On May 27, 2021, at 9:32 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>
> ----- Mail original -----
>
> De: "Tagir Valeev" <amaembo at gmail.com>
> ?: "compiler-dev" <compiler-dev at openjdk.java.net>, "amber-dev" <amber-dev at openjdk.java.net>
> Envoy?: Jeudi 27 Mai 2021 12:22:48
> Objet: Class modifiers in Java 16
>
>
> Hello!
>
> I want to clarify my understanding of Java 16 spec and the
> corresponding compiler behavior regarding class modifiers (8.1.1)
>
> 1. static modifier
> Java 15 spec 8.1.1 [1] says:
> The modifier static pertains only to member classes (?8.5.1), not to
> top level or local or anonymous classes.
>
> Java 16 spec 8.1.1 [2] says:
> The modifier static pertains only to member classes and local classes.
> However, Java 16 spec 14.3 says:
> It is a compile-time error if a local class or interface declaration
> has the modifier static (?8.1.1).
>
> Is it my bad understanding of English or there's some contradiction?
> To me, 8.1.1 says that now, local classes can be declared as static
> while 14.3 says the opposite thing.
>
>
> In JEP 395, under "Static members of inner classes"
> "We relax this restriction in order to allow an inner class to declare members that are either explicitly or implicitly static. In particular, this allows an inner class to declare a static member that is a record class."
> that why 8.1.1 was modified.
>
> Yes, the sentence in 14.3 seems wrong.
>
> Thank you in advance,
> With best regards,
> Tagir Valeev.
>
>
> regards,
> R?mi
>
>
> [1]
> https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-ClassModifier
> [2]
> https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-ClassModifier
> [3] https://docs.oracle.com/javase/specs/jls/se16/html/jls-14.html#jls-14.3
>
>

From lgxbslgx at gmail.com  Sun May 30 13:48:27 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Sun, 30 May 2021 21:48:27 +0800
Subject: A potential enhancement about switch at JavacParser
Message-ID: <CAPSsVqik0Tj7sb+xrHAKZzPYQdE-t9r4YeGGQLz62rREoEpVjA@mail.gmail.com>

Hi all,

Currently, we have the switch statement and switch expression.
They have some different points. For example, the `yield` only can
be enclosed in the switch expression. But in general, they may be
the same in many situations, especially only considering their
syntactic struct.

Please see the following productions excerpted from the JLS.



*SwitchStatement:     switch ( Expression ) SwitchBlock*


*SwitchExpression:      switch ( Expression ) SwitchBlock*

They use the same `SwitchBlock` to construct the AST. But currently,
the parser uses different methods to construct them.

1. The class `JavacParser` uses methods `switchExpressionStatementGroup`
and `switchBlockStatementGroup` to separately construct the `case` subtree
of the switch expression and the switch statement.

2. And  the `case SWITCH` clause of the method `term3` (where the switch
expression is implemented)
and  the method `switchBlockStatementGroups` has the similar code snippet
to construct the switch body.

Maybe the methods of the two aspects above can be merged to clean up the
code
and reduce the complication of the parser.

And the codes mentioned above have other places that need to be adjusted.
For example, the return type of the method `switchExpressionStatementGroup`
and
`switchBlockStatementGroup` could be the `JCCase` instead of the
`List<JCCase>`.

What do you think about this enhancement?
Could someone who implemented the switch expression provide more
information on why the different methods were used?
Any ideas are appreciated.

And considering that the `Pattern matching for switch` may revise these
codes
and the Rampdown Phase One is coming soon, if we confirm this enhancement
is feasible, it is best to complete it at JDK 18 so that the feature of the
`Pattern matching for switch` won't be affected.

Best Regards,
-- Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210530/0491e435/attachment.htm>

From forax at univ-mlv.fr  Mon May 31 12:13:30 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 31 May 2021 14:13:30 +0200 (CEST)
Subject: Class modifiers in Java 16
In-Reply-To: <CAE+3fjY18URnUHpYgin_UCjF_U=zydRjb3HgFbcJEvpPX1oNbw@mail.gmail.com>
References: <CAE+3fjYusNNU0OttRHDqQWq_8xapMNKwDTzyxEEyZVxX1gng6A@mail.gmail.com>
 <353152954.793844.1622122368158.JavaMail.zimbra@u-pem.fr>
 <47D450F0-B71C-435F-BC96-34DFFBB496AB@oracle.com>
 <CAE+3fjY18URnUHpYgin_UCjF_U=zydRjb3HgFbcJEvpPX1oNbw@mail.gmail.com>
Message-ID: <1505846013.357835.1622463210288.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Tagir Valeev" <amaembo at gmail.com>
> ?: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "compiler-dev" <compiler-dev at openjdk.java.net>, "amber-dev"
> <amber-dev at openjdk.java.net>
> Envoy?: Dimanche 30 Mai 2021 06:48:13
> Objet: Re: Class modifiers in Java 16

> Thank you for the answers. Judging from the javac behavior, 'static'
> modifier on local classes is still not allowed, so the sentence 8.1.1
> is wrong, as for Java 16.

yes, using static explicitly is not yet allowed.
Enums, records and interfaces which are implicitly static are all allowed.
And as i said earlier, for a reason ?, annotations are not allowed despite being implicitly static.

> 
> What about my second question, access modifiers? Is this intended
> change to allow them inside local/anonymous classes?

Local classes/anonymous classes should not have access modifiers, they are scoped inside the method they are defined, so no modifier is needed.

> 
> With best regards,
> Tagir Valeev.

regards,
R?mi

> 
> On Thu, May 27, 2021 at 8:37 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> I think there?s a bit of preparing for the future here.  There?s the concepts
>> (how static interacts with nesting) which is separate from which exact
>> combinations of those concepts that the language currently supports.  We?re
>> moving towards trying to get rid of the arbitrary nest-x-in-y rules, step 1 was
>> defining the concepts separate from the arbitrary restrictions, but we haven?t
>> lifted the restrictions yet.
>>
>> On May 27, 2021, at 9:32 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> ----- Mail original -----
>>
>> De: "Tagir Valeev" <amaembo at gmail.com>
>> ?: "compiler-dev" <compiler-dev at openjdk.java.net>, "amber-dev"
>> <amber-dev at openjdk.java.net>
>> Envoy?: Jeudi 27 Mai 2021 12:22:48
>> Objet: Class modifiers in Java 16
>>
>>
>> Hello!
>>
>> I want to clarify my understanding of Java 16 spec and the
>> corresponding compiler behavior regarding class modifiers (8.1.1)
>>
>> 1. static modifier
>> Java 15 spec 8.1.1 [1] says:
>> The modifier static pertains only to member classes (?8.5.1), not to
>> top level or local or anonymous classes.
>>
>> Java 16 spec 8.1.1 [2] says:
>> The modifier static pertains only to member classes and local classes.
>> However, Java 16 spec 14.3 says:
>> It is a compile-time error if a local class or interface declaration
>> has the modifier static (?8.1.1).
>>
>> Is it my bad understanding of English or there's some contradiction?
>> To me, 8.1.1 says that now, local classes can be declared as static
>> while 14.3 says the opposite thing.
>>
>>
>> In JEP 395, under "Static members of inner classes"
>> "We relax this restriction in order to allow an inner class to declare members
>> that are either explicitly or implicitly static. In particular, this allows an
>> inner class to declare a static member that is a record class."
>> that why 8.1.1 was modified.
>>
>> Yes, the sentence in 14.3 seems wrong.
>>
>> Thank you in advance,
>> With best regards,
>> Tagir Valeev.
>>
>>
>> regards,
>> R?mi
>>
>>
>> [1]
>> https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-ClassModifier
>> [2]
>> https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-ClassModifier
>> [3] https://docs.oracle.com/javase/specs/jls/se16/html/jls-14.html#jls-14.3
>>

From jlahoda at openjdk.java.net  Mon May 31 13:49:56 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 31 May 2021 13:49:56 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v7]
In-Reply-To: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
References: <thh-9O4EHk71jKq3SdcwY22vQ6eLkFdjawp5OEqwekY=.3d0aca34-10c9-464a-8b91-a12119124525@github.com>
Message-ID: <pFQeZUteOYqz-hvmdjA-4dTehMQZLbOpRx1m7GCfwYw=.7097369a-f1ba-4499-bc20-e18677aabe4d@github.com>

> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
> 
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Fixing tests.
 - Total pattern dominates the null pattern.
 - Properly report errors for pattern+default clash.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3863/files
  - new: https://git.openjdk.java.net/jdk/pull/3863/files/a57d306b..a49b6109

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=05-06

  Stats: 52 lines in 6 files changed: 45 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863

PR: https://git.openjdk.java.net/jdk/pull/3863

From weijun at openjdk.java.net  Mon May 31 15:02:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:02:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  default behavior reverted to allow

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04-05

  Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 31 15:09:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:09:27 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <TdTmyQQ8Wnh6Ko6yk3xYGN-eN8CCaUiw_W6bh9WbOTc=.8388e5dc-6cf8-4215-be1e-4b98eadb6d4c@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From lancea at openjdk.java.net  Mon May 31 16:24:24 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 31 May 2021 16:24:24 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From darcy at openjdk.java.net  Mon May 31 21:46:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 31 May 2021 21:46:37 GMT
Subject: RFR: 8244146: javac changes for JEP 306 [v7]
In-Reply-To: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
References: <iFKQPVSOd9C2wKEtLcrIfDMDNuUdKX3JhZHPqh5IQIE=.a632734a-d639-4016-96d6-e50141ace2f0@github.com>
Message-ID: <FBQdlpg4kGJROFZikcyazD5QHuOiu1q9Ml0mIfqpCIc=.bb2eef89-535c-456c-b4cc-84480c18b913@github.com>

> 8244146: javac changes for JEP 306

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into 8244146
 - Update GenericStringTest
 - Merge branch 'master' into 8244146
 - Merge branch 'master' into 8244146
 - Merge branch 'master' into 8244146
 - Respond to review feedback.
 - Respond to review feedback.
 - Respond to review feedback.
 - Add explicit test for warning strictfp suppression.
 - Appease jcheck and enabled strictfp in ConstFold.
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/c06db45f...0c5417b8

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3831/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=06
  Stats: 571 lines in 28 files changed: 529 ins; 7 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3831.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3831/head:pull/3831

PR: https://git.openjdk.java.net/jdk/pull/3831