From shade at openjdk.java.net  Thu Apr  1 06:56:22 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 1 Apr 2021 06:56:22 GMT
Subject: RFR: 8264331: Use the blessed modifier order in jdk.compiler
In-Reply-To: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
References: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
Message-ID: <N579R7_gAjpYW_vj6dd6pWjMF4YZ6vm08ZPlKY53E_s=.c0ad5b0e-ad9c-45df-a99f-ea6cbae65ac7@github.com>

On Sun, 28 Mar 2021 13:55:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264331: Use the blessed modifier order in jdk.compiler

Marked as reviewed by shade (Reviewer).

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

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

From github.com+76791+alblue at openjdk.java.net  Thu Apr  1 06:56:23 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 1 Apr 2021 06:56:23 GMT
Subject: Integrated: 8264331: Use the blessed modifier order in jdk.compiler
In-Reply-To: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
References: <EDJdI4MRZtGY1p2bcG6v6m-j_KewSBJV7JHRIaAhhJ4=.6f0a7b4e-7e26-43e8-903b-4d4986aad152@github.com>
Message-ID: <Yr8_PzhGCtZjENwcBUuAF4PzTjDcAuIh9FNQhWaXTQ4=.8cfb39b5-3120-4409-aed7-f9a8d31cd6af@github.com>

On Sun, 28 Mar 2021 13:55:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264331: Use the blessed modifier order in jdk.compiler

This pull request has now been integrated.

Changeset: d2df9a7d
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d2df9a7d
Stats:     108 lines in 34 files changed: 0 ins; 0 del; 108 mod

8264331: Use the blessed modifier order in jdk.compiler

Reviewed-by: vromero, iris, shade

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

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

From jlahoda at openjdk.java.net  Thu Apr  1 11:42:36 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 1 Apr 2021 11:42:36 GMT
Subject: Integrated: 8264306: Non deterministic generation of
 java/lang/invoke/MemberName.class
In-Reply-To: <UydoIlgIn3ktldbgbS8eJgE5jK_4dqSMJWY2AsdXwf0=.8ee46224-d981-478a-bccb-319446f65c83@github.com>
References: <UydoIlgIn3ktldbgbS8eJgE5jK_4dqSMJWY2AsdXwf0=.8ee46224-d981-478a-bccb-319446f65c83@github.com>
Message-ID: <RsMsjkINOnRVddM59x6DYCuIm4Zil1YF85nmuxgpOio=.5f4c8d4b-a5da-4113-8c9e-7591cdff6e33@github.com>

On Tue, 30 Mar 2021 06:19:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When hoisting binding variables to the outer scope, we should use `LinkedHashMap` instead of `HashMap`, so that `javac` produces reproducible classfiles.

This pull request has now been integrated.

Changeset: fdfa1dda
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fdfa1dda
Stats:     121 lines in 2 files changed: 119 ins; 1 del; 1 mod

8264306: Non deterministic generation of java/lang/invoke/MemberName.class

Reviewed-by: shade, jfranck

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

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

From jpai at openjdk.java.net  Thu Apr  1 15:02:58 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 1 Apr 2021 15:02:58 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v3]
In-Reply-To: <UX_PIU0pgWPZnI_jsSBiE6w-D5KD0PQGSOORZKtRzQY=.d126b8fc-0658-4adc-b6cc-bb57e9d054ca@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
 <UX_PIU0pgWPZnI_jsSBiE6w-D5KD0PQGSOORZKtRzQY=.d126b8fc-0658-4adc-b6cc-bb57e9d054ca@github.com>
Message-ID: <51etfLTxZoIdvAf8SqESmwl5LhivbcOqx46tzCig6ps=.6f2a87ff-892e-426f-a02b-ea62489ffe5b@github.com>

On Wed, 31 Mar 2021 17:22:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Alan's review feedback for -C help text
>>  - Keep -xfP backward compatible but don't allow -C/--dir with -xfP
>
> Some additional comments basically suggesting that we test --extract in addition to -x

Thank you for the reviews, Lance. The latest version of this PR has taken into account most of these comments. There's one review comment which hasn't resulted in a change and I've added a reply to that review comment explaining my thoughts.

> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1427:
> 
>> 1425:             return rc;    // leading '/' or 'dot-dot' only path
>> 1426:         }
>> 1427:         File f = new File(xdestDir, name.replace('/', File.separatorChar));
> 
> Could you please add a comment regarding xdestDir and also correct the typo on line 1418 'requres' -> 'requires'

Fixed the typo and also added code comment about the `xdestDir` usage and semantics. If the new comment needs clarification/changes, do let me know.

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 62:
> 
>> 60:         Could not create a temporary file
>> 61: error.extract.multiple.dest.dir=\
>> 62:         You may not specify more than one directory for extracting the jar
> 
> Perhaps something similar to:
> 
> You may not specify  the  '-C' or '--dir' option more than once with the '-x' option

Done

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 64:
> 
>> 62:         You may not specify more than one directory for extracting the jar
>> 63: error.extract.pflag.not.allowed=\
>> 64:         -P option cannot be used when extracting a jar to a specific location
> 
> Perhaps something similar to
> 
> You may not specify '-Px'  with the '-C' or '--dir' options

Makes sense. I've updated the PR with this change.

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 167:
> 
>> 165:         (in = {0}) (out= {1})
>> 166: out.extract.dir=\
>> 167:         extracting to {0}
> 
> Perhaps 'Extracting to directory: {0}'

Updated the message to say `extracting to directory: {0}`. I decided to use lower case for `extracting` to keep it consistent with other similar messages that get logged here.

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 249:
> 
>> 247: \  -C DIR                     Change to the specified directory and include the\n\
>> 248: \                             following file. When used in extract mode, extracts\n\
>> 249: \                             the jar to the specified directory
> 
> Should this be updated on line 187 as well in the compatibility mode section?

Updated in latest version of the PR.

> test/jdk/tools/jar/JarExtractTest.java line 152:
> 
>> 150:         return abs;
>> 151:     }
>> 152: 
> 
> Please add a comment to each test giving a high level overview of what it does as it will help future maintainers

Done in latest update to this PR

> test/jdk/tools/jar/JarExtractTest.java line 175:
> 
>> 173:         final String dest = "foo-bar";
>> 174:         System.out.println("Extracting " + testJarPath + " to " + dest);
>> 175:         final int exitCode = JAR_TOOL.run(System.out, System.err, "-x", "-f", testJarPath.toString(),
> 
> Perhaps add a DataProvider so you can test --extract as well?

Not a data provider but the latest version of PR tests --extract as well

> test/jdk/tools/jar/JarExtractTest.java line 216:
> 
>> 214:         final Path jarPath = createJarWithPFlagSemantics();
>> 215:         // extract with -P flag without any explicit destination directory (expect the extraction to work fine)
>> 216:         final String[] args = new String[]{"-xvfP", jarPath.toString()};
> 
> Perhaps add a DataProvider so you can test --extract as well?

Not a data provider but the latest version of PR tests --extract as well

> test/jdk/tools/jar/JarExtractTest.java line 239:
> 
>> 237:      */
>> 238:     @Test
>> 239:     public void testExtractWithDirPFlagNotAllowed() throws Exception {
> 
> I would include --extract in your testing options

Done in latest version of the PR

> test/jdk/tools/jar/JarExtractTest.java line 240:
> 
>> 238:     @Test
>> 239:     public void testExtractWithDirPFlagNotAllowed() throws Exception {
>> 240:         final String expectedErrMsg = "-P option cannot be used when extracting a jar to a specific location";
> 
> Probably need to add a comment that this must match the entry in jar.properties

Added a comment mentioning where this message is sourced from.

> test/jdk/tools/jar/JarExtractTest.java line 247:
> 
>> 245:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-P", "-C", "."});
>> 246:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-P", "--dir", "."});
>> 247:         cmdArgs.add(new String[]{"-xvfP", testJarPath.toString(), "-C", tmpDir});
> 
> Perhaps add a DataProvider so you can test --extract as well?

Not a data provider but the latest version of PR tests `--extract` as well.

> test/jdk/tools/jar/JarExtractTest.java line 262:
> 
>> 260:      */
>> 261:     @Test
>> 262:     public void testLegacyCompatibilityMode() throws Exception {
> 
> Perhaps add a DataProvider so you can test --extract as well?

So from what I understand of the code in the jar tool the "legacy compatibility" mode stands for using the single hypen option and clubbing multiple options into one. Something like `-xvfP` instead of `-x -v -f -P` and this legacy compatibility mode isn't applicable for the long form options like `--extract`. So IMO using `--extract` here won't work. Let me know if I have misunderstood this review comment or the semantics of the legacy compatibility mode.

> test/jdk/tools/jar/JarExtractTest.java line 282:
> 
>> 280:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-C", tmpDir, "-C", tmpDir});
>> 281:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir, "--dir", tmpDir});
>> 282:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir, "-C", tmpDir});
> 
> Perhaps use a DataProvider so you can test --extract as well?

Done

> test/jdk/tools/jar/JarExtractTest.java line 300:
> 
>> 298:     public void testExtractPartialContent() throws Exception {
>> 299:         final String tmpDir = Files.createTempDirectory(Path.of("."), "8173970-").toString();
>> 300:         final String[] cmdArgs = new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir,
> 
> Perhaps add a DataProvider so you can test --extract as well?

Didn't use a data provider, but did add tests for `--extract` as well, in the latest version of this PR.

> test/jdk/tools/jar/JarExtractTest.java line 307:
> 
>> 305:         // make sure only the specific files were extracted
>> 306:         final Stream<Path> paths = Files.walk(Path.of(tmpDir));
>> 307:         Assert.assertEquals(paths.count(), 6, "Unexpected number of files/dirs in " + tmpDir);
> 
> Should '6' be in a local variable to make it clearer or at a minimum a comment

The latest update to the PR includes a comment explaining what this number represents.

> test/jdk/tools/jar/JarExtractTest.java line 332:
> 
>> 330:      */
>> 331:     private void testExtract(final String dest) throws Exception {
>> 332:         final String[] args = new String[]{"-x", "-f", testJarPath.toString(), "-C", dest};
> 
> Perhaps add a DataProvider so you can test --extract as well?

The latest version of the PR tests the `--extract` as well.

> test/jdk/tools/jar/JarExtractTest.java line 367:
> 
>> 365:     }
>> 366: 
>> 367:     private static Path createJarWithPFlagSemantics() throws IOException {
> 
> Perhaps add a comment as to what the method does

Done

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

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

From jpai at openjdk.java.net  Thu Apr  1 15:02:42 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 1 Apr 2021 15:02:42 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v4]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <xIE8AvPWcFR_f-z7z4Om_zSn1J8_xUXY6egI9MHIrNU=.8ae9c4f6-cd29-4f46-ab82-47ea43052205@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with seven additional commits since the last revision:

 - Lance's review - include tests for --extract long form option
 - cleanup after each test
 - Adjust test for new error messages
 - Lance's review - add a code comment for xdestDir
 - Lance's review - updates to the help messages in jar.properties
 - Lance's review - add comment to the magic number 6 in the tests
 - Lance's review - add comments to test methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2752/files
  - new: https://git.openjdk.java.net/jdk/pull/2752/files/3df602d2..b5de6e3d

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

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

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

From sspitsyn at openjdk.java.net  Fri Apr  2 17:17:24 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 2 Apr 2021 17:17:24 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <CU8ip-eXtf0s8gc20flTzNVYfthdqwqcHzBbxQp_7Bc=.cb558101-29c9-4e5f-8334-6b5e8c79ecd3@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

Joe,
The Serviceability part looks good.
Thanks,
Serguei

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

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

From jjg at openjdk.java.net  Sat Apr  3 01:22:05 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 3 Apr 2021 01:22:05 GMT
Subject: Integrated: JDK-8264664: use text blocks in javac module tests
Message-ID: <mT0Km_cxkbsq7tOiqwJy3SJRJ19tULrQtw7mMOMgv6U=.0b76bd38-269c-4eab-8965-b3d76eec6df7@github.com>

Please review an update to the javac module tests to use text blocks to represent multi-line strings.

The conversion was done mostly semi-automatically, using a utility used to covert the javadoc tests. Some edits were manual.

In all cases, there are no changes to the semantics of any test. In particular, no diagnostic messages containing line and column information were updated.

All `:tier1` tests pass on all standard platforms.

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

Commit messages:
 - fix whitespace issues
 - JDK-8264664: use text blocks in javac module tests

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

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

From darcy at openjdk.java.net  Sat Apr  3 01:22:06 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 3 Apr 2021 01:22:06 GMT
Subject: Integrated: JDK-8264664: use text blocks in javac module tests
In-Reply-To: <mT0Km_cxkbsq7tOiqwJy3SJRJ19tULrQtw7mMOMgv6U=.0b76bd38-269c-4eab-8965-b3d76eec6df7@github.com>
References: <mT0Km_cxkbsq7tOiqwJy3SJRJ19tULrQtw7mMOMgv6U=.0b76bd38-269c-4eab-8965-b3d76eec6df7@github.com>
Message-ID: <qS0Z5X3Ooiyj-Z3BBWV9PrpnBbX9hdYbNUR6pCGQ0H8=.c2417ab3-e6d3-4b1b-8330-c8005c2d1b89@github.com>

On Sat, 3 Apr 2021 00:33:54 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to the javac module tests to use text blocks to represent multi-line strings.
> 
> The conversion was done mostly semi-automatically, using a utility used to covert the javadoc tests. Some edits were manual.
> 
> In all cases, there are no changes to the semantics of any test. In particular, no diagnostic messages containing line and column information were updated.
> 
> All `:tier1` tests pass on all standard platforms.

Marked as reviewed by darcy (Reviewer).

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

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

From jjg at openjdk.java.net  Sat Apr  3 01:22:06 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 3 Apr 2021 01:22:06 GMT
Subject: Integrated: JDK-8264664: use text blocks in javac module tests
In-Reply-To: <mT0Km_cxkbsq7tOiqwJy3SJRJ19tULrQtw7mMOMgv6U=.0b76bd38-269c-4eab-8965-b3d76eec6df7@github.com>
References: <mT0Km_cxkbsq7tOiqwJy3SJRJ19tULrQtw7mMOMgv6U=.0b76bd38-269c-4eab-8965-b3d76eec6df7@github.com>
Message-ID: <HIGfasYmp8bVjG7QOvN8pNAZX22ZKHY1HHwX1iJESUo=.ffb627ac-1d98-4868-b857-ce189f243939@github.com>

On Sat, 3 Apr 2021 00:33:54 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to the javac module tests to use text blocks to represent multi-line strings.
> 
> The conversion was done mostly semi-automatically, using a utility used to covert the javadoc tests. Some edits were manual.
> 
> In all cases, there are no changes to the semantics of any test. In particular, no diagnostic messages containing line and column information were updated.
> 
> All `:tier1` tests pass on all standard platforms.

This pull request has now been integrated.

Changeset: e8eda655
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e8eda655
Stats:     632 lines in 18 files changed: 127 ins; 0 del; 505 mod

8264664: use text blocks in javac module tests

Reviewed-by: darcy

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Apr  6 04:47:21 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 6 Apr 2021 04:47:21 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <PMCKdl-wruSSgvBpylJrWLbU9te3WH_JhfXG9dVXY1g=.8a96ea89-96d4-41fc-a449-546109db6b6b@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <PMCKdl-wruSSgvBpylJrWLbU9te3WH_JhfXG9dVXY1g=.8a96ea89-96d4-41fc-a449-546109db6b6b@github.com>
Message-ID: <e4AvG0W0tmrgySDiZOKKuIMMy3WObcX_e27z8mDKCf8=.5dd891bf-2ec7-4a60-a9f1-fc9886be5ac2@github.com>

On Fri, 5 Mar 2021 21:59:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
>> Two existing tests failed and I fixed it.
>> Currently, all the tests in `test/langtools` passed locally by using the following command.
>> 
>> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> This looks very good - sorry I missed it. If you reopen I will approve!

@mcimadamore Thank you for your help. I will reopen it.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Apr  6 05:13:29 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 6 Apr 2021 05:13:29 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <e4AvG0W0tmrgySDiZOKKuIMMy3WObcX_e27z8mDKCf8=.5dd891bf-2ec7-4a60-a9f1-fc9886be5ac2@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <PMCKdl-wruSSgvBpylJrWLbU9te3WH_JhfXG9dVXY1g=.8a96ea89-96d4-41fc-a449-546109db6b6b@github.com>
 <e4AvG0W0tmrgySDiZOKKuIMMy3WObcX_e27z8mDKCf8=.5dd891bf-2ec7-4a60-a9f1-fc9886be5ac2@github.com>
Message-ID: <OIhMSGbkIYPoFS259ZZC0gp7SPGOCPoLws2Xls4oT0I=.51be191b-8cb6-4879-8ccf-ae219a857d63@github.com>

On Tue, 6 Apr 2021 04:43:04 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> This looks very good - sorry I missed it. If you reopen I will approve!
>
> @mcimadamore Thank you for your help. I will reopen it.

I can't find the `reopen` button. Maybe it is my permission issue. Could anyone reopen it for me? Thanks a lot.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Apr  6 05:15:24 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 6 Apr 2021 05:15:24 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v3]
In-Reply-To: <o4xTQDIrHZjw02AW1glt9ULZvdu5xL8Ku9hSOg0GlH4=.90917478-7737-453e-9cd9-c729980799ca@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
 <JX-iyXc_sJJURjgud46jHz7kLSJt7Jvf-7XkeRtNjLU=.29e853a7-4932-413b-9f98-ac619dcd5069@github.com>
 <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com>
 <hSAOOWfjpir1YS6CcWYjFRE49HCzBTeNDjUcEhYc5hU=.778e45ae-647d-4dde-937e-616d1fc2ca80@github.com>
 <IuffxoxpXLsRxsyHihUGCtJ0vhom46ak7apoAYPJ2s0=.d982a842-05bf-482f-a30e-639b61aafaf4@github.com>
 <o4xTQDIrHZjw02AW1glt9ULZvdu5xL8Ku9hSOg0GlH4=.90917478-7737-453e-9cd9-c729980799ca@github.com>
Message-ID: <5vyEd4RnfKt0QAueE_sBZbQxfZCbNaB3XAMEVqoQIYk=.3d3a4bfb-c03b-4d0f-b47c-9eb07acd2e04@github.com>

On Tue, 2 Mar 2021 17:43:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> @jonathan-gibbons I updated the code according to your comments. Thank you for taking the time to review.
>
> @lgxbslgx, could you please re-open this PR? Thanks!

@lahodaj sorry for the delay. I will assist you to completing the new PR.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Apr  6 05:22:29 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 6 Apr 2021 05:22:29 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility
In-Reply-To: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
References: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
Message-ID: <669qxK1I18CIawVZmOrEfcjuiOACkWN9jWX91MaJmDI=.4a6acdce-e3cc-4e7c-aa90-229e0332919b@github.com>

On Mon, 8 Mar 2021 11:21:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara.
> 
> @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself.

@lahodaj It is good for me to continue the work in this PR. I will assist you if you need.

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

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

From maurizio.cimadamore at oracle.com  Tue Apr  6 10:08:47 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 6 Apr 2021 11:08:47 +0100
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <OIhMSGbkIYPoFS259ZZC0gp7SPGOCPoLws2Xls4oT0I=.51be191b-8cb6-4879-8ccf-ae219a857d63@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <PMCKdl-wruSSgvBpylJrWLbU9te3WH_JhfXG9dVXY1g=.8a96ea89-96d4-41fc-a449-546109db6b6b@github.com>
 <e4AvG0W0tmrgySDiZOKKuIMMy3WObcX_e27z8mDKCf8=.5dd891bf-2ec7-4a60-a9f1-fc9886be5ac2@github.com>
 <OIhMSGbkIYPoFS259ZZC0gp7SPGOCPoLws2Xls4oT0I=.51be191b-8cb6-4879-8ccf-ae219a857d63@github.com>
Message-ID: <d53095ba-b5b2-4101-2223-dd763be319c6@oracle.com>

Not sure - I don't see it either - CC'ing Erik

Maurizio


On 06/04/2021 06:13, Guoxiong Li wrote:
> On Tue, 6 Apr 2021 04:43:04 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:
>
>>> This looks very good - sorry I missed it. If you reopen I will approve!
>> @mcimadamore Thank you for your help. I will reopen it.
> I can't find the `reopen` button. Maybe it is my permission issue. Could anyone reopen it for me? Thanks a lot.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1898

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Apr  7 12:35:14 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 7 Apr 2021 12:35:14 GMT
Subject: RFR: 8264696: Multi-catch clause causes compiler exception because it
 uses the package-private supertype
Message-ID: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>

Hi all,

The method `isAccessible(Env<AttrContext> env, Type t, boolean checkInner)` should take `UnionClassType` as a special type to do some corresponding work. If not, the problem will occur. This patch fixes it and adds a test case.

Thank you for taking the time to review.

Best Regards.
-- Guoxiong

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

Commit messages:
 - 8264696: Multi-catch clause causes compiler exception because it uses the package-private supertype

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

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

From darcy at openjdk.java.net  Wed Apr  7 19:01:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 7 Apr 2021 19:01:18 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)`
Message-ID: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>

Addition of a small convenience method, with a default implementation, to Elements.

Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.

An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.

Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.

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

Commit messages:
 - Add test coverage.
 - Merge branch 'master' into 8261625
 - 8261625

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

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

From darcy at openjdk.java.net  Wed Apr  7 19:14:52 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 7 Apr 2021 19:14:52 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)`
In-Reply-To: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
Message-ID: <_7VYO3nGIxRPSSeZBb3kb0-RhRF_SUp8dMmWC24Rx6s=.21ab10e9-f77c-4d66-9e69-058cebcfab75@github.com>

On Wed, 7 Apr 2021 18:49:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Addition of a small convenience method, with a default implementation, to Elements.
> 
> Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.
> 
> An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.
> 
> Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.

PS And the CSR should be reviewed as well:

https://bugs.openjdk.java.net/browse/JDK-8264865

Thanks.

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

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

From vromero at openjdk.java.net  Thu Apr  8 01:52:59 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 8 Apr 2021 01:52:59 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)`
In-Reply-To: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
Message-ID: <C6zoG4BZsmdOaYii9ORhznmOL_7QkIbp-0wWHMYav2E=.f395d7a8-9922-46a4-98a7-8e8ba9d67706@github.com>

On Wed, 7 Apr 2021 18:49:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Addition of a small convenience method, with a default implementation, to Elements.
> 
> Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.
> 
> An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.
> 
> Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.

test/langtools/tools/javac/modules/AutomaticModules.java line 694:

> 692:                      })
> 693:                 .writeAll()
> 694:                 .getOutputLines(Task.OutputKind.DIRECT);

I know this code predates your patch but now that you are here :) these two lines are unnecessary as the output is not kept. I mean you can remove:
           .writeAll()
           .getOutputLines(Task.OutputKind.DIRECT)

test/langtools/tools/javac/processing/model/util/elements/TestIsAutomaticMod.java line 2:

> 1: /*
> 2:  * Copyright (c) 2006, 2021, Oracle and/or its affiliates. All rights reserved.

2006 can be removed

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

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

From vromero at openjdk.java.net  Thu Apr  8 02:03:07 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 8 Apr 2021 02:03:07 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)`
In-Reply-To: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
Message-ID: <zHr1FaYdX_aKB8s7V9jgWXwaA5Vg-GXmWIT18kZaby8=.a240aaf9-2311-4b2a-b25f-549cc4e1e6e5@github.com>

On Wed, 7 Apr 2021 18:49:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Addition of a small convenience method, with a default implementation, to Elements.
> 
> Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.
> 
> An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.
> 
> Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.

Changes requested by vromero (Reviewer).

test/langtools/tools/lib/toolbox/JavacTask.java line 341:

> 339:      * @return the result of calling {@code run}
> 340:      */
> 341:     public Result run(Expect expect, Processor... procs) {

I would prefer to add a new method to this class, something in the lines of:
public JavacTask processors(Processor... procs) {
    this.procs = List.of(procs);
    return this;
}

which I think is more in the spirit of the existing API, then you won't need to add the two new versions of the `run` method

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

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

From vromero at openjdk.java.net  Thu Apr  8 02:24:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 8 Apr 2021 02:24:44 GMT
Subject: RFR: 8264696: Multi-catch clause causes compiler exception
 because it uses the package-private supertype
In-Reply-To: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
References: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
Message-ID: <EK2VoEgYUX29fDL4r56yygVwicsQ4A4vTtqfRULGtbg=.c473685e-de4f-4d32-9ff3-115375cb3271@github.com>

On Wed, 7 Apr 2021 12:26:34 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The method `isAccessible(Env<AttrContext> env, Type t, boolean checkInner)` should take `UnionClassType` as a special type to do some corresponding work. If not, the problem will occur. This patch fixes it and adds a test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.
> -- Guoxiong

test/langtools/tools/javac/resolve/PackagePrivateSupertypeAtMultiCatch.java line 105:

> 103:                 .outdir(out)
> 104:                 .run()
> 105:                 .writeAll();

nit: you don't need the `writeAll()` method given that you are not collecting the output

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

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

From vromero at openjdk.java.net  Thu Apr  8 02:46:17 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 8 Apr 2021 02:46:17 GMT
Subject: RFR: 8264696: Multi-catch clause causes compiler exception
 because it uses the package-private supertype
In-Reply-To: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
References: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
Message-ID: <CQMToFICknWil5auDJNTUI4O2FmVU4jFCBA30zIJksg=.7cf39c17-739b-4d62-86a9-d262a9cd625b@github.com>

On Wed, 7 Apr 2021 12:26:34 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The method `isAccessible(Env<AttrContext> env, Type t, boolean checkInner)` should take `UnionClassType` as a special type to do some corresponding work. If not, the problem will occur. This patch fixes it and adds a test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.
> -- Guoxiong

Changes requested by vromero (Reviewer).

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

> 388:         if (t.hasTag(ARRAY)) {
> 389:             return isAccessible(env, types.cvarUpperBound(types.elemtype(t)));
> 390:         } else if (!t.isUnion()) {

I would change the code a bit, like in:

        } else if (t.isUnion()) {
            return StreamSupport.stream(((UnionClassType) t).getAlternativeTypes().spliterator(), false)
                    .allMatch(alternative -> isAccessible(env, alternative.tsym, checkInner));
        } else {
            return isAccessible(env, t.tsym, checkInner);
        }

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Apr  8 04:47:38 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 8 Apr 2021 04:47:38 GMT
Subject: RFR: 8264696: Multi-catch clause causes compiler exception
 because it uses the package-private supertype
In-Reply-To: <CQMToFICknWil5auDJNTUI4O2FmVU4jFCBA30zIJksg=.7cf39c17-739b-4d62-86a9-d262a9cd625b@github.com>
References: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
 <CQMToFICknWil5auDJNTUI4O2FmVU4jFCBA30zIJksg=.7cf39c17-739b-4d62-86a9-d262a9cd625b@github.com>
Message-ID: <0ZbKReJhbSP-gIlXrPLCjOPZhCXTOuxxSKyEGd4E5Fc=.ad52962f-815d-4f43-8025-905ca82b6c41@github.com>

On Thu, 8 Apr 2021 02:42:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hi all,
>> 
>> The method `isAccessible(Env<AttrContext> env, Type t, boolean checkInner)` should take `UnionClassType` as a special type to do some corresponding work. If not, the problem will occur. This patch fixes it and adds a test case.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>> -- Guoxiong
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 390:
> 
>> 388:         if (t.hasTag(ARRAY)) {
>> 389:             return isAccessible(env, types.cvarUpperBound(types.elemtype(t)));
>> 390:         } else if (!t.isUnion()) {
> 
> I would change the code a bit, like in:
> 
>         } else if (t.isUnion()) {
>             return StreamSupport.stream(((UnionClassType) t).getAlternativeTypes().spliterator(), false)
>                     .allMatch(alternative -> isAccessible(env, alternative.tsym, checkInner));
>         } else {
>             return isAccessible(env, t.tsym, checkInner);
>         }

Very nice suggestion. Fixed.

> test/langtools/tools/javac/resolve/PackagePrivateSupertypeAtMultiCatch.java line 105:
> 
>> 103:                 .outdir(out)
>> 104:                 .run()
>> 105:                 .writeAll();
> 
> nit: you don't need the `writeAll()` method given that you are not collecting the output

Fixed.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Apr  8 05:13:38 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 8 Apr 2021 05:13:38 GMT
Subject: RFR: 8264696: Multi-catch clause causes compiler exception
 because it uses the package-private supertype [v2]
In-Reply-To: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
References: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
Message-ID: <eY2BmD52WrzjCM7gPd5x24k5lLhMRtfzX6UQ5xUepXk=.4a8e6ba8-7e5a-4da5-8b23-38a27d72db05@github.com>

> Hi all,
> 
> The method `isAccessible(Env<AttrContext> env, Type t, boolean checkInner)` should take `UnionClassType` as a special type to do some corresponding work. If not, the problem will occur. This patch fixes it and adds a test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision:

 - Use stream api
 - Remove writeAll()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3374/files
  - new: https://git.openjdk.java.net/jdk/pull/3374/files/2e0dba0f..d6a8b12e

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

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

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

From darcy at openjdk.java.net  Thu Apr  8 06:25:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Apr 2021 06:25:37 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)` [v2]
In-Reply-To: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
Message-ID: <6Y40VpLNwo0xLQXZ-RtZiKTqQEGWHZ947ToF8sevOz8=.cb70319d-6013-4eb3-ad63-b4e7f8439ad6@github.com>

> Addition of a small convenience method, with a default implementation, to Elements.
> 
> Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.
> 
> An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.
> 
> Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.

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

 - Respond to review feedback.
 - Merge branch 'master' into 8261625
 - Add test coverage.
 - Merge branch 'master' into 8261625
 - 8261625

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3382/files
  - new: https://git.openjdk.java.net/jdk/pull/3382/files/fdeadb26..5dab5c2f

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

  Stats: 2952 lines in 89 files changed: 2325 ins; 314 del; 313 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3382.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3382/head:pull/3382

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

From darcy at openjdk.java.net  Thu Apr  8 06:26:04 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Apr 2021 06:26:04 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)` [v2]
In-Reply-To: <C6zoG4BZsmdOaYii9ORhznmOL_7QkIbp-0wWHMYav2E=.f395d7a8-9922-46a4-98a7-8e8ba9d67706@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
 <C6zoG4BZsmdOaYii9ORhznmOL_7QkIbp-0wWHMYav2E=.f395d7a8-9922-46a4-98a7-8e8ba9d67706@github.com>
Message-ID: <UJTeoXPuQ10KslHxDnqx3z-wBL49_BBNiELJ25I-FMw=.5fdb2a08-08d4-408a-b832-b11a013c2c6b@github.com>

On Thu, 8 Apr 2021 01:50:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Respond to review feedback.
>>  - Merge branch 'master' into 8261625
>>  - Add test coverage.
>>  - Merge branch 'master' into 8261625
>>  - 8261625
>
> test/langtools/tools/javac/processing/model/util/elements/TestIsAutomaticMod.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2006, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> 2006 can be removed

I copied a file from 2006 and then edited the result, hence I started with the 2006 year.

> test/langtools/tools/lib/toolbox/JavacTask.java line 341:
> 
>> 339:      * @return the result of calling {@code run}
>> 340:      */
>> 341:     public Result run(Expect expect, Processor... procs) {
> 
> I would prefer to add a new method to this class, something in the lines of:
> public JavacTask processors(Processor... procs) {
>     this.procs = List.of(procs);
>     return this;
> }
> 
> which I think is more in the spirit of the existing API, then you won't need to add the two new versions of the `run` method

Added as suggested; thanks.

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

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

From vromero at openjdk.java.net  Thu Apr  8 11:32:23 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 8 Apr 2021 11:32:23 GMT
Subject: RFR: 8264696: Multi-catch clause causes compiler exception
 because it uses the package-private supertype [v2]
In-Reply-To: <eY2BmD52WrzjCM7gPd5x24k5lLhMRtfzX6UQ5xUepXk=.4a8e6ba8-7e5a-4da5-8b23-38a27d72db05@github.com>
References: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
 <eY2BmD52WrzjCM7gPd5x24k5lLhMRtfzX6UQ5xUepXk=.4a8e6ba8-7e5a-4da5-8b23-38a27d72db05@github.com>
Message-ID: <rALlAqT-Fj13pqQJgp0ogzj_WWIFBddaRuduTSu3GcQ=.3bd8c513-437e-4082-9204-76dc930a12c2@github.com>

On Thu, 8 Apr 2021 05:13:38 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> The method `isAccessible(Env<AttrContext> env, Type t, boolean checkInner)` should take `UnionClassType` as a special type to do some corresponding work. If not, the problem will occur. This patch fixes it and adds a test case.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use stream api
>  - Remove writeAll()

looks good, thanks for the fix

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Thu Apr  8 16:58:13 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 8 Apr 2021 16:58:13 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)` [v2]
In-Reply-To: <6Y40VpLNwo0xLQXZ-RtZiKTqQEGWHZ947ToF8sevOz8=.cb70319d-6013-4eb3-ad63-b4e7f8439ad6@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
 <6Y40VpLNwo0xLQXZ-RtZiKTqQEGWHZ947ToF8sevOz8=.cb70319d-6013-4eb3-ad63-b4e7f8439ad6@github.com>
Message-ID: <UOc7f0YjwTAYSi_uWemSIneS9upktTCL37RMue3bTF4=.f44c30ef-3aa9-4d65-a2e6-c52ec309a20f@github.com>

On Thu, 8 Apr 2021 06:25:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Addition of a small convenience method, with a default implementation, to Elements.
>> 
>> Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.
>> 
>> An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.
>> 
>> Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into 8261625
>  - Add test coverage.
>  - Merge branch 'master' into 8261625
>  - 8261625

lgtm

test/langtools/tools/javac/processing/model/util/elements/TestIsAutomaticMod.java line 53:

> 51:                 ModuleElement enclosing = elements.getModuleOf(e);
> 52:                 checkMod(enclosing, false);
> 53:                 System.out.println(enclosing.toString());

can this line `System.out...` be removed? probably a debugging leftover?

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.java.net  Thu Apr  8 17:10:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Apr 2021 17:10:09 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)` [v2]
In-Reply-To: <UOc7f0YjwTAYSi_uWemSIneS9upktTCL37RMue3bTF4=.f44c30ef-3aa9-4d65-a2e6-c52ec309a20f@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
 <6Y40VpLNwo0xLQXZ-RtZiKTqQEGWHZ947ToF8sevOz8=.cb70319d-6013-4eb3-ad63-b4e7f8439ad6@github.com>
 <UOc7f0YjwTAYSi_uWemSIneS9upktTCL37RMue3bTF4=.f44c30ef-3aa9-4d65-a2e6-c52ec309a20f@github.com>
Message-ID: <PrLNq8MJX5H5vVuA_3TF_iS7y2UmxmOePF27DVLeRGE=.7c89b69d-a5fa-405a-84c2-f5aac8e67ad0@github.com>

On Thu, 8 Apr 2021 16:54:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Respond to review feedback.
>>  - Merge branch 'master' into 8261625
>>  - Add test coverage.
>>  - Merge branch 'master' into 8261625
>>  - 8261625
>
> test/langtools/tools/javac/processing/model/util/elements/TestIsAutomaticMod.java line 53:
> 
>> 51:                 ModuleElement enclosing = elements.getModuleOf(e);
>> 52:                 checkMod(enclosing, false);
>> 53:                 System.out.println(enclosing.toString());
> 
> can this line `System.out...` be removed? probably a debugging leftover?

Sure; I'll remove it before pushing.

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

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

From darcy at openjdk.java.net  Thu Apr  8 17:26:33 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Apr 2021 17:26:33 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)` [v3]
In-Reply-To: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
Message-ID: <jf0BUqXFiQ0GCgX9MB0JK8RUedcsalrhykMjON0GpbQ=.3526d769-8fd4-4766-8898-c268c8519fde@github.com>

> Addition of a small convenience method, with a default implementation, to Elements.
> 
> Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.
> 
> An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.
> 
> Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.

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/3382/files
  - new: https://git.openjdk.java.net/jdk/pull/3382/files/5dab5c2f..cea0aa16

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

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

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

From jlahoda at openjdk.java.net  Thu Apr  8 17:38:12 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 8 Apr 2021 17:38:12 GMT
Subject: RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)` [v3]
In-Reply-To: <jf0BUqXFiQ0GCgX9MB0JK8RUedcsalrhykMjON0GpbQ=.3526d769-8fd4-4766-8898-c268c8519fde@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
 <jf0BUqXFiQ0GCgX9MB0JK8RUedcsalrhykMjON0GpbQ=.3526d769-8fd4-4766-8898-c268c8519fde@github.com>
Message-ID: <EXKFAscASFfI3rle3S08BC8aRsTAjVqNO6lRVnW2fDQ=.c469216b-267e-4c87-b380-3e11e7102918@github.com>

On Thu, 8 Apr 2021 17:26:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Addition of a small convenience method, with a default implementation, to Elements.
>> 
>> Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.
>> 
>> An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.
>> 
>> Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

LGTM

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

Marked as reviewed by jlahoda (Reviewer).

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

From darcy at openjdk.java.net  Thu Apr  8 21:28:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Apr 2021 21:28:15 GMT
Subject: Integrated: 8261625: Add `Elements.isAutomaticModule(ModuleElement)`
In-Reply-To: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
References: <5ww__yoXn1vBuOWVCKPEPN9O75DyH0I_HYDEAj3xrhM=.feb6af0c-da75-425b-9d97-03df51612f53@github.com>
Message-ID: <eWQVgL0K4hxHegVR5TVj9s2E-nrYxkC3XjtbAXF0J5A=.10af65de-cc35-4e7d-aa4f-701d0f860739@github.com>

On Wed, 7 Apr 2021 18:49:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Addition of a small convenience method, with a default implementation, to Elements.
> 
> Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.
> 
> An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.
> 
> Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.

This pull request has now been integrated.

Changeset: ccefa5e3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ccefa5e3
Stats:     194 lines in 5 files changed: 186 ins; 0 del; 8 mod

8261625: Add `Elements.isAutomaticModule(ModuleElement)`

Reviewed-by: vromero, jlahoda

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Apr  8 21:28:36 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 8 Apr 2021 21:28:36 GMT
Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of
 intersection type in cast
Message-ID: <xpJJ3Evrr6AXV68JqbKkY2RFrKsdn8a3YbSgWyyYou8=.63bc2026-df3f-4424-964f-3a37a46f760c@github.com>

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

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

Commit messages:
 - 8263642: javac emits duplicate checkcast for first bound of intersection type in cast

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Apr  8 21:39:20 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 8 Apr 2021 21:39:20 GMT
Subject: Integrated: 8264696: Multi-catch clause causes compiler exception
 because it uses the package-private supertype
In-Reply-To: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
References: <INWXyArQCYgN-ow_SjDatJcFdVyUYvpRcAiSFQazkN8=.b64635c3-24ae-4987-9d55-ff823dcb1478@github.com>
Message-ID: <n08amafLiARLFGafyvn4GfpXZJHsFPD1BzxgIwM3iLk=.f1c6ac4a-0aa5-4277-9e4a-6a769816130e@github.com>

On Wed, 7 Apr 2021 12:26:34 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The method `isAccessible(Env<AttrContext> env, Type t, boolean checkInner)` should take `UnionClassType` as a special type to do some corresponding work. If not, the problem will occur. This patch fixes it and adds a test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.
> -- Guoxiong

This pull request has now been integrated.

Changeset: 57f1e7d9
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57f1e7d9
Stats:     115 lines in 2 files changed: 112 ins; 0 del; 3 mod

8264696: Multi-catch clause causes compiler exception because it uses the package-private supertype

Reviewed-by: vromero

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

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

From darcy at openjdk.java.net  Thu Apr  8 22:05:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Apr 2021 22:05:37 GMT
Subject: RFR: 8005295: Use mandated information for printing of repeating
 annotations
Message-ID: <wNoqvJPGOLrAe16sqM4_S2dq0NnazmorzEN5LGlaqLQ=.3a2365c7-f64c-4dbf-9e32-a9f837720e2e@github.com>

Small behavioral change to improve the source fidelity of the Xprint output in the case of repeated annotations being placed in a mandated, that is compiler-generated, container annotation.

The checks over and above the annotation being marked as MANDATED are meant to catch potential cases where an annotation was marked as mandated, but was not a container for a repeating annotation.

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

Commit messages:
 - Appease jcheck
 - 8005295: Use mandated information for printing of repeating annotations

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

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

From kvn at openjdk.java.net  Fri Apr  9 17:43:22 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:43:22 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler
Message-ID: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>

As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:

- `jdk.internal.vm.compiler` ? the Graal compiler 
- `jdk.internal.vm.compiler.management` ? Graal's `MBean`
- `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests

Remove Graal related code in makefiles.

Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
src/jdk.internal.vm.compiler/share/classes/module-info.java
src/jdk.internal.vm.compiler.management/share/classes/module-info.java

@AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.

Tested hs-tier1-4

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

Depends on: https://git.openjdk.java.net/jdk/pull/3398

Commit messages:
 - 8264806: Remove the experimental JIT compiler

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

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

From erikj at openjdk.java.net  Fri Apr  9 19:33:34 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 9 Apr 2021 19:33:34 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <9YQ-kwVWOO0OzJO1YcfP9nnzUInhLOJ9yiecsYWBIp4=.22504511-4d72-4a41-8092-820501c1ca35@github.com>

On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

make/GraalBuilderImage.gmk line 1:

> 1: #

This file should not be removed. This outout image is this makefile produces is used as input to the separate GraalVM build.

make/Main.gmk line 444:

> 442: ))
> 443: 
> 444: $(eval $(call SetupTarget, graal-builder-image, \

Same as above, this needs to stay.

make/autoconf/spec.gmk.in line 895:

> 893: STATIC_LIBS_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(STATIC_LIBS_IMAGE_SUBDIR)
> 894: 
> 895: # Graal builder image

Like above, this needs to stay.

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

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

From jjg at openjdk.java.net  Fri Apr  9 20:24:27 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 9 Apr 2021 20:24:27 GMT
Subject: RFR: 8005295: Use mandated information for printing of repeating
 annotations
In-Reply-To: <wNoqvJPGOLrAe16sqM4_S2dq0NnazmorzEN5LGlaqLQ=.3a2365c7-f64c-4dbf-9e32-a9f837720e2e@github.com>
References: <wNoqvJPGOLrAe16sqM4_S2dq0NnazmorzEN5LGlaqLQ=.3a2365c7-f64c-4dbf-9e32-a9f837720e2e@github.com>
Message-ID: <dQkWTC2Qvdb2hcUKOFnm46JnYxLf3Fk3uPQ2eY_nzSk=.edc43f9b-d3e6-42e1-8349-c47cc566b08b@github.com>

On Thu, 8 Apr 2021 21:56:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small behavioral change to improve the source fidelity of the Xprint output in the case of repeated annotations being placed in a mandated, that is compiler-generated, container annotation.
> 
> The checks over and above the annotation being marked as MANDATED are meant to catch potential cases where an annotation was marked as mandated, but was not a container for a repeating annotation.

Marked as reviewed by jjg (Reviewer).

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

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

From darcy at openjdk.java.net  Fri Apr  9 22:06:33 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 9 Apr 2021 22:06:33 GMT
Subject: Integrated: 8005295: Use mandated information for printing of
 repeating annotations
In-Reply-To: <wNoqvJPGOLrAe16sqM4_S2dq0NnazmorzEN5LGlaqLQ=.3a2365c7-f64c-4dbf-9e32-a9f837720e2e@github.com>
References: <wNoqvJPGOLrAe16sqM4_S2dq0NnazmorzEN5LGlaqLQ=.3a2365c7-f64c-4dbf-9e32-a9f837720e2e@github.com>
Message-ID: <C0xDqys-KvUIEw9Uhq-MYYBdVtnLHjfaM_7ZPSGzPHM=.8b805d12-8a70-4dc7-a5f3-8e745ea10eb7@github.com>

On Thu, 8 Apr 2021 21:56:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small behavioral change to improve the source fidelity of the Xprint output in the case of repeated annotations being placed in a mandated, that is compiler-generated, container annotation.
> 
> The checks over and above the annotation being marked as MANDATED are meant to catch potential cases where an annotation was marked as mandated, but was not a container for a repeating annotation.

This pull request has now been integrated.

Changeset: 863feab9
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/863feab9
Stats:     181 lines in 3 files changed: 179 ins; 0 del; 2 mod

8005295: Use mandated information for printing of repeating annotations

Reviewed-by: jjg

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

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

From kvn at openjdk.java.net  Fri Apr  9 22:26:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 22:26:40 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

Vladimir Kozlov 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:

 - Restore Graal Builder image makefile
 - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
 - 8264806: Remove the experimental JIT compiler

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3421/files
  - new: https://git.openjdk.java.net/jdk/pull/3421/files/8ff9b599..a246aaa6

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

  Stats: 102 lines in 12 files changed: 66 ins; 27 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3421.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421

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

From jespersm at openjdk.java.net  Sun Apr 11 13:01:10 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Sun, 11 Apr 2021 13:01:10 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors
Message-ID: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>

Unknown lookups in the java package give misleading compilation errors

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

Commit messages:
 - 8264258: Unknown lookups in the java package give misleading compilation errors

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

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

From jespersm at openjdk.java.net  Sun Apr 11 13:01:10 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Sun, 11 Apr 2021 13:01:10 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors
In-Reply-To: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
Message-ID: <GRyAdN_xJ4AcCUSXdhZd_D2vuSEM2BB0SnJRU6NKnB8=.b0937b57-ef7e-4167-99bf-07406480245c@github.com>

On Sun, 11 Apr 2021 12:49:35 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Unknown lookups in the java package give misleading compilation errors

The problem only really occurs for the 'java' package, which is special according to the JLS, since it is always in scope (as per ?6.3) and observable (as per ?7.4.3). The special handling of unfound symbols in com.sun.tools.javac.comp.Resolve.SymbolNotFoundError.getDiagnostic explcitly handles the issues of unfound classes in unfound packages, and fails to differentiate 'java'. 

My research shows that the error was introduced with Jigsaw, see commit 001ebb3a7279d9a193acebc389cbbee867fa5eb3 where the blessed output for TryWithResources/TwrForVariable3.out was changed from "unknown class lang" to "unknown packages java".

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

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

From jiefu at tencent.com  Mon Apr 12 11:44:05 2021
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Mon, 12 Apr 2021 11:44:05 +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: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
Message-ID: <72184DF4-C63B-488F-8490-074247292022@tencent.com>

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 raffaello.giulietti at gmail.com  Mon Apr 12 14:17:57 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 12 Apr 2021 16:17:57 +0200
Subject: test/langtools/tools/javac/sym/ElementStructureTest fails: what does
 it mean?
Message-ID: <255557d5-97c7-159a-4736-4af543582741@gmail.com>

Hello,

(hope this is the right mailing list for such questions: otherwise 
please redirect me.)

I recently posted a PR [1] on the core-libs-dev mailing list that fails 
to pass one of the automatic GitHub action tests on all supported platforms.

The test that fails is
test/langtools/tools/javac/sym/ElementStructureTest.java

The same test also fails on my local repo when I run
make test 
TEST="jtreg:test/langtools/tools/javac/sym/ElementStructureTest.java"

I have no clue what in my changes in the PR can lead to the failure.

Any suggestions?


Thanks
Raffaello

----

[1] https://github.com/openjdk/jdk/pull/3402

From jan.lahoda at oracle.com  Mon Apr 12 16:22:52 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 12 Apr 2021 18:22:52 +0200
Subject: test/langtools/tools/javac/sym/ElementStructureTest fails: what
 does it mean?
In-Reply-To: <255557d5-97c7-159a-4736-4af543582741@gmail.com>
References: <255557d5-97c7-159a-4736-4af543582741@gmail.com>
Message-ID: <bc90ae32-8909-d7bf-2a68-506fe3472904@oracle.com>

Hi Raffaello,


The test is printing the whole stored/recorded JDK 7 and 8 API, computes 
a digest from it, and checkes if it matches the expected value. And, 
there are some double constants in the API, (e.g. in java.lang.Double), 
and these presumably may be printed in a different way after your patch. 
I'll check manually if the results make sense, and we can then update 
the hashes (we could also use a more resilient way to print doubles, 
together with updating the hashes).


Jan


On 12. 04. 21 16:17, Raffaello Giulietti wrote:
> Hello,
>
> (hope this is the right mailing list for such questions: otherwise 
> please redirect me.)
>
> I recently posted a PR [1] on the core-libs-dev mailing list that 
> fails to pass one of the automatic GitHub action tests on all 
> supported platforms.
>
> The test that fails is
> test/langtools/tools/javac/sym/ElementStructureTest.java
>
> The same test also fails on my local repo when I run
> make test 
> TEST="jtreg:test/langtools/tools/javac/sym/ElementStructureTest.java"
>
> I have no clue what in my changes in the PR can lead to the failure.
>
> Any suggestions?
>
>
> Thanks
> Raffaello
>
> ----
>
> [1] https://github.com/openjdk/jdk/pull/3402

From raffaello.giulietti at gmail.com  Mon Apr 12 16:36:12 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 12 Apr 2021 18:36:12 +0200
Subject: test/langtools/tools/javac/sym/ElementStructureTest fails: what
 does it mean?
In-Reply-To: <bc90ae32-8909-d7bf-2a68-506fe3472904@oracle.com>
References: <255557d5-97c7-159a-4736-4af543582741@gmail.com>
 <bc90ae32-8909-d7bf-2a68-506fe3472904@oracle.com>
Message-ID: <cdb01085-784f-20b3-6eb7-b5ee9488da3b@gmail.com>

Hi Jan,

thanks for looking at the problem.

A way to be more resilient is to use hex notation for float/double 
literals, as they are not affected by my patch.

To avoid misunderstandings, the patch is not meant to be back-ported to 
JDK 7 or 8, both because it is associated with a CSR and because it 
makes use of feature that are not present in JDK 7 or 8, in particular 
Math.multiplyHigh().

Please let me know if you discover doubles that are represented 
differently, so I can add them to my tests.


Greetings
Raffaello



On 2021-04-12 18:22, Jan Lahoda wrote:
> Hi Raffaello,
> 
> 
> The test is printing the whole stored/recorded JDK 7 and 8 API, computes 
> a digest from it, and checkes if it matches the expected value. And, 
> there are some double constants in the API, (e.g. in java.lang.Double), 
> and these presumably may be printed in a different way after your patch. 
> I'll check manually if the results make sense, and we can then update 
> the hashes (we could also use a more resilient way to print doubles, 
> together with updating the hashes).
> 
> 
> Jan
> 
> 
> On 12. 04. 21 16:17, Raffaello Giulietti wrote:
>> Hello,
>>
>> (hope this is the right mailing list for such questions: otherwise 
>> please redirect me.)
>>
>> I recently posted a PR [1] on the core-libs-dev mailing list that 
>> fails to pass one of the automatic GitHub action tests on all 
>> supported platforms.
>>
>> The test that fails is
>> test/langtools/tools/javac/sym/ElementStructureTest.java
>>
>> The same test also fails on my local repo when I run
>> make test 
>> TEST="jtreg:test/langtools/tools/javac/sym/ElementStructureTest.java"
>>
>> I have no clue what in my changes in the PR can lead to the failure.
>>
>> Any suggestions?
>>
>>
>> Thanks
>> Raffaello
>>
>> ----
>>
>> [1] https://github.com/openjdk/jdk/pull/3402

From sadayapalam at openjdk.java.net  Wed Apr 14 07:57:57 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 14 Apr 2021 07:57:57 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors
In-Reply-To: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
Message-ID: <PdX-yn7rXWU2-AhdJEjjogR9cAqvDz8CuCgEp75nrt0=.3325772f-0493-4bc4-9149-5d8501ced80d@github.com>

On Sun, 11 Apr 2021 12:49:35 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Unknown lookups in the java package give misleading compilation errors

Thanks for the patch Jesper, I will review it and share comments within the next couple of days.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Apr 15 01:42:06 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 15 Apr 2021 01:42:06 GMT
Subject: RFR: 8203925: tools/javac/importscope/T8193717.java ran out of
 java heap [v2]
In-Reply-To: <1JXr4lZxAIVdzvun1QqH6qaHQM37WciEWCHmZ3XT-Os=.a2f7d741-a7a5-42bc-9cc5-13aaae9fa96f@github.com>
References: <1JXr4lZxAIVdzvun1QqH6qaHQM37WciEWCHmZ3XT-Os=.a2f7d741-a7a5-42bc-9cc5-13aaae9fa96f@github.com>
Message-ID: <bT3KfB-m9AFbifyYGa7LOVniFdMaZjrvUTqmZJDGnME=.da5cb79c-3f4a-429e-a41d-448d105452c0@github.com>

> Hi all,
> 
> Because [JDK-8225054-PATCH](https://github.com/openjdk/jdk/commit/827e5e32264666639d36990edd5e7d0b7e7c78a9) modified `T8193717.java`, changing `private static final int CLASSES = 500000;` to `private static final int CLASSES = 50000;`(500K -> 50K). The error, `out of java heap`, no longer occurs now. And the pre-submit tests of this patch passed. I think `tools/javac/importscope/T8193717.java` could be removed from `ProblemList.txt`.
> 
> 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8203925
 - 8203925: tools/javac/importscope/T8193717.java ran out of java heap

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1998/files
  - new: https://git.openjdk.java.net/jdk/pull/1998/files/a9c3f3d1..6323be61

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

  Stats: 277815 lines in 7216 files changed: 157319 ins; 77393 del; 43103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1998.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1998/head:pull/1998

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Apr 15 01:50:16 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 15 Apr 2021 01:50:16 GMT
Subject: RFR: 8231179: Investigate why
 tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v4]
In-Reply-To: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
References: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
Message-ID: <aEKakU580dZAb60qbdKSc5z0VPNXAZGjjf5kjw1Izrc=.2710cb07-fccd-4301-b4bb-3219eec68819@github.com>

> Hi all,
> 
> The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below.
> 
> 
> @Override @DefinedBy(Api.COMPILER)
> public String getName() {
>     return relativePath.resolveAgainst(userPackageRootDir).toString();  // <-----------------
> }
> 
> 
> And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below
> 
> 
> public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException {
>     String sep = directory.getFileSystem().getSeparator();  // <---------------------
>     return directory.resolve(path.replace("/", sep));
> }
> 
> 
> We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected.
> 
> This patch fixes the test by using the file system separator instead of operating system separator.
> 
> 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 five additional commits since the last revision:

 - Merge branch 'master' into JDK-8231179
 - Merge branch 'master' into JDK-8231179
 - Use StandardJavaFileManager::asPath
 - Modify copyright
 - 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2004/files
  - new: https://git.openjdk.java.net/jdk/pull/2004/files/0cfaae62..a2887ee3

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

  Stats: 221708 lines in 6269 files changed: 133763 ins; 52529 del; 35416 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2004/head:pull/2004

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Apr 15 02:57:47 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 15 Apr 2021 02:57:47 GMT
Subject: RFR: 8203925: tools/javac/importscope/T8193717.java ran out of
 java heap [v2]
In-Reply-To: <bT3KfB-m9AFbifyYGa7LOVniFdMaZjrvUTqmZJDGnME=.da5cb79c-3f4a-429e-a41d-448d105452c0@github.com>
References: <1JXr4lZxAIVdzvun1QqH6qaHQM37WciEWCHmZ3XT-Os=.a2f7d741-a7a5-42bc-9cc5-13aaae9fa96f@github.com>
 <bT3KfB-m9AFbifyYGa7LOVniFdMaZjrvUTqmZJDGnME=.da5cb79c-3f4a-429e-a41d-448d105452c0@github.com>
Message-ID: <brhjgspiKnLhU0_wBOYRDmNmj5xY120g5uSq5Ub-RXQ=.5d62e79e-a40b-49a7-8b53-f6ad270cbe2e@github.com>

On Thu, 15 Apr 2021 01:42:06 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> Because [JDK-8225054-PATCH](https://github.com/openjdk/jdk/commit/827e5e32264666639d36990edd5e7d0b7e7c78a9) modified `T8193717.java`, changing `private static final int CLASSES = 500000;` to `private static final int CLASSES = 50000;`(500K -> 50K). The error, `out of java heap`, no longer occurs now. And the pre-submit tests of this patch passed. I think `tools/javac/importscope/T8193717.java` could be removed from `ProblemList.txt`.
>> 
>> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8203925
>  - 8203925: tools/javac/importscope/T8193717.java ran out of java heap

@vicente-romero-oracle Thank you for your comment. When the number of the `import` statements increases, the `JCImport` tree and other objects in `javac` would increase, too.(In other words, the memory would be gradually used, too) There is no doubt that `out of heap` would occur if the number of the `import` statements becomes so large.

---
I read the original issue [JDK-8193717](https://bugs.openjdk.java.net/browse/JDK-8193717) and found the original number should be 50k instead of 500k. The quote is shown below. We can consider that the 500k is the wrong value.
> Compiling a generated file with about 50 thousand imports

And then, [JDK-8225054-PATCH](https://github.com/openjdk/jdk/commit/827e5e32264666639d36990edd5e7d0b7e7c78a9) fixed it(500k -> 50k). The [JDK-8225054-PATCH](https://github.com/openjdk/jdk/commit/827e5e32264666639d36990edd5e7d0b7e7c78a9) is a big feature(Compiler implementation for records) and some details may be omitted. I think that the authors of the patch forgot to remove `tools/javac/importscope/T8193717.java` from the `ProblemList` when they fixed the bug(500k -> 50k).

---
I merged the master branch code just now to restart the `Pre-submit test`. If the test `tools/javac/importscope/T8193717.java` passes at the `Pre-submit test`, I think it is good to remove it from the `ProblemList`.

What's your opinion? Maybe the authors of the [JDK-8225054-PATCH](https://github.com/openjdk/jdk/commit/827e5e32264666639d36990edd5e7d0b7e7c78a9) could give more information. Any idea is appreciated.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Apr 15 03:10:46 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 15 Apr 2021 03:10:46 GMT
Subject: RFR: 8231179: Investigate why
 tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v4]
In-Reply-To: <aEKakU580dZAb60qbdKSc5z0VPNXAZGjjf5kjw1Izrc=.2710cb07-fccd-4301-b4bb-3219eec68819@github.com>
References: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
 <aEKakU580dZAb60qbdKSc5z0VPNXAZGjjf5kjw1Izrc=.2710cb07-fccd-4301-b4bb-3219eec68819@github.com>
Message-ID: <oKuoLWZDom8j0bdz1cxqX_F7VXSl5iqbQiYRI6s8A4Q=.784f6b5f-40e8-4704-8008-0c3b5b42b4dc@github.com>

On Thu, 15 Apr 2021 01:50:16 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below.
>> 
>> 
>> @Override @DefinedBy(Api.COMPILER)
>> public String getName() {
>>     return relativePath.resolveAgainst(userPackageRootDir).toString();  // <-----------------
>> }
>> 
>> 
>> And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below
>> 
>> 
>> public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException {
>>     String sep = directory.getFileSystem().getSeparator();  // <---------------------
>>     return directory.resolve(path.replace("/", sep));
>> }
>> 
>> 
>> We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected.
>> 
>> This patch fixes the test by using the file system separator instead of operating system separator.
>> 
>> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8231179
>  - Merge branch 'master' into JDK-8231179
>  - Use StandardJavaFileManager::asPath
>  - Modify copyright
>  - 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window

I merged the code of the master branch just now to see whether the `tools/javac/options/BCPOrSystemNotSpecified.java` passes the `Pre-submit test`. If so, maybe it is time for us to push this patch.

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

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

From vicente.romero at oracle.com  Thu Apr 15 09:14:47 2021
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 15 Apr 2021 05:14:47 -0400
Subject: ping
Message-ID: <7e8f7567-d2fe-120f-3ce5-ff694e284b1e@oracle.com>

Hi,

Please review [1], this one is related to sealed classes and I would 
like to have this smaller issue closed before making sealed final,

Thanks,
Vicente

[1] https://github.com/openjdk/jdk/pull/3273

From vromero at openjdk.java.net  Thu Apr 15 09:22:46 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 15 Apr 2021 09:22:46 GMT
Subject: RFR: 8203925: tools/javac/importscope/T8193717.java ran out of
 java heap [v2]
In-Reply-To: <bT3KfB-m9AFbifyYGa7LOVniFdMaZjrvUTqmZJDGnME=.da5cb79c-3f4a-429e-a41d-448d105452c0@github.com>
References: <1JXr4lZxAIVdzvun1QqH6qaHQM37WciEWCHmZ3XT-Os=.a2f7d741-a7a5-42bc-9cc5-13aaae9fa96f@github.com>
 <bT3KfB-m9AFbifyYGa7LOVniFdMaZjrvUTqmZJDGnME=.da5cb79c-3f4a-429e-a41d-448d105452c0@github.com>
Message-ID: <_t2AcWaKriAGmPW7A8aQXF24_qHifKJm_wfP3iZi14E=.d0aa14bb-7810-4b8f-ba3f-6526c3b15ba9@github.com>

On Thu, 15 Apr 2021 01:42:06 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> Because [JDK-8225054-PATCH](https://github.com/openjdk/jdk/commit/827e5e32264666639d36990edd5e7d0b7e7c78a9) modified `T8193717.java`, changing `private static final int CLASSES = 500000;` to `private static final int CLASSES = 50000;`(500K -> 50K). The error, `out of java heap`, no longer occurs now. And the pre-submit tests of this patch passed. I think `tools/javac/importscope/T8193717.java` could be removed from `ProblemList.txt`.
>> 
>> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8203925
>  - 8203925: tools/javac/importscope/T8193717.java ran out of java heap

Marked as reviewed by vromero (Reviewer).

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

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

From jlahoda at openjdk.java.net  Thu Apr 15 10:24:36 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 15 Apr 2021 10:24:36 GMT
Subject: RFR: 8264373: javac hangs when annotation is declared with sealed
 public modifier
In-Reply-To: <J355B6uV8DqWLzGyKNxsLu5hv6N4BRK3V1qJHtVydes=.c285eff5-490f-47c8-999c-7634dd86fac7@github.com>
References: <J355B6uV8DqWLzGyKNxsLu5hv6N4BRK3V1qJHtVydes=.c285eff5-490f-47c8-999c-7634dd86fac7@github.com>
Message-ID: <E1kfly2Vkx4FVXCzfKc84eWbj-uSmNc7lZrpoS1VhLs=.80fcc63e-6b13-4128-931e-f22933c43167@github.com>

On Tue, 30 Mar 2021 16:41:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this one liner fix. Although the title mentions the `sealed` modifier, the issue is not strictly related to it. Basically the situation is the following: modifiers `sealed` + `annotation` can't be applied together meaning that this declaration:
> 
> sealed public @interface SealedTest { }
> 
> 
> should be rejected by the compiler. We check this assertion at method: `Check::checkFlags` which then invokes `Check::checkDisjoint` which at the end invokes `TreeInfo::firstFlag` to find out what is the first low order bit set to 1 in the intersection between the current symbol flags and subset of them. Now the current implementation of this method is:
> 
> 
>     public static long firstFlag(long flags) {
>         long flag = 1;
>         while ((flag & flags & ExtendedStandardFlags) == 0)
>             flag = flag << 1;
>         return flag;
>     }
> 
> but given that `ExtendedStandardFlags` is defined as: `StandardFlags | DEFAULT | SEALED | NON_SEALED` and `StandardFlags` is: `0x0FFF` which if we intersect with the ANNOTATION flag (1<<13) will always return 0, the the loop executes forever. I guess we didn't see this issue before because we didn't had a constraint involving a flag with a value > 0x0FFF and less than 0xFFFF which is the case of the ANNOTATION flag. It seems to me that we can safely drop the `& ExtendedStandardFlags` in method `TreeInfo::firstFlag` given that it is used only by Check::checkDisjoint and it is invoked with an intersection of the current flags and the subset the invoking method cares about. So it won't be possible for the argument of `TreeInfo::firstFlag` to contain some javac internal flags we don't want a compiler user to see. What do you think?

Looks good.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.java.net  Thu Apr 15 11:36:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 15 Apr 2021 11:36:04 GMT
Subject: RFR: JDK-8265270: Type.getEnclosingType() may fail with
 CompletionFailure
Message-ID: <-ah4gNm7azRuo-7-WA6UFBPTg6lR9x_9V51acObmE_M=.760642c2-02da-47d4-9a66-e008af841573@github.com>

The setup is a little bit tricky, but it may happen that user code calls `Type{Mirror}.getEnclosingType()` (or e.g. `Type{Mirror}.toString()` which will in turn invoke `getEnclosingType()`), and the method may throw the `CompletionFailure` (internal) exception. The reason is that the corresponding Symbol is completed using a `complete` method, instead of `apiComplete` method, which is intended to be used in API methods. `apiComplete` does the same as `complete` when running in a javac context, but will suppress the exception when the API method was invoked from a user code, avoiding the exception.

The proposed change is to use `apiComplete`, as it should be done in implementations of API methods.

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

Commit messages:
 - JDK-8265270: Type.getEnclosingType() may fail with CompletionFailure

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

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

From dad4had at gmail.com  Thu Apr 15 14:38:53 2021
From: dad4had at gmail.com (IvaN Cabral)
Date: Thu, 15 Apr 2021 09:38:53 -0500
Subject: No subject
Message-ID: <CA+ooNYYQVo1bCAX8fwoWY2DehXq+RBw5JjEPj2=ERpZ4PbahNA@mail.gmail.com>

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

From jlahoda at openjdk.java.net  Thu Apr 15 16:39:00 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 15 Apr 2021 16:39:00 GMT
Subject: RFR: 8263452: Javac slow compilation due to algorithmic complexity
Message-ID: <E08ZDwDImMWNy_8BhR31z2ijeDxKf_ErShsAs3gfLnk=.43946497-a910-4774-9220-e56d7d04f699@github.com>

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.

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

Commit messages:
 - Improving order of Flag constants.
 - 8263452: Javac slow compilation due to algorithmic complexity

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

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

From vromero at openjdk.java.net  Thu Apr 15 17:29:58 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 15 Apr 2021 17:29:58 GMT
Subject: RFR: 8264373: javac hangs when annotation is declared with sealed
 public modifier [v2]
In-Reply-To: <J355B6uV8DqWLzGyKNxsLu5hv6N4BRK3V1qJHtVydes=.c285eff5-490f-47c8-999c-7634dd86fac7@github.com>
References: <J355B6uV8DqWLzGyKNxsLu5hv6N4BRK3V1qJHtVydes=.c285eff5-490f-47c8-999c-7634dd86fac7@github.com>
Message-ID: <0JvGXOty7BoRF3iNkPp6yYoLKQXqbMOkXFIVN_8VApo=.c945fd5d-5d3b-46e4-838c-12905a653517@github.com>

> Please review this one liner fix. Although the title mentions the `sealed` modifier, the issue is not strictly related to it. Basically the situation is the following: modifiers `sealed` + `annotation` can't be applied together meaning that this declaration:
> 
> sealed public @interface SealedTest { }
> 
> 
> should be rejected by the compiler. We check this assertion at method: `Check::checkFlags` which then invokes `Check::checkDisjoint` which at the end invokes `TreeInfo::firstFlag` to find out what is the first low order bit set to 1 in the intersection between the current symbol flags and subset of them. Now the current implementation of this method is:
> 
> 
>     public static long firstFlag(long flags) {
>         long flag = 1;
>         while ((flag & flags & ExtendedStandardFlags) == 0)
>             flag = flag << 1;
>         return flag;
>     }
> 
> but given that `ExtendedStandardFlags` is defined as: `StandardFlags | DEFAULT | SEALED | NON_SEALED` and `StandardFlags` is: `0x0FFF` which if we intersect with the ANNOTATION flag (1<<13) will always return 0, the the loop executes forever. I guess we didn't see this issue before because we didn't had a constraint involving a flag with a value > 0x0FFF and less than 0xFFFF which is the case of the ANNOTATION flag. It seems to me that we can safely drop the `& ExtendedStandardFlags` in method `TreeInfo::firstFlag` given that it is used only by Check::checkDisjoint and it is invoked with an intersection of the current flags and the subset the invoking method cares about. So it won't be possible for the argument of `TreeInfo::firstFlag` to contain some javac internal flags we don't want a compiler user to see. What do you think?

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-8264373
 - 8264373: javac hangs when annotation is declared with sealed public modifier

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3273/files
  - new: https://git.openjdk.java.net/jdk/pull/3273/files/190ddd0a..9b5fb848

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

  Stats: 50947 lines in 1477 files changed: 34462 ins; 11107 del; 5378 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3273/head:pull/3273

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

From vromero at openjdk.java.net  Thu Apr 15 19:10:35 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 15 Apr 2021 19:10:35 GMT
Subject: Integrated: 8264373: javac hangs when annotation is declared with
 sealed public modifier
In-Reply-To: <J355B6uV8DqWLzGyKNxsLu5hv6N4BRK3V1qJHtVydes=.c285eff5-490f-47c8-999c-7634dd86fac7@github.com>
References: <J355B6uV8DqWLzGyKNxsLu5hv6N4BRK3V1qJHtVydes=.c285eff5-490f-47c8-999c-7634dd86fac7@github.com>
Message-ID: <QMtZZwyrQpcqlvAAXyTi-4e67BZkYsSkzdWNOWCLKiQ=.56bd4438-01ac-4791-a2d8-9fa226143fd8@github.com>

On Tue, 30 Mar 2021 16:41:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this one liner fix. Although the title mentions the `sealed` modifier, the issue is not strictly related to it. Basically the situation is the following: modifiers `sealed` + `annotation` can't be applied together meaning that this declaration:
> 
> sealed public @interface SealedTest { }
> 
> 
> should be rejected by the compiler. We check this assertion at method: `Check::checkFlags` which then invokes `Check::checkDisjoint` which at the end invokes `TreeInfo::firstFlag` to find out what is the first low order bit set to 1 in the intersection between the current symbol flags and subset of them. Now the current implementation of this method is:
> 
> 
>     public static long firstFlag(long flags) {
>         long flag = 1;
>         while ((flag & flags & ExtendedStandardFlags) == 0)
>             flag = flag << 1;
>         return flag;
>     }
> 
> but given that `ExtendedStandardFlags` is defined as: `StandardFlags | DEFAULT | SEALED | NON_SEALED` and `StandardFlags` is: `0x0FFF` which if we intersect with the ANNOTATION flag (1<<13) will always return 0, the the loop executes forever. I guess we didn't see this issue before because we didn't had a constraint involving a flag with a value > 0x0FFF and less than 0xFFFF which is the case of the ANNOTATION flag. It seems to me that we can safely drop the `& ExtendedStandardFlags` in method `TreeInfo::firstFlag` given that it is used only by Check::checkDisjoint and it is invoked with an intersection of the current flags and the subset the invoking method cares about. So it won't be possible for the argument of `TreeInfo::firstFlag` to contain some javac internal flags we don't want a compiler user to see. What do you think?

This pull request has now been integrated.

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

8264373: javac hangs when annotation is declared with sealed public modifier

Reviewed-by: jlahoda

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

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

From vromero at openjdk.java.net  Thu Apr 15 20:24:34 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 15 Apr 2021 20:24:34 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: <r3XqoPCU669FVjA2Ol-HXYVIothKsM8z0UkyqgqsiO8=.c4c01b73-6d72-4e66-9f61-8eff8f71c222@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 sensible

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Fri Apr 16 01:15:58 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 01:15:58 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature
Message-ID: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@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.

Thanks

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

Commit messages:
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - fixing failing regression tests
 - JVM related changes
 - 8260517: Compiler implementation for Sealed Classes

Changes: https://git.openjdk.java.net/jdk/pull/3526/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260517
  Stats: 450 lines in 56 files changed: 48 ins; 282 del; 120 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  Fri Apr 16 02:01:48 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 02:01:48 GMT
Subject: RFR: 8265319: implement Sealed Classes as a standard feature in Java,
 javax.lang.model changes
Message-ID: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>

Please review the changes needed in javax.lang.model API to make Sealed Classes a final feature in Java,

Thanks,

note: this PR is related to [PR-3526](https://github.com/openjdk/jdk/pull/3526)

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

Commit messages:
 - 8265319: implement Sealed Classes as a standard feature in Java, javax.lang.model changes

Changes: https://git.openjdk.java.net/jdk/pull/3528/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3528&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265319
  Stats: 9 lines in 2 files changed: 0 ins; 6 del; 3 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 dholmes at openjdk.java.net  Fri Apr 16 02:14:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Apr 2021 02:14:02 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v2]
In-Reply-To: <Llnn9ItDfpg4apLNxPsV_YEwhic9cLOYJZ7TO7e6U7A=.17db82ff-2b75-4efa-8f8e-2a80363ee3cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <Llnn9ItDfpg4apLNxPsV_YEwhic9cLOYJZ7TO7e6U7A=.17db82ff-2b75-4efa-8f8e-2a80363ee3cc@github.com>
Message-ID: <Y_Gtqn1nI1-LxCYiuYEB-cGh85zCgvX3ms5Jb95QlGI=.bdd26a69-18cd-4680-adcc-6a500bb4f3c9@github.com>

On Fri, 16 Apr 2021 02:11:10 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:
> 
>   removing javax.lang.model changes

Hi Vincente,

Hotspot and hotspot tests all look fine. One query: why was this test removed?

 test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java

is that functionality tested elsewhere? (The other deleted test seemed obviously trivial.)

Thanks,
David

src/hotspot/share/classfile/classFileParser.cpp line 3916:

> 3914:             record_attribute_start = cfs->current();
> 3915:             record_attribute_length = attribute_length;
> 3916:           } else if (_major_version >= JAVA_17_VERSION) {

Can you update the comment at L3932 to say JAVA_17_VERSION please.

src/hotspot/share/classfile/classFileParser.hpp line 345:

> 343: 
> 344:   bool supports_sealed_types();
> 345:   bool supports_records();

Good catch!

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

Marked as reviewed by dholmes (Reviewer).

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

From vromero at openjdk.java.net  Fri Apr 16 02:14:01 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 02:14:01 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v2]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <Llnn9ItDfpg4apLNxPsV_YEwhic9cLOYJZ7TO7e6U7A=.17db82ff-2b75-4efa-8f8e-2a80363ee3cc@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:

  removing javax.lang.model changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/6e2a99c6..5aef5108

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

  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 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  Fri Apr 16 03:26:34 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 03:26:34 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v2]
In-Reply-To: <Y_Gtqn1nI1-LxCYiuYEB-cGh85zCgvX3ms5Jb95QlGI=.bdd26a69-18cd-4680-adcc-6a500bb4f3c9@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <Llnn9ItDfpg4apLNxPsV_YEwhic9cLOYJZ7TO7e6U7A=.17db82ff-2b75-4efa-8f8e-2a80363ee3cc@github.com>
 <Y_Gtqn1nI1-LxCYiuYEB-cGh85zCgvX3ms5Jb95QlGI=.bdd26a69-18cd-4680-adcc-6a500bb4f3c9@github.com>
Message-ID: <DeHK882Tz7EuaIN3cMmuHGyCm1HFPwiBG31dVb9OMy0=.df2bc23b-34e1-40f3-be52-82fc4393dd06@github.com>

On Fri, 16 Apr 2021 02:10:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Vicente,
> 
> Hotspot and hotspot tests all look fine. One query: why was this test removed?
> 
> test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java
> 
> is that functionality tested elsewhere? (The other deleted test seemed obviously trivial.)
> 
> Thanks,
> David

Hi David, thanks for your comments, yes regarding `test test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java`, it was removed because the functionality is tested in `test/langtools/tools/javac/sealed/SealedCompilationTests.java`

> src/hotspot/share/classfile/classFileParser.cpp line 3916:
> 
>> 3914:             record_attribute_start = cfs->current();
>> 3915:             record_attribute_length = attribute_length;
>> 3916:           } else if (_major_version >= JAVA_17_VERSION) {
> 
> Can you update the comment at L3932 to say JAVA_17_VERSION please.

sure

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

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

From vromero at openjdk.java.net  Fri Apr 16 03:35:06 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 03:35:06 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v3]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <G43LId0M-ZZiM447iIsG4geyGogSR7HryckiLcXDj6I=.82585196-9db7-45fc-9688-b9ef9d2507ab@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:

  updating comment after review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/5aef5108..8ebe56fd

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 darcy at openjdk.java.net  Fri Apr 16 04:07:40 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 16 Apr 2021 04:07:40 GMT
Subject: RFR: 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: <SbHvmTkwkBXYRRZimmlS9gLzsZIFf917TgVwdp8dFLg=.bf0f9440-85e9-42ea-8d2b-4d13e0864592@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)

Looks fine.

Seems that the associated test updates are being done under the related PR.

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

Marked as reviewed by darcy (Reviewer).

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

From vromero at openjdk.java.net  Fri Apr 16 04:42:34 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 04:42:34 GMT
Subject: RFR: 8265319: implement Sealed Classes as a standard feature in
 Java, javax.lang.model changes
In-Reply-To: <SbHvmTkwkBXYRRZimmlS9gLzsZIFf917TgVwdp8dFLg=.bf0f9440-85e9-42ea-8d2b-4d13e0864592@github.com>
References: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
 <SbHvmTkwkBXYRRZimmlS9gLzsZIFf917TgVwdp8dFLg=.bf0f9440-85e9-42ea-8d2b-4d13e0864592@github.com>
Message-ID: <BBCQNYwKdlCxT_N2pquQaHxId4Fznc00UUeOcRcXZDI=.612bd248-6c9b-484f-b541-8462811e2ce6@github.com>

On Fri, 16 Apr 2021 04:04:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Looks fine.
> 
> Seems that the associated test updates are being done under the related PR.

thanks, correct they are in the related PR

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

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

From shade at openjdk.java.net  Fri Apr 16 08:06:35 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 16 Apr 2021 08:06:35 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone
In-Reply-To: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
Message-ID: <SvLloYg_72eiBxC1MwqntCuaNmyOIpCabPkmji4qzoQ=.25e1c2af-424a-4cc0-9430-6cd7f6f0f928@github.com>

On Sat, 30 Jan 2021 08:50:53 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> If the argument `Type t` of the method `Types.unboxedType` is an `ErrorType`, the `Types.unboxedType` may return the wrong result. And in this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return the wrong result, too.
> 
> This patch fixes it and adds a test case.
> Thank you for taking the time to review.
> 
> Best Regards.
> -- xiong

I think we want to ping @lahodaj to see if this makes sense.

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

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

From jfranck at openjdk.java.net  Fri Apr 16 08:52:36 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Fri, 16 Apr 2021 08:52:36 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: <HQRLZwbsZv0utyGtaqh2jkHJ2bIwh9FEo_0h5YMpMI4=.3d6e7705-5353-477c-b3c9-0ddadcb4e418@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.

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

> 5094:             // First, attribute superclass.
> 5095:             if (st.hasTag(CLASS))
> 5096:                 attribClass((ClassSymbol)st.tsym);

This looks like a guarding against a special case of attributing something twice. Did you consider pushing this into attribClass instead so that calling it a second time is a no-op?

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Apr 16 15:41:37 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 16 Apr 2021 15:41:37 GMT
Subject: Integrated: 8203925: tools/javac/importscope/T8193717.java ran out of
 java heap
In-Reply-To: <1JXr4lZxAIVdzvun1QqH6qaHQM37WciEWCHmZ3XT-Os=.a2f7d741-a7a5-42bc-9cc5-13aaae9fa96f@github.com>
References: <1JXr4lZxAIVdzvun1QqH6qaHQM37WciEWCHmZ3XT-Os=.a2f7d741-a7a5-42bc-9cc5-13aaae9fa96f@github.com>
Message-ID: <mGD9cOCQYbn3B5DTWi5PWLWvAb9cT90Zfof9wcJX0BA=.557d6bf8-423e-4114-bb06-dcf2f1cc530f@github.com>

On Fri, 8 Jan 2021 08:12:45 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> Because [JDK-8225054-PATCH](https://github.com/openjdk/jdk/commit/827e5e32264666639d36990edd5e7d0b7e7c78a9) modified `T8193717.java`, changing `private static final int CLASSES = 500000;` to `private static final int CLASSES = 50000;`(500K -> 50K). The error, `out of java heap`, no longer occurs now. And the pre-submit tests of this patch passed. I think `tools/javac/importscope/T8193717.java` could be removed from `ProblemList.txt`.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: cee4f1d9
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cee4f1d9
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8203925: tools/javac/importscope/T8193717.java ran out of java heap

Reviewed-by: vromero

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

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

From mcimadamore at openjdk.java.net  Fri Apr 16 15:57:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 16 Apr 2021 15:57:40 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone
In-Reply-To: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
Message-ID: <Yb5oMV3hW0jpbJpV6UHPDhUDr60juoGVZqe61m6KYu4=.44f53bf1-4220-4324-9ff1-f150c6775fb5@github.com>

On Sat, 30 Jan 2021 08:50:53 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> If the argument `Type t` of the method `Types.unboxedType` is an `ErrorType`, the `Types.unboxedType` may return the wrong result. And in this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return the wrong result, too.
> 
> This patch fixes it and adds a test case.
> Thank you for taking the time to review.
> 
> Best Regards.
> -- xiong

The fix looks good - it's a good "quality of life" fix, which improves the conditional classification by making it more resilient to erroneous types. I wonder if the fix can be made more minimal (see code comment).

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 4326:

> 4324:      */
> 4325:     public Type unboxedType(Type t) {
> 4326:         if (t.hasTag(ERROR))

This is not necessary, right? After all, you check for errors upfront, in the conditional code. Reason I'm asking is that it's not clear to me as to whether we should just return the error type, or no type. Also, this might affect code which is unrelated to the one you are fixing.

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

> 1957:         //where
> 1958:             boolean primitiveOrBoxed(Type t) {
> 1959:                 return (!t.hasTag(TYPEVAR) && !t.hasTag(ERROR) && types.unboxedTypeOrType(t).isPrimitive());

Good catch - you can also use `!t.isErroneous()` here.

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

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

From jlahoda at openjdk.java.net  Fri Apr 16 16:58:36 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 16 Apr 2021 16:58:36 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone
In-Reply-To: <Yb5oMV3hW0jpbJpV6UHPDhUDr60juoGVZqe61m6KYu4=.44f53bf1-4220-4324-9ff1-f150c6775fb5@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
 <Yb5oMV3hW0jpbJpV6UHPDhUDr60juoGVZqe61m6KYu4=.44f53bf1-4220-4324-9ff1-f150c6775fb5@github.com>
Message-ID: <_Iyqer8frhkufmLUH19u5fcfy6XqQdKauGpun9hZMP0=.58a45090-bbb1-46fe-aa91-ca36d483e80a@github.com>

On Fri, 16 Apr 2021 15:53:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> If the argument `Type t` of the method `Types.unboxedType` is an `ErrorType`, the `Types.unboxedType` may return the wrong result. And in this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return the wrong result, too.
>> 
>> This patch fixes it and adds a test case.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>> -- xiong
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 4326:
> 
>> 4324:      */
>> 4325:     public Type unboxedType(Type t) {
>> 4326:         if (t.hasTag(ERROR))
> 
> This is not necessary, right? After all, you check for errors upfront, in the conditional code. Reason I'm asking is that it's not clear to me as to whether we should just return the error type, or no type. Also, this might affect code which is unrelated to the one you are fixing.

(I am not an expert on types, so I may be wrong.)

This method seems to return either the primitive type for which `t` is a box, or `noType`. So returning a `noType` for erroneous type seems reasonable to me. Basically, it would mean that an erroneous type is not a box for any type, which seems sensible. (Currently, every erroneous type is seen as the box for the first primitive type in the sequence, which I think is `byte`.)

I agree only one of these two changes is needed, although I'd personally probably try to go with the one here, in `unboxedType`, as it seems like a generally desirable behavior to me. I agree it can have effects on other parts of the code, though, so it has more potential to break something.

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

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

From mcimadamore at openjdk.java.net  Fri Apr 16 17:29:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 16 Apr 2021 17:29:43 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone
In-Reply-To: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
Message-ID: <fo3ng4FuDo4_Ax0LkqgROu_XOIkZequWMXHR3NkX2Q4=.48553cd3-a9e6-4724-bb27-7bec36319740@github.com>

On Sat, 30 Jan 2021 08:50:53 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> If the argument `Type t` of the method `Types.unboxedType` is an `ErrorType`, the `Types.unboxedType` may return the wrong result. And in this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return the wrong result, too.
> 
> This patch fixes it and adds a test case.
> Thank you for taking the time to review.
> 
> Best Regards.
> -- xiong

Marked as reviewed by mcimadamore (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Fri Apr 16 17:29:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 16 Apr 2021 17:29:43 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone
In-Reply-To: <_Iyqer8frhkufmLUH19u5fcfy6XqQdKauGpun9hZMP0=.58a45090-bbb1-46fe-aa91-ca36d483e80a@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
 <Yb5oMV3hW0jpbJpV6UHPDhUDr60juoGVZqe61m6KYu4=.44f53bf1-4220-4324-9ff1-f150c6775fb5@github.com>
 <_Iyqer8frhkufmLUH19u5fcfy6XqQdKauGpun9hZMP0=.58a45090-bbb1-46fe-aa91-ca36d483e80a@github.com>
Message-ID: <B9a31KOzog51S5EpDhXhG4z0kkCGeGJVQn6IzIvpmmM=.793048e6-eaab-4c54-97c9-3bd803304713@github.com>

On Fri, 16 Apr 2021 16:55:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 4326:
>> 
>>> 4324:      */
>>> 4325:     public Type unboxedType(Type t) {
>>> 4326:         if (t.hasTag(ERROR))
>> 
>> This is not necessary, right? After all, you check for errors upfront, in the conditional code. Reason I'm asking is that it's not clear to me as to whether we should just return the error type, or no type. Also, this might affect code which is unrelated to the one you are fixing.
>
> (I am not an expert on types, so I may be wrong.)
> 
> This method seems to return either the primitive type for which `t` is a box, or `noType`. So returning a `noType` for erroneous type seems reasonable to me. Basically, it would mean that an erroneous type is not a box for any type, which seems sensible. (Currently, every erroneous type is seen as the box for the first primitive type in the sequence, which I think is `byte`.)
> 
> I agree only one of these two changes is needed, although I'd personally probably try to go with the one here, in `unboxedType`, as it seems like a generally desirable behavior to me. I agree it can have effects on other parts of the code, though, so it has more potential to break something.

I'm ok with going for the proposed fix, as long as tests are ok. Approving.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Apr 17 04:13:36 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 17 Apr 2021 04:13:36 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone
In-Reply-To: <B9a31KOzog51S5EpDhXhG4z0kkCGeGJVQn6IzIvpmmM=.793048e6-eaab-4c54-97c9-3bd803304713@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
 <Yb5oMV3hW0jpbJpV6UHPDhUDr60juoGVZqe61m6KYu4=.44f53bf1-4220-4324-9ff1-f150c6775fb5@github.com>
 <_Iyqer8frhkufmLUH19u5fcfy6XqQdKauGpun9hZMP0=.58a45090-bbb1-46fe-aa91-ca36d483e80a@github.com>
 <B9a31KOzog51S5EpDhXhG4z0kkCGeGJVQn6IzIvpmmM=.793048e6-eaab-4c54-97c9-3bd803304713@github.com>
Message-ID: <h2I3URRvdPfU0jgCCTUQS3rH9UgdPgf6ayzA24TT3Kg=.28e7f9b1-fdd7-408c-a888-15619453b6a2@github.com>

On Fri, 16 Apr 2021 17:26:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> (I am not an expert on types, so I may be wrong.)
>> 
>> This method seems to return either the primitive type for which `t` is a box, or `noType`. So returning a `noType` for erroneous type seems reasonable to me. Basically, it would mean that an erroneous type is not a box for any type, which seems sensible. (Currently, every erroneous type is seen as the box for the first primitive type in the sequence, which I think is `byte`.)
>> 
>> I agree only one of these two changes is needed, although I'd personally probably try to go with the one here, in `unboxedType`, as it seems like a generally desirable behavior to me. I agree it can have effects on other parts of the code, though, so it has more potential to break something.
>
> I'm ok with going for the proposed fix, as long as tests are ok. Approving.

Yes, this is not necessary if we only solve this bug. But it is useful logically. And all the related tests passed locally and passed at the `Pre-submit tests`. So I think it is good to remain it.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Apr 17 07:27:55 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 17 Apr 2021 07:27:55 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone [v2]
In-Reply-To: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
Message-ID: <R8e_Xl3svxqUlJmZna3ddXZY9rgychL1iFyzyjc4YqE=.05c29601-f01b-4cc7-a251-b6f80b7490d5@github.com>

> Hi all,
> 
> If the argument `Type t` of the method `Types.unboxedType` is an `ErrorType`, the `Types.unboxedType` may return the wrong result. And in this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return the wrong result, too.
> 
> This patch fixes it and adds a test case.
> Thank you for taking the time to review.
> 
> Best Regards.
> -- xiong

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

  Use method isErroneous

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2324/files
  - new: https://git.openjdk.java.net/jdk/pull/2324/files/bf5e88f1..2fe7665d

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

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Apr 17 07:27:57 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 17 Apr 2021 07:27:57 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone [v2]
In-Reply-To: <Yb5oMV3hW0jpbJpV6UHPDhUDr60juoGVZqe61m6KYu4=.44f53bf1-4220-4324-9ff1-f150c6775fb5@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
 <Yb5oMV3hW0jpbJpV6UHPDhUDr60juoGVZqe61m6KYu4=.44f53bf1-4220-4324-9ff1-f150c6775fb5@github.com>
Message-ID: <9FjETXbXJpFjR_on0XyQqZaK3iwp0VrysQ99YrhXtFI=.0582cdc9-767a-4388-aed3-db647ccf5405@github.com>

On Fri, 16 Apr 2021 15:54:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use method isErroneous
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1959:
> 
>> 1957:         //where
>> 1958:             boolean primitiveOrBoxed(Type t) {
>> 1959:                 return (!t.hasTag(TYPEVAR) && !t.hasTag(ERROR) && types.unboxedTypeOrType(t).isPrimitive());
> 
> Good catch - you can also use `!t.isErroneous()` here.

Fixed.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Apr 17 15:16:13 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 17 Apr 2021 15:16:13 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone [v3]
In-Reply-To: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
Message-ID: <21RCFGIvfPEv6_b2rV84dnk6w-36ZDUaFNZrqyxJBJI=.86fd46ec-6be9-4aa8-aa61-14bcfd260df4@github.com>

> Hi all,
> 
> If the argument `Type t` of the method `Types.unboxedType` is an `ErrorType`, the `Types.unboxedType` may return the wrong result. And in this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return the wrong result, too.
> 
> This patch fixes it and adds a test case.
> Thank you for taking the time to review.
> 
> Best Regards.
> -- xiong

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

 -  Merge branch 'master' into JDK-8200145
 - Use method isErroneous
 - 8200145: Conditional expression mistakenly treated as standalone

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2324/files
  - new: https://git.openjdk.java.net/jdk/pull/2324/files/2fe7665d..ec4c6402

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

  Stats: 238854 lines in 6772 files changed: 141667 ins; 67989 del; 29198 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2324/head:pull/2324

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Apr 17 16:13:47 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 17 Apr 2021 16:13:47 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone [v3]
In-Reply-To: <21RCFGIvfPEv6_b2rV84dnk6w-36ZDUaFNZrqyxJBJI=.86fd46ec-6be9-4aa8-aa61-14bcfd260df4@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
 <21RCFGIvfPEv6_b2rV84dnk6w-36ZDUaFNZrqyxJBJI=.86fd46ec-6be9-4aa8-aa61-14bcfd260df4@github.com>
Message-ID: <k4KLBFDdZAvUNVZquD6FBpd3FbTEfdJFd7cB-auJkc8=.e27b2b0e-cf06-4770-9dc8-1551b1c87803@github.com>

On Sat, 17 Apr 2021 15:16:13 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> If the argument `Type t` of the method `Types.unboxedType` is an `ErrorType`, the `Types.unboxedType` may return the wrong result. And in this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return the wrong result, too.
>> 
>> This patch fixes it and adds a test case.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>> -- xiong
>
> 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 three additional commits since the last revision:
> 
>  -  Merge branch 'master' into JDK-8200145
>  - Use method isErroneous
>  - 8200145: Conditional expression mistakenly treated as standalone

I updated the code according to the comment. Thank you for reviewing again and sponsoring.

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

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

From dad4had at gmail.com  Sat Apr 17 17:59:50 2021
From: dad4had at gmail.com (IvaN Cabral)
Date: Sat, 17 Apr 2021 12:59:50 -0500
Subject: compiler-dev Digest, Vol 168, Issue 19
In-Reply-To: <mailman.1.1618660500.1807.compiler-dev@openjdk.java.net>
References: <mailman.1.1618660500.1807.compiler-dev@openjdk.java.net>
Message-ID: <CA+ooNYZR9gVbWuUeWBj=yq62RjeyDNp49xTNhAe3eeqSa25U=g@mail.gmail.com>

Ok

A s?bado, 17/04/2021, 6:55 AM, <compiler-dev-request at openjdk.java.net>
escreveu:

> Send compiler-dev mailing list submissions to
>         compiler-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.openjdk.java.net/mailman/listinfo/compiler-dev
> or, via email, send a message with subject or body 'help' to
>         compiler-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>         compiler-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of compiler-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: RFR: 8200145: Conditional expression mistakenly treated
>       as standalone [v2] (Guoxiong Li)
>    2. Re: RFR: 8200145: Conditional expression mistakenly treated
>       as standalone [v2] (Guoxiong Li)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 17 Apr 2021 07:27:55 GMT
> From: Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.java.net>
> To: <compiler-dev at openjdk.java.net>
> Subject: Re: RFR: 8200145: Conditional expression mistakenly treated
>         as standalone [v2]
> Message-ID:
>         <R8e_Xl3svxqUlJmZna3ddXZY9rgychL1iFyzyjc4YqE=.
> 05c29601-f01b-4cc7-a251-b6f80b7490d5 at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> > Hi all,
> >
> > If the argument `Type t` of the method `Types.unboxedType` is an
> `ErrorType`, the `Types.unboxedType` may return the wrong result. And in
> this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return
> the wrong result, too.
> >
> > This patch fixes it and adds a test case.
> > Thank you for taking the time to review.
> >
> > Best Regards.
> > -- xiong
>
> Guoxiong Li has updated the pull request incrementally with one additional
> commit since the last revision:
>
>   Use method isErroneous
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.java.net/jdk/pull/2324/files
>   - new:
> https://git.openjdk.java.net/jdk/pull/2324/files/bf5e88f1..2fe7665d
>
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2324&range=01
>  - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2324&range=00-01
>
>   Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/2324.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk
> pull/2324/head:pull/2324
>
> PR: https://git.openjdk.java.net/jdk/pull/2324
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 17 Apr 2021 07:27:57 GMT
> From: Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.java.net>
> To: <compiler-dev at openjdk.java.net>
> Subject: Re: RFR: 8200145: Conditional expression mistakenly treated
>         as standalone [v2]
> Message-ID:
>         <9FjETXbXJpFjR_on0XyQqZaK3iwp0VrysQ99YrhXtFI=.
> 0582cdc9-767a-4388-aed3-db647ccf5405 at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, 16 Apr 2021 15:54:05 GMT, Maurizio Cimadamore <
> mcimadamore at openjdk.org> wrote:
>
> >> Guoxiong Li has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >>   Use method isErroneous
> >
> > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line
> 1959:
> >
> >> 1957:         //where
> >> 1958:             boolean primitiveOrBoxed(Type t) {
> >> 1959:                 return (!t.hasTag(TYPEVAR) && !t.hasTag(ERROR) &&
> types.unboxedTypeOrType(t).isPrimitive());
> >
> > Good catch - you can also use `!t.isErroneous()` here.
>
> Fixed.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2324
>
>
> End of compiler-dev Digest, Vol 168, Issue 19
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210417/91984ca3/attachment.htm>

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Apr 19 00:22:41 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 19 Apr 2021 00:22:41 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <PMCKdl-wruSSgvBpylJrWLbU9te3WH_JhfXG9dVXY1g=.8a96ea89-96d4-41fc-a449-546109db6b6b@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <PMCKdl-wruSSgvBpylJrWLbU9te3WH_JhfXG9dVXY1g=.8a96ea89-96d4-41fc-a449-546109db6b6b@github.com>
Message-ID: <cJ57az8nvP2qccxR-ojO7YGz7tDLR5HVv_pqUx5ZMTI=.7e44adf0-0e57-41ee-8768-89e890c1673c@github.com>

On Fri, 5 Mar 2021 21:59:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
>> Two existing tests failed and I fixed it.
>> Currently, all the tests in `test/langtools` passed locally by using the following command.
>> 
>> 
>> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
>> 
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> This looks very good - sorry I missed it. If you reopen I will approve!

@mcimadamore Who should we ping to solve the `reopen` problem? I have several PRs which were closed by the robot and need to be reopen too.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Apr 19 04:36:03 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 19 Apr 2021 04:36:03 GMT
Subject: RFR: 8231179: Investigate why
 tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v5]
In-Reply-To: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
References: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
Message-ID: <7jmnF46PRLbCoyyRe3emdRzMq2fKLdrjrC2DkVP9kAc=.8ef1a06d-9143-4d03-9a3f-b9d4b2fea337@github.com>

> Hi all,
> 
> The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below.
> 
> 
> @Override @DefinedBy(Api.COMPILER)
> public String getName() {
>     return relativePath.resolveAgainst(userPackageRootDir).toString();  // <-----------------
> }
> 
> 
> And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below
> 
> 
> public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException {
>     String sep = directory.getFileSystem().getSeparator();  // <---------------------
>     return directory.resolve(path.replace("/", sep));
> }
> 
> 
> We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected.
> 
> This patch fixes the test by using the file system separator instead of operating system separator.
> 
> 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 six commits:

 - Merge branch 'master' into JDK-8231179
   
   # Conflicts:
   #	test/langtools/ProblemList.txt
 - Merge branch 'master' into JDK-8231179
 - Merge branch 'master' into JDK-8231179
 - Use StandardJavaFileManager::asPath
 - Modify copyright
 - 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window

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

Changes: https://git.openjdk.java.net/jdk/pull/2004/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2004&range=04
  Stats: 10 lines in 2 files changed: 6 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2004/head:pull/2004

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Apr 19 04:36:10 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 19 Apr 2021 04:36:10 GMT
Subject: RFR: 8231179: Investigate why
 tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v4]
In-Reply-To: <aEKakU580dZAb60qbdKSc5z0VPNXAZGjjf5kjw1Izrc=.2710cb07-fccd-4301-b4bb-3219eec68819@github.com>
References: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
 <aEKakU580dZAb60qbdKSc5z0VPNXAZGjjf5kjw1Izrc=.2710cb07-fccd-4301-b4bb-3219eec68819@github.com>
Message-ID: <JV54drhQciVdF0jnhHXY5xAjkgD-r4dvOYYAilwWH3c=.093d6018-fa89-4a10-b975-56974be7bffc@github.com>

On Thu, 15 Apr 2021 01:50:16 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below.
>> 
>> 
>> @Override @DefinedBy(Api.COMPILER)
>> public String getName() {
>>     return relativePath.resolveAgainst(userPackageRootDir).toString();  // <-----------------
>> }
>> 
>> 
>> And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below
>> 
>> 
>> public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException {
>>     String sep = directory.getFileSystem().getSeparator();  // <---------------------
>>     return directory.resolve(path.replace("/", sep));
>> }
>> 
>> 
>> We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected.
>> 
>> This patch fixes the test by using the file system separator instead of operating system separator.
>> 
>> 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-8231179
>  - Merge branch 'master' into JDK-8231179
>  - Use StandardJavaFileManager::asPath
>  - Modify copyright
>  - 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window

I merged the master branch to solve the conflict. Thank you for reviewing.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Apr 19 08:13:38 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 19 Apr 2021 08:13:38 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java [v2]
In-Reply-To: <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
 <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
Message-ID: <u23f1BTuL4PeSGEB-JDqyY90eoQWKgaodFlMi0yUE9A=.384fdd1c-6fa0-49c3-852d-9d4d0ec5dc37@github.com>

On Tue, 22 Dec 2020 18:52:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This code was introduced in main repository under https://bugs.openjdk.java.net/browse/JDK-8006775
>> I checked original commit in `type-annotations/langtools` repository: https://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/71f35e4b93a5
>> Looks like it's not a merge problem.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066694: Strange code in JavacParser.java

Issue is still actual

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

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

From mcimadamore at openjdk.java.net  Mon Apr 19 10:44:38 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 19 Apr 2021 10:44:38 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
Message-ID: <1rpuVofnrbDV7LQZiCDndCZTkypwkELL3qjEAdXXk8Q=.6a2fcf66-2efa-4bf2-9922-b9a3d6745b47@github.com>

On Sun, 27 Dec 2020 14:54:16 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
> Two existing tests failed and I fixed it.
> Currently, all the tests in `test/langtools` passed locally by using the following command.
> 
> 
> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
> 
> 
> Thank you for taking the time to review.
> 
> Best Regards.

@edvbld Can you please help?

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

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

From eastig at amazon.co.uk  Mon Apr 19 11:02:47 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Mon, 19 Apr 2021 11:02:47 +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: <14294007-A41E-4A5C-86BB-1E616ECCDA1C@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 Astigeevich




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/20210419/67549e75/attachment-0001.htm>

From jlaskey at openjdk.java.net  Mon Apr 19 12:03:39 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 19 Apr 2021 12:03:39 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java [v2]
In-Reply-To: <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
 <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
Message-ID: <t3d-MaEF2Aw7N1bfscFggrRVmgkXkOBH3ZNCrG1RdOo=.f527ca2a-1fce-4a13-a2d4-42eda83ec47a@github.com>

On Tue, 22 Dec 2020 18:52:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This code was introduced in main repository under https://bugs.openjdk.java.net/browse/JDK-8006775
>> I checked original commit in `type-annotations/langtools` repository: https://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/71f35e4b93a5
>> Looks like it's not a merge problem.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066694: Strange code in JavacParser.java

LOTM

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Apr 19 12:24:40 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 19 Apr 2021 12:24:40 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java [v2]
In-Reply-To: <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
 <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
Message-ID: <cy9DDZiQ0OOD-Oz-7FobRjeX0u4dCSPJ25v-OO7RtaM=.290fec1e-d770-475f-a1ee-1555042c97bd@github.com>

On Tue, 22 Dec 2020 18:52:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This code was introduced in main repository under https://bugs.openjdk.java.net/browse/JDK-8006775
>> I checked original commit in `type-annotations/langtools` repository: https://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/71f35e4b93a5
>> Looks like it's not a merge problem.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066694: Strange code in JavacParser.java

How to reopen this PR?

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

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

From sadayapalam at openjdk.java.net  Tue Apr 20 06:51:10 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 20 Apr 2021 06:51:10 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors
In-Reply-To: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
Message-ID: <5NROl1m-mrADUQIrena5Oj2MyxNOhdn_5ORPjG0Yltc=.f0720961-98a4-4e20-807e-a2035327f289@github.com>

On Sun, 11 Apr 2021 12:49:35 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Unknown lookups in the java package give misleading compilation errors

Changes requested by sadayapalam (Reviewer).

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

> 4062:             if (!location.name.isEmpty()) {
> 4063:                 if (location.kind == PCK && !site.tsym.exists() && location.name != names.java) {
> 4064:                     return diags.create(dkind, log.currentSource(), pos,

This works, but I am not sure it is the fix we want. I would be curious to find out why site.tsym.exists() returns false for the java PackageSymbol. What I find with some preliminary debugging is that we end up creating a PackageSymbol for `java' that is distinct from the PackageSymbol java that is the owner of the PackageSymbol java.lang.

In this block of code

// Import-on-demand java.lang.
                PackageSymbol javaLang = syms.enterPackage(syms.java_base, names.java_lang);
                if (javaLang.members().isEmpty() && !javaLang.exists())
                    throw new FatalError(diags.fragment(Fragments.FatalErrNoJavaLang));
                importAll(make.at(tree.pos()).Import(make.QualIdent(javaLang), false), javaLang, env);

com.sun.tools.javac.comp.TypeEnter.ImportsPhase#resolveImports

at the importAll call if you have a breakpoint and query the javaLang.exists() and javaLang.owner.exists() they both answer true.

So it looks fishy to me that we somehow end up with a distinct PackageSymbol for java that answers false for exists() even as there exist other symbols that answer true.

If you debug through javac as it attributes:

Object o1 = java.lang.String.class;

while attributing the FieldSelect node you can see that the PackageSymbol for java.lang has a owner that is distinct from the PackageSymbol for siteSym - so we do right thing by coalescing the symbols somehow - how is what needs further analysis.

test/langtools/tools/javac/8264258/MisleadingTypeNotFound.java line 5:

> 3:  * @bug 8264258
> 4:  * @summary unknown.Class.default gives misleading compilation error
> 5:  * @compile/fail/ref=MisleadingTypeNotFound.out -Xlint:all -Werror -XDrawDiagnostics -XDdev MisleadingTypeNotFound.java

Summary looks incorrect, copying over Valhallaisms ??

test/langtools/tools/javac/8264258/MisleadingTypeNotFound.java line 10:

> 8: 
> 9: public class MisleadingTypeNotFound {
> 10: 

It is a bit confusing. The misleading message is not about Type not found, but existing package being reported as non-existent. So we should change these names of classes/files/jbs descriptions etc suitably. 

MisleadingNonExistentPathError ??

test/langtools/tools/javac/8264258/MisleadingTypeNotFound.java line 21:

> 19:         Class<?> c3 = unknownpkg.NotFound.class;
> 20: 
> 21:         // Not found, but in the 'java' package which is in scope as per JLS 6.3 and observable as per JLS 7.4.3

Could you just for completeness, add the new java.lang() case also ? Thanks

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

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

From sadayapalam at openjdk.java.net  Tue Apr 20 07:11:12 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 20 Apr 2021 07:11:12 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors
In-Reply-To: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
Message-ID: <ZqyfSrl5AM_uykjE34RZRDmTOfwjVoeFeSHK1zk8H88=.b989c3f3-f4f6-4f35-ad4c-d11aa38a2e46@github.com>

On Sun, 11 Apr 2021 12:49:35 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Unknown lookups in the java package give misleading compilation errors

This block of code in com.sun.tools.javac.code.ClassFinder#includeClassFile

if ((p.flags_field & EXISTS) == 0)
            for (Symbol q = p; q != null && q.kind == PCK; q = q.owner)
                q.flags_field |= EXISTS;

is updating one version of the PackageSymbol("java") as being existing while we land up with up another that hasn't been so updated.

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

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

From jlahoda at openjdk.java.net  Tue Apr 20 08:29:09 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 20 Apr 2021 08:29:09 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors
In-Reply-To: <5NROl1m-mrADUQIrena5Oj2MyxNOhdn_5ORPjG0Yltc=.f0720961-98a4-4e20-807e-a2035327f289@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
 <5NROl1m-mrADUQIrena5Oj2MyxNOhdn_5ORPjG0Yltc=.f0720961-98a4-4e20-807e-a2035327f289@github.com>
Message-ID: <D5Z_Is9mq9Tp6JC9MrmnOAlOvwqR_4AvN7teMJdAGgM=.2079c022-4c68-4eb0-beb0-607f7d8948c9@github.com>

On Tue, 20 Apr 2021 06:42:45 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Unknown lookups in the java package give misleading compilation errors
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4064:
> 
>> 4062:             if (!location.name.isEmpty()) {
>> 4063:                 if (location.kind == PCK && !site.tsym.exists() && location.name != names.java) {
>> 4064:                     return diags.create(dkind, log.currentSource(), pos,
> 
> This works, but I am not sure it is the fix we want. I would be curious to find out why site.tsym.exists() returns false for the java PackageSymbol. What I find with some preliminary debugging is that we end up creating a PackageSymbol for `java' that is distinct from the PackageSymbol java that is the owner of the PackageSymbol java.lang.
> 
> In this block of code
> 
> // Import-on-demand java.lang.
>                 PackageSymbol javaLang = syms.enterPackage(syms.java_base, names.java_lang);
>                 if (javaLang.members().isEmpty() && !javaLang.exists())
>                     throw new FatalError(diags.fragment(Fragments.FatalErrNoJavaLang));
>                 importAll(make.at(tree.pos()).Import(make.QualIdent(javaLang), false), javaLang, env);
> 
> com.sun.tools.javac.comp.TypeEnter.ImportsPhase#resolveImports
> 
> at the importAll call if you have a breakpoint and query the javaLang.exists() and javaLang.owner.exists() they both answer true.
> 
> So it looks fishy to me that we somehow end up with a distinct PackageSymbol for java that answers false for exists() even as there exist other symbols that answer true.
> 
> If you debug through javac as it attributes:
> 
> Object o1 = java.lang.String.class;
> 
> while attributing the FieldSelect node you can see that the PackageSymbol for java.lang has a owner that is distinct from the PackageSymbol for siteSym - so we do right thing by coalescing the symbols somehow - how is what needs further analysis.

There is an issue with the PackageSymbol for `java`: it is not clear what is the correct PackageSymbol. There is no module that would export package `java`. There are multiple modules that export direct sub-packages of `java` (e.g. java.base and java.desktop). In case of package `java`, we could say the PackageSymbol should be from java.base, as that is the most base module that contains subpackages of `java`, but that does not work generally. Consider, e.g., three modules: m1 exporting api.a, m2 exporting api.b (with no relation between m1 and m2), and m3 using both m1 and m2. There is no way to have a PackageSymbol for `api` in `m3` such that it would be the same time the owner of `api.a` in `m1` and `api.b` in `m2`. So, what javac is doing is that it synthesizes a new PackageSymbol in the current module (for `java` or `api`). Most of the few places where this caused issues were hopefully fixed, so this may be one of the remaining. 

One thing we could try is to look into the `visiblePackages` of a reasonable module and see if any of them is existing and is a sub-package of the current package (there may be a nicer way to do this, tough):

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 db416413588..6e4db4bc49f 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
@@ -4060,7 +4060,8 @@ public class Resolve {
                 location = site.tsym;
             }
             if (!location.name.isEmpty()) {
-                if (location.kind == PCK && !site.tsym.exists()) {
+                if (location.kind == PCK && !site.tsym.exists() &&
+                    location.packge().modle.visiblePackages.values().stream().filter(ps -> ps.exists()).flatMap(this::owners).noneMatch(ps -> ps.flatName() == site.tsym.flatName())) {
                     return diags.create(dkind, log.currentSource(), pos,
                         "doesnt.exist", location);
                 }
@@ -4087,6 +4088,23 @@ public class Resolve {
         private Object args(List<Type> args) {
             return args.isEmpty() ? args : methodArguments(args);
         }
+        private Stream<Symbol> owners(PackageSymbol ps) {
+            Iterable<Symbol> ownersIt = () -> new Iterator<>() {
+                private Symbol current = ps.owner;
+                @Override
+                public boolean hasNext() {
+                    return !current.name.isEmpty();
+                }
+
+                @Override
+                public Symbol next() {
+                    Symbol result = current;
+                    current = current.owner;
+                    return result;
+                }
+            };
+            return StreamSupport.stream(ownersIt.spliterator(), false);
+        }
 
         private String getErrorKey(KindName kindname, boolean hasTypeArgs, boolean hasLocation) {
             String key = "cant.resolve";

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

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

From sadayapalam at openjdk.java.net  Tue Apr 20 10:35:05 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 20 Apr 2021 10:35:05 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors
In-Reply-To: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
Message-ID: <ii_bexxrgx8ngjRKmwTmBZx6B1K4hHqgZSepjyeBfcE=.46fd59b2-f48d-43e0-9595-e7663ebab62a@github.com>

On Sun, 11 Apr 2021 12:49:35 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Unknown lookups in the java package give misleading compilation errors

In thinking about it more, I think we can settle for the changes in com.sun.tools.javac.comp.Resolve.SymbolNotFoundError#getDiagnostic as is - it being in error recovery that affords us a bit of leeway. An aesthetically cleaner approach would have been preferable, but sometime handling the special case directly is clean enough. I also suspect this is corner case territory and we may not care that much.

So, Jesper could you make the other changes suggested and restest.

Please indicate what tests you ran. TIA.

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

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

From eastig at amazon.co.uk  Tue Apr 20 17:02:21 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Tue, 20 Apr 2021 17:02:21 +0000
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow
In-Reply-To: <14294007-A41E-4A5C-86BB-1E616ECCDA1C@amazon.com>
References: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com>
 <14294007-A41E-4A5C-86BB-1E616ECCDA1C@amazon.com>
Message-ID: <BE000556-1C5A-49F1-811C-9426AAC02C98@amazon.com>

Ping.

From: compiler-dev <compiler-dev-retn at openjdk.java.net> on behalf of "Astigeevich, Evgeny" <eastig at amazon.co.uk>
Date: Monday, 19 April 2021 at 12:04
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 Astigeevich




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/20210420/2902840d/attachment.htm>

From darcy at openjdk.java.net  Tue Apr 20 23:44:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 20 Apr 2021 23:44:12 GMT
Subject: RFR: 8265591: Remove vestiages of intermediate JSR 175 annotation
 format
Message-ID: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>

During the recent review of JDK-8228988, I noticed again the comments in the annotation parser about support for the pre-GA annotation format used before JDK 5.0 shipped. During the development of annotations, there was a late change to correct a flaw in the annotation encoding, JDK-5020908.

I don't think it is necessary to carry forward support for this transient format any longer and this changeset removes support from both core reflection and javac.

Clean runs of relevant test; I gauge this fix as no-reg hard.

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

Commit messages:
 - 8265591: Remove vestiages of intermediate JSR 175 annotation format

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

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

From darcy at openjdk.java.net  Tue Apr 20 23:52:04 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 20 Apr 2021 23:52:04 GMT
Subject: RFR: 8265591: Remove vestiages of intermediate JSR 175 annotation
 format
In-Reply-To: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
References: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
Message-ID: <v0dGNw055-MiQxZdAYP3z56LTcHcMRzuZCHUdYQJHQE=.4a6cf0b6-06cc-418c-a16e-28aeae3fdbfc@github.com>

On Tue, 20 Apr 2021 23:37:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> During the recent review of JDK-8228988, I noticed again the comments in the annotation parser about support for the pre-GA annotation format used before JDK 5.0 shipped. During the development of annotations, there was a late change to correct a flaw in the annotation encoding, JDK-5020908.
> 
> I don't think it is necessary to carry forward support for this transient format any longer and this changeset removes support from both core reflection and javac.
> 
> Clean runs of relevant test; I gauge this fix as no-reg hard.

PS CSR for the behavioral change: https://bugs.openjdk.java.net/browse/JDK-8265608

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

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

From jlahoda at openjdk.java.net  Wed Apr 21 11:52:35 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 21 Apr 2021 11:52:35 GMT
Subject: RFR: 8263432: javac may report an invalid package/class clash on
 case insensitive filesystems
In-Reply-To: <XVY3kmwWCWjj3JOIbj8cwSOHK-RDSVH4OpMpVKcN-gM=.4a82383d-0114-471f-8b5c-3aae562f2c1e@github.com>
References: <XVY3kmwWCWjj3JOIbj8cwSOHK-RDSVH4OpMpVKcN-gM=.4a82383d-0114-471f-8b5c-3aae562f2c1e@github.com>
Message-ID: <Y7zG6yu4sS5u8t9pblt9o-wzm4Hr75tpTVSaPZldc1w=.a4d75fc4-9d64-4a1a-b4cd-5ade051e8ec7@github.com>

On Thu, 18 Mar 2021 09:12:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> To implement the package/class clash check as per JLS 7.1, javac creates "phantom" packages with the same names as the classes and checks if these packages exist (implemented as a check if it has seen a source or class file in the corresponding directory). Every package created (phantom or not) gets registered to its enclosing `ModuleSymbol`, and when `ModuleSymbol.getEnclosedElements()` is called, the package is completed (i.e. its directory is listed).
> 
> This can cause an invalid package/class clash error to be reported in specific cases if there is a package and a class with names differing only in letter cases (like `org.jruby.runtime.callsite` and `org.jruby.runtime.CallSite`). What happens here is: the phantom package for the `org.jruby.runtime.CallSite` package is created, the package/class clash check is performed and passes (no errors). Then annotation processing calls `ModuleSymbol.getEnclosedElements()`, the phantom package's directory (`org/jruby/runtime/CallSite`) is listed from the filesystem, and contains some source files, so appears non-empty/existing (due to the case insensitive filesystem, the content of `org/jruby/runtime/callsite` directory is listed in fact). Then another round of annotation processing happens, and the package/class clash check is performed again. This time, the package appears to exist, and hence the check fails.
> 
> The proposal here is to avoid creating of the phantom packages (and hence registering them into `ModuleSymbol`) for the package/class clash check. That should prevent listing the package with the wrong name unnecessarily/unintentionally.

Any comments on this?

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

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

From eastig at amazon.co.uk  Wed Apr 21 12:31:36 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Wed, 21 Apr 2021 12:31:36 +0000
Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow
In-Reply-To: <22320329-53EB-4B4B-8764-42C8D0A0C80C@amazon.com>
References: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com>
 <14294007-A41E-4A5C-86BB-1E616ECCDA1C@amazon.com>
 <BE000556-1C5A-49F1-811C-9426AAC02C98@amazon.com>
 <22320329-53EB-4B4B-8764-42C8D0A0C80C@amazon.com>
Message-ID: <86AF48AA-D21B-4192-B774-131FD05EBE8A@amazon.com>

Hi Paul,

Thanks for reviewing.

-Evgeny

From: "Hohensee, Paul" <hohensee at amazon.com>
Date: Tuesday, 20 April 2021 at 19:13
To: "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

Lgtm.

Thanks,
Paul

From: compiler-dev <compiler-dev-retn at openjdk.java.net> on behalf of "Astigeevich, Evgeny" <eastig at amazon.co.uk>
Date: Tuesday, April 20, 2021 at 10:03 AM
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: Re: [11u] RFR 8177068: incomplete classpath causes NPE in Flow

Ping.

From: compiler-dev <compiler-dev-retn at openjdk.java.net> on behalf of "Astigeevich, Evgeny" <eastig at amazon.co.uk>
Date: Monday, 19 April 2021 at 12:04
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 Astigeevich




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.







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/20210421/9242bae1/attachment.htm>

From duke at openjdk.java.net  Wed Apr 21 13:15:33 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 21 Apr 2021 13:15:33 GMT
Subject: Withdrawn: 8213766: Assertion error in
 TypeAnnotations$TypeAnnotationPositions.resolveFrame
In-Reply-To: <-img5oopyq6D7dQCDMBQOGMSlf5kDClvabMowfqgpXU=.2a316b41-63a6-4149-8434-8fbb5d0000c1@github.com>
References: <-img5oopyq6D7dQCDMBQOGMSlf5kDClvabMowfqgpXU=.2a316b41-63a6-4149-8434-8fbb5d0000c1@github.com>
Message-ID: <lpvGB_qVdxyTPNmaupiSpeud-ojvWFPCFuobbxuPd6g=.f463d76b-0465-428a-81f8-4a4fe22e2343@github.com>

On Sun, 17 Jan 2021 16:52:45 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This regression is caused by [PATCH-8078093](https://github.com/openjdk/jdk/commit/981c6dc2989b66f3691090c9f81e23d2b0a00087).
> 
> The method `DeferredAttr$DeferredAttrNode$StructuralStuckChecker.canLambdaBodyCompleteNormally` uses `attribSpeculativeLambda`. Later, the `ArgumentAttr.visitLambda(JCLambda that)` would be invoked, which sets the `ExplicitLambdaType.tree.type` to its `ExplicitLambdaType`. Note: currently, the `ExplicitLambdaType.tree` was not attributed and only the `ExplicitLambdaType.speculativeTree` was attributed.
> 
> Then, `DeferredAttr$RecoveryDeferredTypeMap.typeOf` would not invoke the method `recover` to attribute the `ExplicitLambdaType.tree` because the `owntype` is not equal to `Type.noType`. The code and some comments are shown below for you.
> 
> 
> protected Type typeOf(DeferredType dt, Type pt) {
>     Type owntype = super.typeOf(dt, pt);  // The `super.typeOf(dt, pt)` returns the `ExplicitLambdaType` which is set previously.
>     return owntype == Type.noType ?
>         recover(dt, pt) : owntype; // Here, the method `recover` is not invoked because `owntype == Type.noType` returns false.
> }
> 
> 
> Because the tree is not attributed, some regressions will occur, including this bug.
> 
> Although I found the cause of this bug, I think my patch is the simplest solution but it may be not the best solution.
> 
> Another solution is that method `DeferredAttr$DeferredAttrNode$StructuralStuckChecker.canLambdaBodyCompleteNormally` uses other way instead of using `attribSpeculativeLambda`. The old way which is before PATCH-8078093 is a candidate.
> 
> Any better solution is appreciated. Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Wed Apr 21 13:17:39 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 21 Apr 2021 13:17:39 GMT
Subject: Withdrawn: 8232765: NullPointerException at Types.eraseNotNeeded()
 when compiling a class
In-Reply-To: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
Message-ID: <7b-oqrKNPD9xqMXLGC2Jk_IycYRF9eU7GzwXaMDsaH0=.30e02a8c-72d6-4055-9512-6c6559766c62@github.com>

On Fri, 15 Jan 2021 12:17:39 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
> 
> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Wed Apr 21 13:38:41 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 21 Apr 2021 13:38:41 GMT
Subject: Withdrawn: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <pDP5xeFMzByh8WRd5O5mePAKLL8iQl1fsbrjzbOz-AQ=.ce5414cf-66ca-4c58-b49e-4e52df238b71@github.com>

On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

This pull request has been closed without being integrated.

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

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

From gli at openjdk.java.net  Wed Apr 21 13:40:37 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 21 Apr 2021 13:40:37 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java [v2]
In-Reply-To: <cy9DDZiQ0OOD-Oz-7FobRjeX0u4dCSPJ25v-OO7RtaM=.290fec1e-d770-475f-a1ee-1555042c97bd@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
 <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
 <cy9DDZiQ0OOD-Oz-7FobRjeX0u4dCSPJ25v-OO7RtaM=.290fec1e-d770-475f-a1ee-1555042c97bd@github.com>
Message-ID: <0YRlA59znnXMZ9r3OnkVIw-a4dCC-eESgcnhETQ4g2k=.765e4422-9861-4b89-bbc5-bcfb17cafcf4@github.com>

On Mon, 19 Apr 2021 12:21:30 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8066694: Strange code in JavacParser.java
>
> How to reopen this PR?

@turbanoff you can type `/open` to reopen the PR.

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

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

From gli at openjdk.java.net  Wed Apr 21 13:43:34 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 21 Apr 2021 13:43:34 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <1rpuVofnrbDV7LQZiCDndCZTkypwkELL3qjEAdXXk8Q=.6a2fcf66-2efa-4bf2-9922-b9a3d6745b47@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <1rpuVofnrbDV7LQZiCDndCZTkypwkELL3qjEAdXXk8Q=.6a2fcf66-2efa-4bf2-9922-b9a3d6745b47@github.com>
Message-ID: <KVv5gyvvo1xpolxeHJlYGNedvYAqiGs5896ulA1YTRw=.b7a565f6-fb6d-4715-a2fd-d6b2512fb3e3@github.com>

On Mon, 19 Apr 2021 10:41:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
>> Two existing tests failed and I fixed it.
>> Currently, all the tests in `test/langtools` passed locally by using the following command.
>> 
>> 
>> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
>> 
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> @edvbld Can you please help?

@mcimadamore The PR could be reopen by typing `/open` command. We can continue the work now. I would resolve the git conflicts later.

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

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

From mcimadamore at openjdk.java.net  Wed Apr 21 14:11:33 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 21 Apr 2021 14:11:33 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
Message-ID: <IkC0_x-XCGmTVgM3dkXcBtoqqlQTXfHqulslkkC8nQk=.468d3b8b-0658-480e-8b7f-85f7bd8fdc98@github.com>

On Sun, 27 Dec 2020 14:54:16 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
> Two existing tests failed and I fixed it.
> Currently, all the tests in `test/langtools` passed locally by using the following command.
> 
> 
> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
> 
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Looks good - left some comments

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacScope.java line 2:

> 1: /*
> 2:  * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.

copyright in this (and other files need to be updated)

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 94:

> 92:     final Symtab syms;
> 93:     final JavacMessages messages;
> 94:     private Names names;

where is this change coming from?

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Filter.java line 36:

> 34:  * instead of {@link com.sun.tools.javac.util.Filter}.
> 35:  */
> 36: @Deprecated(forRemoval = true, since = "17")

This is not a public API - we're in a JDK internal class - if this class is no longer needed (as is the goal of this change) simply remove it :-)

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

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

From mcimadamore at openjdk.java.net  Wed Apr 21 14:16:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 21 Apr 2021 14:16:40 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class
In-Reply-To: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
Message-ID: <iGSJo_LeKj9d6DEhxbe4Q2LVUgoqzx82LRq0CNcFzvo=.8d14d0d6-15e9-4399-85f1-66a4df1a864b@github.com>

On Fri, 15 Jan 2021 12:17:39 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
> 
> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

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

> 3499:                                            eType,
> 3500:                                            List.nil());
> 3501:             Type returnType = types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym);

I know you closed this PR - just wanted to leave a comment: issuing this kind of type-checking errors in Lower is unusual. This kind of stuff should be caught in earlier (e.g. in Attr) - and, over the years we've been making efforts to move all error generation in the front-end; note than when using compiler through the compiler API, you might not run Lower (and all desugaring steps) so you might miss errors if these are generated too late.

That said, surely the check:


            Type returnType = types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym);
 ```

Must be somewhere in Attr?

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

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

From gli at openjdk.java.net  Wed Apr 21 14:20:47 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 21 Apr 2021 14:20:47 GMT
Subject: RFR: 8200145: Conditional expression mistakenly treated as
 standalone [v3]
In-Reply-To: <fo3ng4FuDo4_Ax0LkqgROu_XOIkZequWMXHR3NkX2Q4=.48553cd3-a9e6-4724-bb27-7bec36319740@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
 <fo3ng4FuDo4_Ax0LkqgROu_XOIkZequWMXHR3NkX2Q4=.48553cd3-a9e6-4724-bb27-7bec36319740@github.com>
Message-ID: <utUPCR5Y6K7FMo-CEJ_T0No-61UptjpakkR0eRIe6Wo=.bfbd0a11-a39d-4994-a3b8-1acac7241828@github.com>

On Fri, 16 Apr 2021 17:26:32 GMT, Maurizio Cimadamore <mcimadamore 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 three additional commits since the last revision:
>> 
>>  -  Merge branch 'master' into JDK-8200145
>>  - Use method isErroneous
>>  - 8200145: Conditional expression mistakenly treated as standalone
>
> Marked as reviewed by mcimadamore (Reviewer).

@mcimadamore Could I get your help to re-review and sponsor? Thanks a lot.

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

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

From mcimadamore at openjdk.java.net  Wed Apr 21 14:27:37 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 21 Apr 2021 14:27:37 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class
In-Reply-To: <iGSJo_LeKj9d6DEhxbe4Q2LVUgoqzx82LRq0CNcFzvo=.8d14d0d6-15e9-4399-85f1-66a4df1a864b@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
 <iGSJo_LeKj9d6DEhxbe4Q2LVUgoqzx82LRq0CNcFzvo=.8d14d0d6-15e9-4399-85f1-66a4df1a864b@github.com>
Message-ID: <Rdb3HB9z9wYky1I846DKj7tsjoAI4Pe-nXM0bGyh90Q=.2ab254a6-1267-43ac-bf40-fa6232f95bfc@github.com>

On Wed, 21 Apr 2021 14:11:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
>> 
>> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3501:
> 
>> 3499:                                            eType,
>> 3500:                                            List.nil());
>> 3501:             Type returnType = types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym);
> 
> I know you closed this PR - just wanted to leave a comment: issuing this kind of type-checking errors in Lower is unusual. This kind of stuff should be caught in earlier (e.g. in Attr) - and, over the years we've been making efforts to move all error generation in the front-end; note than when using compiler through the compiler API, you might not run Lower (and all desugaring steps) so you might miss errors if these are generated too late.
> 
> That said, surely the check:
> 
> 
>             Type returnType = types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym);
>  ```
> 
> Must be somewhere in Attr?

So, in `Attr` we check that the class implements `Iterable`. In this case it does, but there's an incompatible override. That issues an error as expected, so compiling the provided test case:


public class T8232765 {
          public void test(String[] args) {
              MyLinkedList<Integer> list = new MyLinkedList<>();
              for (int x : list)
                  System.out.print(x);
          }
      }
      class MyLinkedList<T> implements java.lang.Iterable<T> {
          public void iterator() {}
      };

Does not result in a crash.

I suspect the issue in JBS is more subtle, and involves, perhaps, separate compilation? I find this very odd - typically javac stops at a phase (e.g. Attr) if one or more files had errors in that phase. In this case we have a bad implementation of `Iterable`, so we should not be able to go past `Attr`.

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

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

From mcimadamore at openjdk.java.net  Wed Apr 21 14:35:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 21 Apr 2021 14:35:40 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class
In-Reply-To: <Rdb3HB9z9wYky1I846DKj7tsjoAI4Pe-nXM0bGyh90Q=.2ab254a6-1267-43ac-bf40-fa6232f95bfc@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
 <iGSJo_LeKj9d6DEhxbe4Q2LVUgoqzx82LRq0CNcFzvo=.8d14d0d6-15e9-4399-85f1-66a4df1a864b@github.com>
 <Rdb3HB9z9wYky1I846DKj7tsjoAI4Pe-nXM0bGyh90Q=.2ab254a6-1267-43ac-bf40-fa6232f95bfc@github.com>
Message-ID: <gd1KyNtxkpPD-q2su-atDzz5EhmIp0UZzDDWCknmURE=.57502c11-933d-4911-bbe9-9e3b22c35658@github.com>

On Wed, 21 Apr 2021 14:24:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3501:
>> 
>>> 3499:                                            eType,
>>> 3500:                                            List.nil());
>>> 3501:             Type returnType = types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym);
>> 
>> I know you closed this PR - just wanted to leave a comment: issuing this kind of type-checking errors in Lower is unusual. This kind of stuff should be caught in earlier (e.g. in Attr) - and, over the years we've been making efforts to move all error generation in the front-end; note than when using compiler through the compiler API, you might not run Lower (and all desugaring steps) so you might miss errors if these are generated too late.
>> 
>> That said, surely the check:
>> 
>> 
>>             Type returnType = types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym);
>>  ```
>> 
>> Must be somewhere in Attr?
>
> So, in `Attr` we check that the class implements `Iterable`. In this case it does, but there's an incompatible override. That issues an error as expected, so compiling the provided test case:
> 
> 
> public class T8232765 {
>           public void test(String[] args) {
>               MyLinkedList<Integer> list = new MyLinkedList<>();
>               for (int x : list)
>                   System.out.print(x);
>           }
>       }
>       class MyLinkedList<T> implements java.lang.Iterable<T> {
>           public void iterator() {}
>       };
> 
> Does not result in a crash.
> 
> I suspect the issue in JBS is more subtle, and involves, perhaps, separate compilation? I find this very odd - typically javac stops at a phase (e.g. Attr) if one or more files had errors in that phase. In this case we have a bad implementation of `Iterable`, so we should not be able to go past `Attr`.

Ok, I see where I went wrong. I can reproduce the crash - the problem I had was related to `public` appearing in a file with wrong name.

So, the issue occurs when two classes are defined in the same source. In that case, we advance T8232765 through the compiler pipeline almost independently of MyLinkedList. The only thing happening for MyLinkedList is the typeEnter step - but no Attr is performed, so no overriding checks.

If the `simple` compile policy is used, no crash occurs:


javac -XDcompilePolicy=simple -XDverboseCompilePolicy=true Test.java 
[attribute T8232765]
[attribute MyLinkedList]
Test.java:8: error: MyLinkedList is not abstract and does not override abstract method iterator() in Iterable
                class MyLinkedList<T> implements java.lang.Iterable<T> {
                ^
  where T is a type-variable:
    T extends Object declared in class MyLinkedList
Test.java:9: error: iterator() in MyLinkedList cannot implement iterator() in Iterable
                    public void iterator() {}
                                ^
  return type void is not compatible with Iterator<T#2>
  where T#1,T#2 are type-variables:
    T#1 extends Object declared in interface Iterable
    T#2 extends Object declared in class MyLinkedList
2 errors


This has come up again in the past: should the *simple* policy be the default?

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

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

From gli at openjdk.java.net  Wed Apr 21 14:39:35 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 21 Apr 2021 14:39:35 GMT
Subject: Integrated: 8200145: Conditional expression mistakenly treated as
 standalone
In-Reply-To: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
References: <Txl_MrSZYazHR0qjJX--sdyJYSo0fkUe38DNFYROp6A=.b6c8921f-0dc3-4e6b-bd49-ba70bb75b587@github.com>
Message-ID: <yOOoDHFVIaXl9CX14UN_5beQBapSEZaVo6ndiuUas-c=.5d163797-c5cc-4715-a228-e1d175ee5fd6@github.com>

On Sat, 30 Jan 2021 08:50:53 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> If the argument `Type t` of the method `Types.unboxedType` is an `ErrorType`, the `Types.unboxedType` may return the wrong result. And in this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return the wrong result, too.
> 
> This patch fixes it and adds a test case.
> Thank you for taking the time to review.
> 
> Best Regards.
> -- xiong

This pull request has now been integrated.

Changeset: 07a7510d
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/07a7510d
Stats:     46 lines in 3 files changed: 45 ins; 0 del; 1 mod

8200145: Conditional expression mistakenly treated as standalone

Reviewed-by: mcimadamore

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

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

From mcimadamore at openjdk.java.net  Wed Apr 21 14:45:34 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 21 Apr 2021 14:45:34 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v3]
In-Reply-To: <G43LId0M-ZZiM447iIsG4geyGogSR7HryckiLcXDj6I=.82585196-9db7-45fc-9688-b9ef9d2507ab@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <G43LId0M-ZZiM447iIsG4geyGogSR7HryckiLcXDj6I=.82585196-9db7-45fc-9688-b9ef9d2507ab@github.com>
Message-ID: <W7UzRgAEJWfnbHO1cwpg7V0Cf4rns4dDZIQocylhkmc=.812c007c-c8ab-4d0d-b644-f88c9866c854@github.com>

On Fri, 16 Apr 2021 03:35:06 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:
> 
>   updating comment after review feedback

Compiler changes look good (I have not checked SymbolGenerator).

Why were some tests removed?

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

Marked as reviewed by mcimadamore (Reviewer).

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

From vromero at openjdk.java.net  Wed Apr 21 15:13:33 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 21 Apr 2021 15:13:33 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v3]
In-Reply-To: <W7UzRgAEJWfnbHO1cwpg7V0Cf4rns4dDZIQocylhkmc=.812c007c-c8ab-4d0d-b644-f88c9866c854@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <G43LId0M-ZZiM447iIsG4geyGogSR7HryckiLcXDj6I=.82585196-9db7-45fc-9688-b9ef9d2507ab@github.com>
 <W7UzRgAEJWfnbHO1cwpg7V0Cf4rns4dDZIQocylhkmc=.812c007c-c8ab-4d0d-b644-f88c9866c854@github.com>
Message-ID: <2gJQiuoDTZDgr62xRlnZLCoL1-EFjUCSHsKBrSpPV2U=.1918b494-34bb-4f1a-939b-9a931b583117@github.com>

On Wed, 21 Apr 2021 14:42:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Compiler changes look good (I have not checked SymbolGenerator).
> 
> Why were some tests removed?

thanks for the review. The removed tests were already covered in langtools regression tests, so I only removed duplicated tests

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

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

From gli at openjdk.java.net  Wed Apr 21 15:33:00 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 21 Apr 2021 15:33:00 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v2]
In-Reply-To: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
Message-ID: <9st3xirkgHshaSh3N8qisRDjFy1iIX1aBSbHIP7bejA=.5218f800-f671-4e12-8b05-6b5bd3182f2e@github.com>

> Hi all,
> 
> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
> Two existing tests failed and I fixed it.
> Currently, all the tests in `test/langtools` passed locally by using the following command.
> 
> 
> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
> 
> 
> 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:

 - Remove file Filter.java
 - Update copyright
 - Merge branch 'master' into JDK-8057543
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java
 - Add comments.
 - 8057543: Replace javac's Filter with Predicate (and lambdas)

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

Changes: https://git.openjdk.java.net/jdk/pull/1898/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1898&range=01
  Stats: 184 lines in 19 files changed: 17 ins; 44 del; 123 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1898.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1898/head:pull/1898

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

From gli at openjdk.java.net  Wed Apr 21 15:33:03 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 21 Apr 2021 15:33:03 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v2]
In-Reply-To: <IkC0_x-XCGmTVgM3dkXcBtoqqlQTXfHqulslkkC8nQk=.468d3b8b-0658-480e-8b7f-85f7bd8fdc98@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <IkC0_x-XCGmTVgM3dkXcBtoqqlQTXfHqulslkkC8nQk=.468d3b8b-0658-480e-8b7f-85f7bd8fdc98@github.com>
Message-ID: <xSB1xxk3MzItSrbc4ydBwSQ7IKBh49aWMdZPxvQ8BjE=.383f8df8-52e7-475f-9c24-b7f95eff35d9@github.com>

On Wed, 21 Apr 2021 14:06:12 GMT, Maurizio Cimadamore <mcimadamore 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:
>> 
>>  - Remove file Filter.java
>>  - Update copyright
>>  - Merge branch 'master' into JDK-8057543
>>    
>>    # Conflicts:
>>    #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java
>>  - Add comments.
>>  - 8057543: Replace javac's Filter with Predicate (and lambdas)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacScope.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
> 
> copyright in this (and other files need to be updated)

Fixed.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 94:
> 
>> 92:     final Symtab syms;
>> 93:     final JavacMessages messages;
>> 94:     private Names names;
> 
> where is this change coming from?

When building the JDK, I got the following error:


jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:950: error: variable names might not have been initialized
                    t.name != names.init &&
                              ^
1 error


Therefore I revised the modifier of the `Names names`.

> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Filter.java line 36:
> 
>> 34:  * instead of {@link com.sun.tools.javac.util.Filter}.
>> 35:  */
>> 36: @Deprecated(forRemoval = true, since = "17")
> 
> This is not a public API - we're in a JDK internal class - if this class is no longer needed (as is the goal of this change) simply remove it :-)

Fixed.

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

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

From gli at openjdk.java.net  Wed Apr 21 15:36:39 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 21 Apr 2021 15:36:39 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <iMmlBs0rju7_yEOzjoD_8zbuFadN-rqTuAbvZF0hwf4=.f137c2e1-dca7-4668-bfe1-5c3a5bf83c2a@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <iMmlBs0rju7_yEOzjoD_8zbuFadN-rqTuAbvZF0hwf4=.f137c2e1-dca7-4668-bfe1-5c3a5bf83c2a@github.com>
Message-ID: <F6yJvL5uz6PRght0L-mXy76o2x6_1wpIjZA_Cmi1ngQ=.9d9e259f-01f4-4cad-a0e2-f8fe6cd43274@github.com>

On Sun, 27 Dec 2020 15:31:38 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> More information and some similar issues:
> 
> These four issues were fixed in [this patch](https://github.com/openjdk/jdk/commit/c4e8276376676bda9aa4cb00b6d071fb70c21b85)
> [JDK-8057542](https://bugs.openjdk.java.net/browse/JDK-8057542)
> [JDK-8057545](https://bugs.openjdk.java.net/browse/JDK-8057545)
> [JDK-8057546](https://bugs.openjdk.java.net/browse/JDK-8057546)
> [JDK-8057547](https://bugs.openjdk.java.net/browse/JDK-8057547)
> 
> This issue was fixed in [this patch](https://github.com/openjdk/jdk/commit/582a4ebd92e60f95ae77d25eb00c6a146e727fab)
> [JDK-8057544](https://bugs.openjdk.java.net/browse/JDK-8057544)
> 
> But their status are still `NEW`. It should be revised to `RESOLVED` or `CLOSED`.

@mcimadamore I want to set these issues to `CLOSED` or `RESOLVED`. What's your opinion?

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

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

From lgxbslgx at gmail.com  Wed Apr 21 16:51:28 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Thu, 22 Apr 2021 00:51:28 +0800
Subject: [Investigation] Use pattern matching for instanceof at module
 jdk.compiler
Message-ID: <CAPSsVqg9WwdbgTjW0=HTz-e969DKnwnQGih8xMR65y7Gb0vi1w@mail.gmail.com>

Hi all,

The JEP-394[1] implemented the `Pattern matching for instanceof` at JDK 16.
It is a good specification. Many packages or modules of the JDK begin to
use it, such as package `java.time`[2][3]. I think it is good for the javac
compiler to use it, too.

Here are some issues we need to consider or something I want to confirm.

1. What's your opinion about this idea? Is it necessary?
2. Is somebody doing the same thing locally? If not, I would like to do
that.
3. Is it good to revise the whole module `jdk.compiler` by submitting a big
patch? Or, should we separate it into several sub-tasks according to
different packages?
4. Do the related modules, such as `java.compiler`, also need to be revised?

Any idea is appreciated.

[1] https://openjdk.java.net/jeps/394
[2] https://bugs.openjdk.java.net/browse/JDK-8263668
[3] https://github.com/openjdk/jdk/pull/3170

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

From brian.goetz at oracle.com  Wed Apr 21 17:08:49 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 21 Apr 2021 13:08:49 -0400
Subject: [Investigation] Use pattern matching for instanceof at module
 jdk.compiler
In-Reply-To: <CAPSsVqg9WwdbgTjW0=HTz-e969DKnwnQGih8xMR65y7Gb0vi1w@mail.gmail.com>
References: <CAPSsVqg9WwdbgTjW0=HTz-e969DKnwnQGih8xMR65y7Gb0vi1w@mail.gmail.com>
Message-ID: <a5cd36de-1260-8d93-52a8-fe30f8e84ce3@oracle.com>

Just like keeping the JDK codebase up to "modern Java" standards (an 
ongoing task!), we should do the same with the compiler codebase.? There 
is one constraint; we must wait one extra version to use new (permanent) 
language features in the compiler, because the compiler must be compiled 
with a boot JDK which is of the previous version.? So if pattern 
matching became permanent in 16, we can start to use it in the compiler 
in 17.

In the JDK, we've set the following guidelines for these sort of 
refactoring patches:

 ?- Each patch should focus on _one_ refactoring (e.g., replace 
traditional instanceof with pattern).? This reduces the cognitive load 
on reviewers.
 ?- Each patch should have a single review domain.? This is not an issue 
for the compiler, but is an issue for the JDK, where `java.base` has 
generic library code, security code, UI code, each of which requires 
review by separate skillsets.
 ?- Patches shouldn't be "too big".? This argues for breaking down by 
groups of related packages if the whole thing is too big.
 ?- No API changes.
 ?- Patches should be, to the degree possible, produced entirely by 
automated refactoring tools.? Resist the urge to make small manual 
tweaks to make the code look better.? Again, this makes it much easier 
for reviewers to conclude "nothing to see here."


On 4/21/2021 12:51 PM, Guoxiong Li wrote:
> Hi all,
>
> The JEP-394[1] implemented the `Pattern matching for instanceof` at 
> JDK 16. It is a good specification. Many?packages or modules of the 
> JDK begin to use it, such as package `java.time`[2][3]. I think it is 
> good for the javac compiler to use it, too.
>
> Here are some issues we need to consider or something?I want to confirm.
>
> 1. What's your opinion about this idea? Is it necessary?
> 2. Is somebody doing the same thing locally? If not, I would like to 
> do that.
> 3. Is it good to revise the whole module `jdk.compiler` by?submitting 
> a big patch? Or, should we separate it into several sub-tasks 
> according to different packages?
> 4. Do the related modules, such as `java.compiler`, also need to be 
> revised?
>
> Any idea is appreciated.
>
> [1] https://openjdk.java.net/jeps/394 <https://openjdk.java.net/jeps/394>
> [2] https://bugs.openjdk.java.net/browse/JDK-8263668 
> <https://bugs.openjdk.java.net/browse/JDK-8263668>
> [3] https://github.com/openjdk/jdk/pull/3170 
> <https://github.com/openjdk/jdk/pull/3170>
>
> ----
> Best Regards,
> Guoxiong

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

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

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/20210421/f23aee79/attachment.htm>

From gli at openjdk.java.net  Thu Apr 22 09:51:35 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 22 Apr 2021 09:51:35 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v2]
In-Reply-To: <jL7jiiU3lYsPz9Bzd1fya2WwXZ2m7o2hl1x_MQOY4I4=.e3bf1893-7540-4567-80e0-cf2944f8ddcf@github.com>
References: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
 <jL7jiiU3lYsPz9Bzd1fya2WwXZ2m7o2hl1x_MQOY4I4=.e3bf1893-7540-4567-80e0-cf2944f8ddcf@github.com>
Message-ID: <JGUF4pOTtEezUFpA7A0QrC3-mEhrdiKFXi8CUgxdu3I=.ca4b64f5-9800-4cfe-9c16-355a045ca495@github.com>

On Mon, 15 Mar 2021 11:23:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara.
>> 
>> @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating test per review comments.

The [original patch](https://github.com/openjdk/jdk/pull/1896) began at Dec 2020. About four months passed. Could somebody help me push this patch? Thanks a lot.

test/langtools/tools/javac/api/TestContextLoggingOutput.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.

The copyright should be updated to 2021.

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

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

From maurizio.cimadamore at oracle.com  Thu Apr 22 09:59:30 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 22 Apr 2021 10:59:30 +0100
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <F6yJvL5uz6PRght0L-mXy76o2x6_1wpIjZA_Cmi1ngQ=.9d9e259f-01f4-4cad-a0e2-f8fe6cd43274@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <iMmlBs0rju7_yEOzjoD_8zbuFadN-rqTuAbvZF0hwf4=.f137c2e1-dca7-4668-bfe1-5c3a5bf83c2a@github.com>
 <F6yJvL5uz6PRght0L-mXy76o2x6_1wpIjZA_Cmi1ngQ=.9d9e259f-01f4-4cad-a0e2-f8fe6cd43274@github.com>
Message-ID: <35ef42c1-01d1-5c1f-8d3b-d54bef18fb7b@oracle.com>

Not sure - it doesn't seem to me that the patch for JDK-8057547 converts 
other stuff to use standard functional interface. Only TypeMapping is 
changed - so it affects (8057544, which can be closed).

Maurizio

On 21/04/2021 16:36, Guoxiong Li wrote:
> On Sun, 27 Dec 2020 15:31:38 GMT, Guoxiong Li <gli at openjdk.org> wrote:
>
>> More information and some similar issues:
>>
>> These four issues were fixed in [this patch](https://github.com/openjdk/jdk/commit/c4e8276376676bda9aa4cb00b6d071fb70c21b85)
>> [JDK-8057542](https://bugs.openjdk.java.net/browse/JDK-8057542)
>> [JDK-8057545](https://bugs.openjdk.java.net/browse/JDK-8057545)
>> [JDK-8057546](https://bugs.openjdk.java.net/browse/JDK-8057546)
>> [JDK-8057547](https://bugs.openjdk.java.net/browse/JDK-8057547)
>>
>> This issue was fixed in [this patch](https://github.com/openjdk/jdk/commit/582a4ebd92e60f95ae77d25eb00c6a146e727fab)
>> [JDK-8057544](https://bugs.openjdk.java.net/browse/JDK-8057544)
>>
>> But their status are still `NEW`. It should be revised to `RESOLVED` or `CLOSED`.
> @mcimadamore I want to set these issues to `CLOSED` or `RESOLVED`. What's your opinion?
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1898

From jfranck at openjdk.java.net  Thu Apr 22 13:02:28 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Thu, 22 Apr 2021 13:02:28 GMT
Subject: RFR: 8265591: Remove vestiages of intermediate JSR 175 annotation
 format
In-Reply-To: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
References: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
Message-ID: <VxGOdmvMsGalUCqqrjZb_vkE6_o6wMh9tXTowodDM8M=.008876cc-90f9-4ae0-92e3-d9969511e7e8@github.com>

On Tue, 20 Apr 2021 23:37:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> During the recent review of JDK-8228988, I noticed again the comments in the annotation parser about support for the pre-GA annotation format used before JDK 5.0 shipped. During the development of annotations, there was a late change to correct a flaw in the annotation encoding, JDK-5020908.
> 
> I don't think it is necessary to carry forward support for this transient format any longer and this changeset removes support from both core reflection and javac.
> 
> Clean runs of relevant test; I gauge this fix as no-reg hard.

Marked as reviewed by jfranck (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Thu Apr 22 13:26:25 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Apr 2021 13:26:25 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v2]
In-Reply-To: <p8dXQUdc7HzVhBsUuYI8NkgHSWy2A8P7hwxsEONzZ9k=.87386ba6-8078-4d7f-b004-986eadfa9c2a@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <IkC0_x-XCGmTVgM3dkXcBtoqqlQTXfHqulslkkC8nQk=.468d3b8b-0658-480e-8b7f-85f7bd8fdc98@github.com>
 <xSB1xxk3MzItSrbc4ydBwSQ7IKBh49aWMdZPxvQ8BjE=.383f8df8-52e7-475f-9c24-b7f95eff35d9@github.com>
 <p8dXQUdc7HzVhBsUuYI8NkgHSWy2A8P7hwxsEONzZ9k=.87386ba6-8078-4d7f-b004-986eadfa9c2a@github.com>
Message-ID: <aXhHEQzKnVPfKlD_jajhMrbbG3IL1YsAfNza2z1hFJo=.ca324950-8aea-4aa5-af07-d20d905b5a69@github.com>

On Wed, 21 Apr 2021 15:36:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When building the JDK, I got the following error:
>> 
>> 
>> jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:950: error: variable names might not have been initialized
>>                     t.name != names.init &&
>>                               ^
>> 1 error
>> 
>> 
>> Therefore I revised the modifier of the `Names names`.
>
> I see - honestly this seems like a bug in definite assignment? E.g. surely the instance field initializer for `bridgeFilter` must run _after_ the `final` field `names` has been initialized? For now you might try using an anonymous inner class instead of a lambda instead, pretty sure that will take care of the issue. But this looks like a compiler bug.

Actually - doing more tests, I think javac is right. Fields with explicit initializers are initialized BEFORE other constructor statements. Which means that the error message is legitimate (e.g. the lambda is capturing a final value that is not initialized). I think reverting back to anon class would be better here.

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

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

From mcimadamore at openjdk.java.net  Thu Apr 22 13:26:25 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Apr 2021 13:26:25 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v2]
In-Reply-To: <xSB1xxk3MzItSrbc4ydBwSQ7IKBh49aWMdZPxvQ8BjE=.383f8df8-52e7-475f-9c24-b7f95eff35d9@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <IkC0_x-XCGmTVgM3dkXcBtoqqlQTXfHqulslkkC8nQk=.468d3b8b-0658-480e-8b7f-85f7bd8fdc98@github.com>
 <xSB1xxk3MzItSrbc4ydBwSQ7IKBh49aWMdZPxvQ8BjE=.383f8df8-52e7-475f-9c24-b7f95eff35d9@github.com>
Message-ID: <p8dXQUdc7HzVhBsUuYI8NkgHSWy2A8P7hwxsEONzZ9k=.87386ba6-8078-4d7f-b004-986eadfa9c2a@github.com>

On Wed, 21 Apr 2021 15:29:44 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 94:
>> 
>>> 92:     final Symtab syms;
>>> 93:     final JavacMessages messages;
>>> 94:     private Names names;
>> 
>> where is this change coming from?
>
> When building the JDK, I got the following error:
> 
> 
> jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:950: error: variable names might not have been initialized
>                     t.name != names.init &&
>                               ^
> 1 error
> 
> 
> Therefore I revised the modifier of the `Names names`.

I see - honestly this seems like a bug in definite assignment? E.g. surely the instance field initializer for `bridgeFilter` must run _after_ the `final` field `names` has been initialized? For now you might try using an anonymous inner class instead of a lambda instead, pretty sure that will take care of the issue. But this looks like a compiler bug.

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

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

From gli at openjdk.java.net  Thu Apr 22 13:43:22 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 22 Apr 2021 13:43:22 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <1rpuVofnrbDV7LQZiCDndCZTkypwkELL3qjEAdXXk8Q=.6a2fcf66-2efa-4bf2-9922-b9a3d6745b47@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <1rpuVofnrbDV7LQZiCDndCZTkypwkELL3qjEAdXXk8Q=.6a2fcf66-2efa-4bf2-9922-b9a3d6745b47@github.com>
Message-ID: <kHtphYC3GflFQXoqZYBWdevGNE34Blj-NIcDKDXO0uw=.8c1276d3-396f-441f-9db4-70ff88edfd12@github.com>

On Mon, 19 Apr 2021 10:41:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
>> Two existing tests failed and I fixed it.
>> Currently, all the tests in `test/langtools` passed locally by using the following command.
>> 
>> 
>> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
>> 
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> @edvbld Can you please help?

@mcimadamore  Thank you for your reply about these issues.

For [JDK-8057542](https://bugs.openjdk.java.net/browse/JDK-8057542) `FreeTypeListener`, I search the words `new FreeTypeListener` at the [PATCH](https://github.com/openjdk/jdk/commit/c4e8276376676bda9aa4cb00b6d071fb70c21b85). I can get 6 places which are like the following code.


-                inferenceContext.addFreeTypeListener(ts, new FreeTypeListener() {
-                    @Override
-                    public void typesInferred(InferenceContext inferenceContext) {
-                        checkAccessibleTypes(pos, env, inferenceContext, inferenceContext.asInstTypes(ts));
-                    }
-                });
+                inferenceContext.addFreeTypeListener(ts,
+                        solvedContext -> checkAccessibleTypes(pos, env, solvedContext, solvedContext.asInstTypes(ts)));


For [JDK-8057545](https://bugs.openjdk.java.net/browse/JDK-8057545) `Factory`,  I search the words `new Context.Factory` at the [PATCH](https://github.com/openjdk/jdk/commit/c4e8276376676bda9aa4cb00b6d071fb70c21b85). I can get 14 places which are like the following code.


-        context.put(JavaFileManager.class, new Context.Factory<JavaFileManager>() {
-            @Override
-            public JavaFileManager make(Context c) {
-                return new JavacFileManager(c, true, null);
-            }
-        });
+        context.put(JavaFileManager.class,
+                (Factory<JavaFileManager>)c -> new JavacFileManager(c, true, null));


For [JDK-8057546](https://bugs.openjdk.java.net/browse/JDK-8057546) `LintLogger`,  I search the words `new DeferredLintHandler.LintLogger` at the [PATCH](https://github.com/openjdk/jdk/commit/c4e8276376676bda9aa4cb00b6d071fb70c21b85). I can get 4 places which are like the following code.


-            deferredLintHandler.report(new DeferredLintHandler.LintLogger() {
-                @Override
-                public void report() {
-                    warnDeprecated(pos, s);
-                }
-            });
+            deferredLintHandler.report(() -> warnDeprecated(pos, s));


For [JDK-8057547](https://bugs.openjdk.java.net/browse/JDK-8057547) `TreeBuilder`,  I search the words `new TreeBuilder` at the [PATCH](https://github.com/openjdk/jdk/commit/c4e8276376676bda9aa4cb00b6d071fb70c21b85). I can get 7 places which are like the following code.


-            return abstractRval(s.selected, new TreeBuilder() {
-                    public JCExpression build(final JCExpression selected) {
-                        return builder.build(make.Select(selected, s.sym));
-                    }
-                });
+            return abstractRval(s.selected, selected -> builder.build(make.Select(selected, s.sym)));


On the other hand, I search `new FreeTypeListener`, `new Context.Factory`, `new DeferredLintHandler.LintLogger` and `new TreeBuilder` at current JDK main line code base. I can't get any result. So I think these four issues are solved by this  [PATCH](https://github.com/openjdk/jdk/commit/c4e8276376676bda9aa4cb00b6d071fb70c21b85) or other patches.

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

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

From github.com+828220+forax at openjdk.java.net  Thu Apr 22 13:43:22 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 22 Apr 2021 13:43:22 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v2]
In-Reply-To: <aXhHEQzKnVPfKlD_jajhMrbbG3IL1YsAfNza2z1hFJo=.ca324950-8aea-4aa5-af07-d20d905b5a69@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <IkC0_x-XCGmTVgM3dkXcBtoqqlQTXfHqulslkkC8nQk=.468d3b8b-0658-480e-8b7f-85f7bd8fdc98@github.com>
 <xSB1xxk3MzItSrbc4ydBwSQ7IKBh49aWMdZPxvQ8BjE=.383f8df8-52e7-475f-9c24-b7f95eff35d9@github.com>
 <p8dXQUdc7HzVhBsUuYI8NkgHSWy2A8P7hwxsEONzZ9k=.87386ba6-8078-4d7f-b004-986eadfa9c2a@github.com>
 <aXhHEQzKnVPfKlD_jajhMrbbG3IL1YsAfNza2z1hFJo=.ca324950-8aea-4aa5-af07-d20d905b5a69@github.com>
Message-ID: <QfGtRtudmIe_WK3iBDvK-TMxJw2tJDKbVxXQn7m9b5A=.06443a8d-2140-408c-8633-a34af6017377@github.com>

On Wed, 21 Apr 2021 15:44:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I see - honestly this seems like a bug in definite assignment? E.g. surely the instance field initializer for `bridgeFilter` must run _after_ the `final` field `names` has been initialized? For now you might try using an anonymous inner class instead of a lambda instead, pretty sure that will take care of the issue. But this looks like a compiler bug.
>
> Actually - doing more tests, I think javac is right. Fields with explicit initializers are initialized BEFORE other constructor statements. Which means that the error message is legitimate (e.g. the lambda is capturing a final value that is not initialized). I think reverting back to anon class would be better here.

It's not a bug, it's a dubious feature, the lambda EG discussed that at length, you can ask Brian about it.

Usually replacing

t.name != names.init

by

  t.name != this.names.init

is enough.

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

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

From mcimadamore at openjdk.java.net  Thu Apr 22 13:48:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Apr 2021 13:48:41 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v2]
In-Reply-To: <9st3xirkgHshaSh3N8qisRDjFy1iIX1aBSbHIP7bejA=.5218f800-f671-4e12-8b05-6b5bd3182f2e@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <9st3xirkgHshaSh3N8qisRDjFy1iIX1aBSbHIP7bejA=.5218f800-f671-4e12-8b05-6b5bd3182f2e@github.com>
Message-ID: <YAyCVNoKqEUNP3dc7x_VUJsk7vMHp3_kaRrUYGFZsus=.838ebc93-6383-45c4-8610-0f9d7f35dfa5@github.com>

On Wed, 21 Apr 2021 15:33:00 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
>> Two existing tests failed and I fixed it.
>> Currently, all the tests in `test/langtools` passed locally by using the following command.
>> 
>> 
>> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
>> 
>> 
>> 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:
> 
>  - Remove file Filter.java
>  - Update copyright
>  - Merge branch 'master' into JDK-8057543
>    
>    # Conflicts:
>    #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java
>  - Add comments.
>  - 8057543: Replace javac's Filter with Predicate (and lambdas)

I agree that all these issues have been fixed - sorry - I thought these issues wanted to replace the various interfaces with interfaces from `j.u.function` (as done in this patch) - but these were about using lambda expressions more where possible - yeah I fixed that long ago.

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

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

From gli at openjdk.java.net  Thu Apr 22 14:01:24 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 22 Apr 2021 14:01:24 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v2]
In-Reply-To: <QfGtRtudmIe_WK3iBDvK-TMxJw2tJDKbVxXQn7m9b5A=.06443a8d-2140-408c-8633-a34af6017377@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <IkC0_x-XCGmTVgM3dkXcBtoqqlQTXfHqulslkkC8nQk=.468d3b8b-0658-480e-8b7f-85f7bd8fdc98@github.com>
 <xSB1xxk3MzItSrbc4ydBwSQ7IKBh49aWMdZPxvQ8BjE=.383f8df8-52e7-475f-9c24-b7f95eff35d9@github.com>
 <p8dXQUdc7HzVhBsUuYI8NkgHSWy2A8P7hwxsEONzZ9k=.87386ba6-8078-4d7f-b004-986eadfa9c2a@github.com>
 <aXhHEQzKnVPfKlD_jajhMrbbG3IL1YsAfNza2z1hFJo=.ca324950-8aea-4aa5-af07-d20d905b5a69@github.com>
 <QfGtRtudmIe_WK3iBDvK-TMxJw2tJDKbVxXQn7m9b5A=.06443a8d-2140-408c-8633-a34af6017377@github.com>
Message-ID: <WZ56jxxW_-W0B5KI24OHLyyI3di2FXADZuQCMlsP_tM=.16502198-62d1-4ddb-8f55-6f852a60852b@github.com>

On Thu, 22 Apr 2021 13:40:40 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Actually - doing more tests, I think javac is right. Fields with explicit initializers are initialized BEFORE other constructor statements. Which means that the error message is legitimate (e.g. the lambda is capturing a final value that is not initialized). I think reverting back to anon class would be better here.
>
> It's not a bug, it's a dubious feature, the lambda EG discussed that at length, you can ask Brian about it.
> 
> Usually replacing
> 
> t.name != names.init
> 
> by
> 
>   t.name != this.names.init
> 
> is enough.

@forax Thank you for your reply. I tested `t.name != this.names.init` with `final Names names;` just now. The error also occurred. Same as `t.name != names.init`.

And I think that `t.name != names.init` and `t.name != this.names.init` are equal at this situation.

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

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

From igraves at openjdk.java.net  Thu Apr 22 14:45:37 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 22 Apr 2021 14:45:37 GMT
Subject: RFR: 8263621: Convert jdk.compiler to use Stream.toList()
Message-ID: <Tuk9V_fzRD8idOrCGmhseD9QiEDMEgsqQfJxqB8oy_E=.896fab32-64ae-4f87-8f71-6faa5377e37b@github.com>

Converting use of `Collectors.toList()` to `Stream.toList()` where appropriate. Per [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559).

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

Commit messages:
 - Converting to Stream.toList()

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

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

From gli at openjdk.java.net  Thu Apr 22 14:56:26 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 22 Apr 2021 14:56:26 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v2]
In-Reply-To: <YAyCVNoKqEUNP3dc7x_VUJsk7vMHp3_kaRrUYGFZsus=.838ebc93-6383-45c4-8610-0f9d7f35dfa5@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <9st3xirkgHshaSh3N8qisRDjFy1iIX1aBSbHIP7bejA=.5218f800-f671-4e12-8b05-6b5bd3182f2e@github.com>
 <YAyCVNoKqEUNP3dc7x_VUJsk7vMHp3_kaRrUYGFZsus=.838ebc93-6383-45c4-8610-0f9d7f35dfa5@github.com>
Message-ID: <qqrpmp_3hSWCqEpGKWFr-WSqJ43KgbSU4l-2h_Wmjwk=.ae52f4d0-58c2-4eca-bf4f-4e4d508a2ad0@github.com>

On Thu, 22 Apr 2021 13:45:36 GMT, Maurizio Cimadamore <mcimadamore 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:
>> 
>>  - Remove file Filter.java
>>  - Update copyright
>>  - Merge branch 'master' into JDK-8057543
>>    
>>    # Conflicts:
>>    #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java
>>  - Add comments.
>>  - 8057543: Replace javac's Filter with Predicate (and lambdas)
>
> I agree that all these issues have been fixed - sorry - I thought these issues wanted to replace the various interfaces with interfaces from `j.u.function` (as done in this patch) - but these were about using lambda expressions more where possible - yeah I fixed that long ago.

@mcimadamore OK, I closed them just now.

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

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

From lgxbslgx at gmail.com  Thu Apr 22 15:02:30 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Thu, 22 Apr 2021 23:02:30 +0800
Subject: [Investigation] Use pattern matching for instanceof at module
 jdk.compiler
In-Reply-To: <a5cd36de-1260-8d93-52a8-fe30f8e84ce3@oracle.com>
References: <CAPSsVqg9WwdbgTjW0=HTz-e969DKnwnQGih8xMR65y7Gb0vi1w@mail.gmail.com>
 <a5cd36de-1260-8d93-52a8-fe30f8e84ce3@oracle.com>
Message-ID: <CAPSsVqhfdQxELgXh5BzB-3vpjnXbYr+P8kzJXapmj2hBS3Se0w@mail.gmail.com>

Hi Brian,

Thank you for your reply. My confusion is solved.

If nobody announces that the same work is in progress, I will start the
work.

----
Best Regards,
Guoxiong.

On Thu, Apr 22, 2021 at 1:08 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Just like keeping the JDK codebase up to "modern Java" standards (an
> ongoing task!), we should do the same with the compiler codebase.  There is
> one constraint; we must wait one extra version to use new (permanent)
> language features in the compiler, because the compiler must be compiled
> with a boot JDK which is of the previous version.  So if pattern matching
> became permanent in 16, we can start to use it in the compiler in 17.
>
> In the JDK, we've set the following guidelines for these sort of
> refactoring patches:
>
>  - Each patch should focus on _one_ refactoring (e.g., replace traditional
> instanceof with pattern).  This reduces the cognitive load on reviewers.
>  - Each patch should have a single review domain.  This is not an issue
> for the compiler, but is an issue for the JDK, where `java.base` has
> generic library code, security code, UI code, each of which requires review
> by separate skillsets.
>  - Patches shouldn't be "too big".  This argues for breaking down by
> groups of related packages if the whole thing is too big.
>  - No API changes.
>  - Patches should be, to the degree possible, produced entirely by
> automated refactoring tools.  Resist the urge to make small manual tweaks
> to make the code look better.  Again, this makes it much easier for
> reviewers to conclude "nothing to see here."
>
>
> On 4/21/2021 12:51 PM, Guoxiong Li wrote:
>
> Hi all,
>
> The JEP-394[1] implemented the `Pattern matching for instanceof` at JDK
> 16. It is a good specification. Many packages or modules of the JDK begin
> to use it, such as package `java.time`[2][3]. I think it is good for the
> javac compiler to use it, too.
>
> Here are some issues we need to consider or something I want to confirm.
>
> 1. What's your opinion about this idea? Is it necessary?
> 2. Is somebody doing the same thing locally? If not, I would like to do
> that.
> 3. Is it good to revise the whole module `jdk.compiler` by submitting a
> big patch? Or, should we separate it into several sub-tasks according to
> different packages?
> 4. Do the related modules, such as `java.compiler`, also need to be
> revised?
>
> Any idea is appreciated.
>
> [1] https://openjdk.java.net/jeps/394
> [2] https://bugs.openjdk.java.net/browse/JDK-8263668
> [3] https://github.com/openjdk/jdk/pull/3170
>
> ----
> Best Regards,
> Guoxiong
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210422/104e8495/attachment-0001.htm>

From mcimadamore at openjdk.java.net  Thu Apr 22 15:20:21 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Apr 2021 15:20:21 GMT
Subject: RFR: 8263621: Convert jdk.compiler to use Stream.toList()
In-Reply-To: <Tuk9V_fzRD8idOrCGmhseD9QiEDMEgsqQfJxqB8oy_E=.896fab32-64ae-4f87-8f71-6faa5377e37b@github.com>
References: <Tuk9V_fzRD8idOrCGmhseD9QiEDMEgsqQfJxqB8oy_E=.896fab32-64ae-4f87-8f71-6faa5377e37b@github.com>
Message-ID: <b9ZGU8OGVGb9zsDNDWnFFBgoI9AnEvDMNUKUNruq6W8=.dd2cd666-660d-4b95-909c-c9fdde4c5171@github.com>

On Thu, 22 Apr 2021 14:35:29 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Converting use of `Collectors.toList()` to `Stream.toList()` where appropriate. Per [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559).

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

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

From vromero at openjdk.java.net  Thu Apr 22 15:32:22 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 22 Apr 2021 15:32:22 GMT
Subject: RFR: 8263621: Convert jdk.compiler to use Stream.toList()
In-Reply-To: <Tuk9V_fzRD8idOrCGmhseD9QiEDMEgsqQfJxqB8oy_E=.896fab32-64ae-4f87-8f71-6faa5377e37b@github.com>
References: <Tuk9V_fzRD8idOrCGmhseD9QiEDMEgsqQfJxqB8oy_E=.896fab32-64ae-4f87-8f71-6faa5377e37b@github.com>
Message-ID: <av_8Rj1VHDuoQVHReWtAUnXbWzRar1KroCOzxXMfdjo=.934d47bb-9a3a-45e8-82fc-495f5c3d8430@github.com>

On Thu, 22 Apr 2021 14:35:29 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Converting use of `Collectors.toList()` to `Stream.toList()` where appropriate. Per [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559).

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From igraves at openjdk.java.net  Thu Apr 22 15:37:25 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 22 Apr 2021 15:37:25 GMT
Subject: RFR: 8263621: Convert jdk.compiler to use Stream.toList()
In-Reply-To: <Tuk9V_fzRD8idOrCGmhseD9QiEDMEgsqQfJxqB8oy_E=.896fab32-64ae-4f87-8f71-6faa5377e37b@github.com>
References: <Tuk9V_fzRD8idOrCGmhseD9QiEDMEgsqQfJxqB8oy_E=.896fab32-64ae-4f87-8f71-6faa5377e37b@github.com>
Message-ID: <polzWUYsfUQR1xmY9ummZ6wqARSWZMO7ZeYZf85k_tE=.4721a29e-fa3c-420f-9521-19c46c8b3656@github.com>

On Thu, 22 Apr 2021 14:35:29 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Converting use of `Collectors.toList()` to `Stream.toList()` where appropriate. Per [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559).

Thanks, all. Not a major change, ran tests last night and it was passing so given two reviewers I'll go ahead and integrate. This one will require a sponsor as I'm not a committer yet. If you want to wait for additional eyes on, that is fine by me too.

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

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

From gli at openjdk.java.net  Thu Apr 22 16:04:51 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 22 Apr 2021 16:04:51 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v3]
In-Reply-To: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
Message-ID: <iDN3xh4itmANMX3lcygOKw4paiq97QCO7lBU20kAL3A=.be5e83e9-f4a2-41a7-9b1c-dd9478a91836@github.com>

> Hi all,
> 
> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
> Two existing tests failed and I fixed it.
> Currently, all the tests in `test/langtools` passed locally by using the following command.
> 
> 
> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
> 
> 
> 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:

  Revert variabl names to modifier final

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1898/files
  - new: https://git.openjdk.java.net/jdk/pull/1898/files/6ee2c890..6670a2e2

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

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

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

From mcimadamore at openjdk.java.net  Thu Apr 22 16:09:23 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Apr 2021 16:09:23 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v3]
In-Reply-To: <iDN3xh4itmANMX3lcygOKw4paiq97QCO7lBU20kAL3A=.be5e83e9-f4a2-41a7-9b1c-dd9478a91836@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <iDN3xh4itmANMX3lcygOKw4paiq97QCO7lBU20kAL3A=.be5e83e9-f4a2-41a7-9b1c-dd9478a91836@github.com>
Message-ID: <sCJxSr-F6YAMOIAQDYjFPU0aFSt1B5kaUn67APcGmuk=.8ef5d5d6-2de6-4bb8-8646-d418eabde94e@github.com>

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

>> Hi all,
>> 
>> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
>> Two existing tests failed and I fixed it.
>> Currently, all the tests in `test/langtools` passed locally by using the following command.
>> 
>> 
>> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
>> 
>> 
>> 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:
> 
>   Revert variabl names to modifier final

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

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

From igraves at openjdk.java.net  Thu Apr 22 16:10:31 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 22 Apr 2021 16:10:31 GMT
Subject: Integrated: 8263621: Convert jdk.compiler to use Stream.toList()
In-Reply-To: <Tuk9V_fzRD8idOrCGmhseD9QiEDMEgsqQfJxqB8oy_E=.896fab32-64ae-4f87-8f71-6faa5377e37b@github.com>
References: <Tuk9V_fzRD8idOrCGmhseD9QiEDMEgsqQfJxqB8oy_E=.896fab32-64ae-4f87-8f71-6faa5377e37b@github.com>
Message-ID: <-7yNaPlAlV2lSaGyXS65qPOo2eCo39O1RYKTksjqIUc=.33aa4310-ba5b-428e-b01d-fd8190d915ff@github.com>

On Thu, 22 Apr 2021 14:35:29 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Converting use of `Collectors.toList()` to `Stream.toList()` where appropriate. Per [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559).

This pull request has now been integrated.

Changeset: 33a86b9e
Author:    Ian Graves <igraves at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/33a86b9e
Stats:     13 lines in 9 files changed: 0 ins; 0 del; 13 mod

8263621: Convert jdk.compiler to use Stream.toList()

Reviewed-by: mcimadamore, vromero

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

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

From gli at openjdk.java.net  Thu Apr 22 16:17:28 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 22 Apr 2021 16:17:28 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
 [v2]
In-Reply-To: <YAyCVNoKqEUNP3dc7x_VUJsk7vMHp3_kaRrUYGFZsus=.838ebc93-6383-45c4-8610-0f9d7f35dfa5@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
 <9st3xirkgHshaSh3N8qisRDjFy1iIX1aBSbHIP7bejA=.5218f800-f671-4e12-8b05-6b5bd3182f2e@github.com>
 <YAyCVNoKqEUNP3dc7x_VUJsk7vMHp3_kaRrUYGFZsus=.838ebc93-6383-45c4-8610-0f9d7f35dfa5@github.com>
Message-ID: <L7bBTRwLd3DtMjIpRAZV5Sd4xYx13Ssth6UBrT63m9M=.0464c4c5-1679-4f40-8bdb-c42e2598abd3@github.com>

On Thu, 22 Apr 2021 13:45:36 GMT, Maurizio Cimadamore <mcimadamore 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:
>> 
>>  - Remove file Filter.java
>>  - Update copyright
>>  - Merge branch 'master' into JDK-8057543
>>    
>>    # Conflicts:
>>    #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java
>>  - Add comments.
>>  - 8057543: Replace javac's Filter with Predicate (and lambdas)
>
> I agree that all these issues have been fixed - sorry - I thought these issues wanted to replace the various interfaces with interfaces from `j.u.function` (as done in this patch) - but these were about using lambda expressions more where possible - yeah I fixed that long ago.

@mcimadamore Thank you for your review. Could I get your help to sponsor this patch?
Although the Pre-submit tests don't finish, the tests on `tools/javac` passed locally.

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

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

From darcy at openjdk.java.net  Thu Apr 22 16:25:21 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 22 Apr 2021 16:25:21 GMT
Subject: Integrated: 8265591: Remove vestiages of intermediate JSR 175
 annotation format
In-Reply-To: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
References: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
Message-ID: <xswxuZoO_BOgIanHKzv1RYc9PzyKPo5BlyXthPEcdWM=.9f4571b6-1145-4077-b106-7fdd0861d34b@github.com>

On Tue, 20 Apr 2021 23:37:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> During the recent review of JDK-8228988, I noticed again the comments in the annotation parser about support for the pre-GA annotation format used before JDK 5.0 shipped. During the development of annotations, there was a late change to correct a flaw in the annotation encoding, JDK-5020908.
> 
> I don't think it is necessary to carry forward support for this transient format any longer and this changeset removes support from both core reflection and javac.
> 
> Clean runs of relevant test; I gauge this fix as no-reg hard.

This pull request has now been integrated.

Changeset: 8758b554
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8758b554
Stats:     24 lines in 2 files changed: 0 ins; 19 del; 5 mod

8265591: Remove vestiages of intermediate JSR 175 annotation format

Reviewed-by: jfranck

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

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

From vromero at openjdk.java.net  Thu Apr 22 16:37:26 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 22 Apr 2021 16:37:26 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java [v2]
In-Reply-To: <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
 <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
Message-ID: <FmZwpxuM9hsPqybZSz1fwItUMOC86D3DJJgWyMbU-1U=.78ca0ecb-08da-4225-a635-ed0526312f7a@github.com>

On Tue, 22 Dec 2020 18:52:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This code was introduced in main repository under https://bugs.openjdk.java.net/browse/JDK-8006775
>> I checked original commit in `type-annotations/langtools` repository: https://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/71f35e4b93a5
>> Looks like it's not a merge problem.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066694: Strange code in JavacParser.java

Marked as reviewed by vromero (Reviewer).

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

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

From gli at openjdk.java.net  Thu Apr 22 16:47:23 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 22 Apr 2021 16:47:23 GMT
Subject: Integrated: 8057543: Replace javac's Filter with Predicate (and
 lambdas)
In-Reply-To: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
Message-ID: <qaFWSmXEktFWLSQ69WzyHSzcvrUVncUulKoWvQcjc6g=.c60306ee-a172-45c1-9d38-698985cbbf37@github.com>

On Sun, 27 Dec 2020 14:54:16 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
> Two existing tests failed and I fixed it.
> Currently, all the tests in `test/langtools` passed locally by using the following command.
> 
> 
> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
> 
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 657f1039
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/657f1039
Stats:     180 lines in 19 files changed: 20 ins; 42 del; 118 mod

8057543: Replace javac's Filter with Predicate (and lambdas)

Reviewed-by: mcimadamore

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

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

From gli at openjdk.java.net  Thu Apr 22 17:43:06 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 22 Apr 2021 17:43:06 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v3]
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: <lajA6WApDfLggTsVmhk52OwIrWkzIeyZwL80sE7T-OE=.31e3e37c-b7fd-4a22-89f9-4315bf99415f@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 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

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

Changes: https://git.openjdk.java.net/jdk/pull/1758/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1758&range=02
  Stats: 63 lines in 4 files changed: 32 ins; 22 del; 9 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 Apr 22 17:43:15 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 22 Apr 2021 17:43:15 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v2]
In-Reply-To: <lihZhiILl0jhuiIj7USLwsx6n114-BAg1cLYtNfIxJ8=.e1651dbd-b915-4533-9ac6-0594cb8ca527@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <lihZhiILl0jhuiIj7USLwsx6n114-BAg1cLYtNfIxJ8=.e1651dbd-b915-4533-9ac6-0594cb8ca527@github.com>
Message-ID: <YPRvJ2DbNcbqWN0GYJnOftrTgul3HfbOF0euqARPI5U=.d1d08930-821c-43c7-8cb0-6d6b5681a9ac@github.com>

On Wed, 23 Dec 2020 04:41: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 incrementally with one additional commit since the last revision:
> 
>   Remove the content in documentation javac.1

The CSR was created. Please see [JDK-8265772](https://bugs.openjdk.java.net/browse/JDK-8265772).  And I updated the copyright. Thank you for taking the time to review the CSR andthis patch.

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

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

From iris at openjdk.java.net  Thu Apr 22 17:56:31 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 22 Apr 2021 17:56:31 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java [v2]
In-Reply-To: <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
 <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>
Message-ID: <HlfO4U_HM9KjcoCFewSzNn_bklMLoQ9C4_FS__tZaBw=.ffc5242e-8b82-42d6-8805-7b3163c6b16a@github.com>

On Tue, 22 Dec 2020 18:52:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This code was introduced in main repository under https://bugs.openjdk.java.net/browse/JDK-8006775
>> I checked original commit in `type-annotations/langtools` repository: https://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/71f35e4b93a5
>> Looks like it's not a merge problem.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8066694: Strange code in JavacParser.java

Marked as reviewed by iris (Reviewer).

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

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

From jespersm at openjdk.java.net  Thu Apr 22 21:05:55 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 22 Apr 2021 21:05:55 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors [v2]
In-Reply-To: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
Message-ID: <UVV2uKxRsnATXch-9yDOezadRwAugs-mtknCSoCPv94=.3a8a8d0f-efe6-4696-8d06-bee9b3bb3e1e@github.com>

> Unknown lookups in the java package give misleading compilation errors

Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:

  Fixes filename, description, and javac options.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3428/files
  - new: https://git.openjdk.java.net/jdk/pull/3428/files/1889dc71..10889111

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

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

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

From jespersm at openjdk.java.net  Thu Apr 22 21:05:55 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 22 Apr 2021 21:05:55 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors
In-Reply-To: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
Message-ID: <1VV7MXg8AQbTiqr87E-Ti730zJxfLieE_whcJRKFu_M=.c48194ed-abd8-4171-8d6c-9fc4b3c058b6@github.com>

On Sun, 11 Apr 2021 12:49:35 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Unknown lookups in the java package give misleading compilation errors

Updated. I'm currently running the tier1 tests, and they won't fail (except the few locale-dependent tests which always fail here)

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

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

From vromero at openjdk.java.net  Fri Apr 23 02:16:04 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 23 Apr 2021 02:16:04 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v4]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <d2S1kXjoYHbf5udn5apKvZynDITGCFg8wWzD1OWfAmE=.97cd30bb-f133-4f81-b55c-a031c4c5a386@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 eight additional commits since the last revision:

 - 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
 - 8260517: Compiler implementation for Sealed Classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/8ebe56fd..43e9cb5f

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

  Stats: 40790 lines in 1391 files changed: 8730 ins; 27464 del; 4596 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 jespersm at openjdk.java.net  Fri Apr 23 05:41:48 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Fri, 23 Apr 2021 05:41:48 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors [v3]
In-Reply-To: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
Message-ID: <z89vBr8cocMX1bzUwo8_SybMCYSjLzZc6q3isX9nYvo=.3341a8da-3e74-4aba-ae75-ff66ded8c3e1@github.com>

> Unknown lookups in the java package give misleading compilation errors

Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:

  Trailing whitespaces again.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3428/files
  - new: https://git.openjdk.java.net/jdk/pull/3428/files/10889111..41efd574

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

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

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

From gli at openjdk.java.net  Fri Apr 23 11:15:11 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 23 Apr 2021 11:15:11 GMT
Subject: RFR: 8239596: PARAMETER annotation on receiver type does not
 cause error [v2]
In-Reply-To: <HIPFxHVe1NJS2dldCZjPosdBxw-cZgpUE-PXc4WZroE=.2f69a16b-017b-44a0-89cd-a0686223c270@github.com>
References: <HIPFxHVe1NJS2dldCZjPosdBxw-cZgpUE-PXc4WZroE=.2f69a16b-017b-44a0-89cd-a0686223c270@github.com>
Message-ID: <cfvL6lUzCrHL3Nkq7NNFrCc7LgyJ7LY1-MZeieJj6-I=.d6baa85f-e3ad-433f-8bac-520dbcd4cecd@github.com>

> Hi all,
> 
> `TypeAnnotationsValidator::visitMethodDef`  uses `checkForDeclarationAnnotations` incorrectly so that the check could not work as expected and some related errors are not reported. This patch fixes it and adds a corresponding test case.
> 
> 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 three additional commits since the last revision:

 - Use meaningful class name and update copyright
 - Merge branch 'master' into JDK-8239596
 - 8239596: PARAMETER annotation on receiver type does not cause error

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1881/files
  - new: https://git.openjdk.java.net/jdk/pull/1881/files/a3b59573..760685a8

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

  Stats: 379785 lines in 8965 files changed: 199458 ins; 123557 del; 56770 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1881.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1881/head:pull/1881

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

From gli at openjdk.java.net  Fri Apr 23 12:01:31 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 23 Apr 2021 12:01:31 GMT
Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering
 [v3]
In-Reply-To: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
References: <IgfH4qwqZwjwcu9PiObG0fJ0YhTo5oqabUFpLI8Wuro=.bb2584a1-6c61-460c-879c-2ffb5e072021@github.com>
Message-ID: <AYhHO6bn3z23gOJyC1UFlrxvPXs2QHjpJeUj2M3AQ_c=.a3147bd3-7706-4d6f-b665-3dcd4f989122@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 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:
  - all: https://git.openjdk.java.net/jdk/pull/1934/files
  - new: https://git.openjdk.java.net/jdk/pull/1934/files/f55e8a3a..f1ae6684

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

  Stats: 375357 lines in 8680 files changed: 198659 ins; 120636 del; 56062 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  Fri Apr 23 12:41:13 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 23 Apr 2021 12:41:13 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v3]
In-Reply-To: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
Message-ID: <4iAX0F9xrfxgTuIxYl1JvUgFqc7Rr6V4BCecemCyXGk=.7f15e598-e1f4-4fa4-9814-e9b22eccc48b@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 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

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

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

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

  Stats: 379711 lines in 8961 files changed: 199371 ins; 123615 del; 56725 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  Fri Apr 23 13:54:25 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 23 Apr 2021 13:54:25 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class
In-Reply-To: <gd1KyNtxkpPD-q2su-atDzz5EhmIp0UZzDDWCknmURE=.57502c11-933d-4911-bbe9-9e3b22c35658@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
 <iGSJo_LeKj9d6DEhxbe4Q2LVUgoqzx82LRq0CNcFzvo=.8d14d0d6-15e9-4399-85f1-66a4df1a864b@github.com>
 <Rdb3HB9z9wYky1I846DKj7tsjoAI4Pe-nXM0bGyh90Q=.2ab254a6-1267-43ac-bf40-fa6232f95bfc@github.com>
 <gd1KyNtxkpPD-q2su-atDzz5EhmIp0UZzDDWCknmURE=.57502c11-933d-4911-bbe9-9e3b22c35658@github.com>
Message-ID: <8zpGaiZwTXa3hUudr6nhCwdQsrJZM7rGco8US8GorSI=.f22523f9-f38d-4d57-a676-f01fdff5aeed@github.com>

On Wed, 21 Apr 2021 14:32:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> So, in `Attr` we check that the class implements `Iterable`. In this case it does, but there's an incompatible override. That issues an error as expected, so compiling the provided test case:
>> 
>> 
>> public class T8232765 {
>>           public void test(String[] args) {
>>               MyLinkedList<Integer> list = new MyLinkedList<>();
>>               for (int x : list)
>>                   System.out.print(x);
>>           }
>>       }
>>       class MyLinkedList<T> implements java.lang.Iterable<T> {
>>           public void iterator() {}
>>       };
>> 
>> Does not result in a crash.
>> 
>> I suspect the issue in JBS is more subtle, and involves, perhaps, separate compilation? I find this very odd - typically javac stops at a phase (e.g. Attr) if one or more files had errors in that phase. In this case we have a bad implementation of `Iterable`, so we should not be able to go past `Attr`.
>
> Ok, I see where I went wrong. I can reproduce the crash - the problem I had was related to `public` appearing in a file with wrong name.
> 
> So, the issue occurs when two classes are defined in the same source. In that case, we advance T8232765 through the compiler pipeline almost independently of MyLinkedList. The only thing happening for MyLinkedList is the typeEnter step - but no Attr is performed, so no overriding checks.
> 
> If the `simple` compile policy is used, no crash occurs:
> 
> 
> javac -XDcompilePolicy=simple -XDverboseCompilePolicy=true Test.java 
> [attribute T8232765]
> [attribute MyLinkedList]
> Test.java:8: error: MyLinkedList is not abstract and does not override abstract method iterator() in Iterable
>                 class MyLinkedList<T> implements java.lang.Iterable<T> {
>                 ^
>   where T is a type-variable:
>     T extends Object declared in class MyLinkedList
> Test.java:9: error: iterator() in MyLinkedList cannot implement iterator() in Iterable
>                     public void iterator() {}
>                                 ^
>   return type void is not compatible with Iterator<T#2>
>   where T#1,T#2 are type-variables:
>     T#1 extends Object declared in interface Iterable
>     T#2 extends Object declared in class MyLinkedList
> 2 errors
> 
> 
> This has come up again in the past: should the *simple* policy be the default?

@mcimadamore Thank you for your review.

> issuing this kind of type-checking errors in Lower is unusual. This kind of stuff should be caught in earlier (e.g. in Attr)

I agree with you about it. I will try to move the check to Attr.

> So, the issue occurs when two classes are defined in the same source. In that case, we advance T8232765 through the compiler pipeline almost independently of MyLinkedList. The only thing happening for MyLinkedList is the typeEnter step - but no Attr is performed, so no overriding checks.

Yes, your analysis is right. And this situation is common when we use the iterator. So it is neccesary to fix it.

> This has come up again in the past: should the simple policy be the default?

For this bug, if we use the `simple` policy, we can get the more correct error message. But we don't know which policy the users use. So I think it is not a issue about the default policy. We only need to comfirm that all the policies work well, which is our ultimate goal.

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

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

From gli at openjdk.java.net  Fri Apr 23 16:33:13 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 23 Apr 2021 16:33:13 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class [v2]
In-Reply-To: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
Message-ID: <n6xw5TiMMFB29pxf4rgVRdgHw44FK0FOIoOMC3OJS4Q=.0e9bdf99-ce90-4cae-ac7c-2d0deb1df9a8@github.com>

> Hi all,
> 
> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
> 
> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
> 
> 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 three additional commits since the last revision:

 - Move the check to Attr. Use meaningful class name. Fix failed tests.
 - Merge branch 'master' into JDK-8232765
 - 8232765: NullPointerException at Types.eraseNotNeeded() when compiling a class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2099/files
  - new: https://git.openjdk.java.net/jdk/pull/2099/files/f2fafbde..cbbaeddc

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

  Stats: 342070 lines in 8019 files changed: 185380 ins; 111856 del; 44834 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2099.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2099/head:pull/2099

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

From gli at openjdk.java.net  Fri Apr 23 16:33:14 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 23 Apr 2021 16:33:14 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class
In-Reply-To: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
Message-ID: <6TsW6Z-YXxtqg5rNsmvp_44mNfHHAxXbyC6Gg1kQafM=.18991964-095b-43ec-9969-19d7f220ce8c@github.com>

On Fri, 15 Jan 2021 12:17:39 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
> 
> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

@mcimadamore I updated the code. Thank you for taking the time to review.

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

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

From mcimadamore at openjdk.java.net  Fri Apr 23 16:42:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 23 Apr 2021 16:42:40 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class [v2]
In-Reply-To: <n6xw5TiMMFB29pxf4rgVRdgHw44FK0FOIoOMC3OJS4Q=.0e9bdf99-ce90-4cae-ac7c-2d0deb1df9a8@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
 <n6xw5TiMMFB29pxf4rgVRdgHw44FK0FOIoOMC3OJS4Q=.0e9bdf99-ce90-4cae-ac7c-2d0deb1df9a8@github.com>
Message-ID: <fp4XOmK8BLt-Q7hUeZMLki0WvGd9XcDfef8CwM6S1dQ=.94a4356b-b5fc-41c2-92aa-725e6da9fa78@github.com>

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

>> Hi all,
>> 
>> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
>> 
>> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
>> 
>> 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 three additional commits since the last revision:
> 
>  - Move the check to Attr. Use meaningful class name. Fix failed tests.
>  - Merge branch 'master' into JDK-8232765
>  - 8232765: NullPointerException at Types.eraseNotNeeded() when compiling a class

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

> 1543:                     if (types.asSuper(iterSymbol.type.getReturnType(), syms.iteratorType.tsym) == null) {
> 1544:                         log.error(tree.pos(),
> 1545:                                 Errors.OverrideIncompatibleRet(

I believe here we don't need a new diagnostic - let's just reuse:


log.error(tree.expr.pos(),
                              Errors.ForeachNotApplicableToType(exprType,
                                                                Fragments.TypeReqArrayOrIterable));


On the basis that the provided type is NOT an well-formed `Iterable` type (because it has a bogus override).

The thing I'm a bit afraid, if we go down this path is that we will need to replicate all the override checks here - what if the method has the right signature but is private? It's still a bogus override.

I could be fine if the answer was "this is the bare minimum we need to verify to make sure code generation doesn't crash". But I'd like to see a comment on the code stating exactly that.

Do we have a similar problem with AutoCloseable? E.g. a close() method returning something odd?

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

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

From vromero at openjdk.java.net  Fri Apr 23 19:23:38 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 23 Apr 2021 19:23:38 GMT
Subject: RFR: 8239596: PARAMETER annotation on receiver type does not
 cause error [v2]
In-Reply-To: <cfvL6lUzCrHL3Nkq7NNFrCc7LgyJ7LY1-MZeieJj6-I=.d6baa85f-e3ad-433f-8bac-520dbcd4cecd@github.com>
References: <HIPFxHVe1NJS2dldCZjPosdBxw-cZgpUE-PXc4WZroE=.2f69a16b-017b-44a0-89cd-a0686223c270@github.com>
 <cfvL6lUzCrHL3Nkq7NNFrCc7LgyJ7LY1-MZeieJj6-I=.d6baa85f-e3ad-433f-8bac-520dbcd4cecd@github.com>
Message-ID: <iEJ9hRji8OKFWW-noeiyv32uXVreNNRtkrw9lLWbhBM=.72a66aa5-6d05-46f8-9fb6-39616584dd8a@github.com>

On Fri, 23 Apr 2021 11:15:11 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> `TypeAnnotationsValidator::visitMethodDef`  uses `checkForDeclarationAnnotations` incorrectly so that the check could not work as expected and some related errors are not reported. This patch fixes it and adds a corresponding test case.
>> 
>> 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 three additional commits since the last revision:
> 
>  - Use meaningful class name and update copyright
>  - Merge branch 'master' into JDK-8239596
>  - 8239596: PARAMETER annotation on receiver type does not cause error

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Fri Apr 23 19:29:32 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 23 Apr 2021 19:29:32 GMT
Subject: RFR: 8263432: javac may report an invalid package/class clash on
 case insensitive filesystems
In-Reply-To: <XVY3kmwWCWjj3JOIbj8cwSOHK-RDSVH4OpMpVKcN-gM=.4a82383d-0114-471f-8b5c-3aae562f2c1e@github.com>
References: <XVY3kmwWCWjj3JOIbj8cwSOHK-RDSVH4OpMpVKcN-gM=.4a82383d-0114-471f-8b5c-3aae562f2c1e@github.com>
Message-ID: <CKDCW9k9FRgFMduivziA60QYZ1XCCeKxInP7xoFVUlQ=.29470e2c-0649-41dc-abf7-cc690647429f@github.com>

On Thu, 18 Mar 2021 09:12:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> To implement the package/class clash check as per JLS 7.1, javac creates "phantom" packages with the same names as the classes and checks if these packages exist (implemented as a check if it has seen a source or class file in the corresponding directory). Every package created (phantom or not) gets registered to its enclosing `ModuleSymbol`, and when `ModuleSymbol.getEnclosedElements()` is called, the package is completed (i.e. its directory is listed).
> 
> This can cause an invalid package/class clash error to be reported in specific cases if there is a package and a class with names differing only in letter cases (like `org.jruby.runtime.callsite` and `org.jruby.runtime.CallSite`). What happens here is: the phantom package for the `org.jruby.runtime.CallSite` package is created, the package/class clash check is performed and passes (no errors). Then annotation processing calls `ModuleSymbol.getEnclosedElements()`, the phantom package's directory (`org/jruby/runtime/CallSite`) is listed from the filesystem, and contains some source files, so appears non-empty/existing (due to the case insensitive filesystem, the content of `org/jruby/runtime/callsite` directory is listed in fact). Then another round of annotation processing happens, and the package/class clash check is performed again. This time, the package appears to exist, and hence the check fails.
> 
> The proposal here is to avoid creating of the phantom packages (and hence registering them into `ModuleSymbol`) for the package/class clash check. That should prevent listing the package with the wrong name unnecessarily/unintentionally.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Fri Apr 23 19:37:26 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 23 Apr 2021 19:37:26 GMT
Subject: RFR: 8231179: Investigate why
 tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v5]
In-Reply-To: <7jmnF46PRLbCoyyRe3emdRzMq2fKLdrjrC2DkVP9kAc=.8ef1a06d-9143-4d03-9a3f-b9d4b2fea337@github.com>
References: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
 <7jmnF46PRLbCoyyRe3emdRzMq2fKLdrjrC2DkVP9kAc=.8ef1a06d-9143-4d03-9a3f-b9d4b2fea337@github.com>
Message-ID: <77P4U_dcbp5Tctg_ILsOWtzUOWEzctRD8ycGmz2ZVvE=.2c6583af-e68a-455a-9d1c-22fbdbc7a68c@github.com>

On Mon, 19 Apr 2021 04:36:03 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below.
>> 
>> 
>> @Override @DefinedBy(Api.COMPILER)
>> public String getName() {
>>     return relativePath.resolveAgainst(userPackageRootDir).toString();  // <-----------------
>> }
>> 
>> 
>> And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below
>> 
>> 
>> public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException {
>>     String sep = directory.getFileSystem().getSeparator();  // <---------------------
>>     return directory.resolve(path.replace("/", sep));
>> }
>> 
>> 
>> We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected.
>> 
>> This patch fixes the test by using the file system separator instead of operating system separator.
>> 
>> 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 six commits:
> 
>  - Merge branch 'master' into JDK-8231179
>    
>    # Conflicts:
>    #	test/langtools/ProblemList.txt
>  - Merge branch 'master' into JDK-8231179
>  - Merge branch 'master' into JDK-8231179
>  - Use StandardJavaFileManager::asPath
>  - Modify copyright
>  - 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window

looks good to me

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

Marked as reviewed by vromero (Reviewer).

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

From gli at openjdk.java.net  Fri Apr 23 21:08:30 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 23 Apr 2021 21:08:30 GMT
Subject: RFR: 8239596: PARAMETER annotation on receiver type does not
 cause error [v2]
In-Reply-To: <iEJ9hRji8OKFWW-noeiyv32uXVreNNRtkrw9lLWbhBM=.72a66aa5-6d05-46f8-9fb6-39616584dd8a@github.com>
References: <HIPFxHVe1NJS2dldCZjPosdBxw-cZgpUE-PXc4WZroE=.2f69a16b-017b-44a0-89cd-a0686223c270@github.com>
 <cfvL6lUzCrHL3Nkq7NNFrCc7LgyJ7LY1-MZeieJj6-I=.d6baa85f-e3ad-433f-8bac-520dbcd4cecd@github.com>
 <iEJ9hRji8OKFWW-noeiyv32uXVreNNRtkrw9lLWbhBM=.72a66aa5-6d05-46f8-9fb6-39616584dd8a@github.com>
Message-ID: <8WFHv6e9HM0baqPoBHQbhQ13eH4p9AXsp34i3bMz3q8=.02f8ef81-f4a2-435c-85c7-6a877572d994@github.com>

On Fri, 23 Apr 2021 19:20:59 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 three additional commits since the last revision:
>> 
>>  - Use meaningful class name and update copyright
>>  - Merge branch 'master' into JDK-8239596
>>  - 8239596: PARAMETER annotation on receiver type does not cause error
>
> looks sensible

@vicente-romero-oracle Thank you for your review. Could I get your help to sponsor this patch?

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

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

From gli at openjdk.java.net  Fri Apr 23 21:09:26 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 23 Apr 2021 21:09:26 GMT
Subject: RFR: 8231179: Investigate why
 tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v5]
In-Reply-To: <77P4U_dcbp5Tctg_ILsOWtzUOWEzctRD8ycGmz2ZVvE=.2c6583af-e68a-455a-9d1c-22fbdbc7a68c@github.com>
References: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
 <7jmnF46PRLbCoyyRe3emdRzMq2fKLdrjrC2DkVP9kAc=.8ef1a06d-9143-4d03-9a3f-b9d4b2fea337@github.com>
 <77P4U_dcbp5Tctg_ILsOWtzUOWEzctRD8ycGmz2ZVvE=.2c6583af-e68a-455a-9d1c-22fbdbc7a68c@github.com>
Message-ID: <q4hkbVSyLOUXZN-YgnJIn4sPH0tG3-Edc4Mgyxi91jg=.feb4cde7-0121-4e52-aeed-f17767efd651@github.com>

On Fri, 23 Apr 2021 19:34:23 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 pull request now contains six commits:
>> 
>>  - Merge branch 'master' into JDK-8231179
>>    
>>    # Conflicts:
>>    #	test/langtools/ProblemList.txt
>>  - Merge branch 'master' into JDK-8231179
>>  - Merge branch 'master' into JDK-8231179
>>  - Use StandardJavaFileManager::asPath
>>  - Modify copyright
>>  - 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window
>
> looks good to me

@vicente-romero-oracle Thank you for your review. Could I get your help to sponsor this patch?

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

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

From gli at openjdk.java.net  Sat Apr 24 02:20:27 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sat, 24 Apr 2021 02:20:27 GMT
Subject: Integrated: 8239596: PARAMETER annotation on receiver type does not
 cause error
In-Reply-To: <HIPFxHVe1NJS2dldCZjPosdBxw-cZgpUE-PXc4WZroE=.2f69a16b-017b-44a0-89cd-a0686223c270@github.com>
References: <HIPFxHVe1NJS2dldCZjPosdBxw-cZgpUE-PXc4WZroE=.2f69a16b-017b-44a0-89cd-a0686223c270@github.com>
Message-ID: <9v0RrQwdv--XPSc_wruyK8UZyX0VtGH9_egYA-MY-kg=.6404d6f4-0fd3-445b-a022-2627b119b171@github.com>

On Wed, 23 Dec 2020 17:05:51 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> `TypeAnnotationsValidator::visitMethodDef`  uses `checkForDeclarationAnnotations` incorrectly so that the check could not work as expected and some related errors are not reported. This patch fixes it and adds a corresponding test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: d87a4c3b
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d87a4c3b
Stats:     89 lines in 2 files changed: 87 ins; 1 del; 1 mod

8239596: PARAMETER annotation on receiver type does not cause error

Reviewed-by: vromero

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

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

From gli at openjdk.java.net  Sat Apr 24 02:22:25 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sat, 24 Apr 2021 02:22:25 GMT
Subject: Integrated: 8231179: Investigate why
 tools/javac/options/BCPOrSystemNotSpecified.java fails on Window
In-Reply-To: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
References: <QWzLFbchq8E9xO79gM8QIJCVzgi4H7rl4RtpbgjgHYE=.6460d5d0-7045-4bd3-a4e7-4a3b83fcd2ea@github.com>
Message-ID: <rkslnWCUgr4MbZd7G6A3_XJNICLsIiwRTGAQpzt8Rz8=.f4b79359-be2e-41d3-9ee4-00d6dd0db56d@github.com>

On Fri, 8 Jan 2021 13:33:34 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below.
> 
> 
> @Override @DefinedBy(Api.COMPILER)
> public String getName() {
>     return relativePath.resolveAgainst(userPackageRootDir).toString();  // <-----------------
> }
> 
> 
> And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below
> 
> 
> public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException {
>     String sep = directory.getFileSystem().getSeparator();  // <---------------------
>     return directory.resolve(path.replace("/", sep));
> }
> 
> 
> We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected.
> 
> This patch fixes the test by using the file system separator instead of operating system separator.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 4b7f0274
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4b7f0274
Stats:     10 lines in 2 files changed: 6 ins; 1 del; 3 mod

8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window

Reviewed-by: vromero

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

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

From gli at openjdk.java.net  Sat Apr 24 08:51:52 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sat, 24 Apr 2021 08:51:52 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class [v3]
In-Reply-To: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
Message-ID: <zAXEhryh1jjrwvw_77xl3P75PIJ4gYmASrnEgSStLIM=.f9cea514-c31b-4819-bf45-4e66a71c7fee@github.com>

> Hi all,
> 
> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
> 
> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
> 
> 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 error message. Add test cases. Add comment.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2099/files
  - new: https://git.openjdk.java.net/jdk/pull/2099/files/cbbaeddc..415e0efa

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

  Stats: 245 lines in 4 files changed: 191 ins; 46 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2099.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2099/head:pull/2099

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

From gli at openjdk.java.net  Sat Apr 24 08:51:53 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sat, 24 Apr 2021 08:51:53 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class [v2]
In-Reply-To: <fp4XOmK8BLt-Q7hUeZMLki0WvGd9XcDfef8CwM6S1dQ=.94a4356b-b5fc-41c2-92aa-725e6da9fa78@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
 <n6xw5TiMMFB29pxf4rgVRdgHw44FK0FOIoOMC3OJS4Q=.0e9bdf99-ce90-4cae-ac7c-2d0deb1df9a8@github.com>
 <fp4XOmK8BLt-Q7hUeZMLki0WvGd9XcDfef8CwM6S1dQ=.94a4356b-b5fc-41c2-92aa-725e6da9fa78@github.com>
Message-ID: <tMuswwu5TGY1LLSGwAxx-1DdEFBKLd-VSkCwEH1rtdU=.453d1cdf-46db-4d03-8d41-7a717005c40c@github.com>

On Fri, 23 Apr 2021 16:39:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I believe here we don't need a new diagnostic - let's just reuse:

Fixed.

> The thing I'm a bit afraid, if we go down this path is that we will need to replicate all the override checks here - what if the method has the right signature but is private? It's still a bogus override.
>
> I could be fine if the answer was "this is the bare minimum we need to verify to make sure code generation doesn't crash". But I'd like to see a comment on the code stating exactly that.

I added the comment to state it and added several test cases to test these situations.

> Do we have a similar problem with AutoCloseable? E.g. a close() method returning something odd?

The check of AutoCloseable is right. I tested the following cases locally. The compiler didn't crash and the error messages were reasonable.


public class T {
    public void test(String[] args) {
        try (Test test = new Test()) {
            int a = 1;
        } catch(Exception ex) {
            ex.printStackTrace();
        }
    }
}
class Test implements AutoCloseable {
    public int close() throws Exception {
        return 0;
    }
}



public class T {
    public void test(String[] args) {
        try (Test test = new Test()) {
            int a = 1;
        } catch(Exception ex) {
            ex.printStackTrace();
        }
    }
    class Test implements AutoCloseable {
        public int close() throws Exception {
            return 0;
        }
    }
}

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

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

From gli at openjdk.java.net  Sat Apr 24 08:57:26 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sat, 24 Apr 2021 08:57:26 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class [v3]
In-Reply-To: <zAXEhryh1jjrwvw_77xl3P75PIJ4gYmASrnEgSStLIM=.f9cea514-c31b-4819-bf45-4e66a71c7fee@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
 <zAXEhryh1jjrwvw_77xl3P75PIJ4gYmASrnEgSStLIM=.f9cea514-c31b-4819-bf45-4e66a71c7fee@github.com>
Message-ID: <xJj5FvIA1jYnzXfns73YYrlMI1sTS_MHVGz2tsgqQEU=.3fdf187a-3350-4753-a99c-77d94b6b7aaf@github.com>

On Sat, 24 Apr 2021 08:51:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
>> 
>> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
>> 
>> 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 error message. Add test cases. Add comment.

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

> 1: /*
> 2:  * Copyright (c) 1999, 2021, Oracle and/or its affiliates. All rights reserved.

I remained this line, because `Lower` was modified at 2021 but the copyright was not updated.

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

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

From gli at openjdk.java.net  Sun Apr 25 08:14:46 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 25 Apr 2021 08:14:46 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class [v4]
In-Reply-To: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
Message-ID: <6xgK5a7FE_s984698N4UUzbZZEIIxw_BKDJIMk1KItc=.0a23ef5c-1e28-41c0-b63a-af6c57398951@github.com>

> Hi all,
> 
> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
> 
> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
> 
> 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:

  Revert copyright.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2099/files
  - new: https://git.openjdk.java.net/jdk/pull/2099/files/415e0efa..9e3d24bb

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

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

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

From gli at openjdk.java.net  Sun Apr 25 08:14:48 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 25 Apr 2021 08:14:48 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class [v3]
In-Reply-To: <xJj5FvIA1jYnzXfns73YYrlMI1sTS_MHVGz2tsgqQEU=.3fdf187a-3350-4753-a99c-77d94b6b7aaf@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
 <zAXEhryh1jjrwvw_77xl3P75PIJ4gYmASrnEgSStLIM=.f9cea514-c31b-4819-bf45-4e66a71c7fee@github.com>
 <xJj5FvIA1jYnzXfns73YYrlMI1sTS_MHVGz2tsgqQEU=.3fdf187a-3350-4753-a99c-77d94b6b7aaf@github.com>
Message-ID: <olMKcCiEKKvLNN8v-HOHlIMdLGqEfT646Wg7LY_hLvI=.18d6bbcd-f88e-446f-b1f3-71e184acd880@github.com>

On Sat, 24 Apr 2021 08:54:39 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise error message. Add test cases. Add comment.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1999, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> I remained this line, because `Lower` was modified at 2021 but the copyright was not updated.

Considering that this file is not related to this patch, I reverted this copyright.

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

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

From gli at openjdk.java.net  Sun Apr 25 09:35:05 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 25 Apr 2021 09:35:05 GMT
Subject: RFR: 8265901: Use pattern matching for instanceof at module
 jdk.compiler(part 3)
Message-ID: <pzDWIh04JqrwvMIFNeCOEdnIVaznokkEBenGz272EQU=.0e57b41a-f18b-4de9-97f7-0a644a5038e3@github.com>

Hi all,

This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.

This patch only revises the package `com.sun.tools.sjavac`.

Thank you for taking the time to review.

--
Best Regards,
Guoxiong.

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

Commit messages:
 - 8265901: Use pattern matching for instanceof at module jdk.compiler(part 3)

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

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

From gli at openjdk.java.net  Sun Apr 25 09:36:19 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 25 Apr 2021 09:36:19 GMT
Subject: RFR: 8265900: Use pattern matching for instanceof at module
 jdk.compiler(part 2)
Message-ID: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>

Hi all,

This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.

This patch would revise the following packages:

com.sun.tools.javac.code
com.sun.tools.javac.comp
com.sun.tools.javac.jvm
com.sun.tools.javac.parser
com.sun.tools.javac.processing


Thank you for taking the time to review.

--
Best Regards,
Guoxiong.

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

Commit messages:
 - 8265900: Use pattern matching for instanceof at module jdk.compiler(part 2)

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

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

From gli at openjdk.java.net  Sun Apr 25 09:37:04 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 25 Apr 2021 09:37:04 GMT
Subject: RFR: 8265899: Use pattern matching for instanceof at module
 jdk.compiler(part 1)
Message-ID: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>

Hi all,

This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.

This patch would revise the following packages:

com.sun.tools.javac.api
com.sun.tools.javac.file
com.sun.tools.javac.main
com.sun.tools.javac.model
com.sun.tools.javac.platform
com.sun.tools.javac.tree
com.sun.tools.javac.util


Thank you for taking the time to review.

--
Best Regards,
Guoxiong.

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

Commit messages:
 - 8265899: Use pattern matching for instanceof at module jdk.compiler(part 1)

Changes: https://git.openjdk.java.net/jdk/pull/3673/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3673&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265899
  Stats: 290 lines in 35 files changed: 3 ins; 39 del; 248 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3673.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3673/head:pull/3673

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

From sadayapalam at openjdk.java.net  Mon Apr 26 09:45:33 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 26 Apr 2021 09:45:33 GMT
Subject: RFR: 8264258: Unknown lookups in the java package give misleading
 compilation errors [v3]
In-Reply-To: <z89vBr8cocMX1bzUwo8_SybMCYSjLzZc6q3isX9nYvo=.3341a8da-3e74-4aba-ae75-ff66ded8c3e1@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
 <z89vBr8cocMX1bzUwo8_SybMCYSjLzZc6q3isX9nYvo=.3341a8da-3e74-4aba-ae75-ff66ded8c3e1@github.com>
Message-ID: <26tXh32UhjXBEo_obN0dvqaXMnAvy3rk1ZHFesgv8ms=.754e293a-83b0-4bb7-af2f-8c7ed9b5faa1@github.com>

On Fri, 23 Apr 2021 05:41:48 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> Unknown lookups in the java package give misleading compilation errors
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Trailing whitespaces again.

Thanks for the changes Jesper. The final version looks good to me. Could you proceed to integrate please ? Thanks!

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

Marked as reviewed by sadayapalam (Reviewer).

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

From jespersm at openjdk.java.net  Mon Apr 26 11:56:30 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Mon, 26 Apr 2021 11:56:30 GMT
Subject: Integrated: 8264258: Unknown lookups in the java package give
 misleading compilation errors
In-Reply-To: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
References: <BqFC9vC-XCSQ-eB4RABynJ5W4Gzqv03r1ZJCVGVQr1E=.2f58800c-f7f7-4146-a1ae-b12b0fd09fdc@github.com>
Message-ID: <lry-C8cszpqqgwie5iHM22hZZyKUbQS4yn5H05w5uPE=.6e523e2d-25a5-4a86-b453-3bfd88273c3b@github.com>

On Sun, 11 Apr 2021 12:49:35 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Unknown lookups in the java package give misleading compilation errors

This pull request has now been integrated.

Changeset: 83364a4b
Author:    Jesper Steen M?ller <jespersm at openjdk.org>
Committer: Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/83364a4b
Stats:     37 lines in 5 files changed: 35 ins; 0 del; 2 mod

8264258: Unknown lookups in the java package give misleading compilation errors

Reviewed-by: sadayapalam

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

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

From mcimadamore at openjdk.java.net  Mon Apr 26 13:48:26 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 26 Apr 2021 13:48:26 GMT
Subject: RFR: 8265899: Use pattern matching for instanceof at module
 jdk.compiler(part 1)
In-Reply-To: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
References: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
Message-ID: <T465BzOU4a0OZU7YyooR3ecJGC2e-nxxNLPxx9-bCwE=.9e23d3d3-82a6-4002-be75-f1c3b9823099@github.com>

On Sun, 25 Apr 2021 09:20:32 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
> 
> This patch would revise the following packages:
> 
> com.sun.tools.javac.api
> com.sun.tools.javac.file
> com.sun.tools.javac.main
> com.sun.tools.javac.model
> com.sun.tools.javac.platform
> com.sun.tools.javac.tree
> com.sun.tools.javac.util
> 
> 
> Thank you for taking the time to review.
> 
> --
> Best Regards,
> Guoxiong.

Very nice cleanup - left few comments

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacScope.java line 130:

> 128: 
> 129:     public boolean equals(Object other) {
> 130:         if (other instanceof JavacScope javacScope) {

Can this be:


return other instanceof JavacScope javacScope &&
            env.equals(javacScope.env) &&
            isStarImportScope() == javacScope.isStarImportScope();

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 963:

> 961:         ArrayList<PathFileObject> result;
> 962:         if (paths != null) {
> 963:             result = new ArrayList<>(paths.size());

This seems odd in the original code - I'd rather have somebody versed in the API double check this - @jonathan-gibbons  ? Anyway - this doesn't seem to be related with using pattern matching, so perhaps it's preferrable to just move it out of this PR.

src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacTypes.java line 332:

> 330:             return Collections.emptySet();
> 331: 
> 332:         if (!(elem instanceof MethodSymbol methodSymbol))

These two look odd - your cleanup is fine, but it seems in the first cast, we want to wrap with IllegalArgumentException instead of failing with ClassCastException. In the second cast (for class symbol) it seems we're ok with just CCE. I'm fine with leaving this as per your cleanup - just noting the inconsistency.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 2181:

> 2179:         @Override @DefinedBy(Api.COMPILER_TREE)
> 2180:         public JCPattern getPattern() {
> 2181:             return pattern instanceof JCPattern jcPattern ? jcPattern : null;

Using patterns to implement patterns support :-)

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

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

From mcimadamore at openjdk.java.net  Mon Apr 26 13:50:25 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 26 Apr 2021 13:50:25 GMT
Subject: RFR: 8265901: Use pattern matching for instanceof at module
 jdk.compiler(part 3)
In-Reply-To: <pzDWIh04JqrwvMIFNeCOEdnIVaznokkEBenGz272EQU=.0e57b41a-f18b-4de9-97f7-0a644a5038e3@github.com>
References: <pzDWIh04JqrwvMIFNeCOEdnIVaznokkEBenGz272EQU=.0e57b41a-f18b-4de9-97f7-0a644a5038e3@github.com>
Message-ID: <1VBoSHGZI4QJOvp3bfVx52a1rkz36TxdVuWV3pR8k5g=.65910a19-2a7c-46b3-a46f-48cfaf7c7f30@github.com>

On Sun, 25 Apr 2021 09:20:54 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
> 
> This patch only revises the package `com.sun.tools.sjavac`.
> 
> 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/3675

From mcimadamore at openjdk.java.net  Mon Apr 26 13:55:30 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 26 Apr 2021 13:55:30 GMT
Subject: RFR: 8265900: Use pattern matching for instanceof at module
 jdk.compiler(part 2)
In-Reply-To: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>
References: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>
Message-ID: <fmIwwlmV1aPrZiBYfyDBeTeSyoAHAXSr6yuQc9LA7X8=.f63f7464-784d-4ad2-8fa1-c42779e45ff3@github.com>

On Sun, 25 Apr 2021 09:20:49 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
> 
> This patch would revise the following packages:
> 
> com.sun.tools.javac.code
> com.sun.tools.javac.comp
> com.sun.tools.javac.jvm
> com.sun.tools.javac.parser
> com.sun.tools.javac.processing
> 
> 
> Thank you for taking the time to review.
> 
> --
> Best Regards,
> Guoxiong.

Looks good, one minor nit comment

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java line 756:

> 754: 
> 755:         protected Scope finalizeSingleScope(Scope impScope) {
> 756:             if (impScope instanceof FilterImportScope filterImportScope && impScope.owner.kind == Kind.TYP &&

break vertically on each `&&` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 754:

> 752:         @Override
> 753:         public boolean equals(Object obj) {
> 754:             return (obj instanceof UniquePos uniquePos)

For another day - UniquePos can be a record :-)

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolConstant.java line 190:

> 188:             @Override
> 189:             public boolean equals(Object obj) {
> 190:                 return (obj instanceof BsmKey key)

BsmKey smells of records too...

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

Marked as reviewed by mcimadamore (Reviewer).

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

From jfranck at openjdk.java.net  Mon Apr 26 13:57:25 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 26 Apr 2021 13:57:25 GMT
Subject: RFR: 8265901: Use pattern matching for instanceof at module
 jdk.compiler(part 3)
In-Reply-To: <pzDWIh04JqrwvMIFNeCOEdnIVaznokkEBenGz272EQU=.0e57b41a-f18b-4de9-97f7-0a644a5038e3@github.com>
References: <pzDWIh04JqrwvMIFNeCOEdnIVaznokkEBenGz272EQU=.0e57b41a-f18b-4de9-97f7-0a644a5038e3@github.com>
Message-ID: <HY6npsfCVdrfcxXxlcmYffhW_ir1dIjgENOGoGkC4hE=.ccc0d980-1341-4af0-b270-bd31658c0944@github.com>

On Sun, 25 Apr 2021 09:20:54 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
> 
> This patch only revises the package `com.sun.tools.sjavac`.
> 
> Thank you for taking the time to review.
> 
> --
> Best Regards,
> Guoxiong.

Marked as reviewed by jfranck (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Mon Apr 26 13:58:28 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 26 Apr 2021 13:58:28 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class [v4]
In-Reply-To: <6xgK5a7FE_s984698N4UUzbZZEIIxw_BKDJIMk1KItc=.0a23ef5c-1e28-41c0-b63a-af6c57398951@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
 <6xgK5a7FE_s984698N4UUzbZZEIIxw_BKDJIMk1KItc=.0a23ef5c-1e28-41c0-b63a-af6c57398951@github.com>
Message-ID: <uQFv6Vrk7-IDyxp4lrahq-gmZpXj6flOkqB_eDJtmO4=.af71994a-f68b-4458-bc83-3a97db7f2db0@github.com>

On Sun, 25 Apr 2021 08:14:46 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
>> 
>> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
>> 
>> 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:
> 
>   Revert copyright.

Thanks for the stress test - looks good.

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

Marked as reviewed by mcimadamore (Reviewer).

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

From brian.goetz at oracle.com  Mon Apr 26 14:04:25 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 26 Apr 2021 10:04:25 -0400
Subject: RFR: 8265900: Use pattern matching for instanceof at module
 jdk.compiler(part 2)
In-Reply-To: <fmIwwlmV1aPrZiBYfyDBeTeSyoAHAXSr6yuQc9LA7X8=.f63f7464-784d-4ad2-8fa1-c42779e45ff3@github.com>
References: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>
 <fmIwwlmV1aPrZiBYfyDBeTeSyoAHAXSr6yuQc9LA7X8=.f63f7464-784d-4ad2-8fa1-c42779e45ff3@github.com>
Message-ID: <76d935d6-3374-4b60-7e9b-c7642342ec76@oracle.com>

Also, FYI: we had a discussion over a similar topic over on corelibs, 
and settled on making the binding variable names a little less "fussy", 
especially in patterns like Object::equals (calling it `that` or `other` 
is fine; we don't have to call it `standardFinalManager`.)? These are 
convenience variables with small scopes; they don't need super-specific 
names (and the super-specific names often make the code harder to 
read.)? You don't have to go and change them, just keep this in mind for 
next time.

On 4/26/2021 9:55 AM, Maurizio Cimadamore wrote:
> On Sun, 25 Apr 2021 09:20:49 GMT, Guoxiong Li <gli at openjdk.org> wrote:
>
>> Hi all,
>>
>> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
>>
>> This patch would revise the following packages:
>>
>> com.sun.tools.javac.code
>> com.sun.tools.javac.comp
>> com.sun.tools.javac.jvm
>> com.sun.tools.javac.parser
>> com.sun.tools.javac.processing
>>
>>
>> Thank you for taking the time to review.
>>
>> --
>> Best Regards,
>> Guoxiong.
> Looks good, one minor nit comment
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java line 756:
>
>> 754:
>> 755:         protected Scope finalizeSingleScope(Scope impScope) {
>> 756:             if (impScope instanceof FilterImportScope filterImportScope && impScope.owner.kind == Kind.TYP &&
> break vertically on each `&&` ?
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 754:
>
>> 752:         @Override
>> 753:         public boolean equals(Object obj) {
>> 754:             return (obj instanceof UniquePos uniquePos)
> For another day - UniquePos can be a record :-)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolConstant.java line 190:
>
>> 188:             @Override
>> 189:             public boolean equals(Object obj) {
>> 190:                 return (obj instanceof BsmKey key)
> BsmKey smells of records too...
>
> -------------
>
> Marked as reviewed by mcimadamore (Reviewer).
>
> PR: https://git.openjdk.java.net/jdk/pull/3674

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

From gli at openjdk.java.net  Mon Apr 26 14:05:28 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 14:05:28 GMT
Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when
 compiling a class [v4]
In-Reply-To: <uQFv6Vrk7-IDyxp4lrahq-gmZpXj6flOkqB_eDJtmO4=.af71994a-f68b-4458-bc83-3a97db7f2db0@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
 <6xgK5a7FE_s984698N4UUzbZZEIIxw_BKDJIMk1KItc=.0a23ef5c-1e28-41c0-b63a-af6c57398951@github.com>
 <uQFv6Vrk7-IDyxp4lrahq-gmZpXj6flOkqB_eDJtmO4=.af71994a-f68b-4458-bc83-3a97db7f2db0@github.com>
Message-ID: <2cV-_fkD2UtdYkDrT5-v3zXw01Hhyq0K7P71TFuP-58=.d420adcd-c4a8-4d0e-953b-e5355dba1f6f@github.com>

On Mon, 26 Apr 2021 13:55:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert copyright.
>
> Thanks for the stress test - looks good.

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

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

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

From gli at openjdk.java.net  Mon Apr 26 14:07:27 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 14:07:27 GMT
Subject: RFR: 8265901: Use pattern matching for instanceof at module
 jdk.compiler(part 3)
In-Reply-To: <1VBoSHGZI4QJOvp3bfVx52a1rkz36TxdVuWV3pR8k5g=.65910a19-2a7c-46b3-a46f-48cfaf7c7f30@github.com>
References: <pzDWIh04JqrwvMIFNeCOEdnIVaznokkEBenGz272EQU=.0e57b41a-f18b-4de9-97f7-0a644a5038e3@github.com>
 <1VBoSHGZI4QJOvp3bfVx52a1rkz36TxdVuWV3pR8k5g=.65910a19-2a7c-46b3-a46f-48cfaf7c7f30@github.com>
Message-ID: <YMBXLT51RK6CYbTJmHEP9O3VO-MQFzV-hv4ezA_ocXM=.d993744c-190c-43b3-91f7-558534d1817e@github.com>

On Mon, 26 Apr 2021 13:47:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
>> 
>> This patch only revises the package `com.sun.tools.sjavac`.
>> 
>> Thank you for taking the time to review.
>> 
>> --
>> Best Regards,
>> Guoxiong.
>
> Looks good

@mcimadamore @jbf Thank you for your review. Could I get your help to sponsor this patch?

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

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

From gli at openjdk.java.net  Mon Apr 26 14:16:32 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 14:16:32 GMT
Subject: Integrated: 8232765: NullPointerException at Types.eraseNotNeeded()
 when compiling a class
In-Reply-To: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
References: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com>
Message-ID: <MqXzZxsHZmuJK11D0FKvpaRmq_90qq_wekBAv9q5rHs=.9d23f338-4d7a-436d-8445-dbff5365ea39@github.com>

On Fri, 15 Jan 2021 12:17:39 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`.
> 
> This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 2b09ff21
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2b09ff21
Stats:     312 lines in 2 files changed: 312 ins; 0 del; 0 mod

8232765: NullPointerException at Types.eraseNotNeeded() when compiling a class

Reviewed-by: mcimadamore

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

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

From lgxbslgx at gmail.com  Mon Apr 26 14:17:56 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Mon, 26 Apr 2021 22:17:56 +0800
Subject: RFR: 8265900: Use pattern matching for instanceof at module
 jdk.compiler(part 2)
In-Reply-To: <76d935d6-3374-4b60-7e9b-c7642342ec76@oracle.com>
References: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>
 <fmIwwlmV1aPrZiBYfyDBeTeSyoAHAXSr6yuQc9LA7X8=.f63f7464-784d-4ad2-8fa1-c42779e45ff3@github.com>
 <76d935d6-3374-4b60-7e9b-c7642342ec76@oracle.com>
Message-ID: <CAPSsVqgSMnV_ucVH5ebxjKxHWaATv4WTecL3=54x+AMm_6WFKA@mail.gmail.com>

Hi Brian,

Thank you for your reminder. It is a good suggestion about code readability.

--
Best Regards,
Guoxiong.

On Mon, Apr 26, 2021 at 10:04 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Also, FYI: we had a discussion over a similar topic over on corelibs, and
> settled on making the binding variable names a little less "fussy",
> especially in patterns like Object::equals (calling it `that` or `other` is
> fine; we don't have to call it `standardFinalManager`.)  These are
> convenience variables with small scopes; they don't need super-specific
> names (and the super-specific names often make the code harder to read.)
> You don't have to go and change them, just keep this in mind for next time.
>
> On 4/26/2021 9:55 AM, Maurizio Cimadamore wrote:
>
> On Sun, 25 Apr 2021 09:20:49 GMT, Guoxiong Li <gli at openjdk.org> <gli at openjdk.org> wrote:
>
>
> Hi all,
>
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
>
> This patch would revise the following packages:
>
> com.sun.tools.javac.code
> com.sun.tools.javac.comp
> com.sun.tools.javac.jvm
> com.sun.tools.javac.parser
> com.sun.tools.javac.processing
>
>
> Thank you for taking the time to review.
>
> --
> Best Regards,
> Guoxiong.
>
> Looks good, one minor nit comment
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java line 756:
>
>
> 754:
> 755:         protected Scope finalizeSingleScope(Scope impScope) {
> 756:             if (impScope instanceof FilterImportScope filterImportScope && impScope.owner.kind == Kind.TYP &&
>
> break vertically on each `&&` ?
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 754:
>
>
> 752:         @Override
> 753:         public boolean equals(Object obj) {
> 754:             return (obj instanceof UniquePos uniquePos)
>
> For another day - UniquePos can be a record :-)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolConstant.java line 190:
>
>
> 188:             @Override
> 189:             public boolean equals(Object obj) {
> 190:                 return (obj instanceof BsmKey key)
>
> BsmKey smells of records too...
>
> -------------
>
> Marked as reviewed by mcimadamore (Reviewer).
>
> PR: https://git.openjdk.java.net/jdk/pull/3674
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210426/76805a58/attachment.htm>

From gli at openjdk.java.net  Mon Apr 26 14:44:49 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 14:44:49 GMT
Subject: RFR: 8265900: Use pattern matching for instanceof at module
 jdk.compiler(part 2) [v2]
In-Reply-To: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>
References: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>
Message-ID: <OiTjWxxN7n2HwCGUAe_JBM2TYCPP5QCraLoH4j2IHBA=.d583a57f-2a5c-488b-aca3-7a4251284fe2@github.com>

> Hi all,
> 
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
> 
> This patch would revise the following packages:
> 
> com.sun.tools.javac.code
> com.sun.tools.javac.comp
> com.sun.tools.javac.jvm
> com.sun.tools.javac.parser
> com.sun.tools.javac.processing
> 
> 
> 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:

  Refactor code style

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3674/files
  - new: https://git.openjdk.java.net/jdk/pull/3674/files/56970261..55de5a07

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

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

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

From gli at openjdk.java.net  Mon Apr 26 14:44:50 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 14:44:50 GMT
Subject: RFR: 8265900: Use pattern matching for instanceof at module
 jdk.compiler(part 2) [v2]
In-Reply-To: <fmIwwlmV1aPrZiBYfyDBeTeSyoAHAXSr6yuQc9LA7X8=.f63f7464-784d-4ad2-8fa1-c42779e45ff3@github.com>
References: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>
 <fmIwwlmV1aPrZiBYfyDBeTeSyoAHAXSr6yuQc9LA7X8=.f63f7464-784d-4ad2-8fa1-c42779e45ff3@github.com>
Message-ID: <EO35GFB5CNL4C5FUyfzGr2Ls7UZ1m-ndS1hgyp9MXaE=.4eb03c75-aef0-4b9f-9288-960fb2a3abaf@github.com>

On Mon, 26 Apr 2021 13:52:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor code style
>
> Looks good, one minor nit comment

@mcimadamore I updated the code. Could I get your help to re-review and sponsor? Thanks a lot.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java line 756:
> 
>> 754: 
>> 755:         protected Scope finalizeSingleScope(Scope impScope) {
>> 756:             if (impScope instanceof FilterImportScope filterImportScope && impScope.owner.kind == Kind.TYP &&
> 
> break vertically on each `&&` ?

Fixed.

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

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

From gli at openjdk.java.net  Mon Apr 26 15:11:52 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 15:11:52 GMT
Subject: RFR: 8265899: Use pattern matching for instanceof at module
 jdk.compiler(part 1) [v2]
In-Reply-To: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
References: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
Message-ID: <-j9p12UtLALZTBOrmRmX7ZjTFn5PZgJeFp9T1MG-UQg=.0880322f-064f-4bb8-ab27-b68181d6f029@github.com>

> Hi all,
> 
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
> 
> This patch would revise the following packages:
> 
> com.sun.tools.javac.api
> com.sun.tools.javac.file
> com.sun.tools.javac.main
> com.sun.tools.javac.model
> com.sun.tools.javac.platform
> com.sun.tools.javac.tree
> com.sun.tools.javac.util
> 
> 
> 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:

  Cleanup method JavacScope.equals

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3673/files
  - new: https://git.openjdk.java.net/jdk/pull/3673/files/5b298b32..dc6c3dd7

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

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

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

From gli at openjdk.java.net  Mon Apr 26 15:28:37 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 15:28:37 GMT
Subject: Integrated: 8265901: Use pattern matching for instanceof at module
 jdk.compiler(part 3)
In-Reply-To: <pzDWIh04JqrwvMIFNeCOEdnIVaznokkEBenGz272EQU=.0e57b41a-f18b-4de9-97f7-0a644a5038e3@github.com>
References: <pzDWIh04JqrwvMIFNeCOEdnIVaznokkEBenGz272EQU=.0e57b41a-f18b-4de9-97f7-0a644a5038e3@github.com>
Message-ID: <OzT2ibJVtXYU0sZYI5rNMnRVDxJ1N-vnrjwutHWaiIw=.92644b57-f96b-4bf4-a6d1-35debd2140ee@github.com>

On Sun, 25 Apr 2021 09:20:54 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
> 
> This patch only revises the package `com.sun.tools.sjavac`.
> 
> Thank you for taking the time to review.
> 
> --
> Best Regards,
> Guoxiong.

This pull request has now been integrated.

Changeset: 851b219d
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Joel Borggr?n-Franck <jfranck at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/851b219d
Stats:     45 lines in 9 files changed: 0 ins; 5 del; 40 mod

8265901: Use pattern matching for instanceof at module jdk.compiler(part 3)

Reviewed-by: mcimadamore, jfranck

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

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

From gli at openjdk.java.net  Mon Apr 26 15:31:29 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 15:31:29 GMT
Subject: RFR: 8265899: Use pattern matching for instanceof at module
 jdk.compiler(part 1) [v2]
In-Reply-To: <T465BzOU4a0OZU7YyooR3ecJGC2e-nxxNLPxx9-bCwE=.9e23d3d3-82a6-4002-be75-f1c3b9823099@github.com>
References: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
 <T465BzOU4a0OZU7YyooR3ecJGC2e-nxxNLPxx9-bCwE=.9e23d3d3-82a6-4002-be75-f1c3b9823099@github.com>
Message-ID: <zNOUVLWfCk338C5qYi2ahQnftXB8wuW5BRJyxhVDs2I=.c14c48a9-3908-46ae-a996-f8b9987d030e@github.com>

On Mon, 26 Apr 2021 13:32:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup method JavacScope.equals
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacScope.java line 130:
> 
>> 128: 
>> 129:     public boolean equals(Object other) {
>> 130:         if (other instanceof JavacScope javacScope) {
> 
> Can this be:
> 
> 
> return other instanceof JavacScope javacScope &&
>             env.equals(javacScope.env) &&
>             isStarImportScope() == javacScope.isStarImportScope();

Fixed

> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 963:
> 
>> 961:         ArrayList<PathFileObject> result;
>> 962:         if (paths != null) {
>> 963:             result = new ArrayList<>(paths.size());
> 
> This seems odd in the original code - I'd rather have somebody versed in the API double check this - @jonathan-gibbons  ? Anyway - this doesn't seem to be related with using pattern matching, so perhaps it's preferrable to just move it out of this PR.

I think that removing the unnecessary `instanceof` expressions is also the goal of this cleanup. So I want to keep it.

In this case, my logical analysis is shown below.

1. Please see the code below. The parameter type of the method `getJavaFileObjectsFromPaths` is `Collection<? extends Path>`, so we don't need to use `paths instanceof Collection<?>`. We only need to judge whether `paths` is `null`. So I use `paths != null` instead.


    public Iterable<? extends JavaFileObject> getJavaFileObjectsFromPaths(
        Collection<? extends Path> paths)


2. Because the `paths` may be `null`, I move the following code from top scope to `if (paths != null) ` branch scope to avoid the NPE.


        for (Path p: paths)
            result.add(PathFileObject.forSimplePath(this,
                    fsInfo.getCanonicalFile(p), p));


In my opinion, these two steps are reasonable for removing the `instanceof` expression.

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

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

From mcimadamore at openjdk.java.net  Mon Apr 26 17:25:07 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 26 Apr 2021 17:25:07 GMT
Subject: RFR: 8265899: Use pattern matching for instanceof at module
 jdk.compiler(part 1) [v2]
In-Reply-To: <-j9p12UtLALZTBOrmRmX7ZjTFn5PZgJeFp9T1MG-UQg=.0880322f-064f-4bb8-ab27-b68181d6f029@github.com>
References: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
 <-j9p12UtLALZTBOrmRmX7ZjTFn5PZgJeFp9T1MG-UQg=.0880322f-064f-4bb8-ab27-b68181d6f029@github.com>
Message-ID: <GbHi1-IFLaXtQ3p0bDhI8YAEzwr3zT51FIqQjI4GUYY=.f5b6bd96-8c45-46f4-9eb3-2893c29cc7ed@github.com>

On Mon, 26 Apr 2021 15:11:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
>> 
>> This patch would revise the following packages:
>> 
>> com.sun.tools.javac.api
>> com.sun.tools.javac.file
>> com.sun.tools.javac.main
>> com.sun.tools.javac.model
>> com.sun.tools.javac.platform
>> com.sun.tools.javac.tree
>> com.sun.tools.javac.util
>> 
>> 
>> 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:
> 
>   Cleanup method JavacScope.equals

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon Apr 26 17:25:14 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 26 Apr 2021 17:25:14 GMT
Subject: RFR: 8265899: Use pattern matching for instanceof at module
 jdk.compiler(part 1) [v2]
In-Reply-To: <zNOUVLWfCk338C5qYi2ahQnftXB8wuW5BRJyxhVDs2I=.c14c48a9-3908-46ae-a996-f8b9987d030e@github.com>
References: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
 <T465BzOU4a0OZU7YyooR3ecJGC2e-nxxNLPxx9-bCwE=.9e23d3d3-82a6-4002-be75-f1c3b9823099@github.com>
 <zNOUVLWfCk338C5qYi2ahQnftXB8wuW5BRJyxhVDs2I=.c14c48a9-3908-46ae-a996-f8b9987d030e@github.com>
Message-ID: <aDtviOZd2-2OCiCgwbN-c6kJehF6qRfhTShvK4rhdxY=.09eb254c-5957-4672-bc84-756d9af04fc0@github.com>

On Mon, 26 Apr 2021 15:28:40 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 963:
>> 
>>> 961:         ArrayList<PathFileObject> result;
>>> 962:         if (paths != null) {
>>> 963:             result = new ArrayList<>(paths.size());
>> 
>> This seems odd in the original code - I'd rather have somebody versed in the API double check this - @jonathan-gibbons  ? Anyway - this doesn't seem to be related with using pattern matching, so perhaps it's preferrable to just move it out of this PR.
>
> I think that removing the unnecessary `instanceof` expressions is also the goal of this cleanup. So I want to keep it.
> 
> In this case, my logical analysis is shown below.
> 
> 1. Please see the code below. The parameter type of the method `getJavaFileObjectsFromPaths` is `Collection<? extends Path>`, so we don't need to use `paths instanceof Collection<?>`. We only need to judge whether `paths` is `null`. So I use `paths != null` instead.
> 
> 
>     public Iterable<? extends JavaFileObject> getJavaFileObjectsFromPaths(
>         Collection<? extends Path> paths)
> 
> 
> 2. Because the `paths` may be `null`, I move the following code from top scope to `if (paths != null) ` branch scope to avoid the NPE.
> 
> 
>         for (Path p: paths)
>             result.add(PathFileObject.forSimplePath(this,
>                     fsInfo.getCanonicalFile(p), p));
> 
> 
> In my opinion, these two steps are reasonable for removing the `instanceof` expression.

OK

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

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

From gli at openjdk.java.net  Mon Apr 26 17:38:05 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 17:38:05 GMT
Subject: Integrated: 8265900: Use pattern matching for instanceof at module
 jdk.compiler(part 2)
In-Reply-To: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>
References: <t9nOwzDCB0KEeP9-WnFT0M8HI29WgAL3eJIknVBmE3M=.5ce99b5f-3e0a-4d75-b715-c22f525adee2@github.com>
Message-ID: <THmgg7OvA2_RJ4X5ra6Keh05aat7fBedtehYJK7KoVI=.674996f5-6f76-4e2c-9101-ebf59395873a@github.com>

On Sun, 25 Apr 2021 09:20:49 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
> 
> This patch would revise the following packages:
> 
> com.sun.tools.javac.code
> com.sun.tools.javac.comp
> com.sun.tools.javac.jvm
> com.sun.tools.javac.parser
> com.sun.tools.javac.processing
> 
> 
> Thank you for taking the time to review.
> 
> --
> Best Regards,
> Guoxiong.

This pull request has now been integrated.

Changeset: 082abbda
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/082abbda
Stats:     277 lines in 29 files changed: 1 ins; 73 del; 203 mod

8265900: Use pattern matching for instanceof at module jdk.compiler(part 2)

Reviewed-by: mcimadamore

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

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

From gli at openjdk.java.net  Mon Apr 26 18:28:37 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 18:28:37 GMT
Subject: RFR: 8265899: Use pattern matching for instanceof at module
 jdk.compiler(part 1) [v2]
In-Reply-To: <GbHi1-IFLaXtQ3p0bDhI8YAEzwr3zT51FIqQjI4GUYY=.f5b6bd96-8c45-46f4-9eb3-2893c29cc7ed@github.com>
References: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
 <-j9p12UtLALZTBOrmRmX7ZjTFn5PZgJeFp9T1MG-UQg=.0880322f-064f-4bb8-ab27-b68181d6f029@github.com>
 <GbHi1-IFLaXtQ3p0bDhI8YAEzwr3zT51FIqQjI4GUYY=.f5b6bd96-8c45-46f4-9eb3-2893c29cc7ed@github.com>
Message-ID: <tehREVDwqwME1DXbabPdd-dYp39GzruoVsGnEKgGacM=.73118cdc-d62f-4b1d-96bc-bac561afe4f4@github.com>

On Mon, 26 Apr 2021 16:39:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup method JavacScope.equals
>
> Looks good

@mcimadamore Thank you for your review. May I ask your help to sponsor this patch?

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

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

From gli at openjdk.java.net  Mon Apr 26 20:18:36 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 26 Apr 2021 20:18:36 GMT
Subject: Integrated: 8265899: Use pattern matching for instanceof at module
 jdk.compiler(part 1)
In-Reply-To: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
References: <tlFGq6Jhf7FwNPphdDDmFNnclbA0Cf7lIvzy-Hriqg0=.920de807-5abb-49e0-bb9c-66875f877c63@github.com>
Message-ID: <prAbwdqWjWv7s3I_fn6io1hOxG53kqw8wCFYxp1Sz5k=.bc5b2043-a12a-4b3a-bc9b-86c616885cae@github.com>

On Sun, 25 Apr 2021 09:20:32 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This series of patches update the code of the module jdk.compiler by using the pattern matching for instanceof.
> 
> This patch would revise the following packages:
> 
> com.sun.tools.javac.api
> com.sun.tools.javac.file
> com.sun.tools.javac.main
> com.sun.tools.javac.model
> com.sun.tools.javac.platform
> com.sun.tools.javac.tree
> com.sun.tools.javac.util
> 
> 
> Thank you for taking the time to review.
> 
> --
> Best Regards,
> Guoxiong.

This pull request has now been integrated.

Changeset: 41daa88d
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/41daa88d
Stats:     292 lines in 35 files changed: 3 ins; 41 del; 248 mod

8265899: Use pattern matching for instanceof at module jdk.compiler(part 1)

Reviewed-by: mcimadamore

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

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

From igraves at openjdk.java.net  Tue Apr 27 00:27:49 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 27 Apr 2021 00:27:49 GMT
Subject: RFR: 8260560: convert jdeps and jdeprscan tools to use Stream.toList()
Message-ID: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>

8260560: convert jdeps and jdeprscan tools to use Stream.toList()

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

Commit messages:
 - Updating jdeps and jdeprscan to use Stream.toList()

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

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

From jlahoda at openjdk.java.net  Tue Apr 27 08:59:35 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 27 Apr 2021 08:59:35 GMT
Subject: Integrated: 8263432: javac may report an invalid package/class clash
 on case insensitive filesystems
In-Reply-To: <XVY3kmwWCWjj3JOIbj8cwSOHK-RDSVH4OpMpVKcN-gM=.4a82383d-0114-471f-8b5c-3aae562f2c1e@github.com>
References: <XVY3kmwWCWjj3JOIbj8cwSOHK-RDSVH4OpMpVKcN-gM=.4a82383d-0114-471f-8b5c-3aae562f2c1e@github.com>
Message-ID: <a7kv912wAJHtDbUshN7pUejgPODFd2i_4PgnmAGIwDo=.c57ed986-cea7-4ae0-83b8-60df0b52ba62@github.com>

On Thu, 18 Mar 2021 09:12:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> To implement the package/class clash check as per JLS 7.1, javac creates "phantom" packages with the same names as the classes and checks if these packages exist (implemented as a check if it has seen a source or class file in the corresponding directory). Every package created (phantom or not) gets registered to its enclosing `ModuleSymbol`, and when `ModuleSymbol.getEnclosedElements()` is called, the package is completed (i.e. its directory is listed).
> 
> This can cause an invalid package/class clash error to be reported in specific cases if there is a package and a class with names differing only in letter cases (like `org.jruby.runtime.callsite` and `org.jruby.runtime.CallSite`). What happens here is: the phantom package for the `org.jruby.runtime.CallSite` package is created, the package/class clash check is performed and passes (no errors). Then annotation processing calls `ModuleSymbol.getEnclosedElements()`, the phantom package's directory (`org/jruby/runtime/CallSite`) is listed from the filesystem, and contains some source files, so appears non-empty/existing (due to the case insensitive filesystem, the content of `org/jruby/runtime/callsite` directory is listed in fact). Then another round of annotation processing happens, and the package/class clash check is performed again. This time, the package appears to exist, and hence the check fails.
> 
> The proposal here is to avoid creating of the phantom packages (and hence registering them into `ModuleSymbol`) for the package/class clash check. That should prevent listing the package with the wrong name unnecessarily/unintentionally.

This pull request has now been integrated.

Changeset: 0a4c3382
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a4c3382
Stats:     108 lines in 2 files changed: 103 ins; 0 del; 5 mod

8263432: javac may report an invalid package/class clash on case insensitive filesystems

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Tue Apr 27 09:21:54 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 27 Apr 2021 09:21:54 GMT
Subject: RFR: 8266027: The diamond finder does not find diamond candidates in
 field initializers
Message-ID: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>

Consider code like:

public class Test {
     private List<String> f2 = new LinkedList<String>();
}


Running with javac with `-XDfind=diamond` will not produce any warning about a possible diamond use. The reason is that the field:

private List<String> f2 = new LinkedList<String>();


will get wrapped by a block, and attributed as a block, but since it has the `private` modifier, an error will be produced, and the transformation will be deemed impossible.

The proposed solution is to clear the modifiers when/if wrapping fields with blocks.

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

Commit messages:
 - 8266027: The diamond finder does not find diamond candidates in field initializers

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

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

From jfranck at openjdk.java.net  Tue Apr 27 11:08:35 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Tue, 27 Apr 2021 11:08:35 GMT
Subject: RFR: 8266027: The diamond finder does not find diamond candidates
 in field initializers
In-Reply-To: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
References: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
Message-ID: <FGivrD9s_ou4F7NXz-BrN_PMy8PhAyelDNzpLKoNQok=.ba2f1bd1-7e42-4e3c-ba27-4c5212a29288@github.com>

On Tue, 27 Apr 2021 09:13:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class Test {
>      private List<String> f2 = new LinkedList<String>();
> }
> 
> 
> Running with javac with `-XDfind=diamond` will not produce any warning about a possible diamond use. The reason is that the field:
> 
> private List<String> f2 = new LinkedList<String>();
> 
> 
> will get wrapped by a block, and attributed as a block, but since it has the `private` modifier, an error will be produced, and the transformation will be deemed impossible.
> 
> The proposed solution is to clear the modifiers when/if wrapping fields with blocks.

Looks good to me

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

Marked as reviewed by jfranck (Reviewer).

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

From jfranck at openjdk.java.net  Tue Apr 27 14:24:52 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Tue, 27 Apr 2021 14:24:52 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: <J6WdgbuDQa2mNY3flSiny2zrFr2ts0NlhNg5ymom2xg=.936fbed4-f527-4f51-a537-a5d6b88c2ea9@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 142:

> 140:                 .writeAll()
> 141:                 .getOutputLines(Task.OutputKind.STDERR);
> 142:         List<String> firstExpected = Arrays.asList("x [final]", "x [final]");

Why are there supposed to be two "x [final]" in the first output?

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

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

From gli at openjdk.java.net  Tue Apr 27 15:13:48 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 27 Apr 2021 15:13:48 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v3]
In-Reply-To: <J6WdgbuDQa2mNY3flSiny2zrFr2ts0NlhNg5ymom2xg=.936fbed4-f527-4f51-a537-a5d6b88c2ea9@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
 <4iAX0F9xrfxgTuIxYl1JvUgFqc7Rr6V4BCecemCyXGk=.7f15e598-e1f4-4fa4-9814-e9b22eccc48b@github.com>
 <J6WdgbuDQa2mNY3flSiny2zrFr2ts0NlhNg5ymom2xg=.936fbed4-f527-4f51-a537-a5d6b88c2ea9@github.com>
Message-ID: <ZVt9mvw_DBBvJEL0ZTBo96wJyozoVYhV9qzU_e3GdtE=.47f4be64-02c7-4a71-afdc-b6bc0ce3ca16@github.com>

On Tue, 27 Apr 2021 14:22:09 GMT, Joel Borggr?n-Franck <jfranck 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 142:
> 
>> 140:                 .writeAll()
>> 141:                 .getOutputLines(Task.OutputKind.STDERR);
>> 142:         List<String> firstExpected = Arrays.asList("x [final]", "x [final]");
> 
> Why are there supposed to be two "x [final]" in the first output?

Because it has two source files. Please see the code snippet of the method `JavaCompiler.enterTrees`.


public List<JCCompilationUnit> enterTrees(List<JCCompilationUnit> roots)
// ignore other code.
        if (!taskListener.isEmpty()) {
            for (JCCompilationUnit unit: roots) {
                TaskEvent e = new TaskEvent(TaskEvent.Kind.ENTER, unit);
                taskListener.finished(e);
            }
        }
//  ignore other code.
}


The task listener is called every time there is a `JCCompilationUnit`.

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

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

From alanb at openjdk.java.net  Tue Apr 27 15:38:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 27 Apr 2021 15:38:39 GMT
Subject: RFR: 8260560: convert jdeps and jdeprscan tools to use
 Stream.toList()
In-Reply-To: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
References: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
Message-ID: <5XiU_ITIOIzVoHJhR1SGCZVjVqIy2w_imGO1-ZtSLLU=.207a54f9-95bd-4f50-941a-680e04dde582@github.com>

On Tue, 27 Apr 2021 00:20:49 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8260560: convert jdeps and jdeprscan tools to use Stream.toList()

Marked as reviewed by alanb (Reviewer).

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

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

From vromero at openjdk.java.net  Tue Apr 27 16:04:37 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 27 Apr 2021 16:04:37 GMT
Subject: RFR: 8266027: The diamond finder does not find diamond candidates
 in field initializers
In-Reply-To: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
References: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
Message-ID: <3Heel5HTf5h54ApPViGSLWilTjljLQHOEeZ-3Lkrp_A=.ce66cca5-bc7d-4c44-8e05-79c91b7cad8b@github.com>

On Tue, 27 Apr 2021 09:13:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class Test {
>      private List<String> f2 = new LinkedList<String>();
> }
> 
> 
> Running with javac with `-XDfind=diamond` will not produce any warning about a possible diamond use. The reason is that the field:
> 
> private List<String> f2 = new LinkedList<String>();
> 
> 
> will get wrapped by a block, and attributed as a block, but since it has the `private` modifier, an error will be produced, and the transformation will be deemed impossible.
> 
> The proposed solution is to clear the modifiers when/if wrapping fields with blocks.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java line 801:

> 799:                 //would be reported, causing the whole rewrite to fail. Removing the non-final
> 800:                 //modifiers from the variable here:
> 801:                 ((JCVariableDecl) result).mods.flags &= Flags.FINAL;

just curious: why preserving the FINAL flag anyway?

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

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

From mchung at openjdk.java.net  Tue Apr 27 16:31:37 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 27 Apr 2021 16:31:37 GMT
Subject: RFR: 8260560: convert jdeps and jdeprscan tools to use
 Stream.toList()
In-Reply-To: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
References: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
Message-ID: <UUSrFhgtCZWs52aVLsfxyh9LG3NWLGUYNcONwlv3jNU=.7b51180a-3ec1-410d-a73e-954e54288f8b@github.com>

On Tue, 27 Apr 2021 00:20:49 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8260560: convert jdeps and jdeprscan tools to use Stream.toList()

Marked as reviewed by mchung (Reviewer).

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

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

From iris at openjdk.java.net  Tue Apr 27 17:12:35 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 27 Apr 2021 17:12:35 GMT
Subject: RFR: 8260560: convert jdeps and jdeprscan tools to use
 Stream.toList()
In-Reply-To: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
References: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
Message-ID: <xPmdTCH3i93vfRmqO2TkmJu-pMQiNY4pu9aS6SRmbKY=.7376f002-4e3e-4db1-9df5-15b5be23de96@github.com>

On Tue, 27 Apr 2021 00:20:49 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8260560: convert jdeps and jdeprscan tools to use Stream.toList()

Marked as reviewed by iris (Reviewer).

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

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

From jlahoda at openjdk.java.net  Tue Apr 27 19:52:08 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 27 Apr 2021 19:52:08 GMT
Subject: RFR: 8266027: The diamond finder does not find diamond candidates
 in field initializers
In-Reply-To: <3Heel5HTf5h54ApPViGSLWilTjljLQHOEeZ-3Lkrp_A=.ce66cca5-bc7d-4c44-8e05-79c91b7cad8b@github.com>
References: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
 <3Heel5HTf5h54ApPViGSLWilTjljLQHOEeZ-3Lkrp_A=.ce66cca5-bc7d-4c44-8e05-79c91b7cad8b@github.com>
Message-ID: <Rx7AF3hgMISccfXBpAD2HFGzItX2_9AThdRUilz3Zs8=.3c039773-40a1-4690-8fc8-f112f41e4b0f@github.com>

On Tue, 27 Apr 2021 16:01:13 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class Test {
>>      private List<String> f2 = new LinkedList<String>();
>> }
>> 
>> 
>> Running with javac with `-XDfind=diamond` will not produce any warning about a possible diamond use. The reason is that the field:
>> 
>> private List<String> f2 = new LinkedList<String>();
>> 
>> 
>> will get wrapped by a block, and attributed as a block, but since it has the `private` modifier, an error will be produced, and the transformation will be deemed impossible.
>> 
>> The proposed solution is to clear the modifiers when/if wrapping fields with blocks.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java line 801:
> 
>> 799:                 //would be reported, causing the whole rewrite to fail. Removing the non-final
>> 800:                 //modifiers from the variable here:
>> 801:                 ((JCVariableDecl) result).mods.flags &= Flags.FINAL;
> 
> just curious: why preserving the FINAL flag anyway?

No particular strong reason, just keeping what we can keep. We can clear the flags to `0`, if you prefer. I don't think that should cause issues (with the current set of Analyzers).

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

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

From vromero at openjdk.java.net  Tue Apr 27 21:31:06 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 27 Apr 2021 21:31:06 GMT
Subject: RFR: 8266027: The diamond finder does not find diamond candidates
 in field initializers
In-Reply-To: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
References: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
Message-ID: <u7HmBZtZYwqBCdq8-8z-_7QBdu0dyHd4o4iKb_-h47A=.37a32804-31e9-4634-a9ff-872d7f5f155a@github.com>

On Tue, 27 Apr 2021 09:13:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class Test {
>      private List<String> f2 = new LinkedList<String>();
> }
> 
> 
> Running with javac with `-XDfind=diamond` will not produce any warning about a possible diamond use. The reason is that the field:
> 
> private List<String> f2 = new LinkedList<String>();
> 
> 
> will get wrapped by a block, and attributed as a block, but since it has the `private` modifier, an error will be produced, and the transformation will be deemed impossible.
> 
> The proposed solution is to clear the modifiers when/if wrapping fields with blocks.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Tue Apr 27 21:31:09 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 27 Apr 2021 21:31:09 GMT
Subject: RFR: 8266027: The diamond finder does not find diamond candidates
 in field initializers
In-Reply-To: <Rx7AF3hgMISccfXBpAD2HFGzItX2_9AThdRUilz3Zs8=.3c039773-40a1-4690-8fc8-f112f41e4b0f@github.com>
References: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
 <3Heel5HTf5h54ApPViGSLWilTjljLQHOEeZ-3Lkrp_A=.ce66cca5-bc7d-4c44-8e05-79c91b7cad8b@github.com>
 <Rx7AF3hgMISccfXBpAD2HFGzItX2_9AThdRUilz3Zs8=.3c039773-40a1-4690-8fc8-f112f41e4b0f@github.com>
Message-ID: <zJU9PzsPM2pHGuPKfshdfO63y4np2FUCvSYObqyaVvM=.0bf00863-3b21-47da-8c65-ba9b398ef73c@github.com>

On Tue, 27 Apr 2021 19:49:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java line 801:
>> 
>>> 799:                 //would be reported, causing the whole rewrite to fail. Removing the non-final
>>> 800:                 //modifiers from the variable here:
>>> 801:                 ((JCVariableDecl) result).mods.flags &= Flags.FINAL;
>> 
>> just curious: why preserving the FINAL flag anyway?
>
> No particular strong reason, just keeping what we can keep. We can clear the flags to `0`, if you prefer. I don't think that should cause issues (with the current set of Analyzers).

I'm fine with either approach was just curious, do as you consider best

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

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

From mchung at openjdk.java.net  Wed Apr 28 01:18:03 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Apr 2021 01:18:03 GMT
Subject: RFR: JDK-8265773: incorrect jdeps message "jdk8internals" to describe
 a removed JDK internal API
Message-ID: <blCgr1AQAqA6r0xpRGnd2HsBIUxK2mnCloDy-lCgnN4=.c00216ab-4a0a-49f8-8d24-738a102cc186@github.com>

jdeps should print "JDK removed internal APIs" to give an informative description when a JDK internal API that is being referenced has been removed.  JDK-8213909 incorrectly changed it to print `jdk8internals`.

An example output is:


classes -> jdk8internals
   p.Main                                             -> sun.misc.Service                                      JDK removed internal API
   p.Main                                             -> sun.misc.SoftCache                                 JDK removed internal API

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

Commit messages:
 - JDK-8265773: jdeps message jdk8internals indicating a non-existent JDK API is incorrect

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

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

From hannesw at openjdk.java.net  Wed Apr 28 07:55:06 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 Apr 2021 07:55:06 GMT
Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program
 element is wrapped
Message-ID: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@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.

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

Commit messages:
 - JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped

Changes: https://git.openjdk.java.net/jdk/pull/3754/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3754&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250766
  Stats: 24 lines in 3 files changed: 17 ins; 1 del; 6 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 prappo at openjdk.java.net  Wed Apr 28 10:18:53 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 28 Apr 2021 10:18:53 GMT
Subject: RFR: 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: <tZ4VN9BbC_KglzqodXyT1tpI-GyNGUrjao8sMAcyr7w=.557b9dc8-ce62-49a8-b948-7405b82f5a31@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.

I have marked [8252039](https://bugs.openjdk.java.net/browse/JDK-8252039) as a duplicate of this bug. The fix looks nice and clean. That said, I wonder if it introduces any harmful discrepancies between the signature string and the start and end positions of DCReference.

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

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

From jfranck at openjdk.java.net  Wed Apr 28 10:40:56 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Wed, 28 Apr 2021 10:40:56 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v2]
In-Reply-To: <jL7jiiU3lYsPz9Bzd1fya2WwXZ2m7o2hl1x_MQOY4I4=.e3bf1893-7540-4567-80e0-cf2944f8ddcf@github.com>
References: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
 <jL7jiiU3lYsPz9Bzd1fya2WwXZ2m7o2hl1x_MQOY4I4=.e3bf1893-7540-4567-80e0-cf2944f8ddcf@github.com>
Message-ID: <qXtvFXJOmiJlqjp_zMjEdwA1ApsO4cIwrAMOTHvTyYU=.732d4d84-0ef4-48a9-9bf9-8ce16c98b849@github.com>

On Mon, 15 Mar 2021 11:23:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara.
>> 
>> @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating test per review comments.

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTool.java line 173:

> 171:                 // Situation: out is null and the value is not set in the context.
> 172:                 context.put(Log.errKey, new PrintWriter(System.err, true));
> 173:             else if (out instanceof PrintWriter)

Can use instance of pattern matching

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

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

From jfranck at openjdk.java.net  Wed Apr 28 10:51:58 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Wed, 28 Apr 2021 10:51:58 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v2]
In-Reply-To: <jL7jiiU3lYsPz9Bzd1fya2WwXZ2m7o2hl1x_MQOY4I4=.e3bf1893-7540-4567-80e0-cf2944f8ddcf@github.com>
References: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
 <jL7jiiU3lYsPz9Bzd1fya2WwXZ2m7o2hl1x_MQOY4I4=.e3bf1893-7540-4567-80e0-cf2944f8ddcf@github.com>
Message-ID: <S2TF7dHRTJQP-3AlV9IRvn_JW03f2zfK5tIaBlmjV7s=.14acefa1-ead2-4ae1-978b-81d0aae5611c@github.com>

On Mon, 15 Mar 2021 11:23:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara.
>> 
>> @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating test per review comments.

Looks good to me

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

Marked as reviewed by jfranck (Reviewer).

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

From jfranck at openjdk.java.net  Wed Apr 28 13:03:53 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Wed, 28 Apr 2021 13:03:53 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v2]
In-Reply-To: <YPRvJ2DbNcbqWN0GYJnOftrTgul3HfbOF0euqARPI5U=.d1d08930-821c-43c7-8cb0-6d6b5681a9ac@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <lihZhiILl0jhuiIj7USLwsx6n114-BAg1cLYtNfIxJ8=.e1651dbd-b915-4533-9ac6-0594cb8ca527@github.com>
 <YPRvJ2DbNcbqWN0GYJnOftrTgul3HfbOF0euqARPI5U=.d1d08930-821c-43c7-8cb0-6d6b5681a9ac@github.com>
Message-ID: <VLwWZe-d5_s6opx_iYV5KHyl_cYpGo3SLLMHqeReF6Y=.c1e89e74-d192-4692-8f00-fd66adbcd97d@github.com>

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

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the content in documentation javac.1
>
> The CSR was created. Please see [JDK-8265772](https://bugs.openjdk.java.net/browse/JDK-8265772).  And I updated the copyright. Thank you for taking the time to review the CSR and this patch.

@lgxbslgx I added myself as a reviewer of the CSR. `javac -X` does not output any lint options on my machine, can you update the CSR it clarifying when `-X` would or would not output lint options,  and/or remove the non-relevant occurrences of `(-X)` ?

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

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

From gli at openjdk.java.net  Wed Apr 28 14:11:53 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 28 Apr 2021 14:11:53 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v2]
In-Reply-To: <VLwWZe-d5_s6opx_iYV5KHyl_cYpGo3SLLMHqeReF6Y=.c1e89e74-d192-4692-8f00-fd66adbcd97d@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <lihZhiILl0jhuiIj7USLwsx6n114-BAg1cLYtNfIxJ8=.e1651dbd-b915-4533-9ac6-0594cb8ca527@github.com>
 <YPRvJ2DbNcbqWN0GYJnOftrTgul3HfbOF0euqARPI5U=.d1d08930-821c-43c7-8cb0-6d6b5681a9ac@github.com>
 <VLwWZe-d5_s6opx_iYV5KHyl_cYpGo3SLLMHqeReF6Y=.c1e89e74-d192-4692-8f00-fd66adbcd97d@github.com>
Message-ID: <67a3M6inq_3TQ5tOo7tpsXGempdaixRuJMzlRfaBahE=.fa95a7c5-09e3-45d8-9b53-60eb5b3ff9b8@github.com>

On Wed, 28 Apr 2021 13:01:19 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> The CSR was created. Please see [JDK-8265772](https://bugs.openjdk.java.net/browse/JDK-8265772).  And I updated the copyright. Thank you for taking the time to review the CSR and this patch.
>
> @lgxbslgx I added myself as a reviewer of the CSR. `javac -X` does not output any lint options on my machine, can you update the CSR it clarifying when `-X` would or would not output lint options,  and/or remove the non-relevant occurrences of `(-X)` ?

@jbf  By using the current master branch code, the command `javac -X` would output the following message.


  --add-exports <module>/<package>=<other-module>(,<other-module>)*
        Specify a package to be considered as exported from its defining module
        to additional modules, or to all unnamed modules if <other-module> is ALL-UNNAMED.
  --add-reads <module>=<other-module>(,<other-module>)*
        Specify additional modules to be considered as required by a given module.
        <other-module> may be ALL-UNNAMED to require the unnamed module.
  --default-module-for-created-files <module-name>
        Fallback target module for files created by annotation processors, if none specified or inferred.
  -Djava.endorsed.dirs=<dirs>  Override location of endorsed standards path
  -Djava.ext.dirs=<dirs>       Override location of installed extensions
  --patch-module <module>=<file>(:<file>)*
        Override or augment a module with classes and resources
        in JAR files or directories
  -Xbootclasspath:<path>       Override location of bootstrap class files
  -Xbootclasspath/a:<path>     Append to the bootstrap class path
  -Xbootclasspath/p:<path>     Prepend to the bootstrap class path
  -Xdiags:{compact,verbose}    Select a diagnostic mode
  -Xdoclint
        Enable recommended checks for problems in javadoc comments
  -Xdoclint:(all|none|[-]<group>)[/<access>]
        Enable or disable specific checks for problems in javadoc comments,
        where <group> is one of accessibility, html, missing, reference, or syntax,
        and <access> is one of public, protected, package, or private.
  -Xdoclint/package:[-]<packages>(,[-]<package>)*
        Enable or disable checks in specific packages. Each <package> is either the
        qualified name of a package or a package name prefix followed by .*, which
        expands to all sub-packages of the given package. Each <package> can be prefixed
        with - to disable checks for the specified package or packages.
  -Xlint                       Enable recommended warnings
  -Xlint:<key>(,<key>)*
        Warnings to enable or disable, separated by comma.
        Precede a key by - to disable the specified warning.
        Supported keys are:
          all                  Enable all warnings
          auxiliaryclass       Warn about an auxiliary class that is hidden in a source file, and is used from other files.
          cast                 Warn about use of unnecessary casts.
          classfile            Warn about issues related to classfile contents.
          deprecation          Warn about use of deprecated items.
          dep-ann              Warn about items marked as deprecated in JavaDoc but not using the @Deprecated annotation.
          divzero              Warn about division by constant integer 0.
          empty                Warn about empty statement after if.
          exports              Warn about issues regarding module exports.
          fallthrough          Warn about falling through from one case of a switch statement to the next.
          finally              Warn about finally clauses that do not terminate normally.
          missing-explicit-ctor Warn about missing explicit constructors in public and protected classes in exported packages.
          module               Warn about module system related issues.
          opens                Warn about issues regarding module opens.
          options              Warn about issues relating to use of command line options.
          overloads            Warn about issues regarding method overloads.
          overrides            Warn about issues regarding method overrides.
          path                 Warn about invalid path elements on the command line.
          processing           Warn about issues regarding annotation processing.
          rawtypes             Warn about use of raw types.
          removal              Warn about use of API that has been marked for removal.
          requires-automatic   Warn about use of automatic modules in the requires clauses.
          requires-transitive-automatic Warn about automatic modules in requires transitive.
          serial               Warn about Serializable classes that do not provide a serial version ID. 
                             Also warn about access to non-public members from a serializable element.
          static               Warn about accessing a static member using an instance.
          synchronization      Warn about synchronization attempts on instances of value-based classes.
          text-blocks          Warn about inconsistent white space characters in text block indentation.
          try                  Warn about issues relating to use of try blocks (i.e. try-with-resources).
          unchecked            Warn about unchecked operations.
          varargs              Warn about potentially unsafe vararg methods.
          preview              Warn about use of preview language features.
          none                 Disable all warnings
  -Xmaxerrs <number>           Set the maximum number of errors to print
  -Xmaxwarns <number>          Set the maximum number of warnings to print
  -Xpkginfo:{always,legacy,nonempty}
        Specify handling of package-info files
  -Xplugin:"name args"
        Name and optional arguments for a plug-in to be run
  -Xprefer:{source,newer}
        Specify which file to read when both a source file and class file are found for an implicitly compiled class
  -Xprint
        Print out a textual representation of specified types
  -XprintProcessorInfo
        Print information about which annotations a processor is asked to process
  -XprintRounds
        Print information about rounds of annotation processing
  -Xstdout <filename>          Redirect standard output

These extra options are subject to change without notice.


Did your machine output the same message? Especially the following output:


  -Xlint                       Enable recommended warnings
  -Xlint:<key>(,<key>)*
        Warnings to enable or disable, separated by comma.
        Precede a key by - to disable the specified warning.
        Supported keys are:    <-------------------- Note here
          all                  Enable all warnings    <-------------------------------- Note here
          auxiliaryclass       Warn about an auxiliary class that is hidden in a source file, and is used from other files.<------Note here
          cast                 Warn about use of unnecessary casts.       <------------------------- Note here
          // <-------------- ignore many other sub-options.
  -Xmaxerrs <number>           Set the maximum number of errors to print


By using the code of this patch, the command `javac -X` would output the following message. We can see that the `Supported keys` is removed.


  --add-exports <module>/<package>=<other-module>(,<other-module>)*
        Specify a package to be considered as exported from its defining module
        to additional modules, or to all unnamed modules if <other-module> is ALL-UNNAMED.
  --add-reads <module>=<other-module>(,<other-module>)*
        Specify additional modules to be considered as required by a given module.
        <other-module> may be ALL-UNNAMED to require the unnamed module.
  --default-module-for-created-files <module-name>
        Fallback target module for files created by annotation processors, if none specified or inferred.
  -Djava.endorsed.dirs=<dirs>  Override location of endorsed standards path
  -Djava.ext.dirs=<dirs>       Override location of installed extensions
  --help-lint                  Print the supported keys of option -Xlint
  --patch-module <module>=<file>(:<file>)*
        Override or augment a module with classes and resources
        in JAR files or directories
  -Xbootclasspath:<path>       Override location of bootstrap class files
  -Xbootclasspath/a:<path>     Append to the bootstrap class path
  -Xbootclasspath/p:<path>     Prepend to the bootstrap class path
  -Xdiags:{compact,verbose}    Select a diagnostic mode
  -Xdoclint
        Enable recommended checks for problems in javadoc comments
  -Xdoclint:(all|none|[-]<group>)[/<access>]
        Enable or disable specific checks for problems in javadoc comments,
        where <group> is one of accessibility, html, missing, reference, or syntax,
        and <access> is one of public, protected, package, or private.
  -Xdoclint/package:[-]<packages>(,[-]<package>)*
        Enable or disable checks in specific packages. Each <package> is either the
        qualified name of a package or a package name prefix followed by .*, which
        expands to all sub-packages of the given package. Each <package> can be prefixed
        with - to disable checks for the specified package or packages.
  -Xlint                       Enable recommended warnings
  -Xlint:<key>(,<key>)*
        Warnings to enable or disable, separated by comma.
        Precede a key by - to disable the specified warning.
        Use option --help-lint to see the supported keys.
  -Xmaxerrs <number>           Set the maximum number of errors to print
  -Xmaxwarns <number>          Set the maximum number of warnings to print
  -Xpkginfo:{always,legacy,nonempty}
        Specify handling of package-info files
  -Xplugin:"name args"
        Name and optional arguments for a plug-in to be run
  -Xprefer:{source,newer}
        Specify which file to read when both a source file and class file are found for an implicitly compiled class
  -Xprint
        Print out a textual representation of specified types
  -XprintProcessorInfo
        Print information about which annotations a processor is asked to process
  -XprintRounds
        Print information about rounds of annotation processing
  -Xstdout <filename>          Redirect standard output

These extra options are subject to change without notice.


And the command `javac --help-lint` would output the following message.


The supported keys of option -Xlint are:
    all                  Enable all warnings
    auxiliaryclass       Warn about an auxiliary class that is hidden in a source file, and is used from other files.
    cast                 Warn about use of unnecessary casts.
    classfile            Warn about issues related to classfile contents.
    deprecation          Warn about use of deprecated items.
    dep-ann              Warn about items marked as deprecated in JavaDoc but not using the @Deprecated annotation.
    divzero              Warn about division by constant integer 0.
    empty                Warn about empty statement after if.
    exports              Warn about issues regarding module exports.
    fallthrough          Warn about falling through from one case of a switch statement to the next.
    finally              Warn about finally clauses that do not terminate normally.
    missing-explicit-ctor Warn about missing explicit constructors in public and protected classes in exported packages.
    module               Warn about module system related issues.
    opens                Warn about issues regarding module opens.
    options              Warn about issues relating to use of command line options.
    overloads            Warn about issues regarding method overloads.
    overrides            Warn about issues regarding method overrides.
    path                 Warn about invalid path elements on the command line.
    processing           Warn about issues regarding annotation processing.
    rawtypes             Warn about use of raw types.
    removal              Warn about use of API that has been marked for removal.
    requires-automatic   Warn about use of automatic modules in the requires clauses.
    requires-transitive-automatic Warn about automatic modules in requires transitive.
    serial               Warn about Serializable classes that do not provide a serial version ID. 
                         Also warn about access to non-public members from a serializable element.
    static               Warn about accessing a static member using an instance.
    synchronization      Warn about synchronization attempts on instances of value-based classes.
    text-blocks          Warn about inconsistent white space characters in text block indentation.
    try                  Warn about issues relating to use of try blocks (i.e. try-with-resources).
    unchecked            Warn about unchecked operations.
    varargs              Warn about potentially unsafe vararg methods.
    preview              Warn about use of preview language features.
    none                 Disable all warnings


A difference between the CSR and the output are `sub-options` and `Supported keys`. I think the name `sub-options` is good for compilers developer and the name `Supported keys` is good for users. I revised the CSR to clarify it just now .

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

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

From jonathan.gibbons at oracle.com  Wed Apr 28 18:52:44 2021
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 28 Apr 2021 11:52:44 -0700
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v2]
In-Reply-To: <67a3M6inq_3TQ5tOo7tpsXGempdaixRuJMzlRfaBahE=.fa95a7c5-09e3-45d8-9b53-60eb5b3ff9b8@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <lihZhiILl0jhuiIj7USLwsx6n114-BAg1cLYtNfIxJ8=.e1651dbd-b915-4533-9ac6-0594cb8ca527@github.com>
 <YPRvJ2DbNcbqWN0GYJnOftrTgul3HfbOF0euqARPI5U=.d1d08930-821c-43c7-8cb0-6d6b5681a9ac@github.com>
 <VLwWZe-d5_s6opx_iYV5KHyl_cYpGo3SLLMHqeReF6Y=.c1e89e74-d192-4692-8f00-fd66adbcd97d@github.com>
 <67a3M6inq_3TQ5tOo7tpsXGempdaixRuJMzlRfaBahE=.fa95a7c5-09e3-45d8-9b53-60eb5b3ff9b8@github.com>
Message-ID: <0801c5fa-98ea-281b-02f2-aa93876c3c4b@oracle.com>

I like the fact that you suggest the use of `--help-list`.

-- Jon

On 4/28/21 7:11 AM, Guoxiong Li wrote:
>    -Xlint:<key>(,<key>)*
>          Warnings to enable or disable, separated by comma.
>          Precede a key by - to disable the specified warning.
>          Use option --help-lint to see the supported keys.

From jlahoda at openjdk.java.net  Thu Apr 29 08:18:26 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 29 Apr 2021 08:18:26 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v3]
In-Reply-To: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
References: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
Message-ID: <NqQuz6OC3Kq3WBfuooptj-Yg_IXLGRyLmg8CTeUmZdI=.bf3427cb-37d1-4738-9524-a9030df4d36e@github.com>

> This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara.
> 
> @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself.

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

  Reflecting review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2871/files
  - new: https://git.openjdk.java.net/jdk/pull/2871/files/ec3c8927..3ed19b95

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

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

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

From jlahoda at openjdk.java.net  Thu Apr 29 09:41:57 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 29 Apr 2021 09:41:57 GMT
Subject: Integrated: 8198317: Enhance JavacTool.getTask for flexibility
In-Reply-To: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
References: <zYNAgZhbcvtkYmuvcllZahjFLrKOFmlixja3puW9vnQ=.25837f2e-c51f-482f-a9c1-ea063d201b83@github.com>
Message-ID: <iv-BKkDAuJiTifUHEsbQpDKBTqd9xCT8JPsgVrWZQlE=.a2d680d1-3e40-4e67-a0b5-5ac0df3a0fce@github.com>

On Mon, 8 Mar 2021 11:21:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a clone of https://github.com/openjdk/jdk/pull/1896, which got closed by Skara.
> 
> @lgxbslgx, please let me know if you would prefer to resubmit the PR yourself.

This pull request has now been integrated.

Changeset: df7f0b46
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/df7f0b4671fd5b23b7b31c27c03af3b34b6a933d
Stats:     134 lines in 2 files changed: 132 ins; 0 del; 2 mod

8198317: Enhance JavacTool.getTask for flexibility

Co-authored-by: Guoxiong Li <lgxbslgx at gmail.com>
Reviewed-by: jfranck

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

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

From jlahoda at openjdk.java.net  Thu Apr 29 09:48:53 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 29 Apr 2021 09:48:53 GMT
Subject: RFR: 8263452: Javac slow compilation due to algorithmic complexity
In-Reply-To: <HQRLZwbsZv0utyGtaqh2jkHJ2bIwh9FEo_0h5YMpMI4=.3d6e7705-5353-477c-b3c9-0ddadcb4e418@github.com>
References: <E08ZDwDImMWNy_8BhR31z2ijeDxKf_ErShsAs3gfLnk=.43946497-a910-4774-9220-e56d7d04f699@github.com>
 <HQRLZwbsZv0utyGtaqh2jkHJ2bIwh9FEo_0h5YMpMI4=.3d6e7705-5353-477c-b3c9-0ddadcb4e418@github.com>
Message-ID: <yFZOMuILU_LkcFrGu3VzM0rg8o_ge0xgjO20Th8l1YY=.0e244a81-3665-4810-beb3-a1979b7a3f92@github.com>

On Fri, 16 Apr 2021 08:49:57 GMT, Joel Borggr?n-Franck <jfranck 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.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5096:
> 
>> 5094:             // First, attribute superclass.
>> 5095:             if (st.hasTag(CLASS))
>> 5096:                 attribClass((ClassSymbol)st.tsym);
> 
> This looks like a guarding against a special case of attributing something twice. Did you consider pushing this into attribClass instead so that calling it a second time is a no-op?

@jbf, sorry, I missed you comment.

I was thinking of using `Flags.UNATTRIBUTED` and skipping this whole method. I was a bit worried about a case where a class from source has a supertype from classfile (which never has `UNATTRIBUTED`), which has a supertype from source - by using `UNATTRIBUTED`, we could get to a state where this supertype attribution wouldn't attribute the super-supertype from source. Using another flag is an attempt to avoid this issue completely - the cost is using one more flag out of a limited pool of flags, of course.

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

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

From jlahoda at openjdk.java.net  Thu Apr 29 14:58:53 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 29 Apr 2021 14:58:53 GMT
Subject: Integrated: 8266027: The diamond finder does not find diamond
 candidates in field initializers
In-Reply-To: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
References: <RQf9_qwFAH7GqSRpNZASGPaupcRBQYvphjNIc7OBfns=.80168677-43dc-46a1-a3b0-5e715066913c@github.com>
Message-ID: <ioe4srjyYNdtVmcQiAcXeUml2niswgxBqQjrH-JCaLg=.bdf74e37-965a-42f8-a90b-46a668be8b75@github.com>

On Tue, 27 Apr 2021 09:13:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class Test {
>      private List<String> f2 = new LinkedList<String>();
> }
> 
> 
> Running with javac with `-XDfind=diamond` will not produce any warning about a possible diamond use. The reason is that the field:
> 
> private List<String> f2 = new LinkedList<String>();
> 
> 
> will get wrapped by a block, and attributed as a block, but since it has the `private` modifier, an error will be produced, and the transformation will be deemed impossible.
> 
> The proposed solution is to clear the modifiers when/if wrapping fields with blocks.

This pull request has now been integrated.

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

8266027: The diamond finder does not find diamond candidates in field initializers

Reviewed-by: jfranck, vromero

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

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

From jpai at openjdk.java.net  Thu Apr 29 15:41:55 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 29 Apr 2021 15:41:55 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v4]
In-Reply-To: <xIE8AvPWcFR_f-z7z4Om_zSn1J8_xUXY6egI9MHIrNU=.8ae9c4f6-cd29-4f46-ab82-47ea43052205@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <xIE8AvPWcFR_f-z7z4Om_zSn1J8_xUXY6egI9MHIrNU=.8ae9c4f6-cd29-4f46-ab82-47ea43052205@github.com>
Message-ID: <0XokWYXVb6wKP82I5fJCll_pYayCpu46bb34r4_K7sU=.ae8dfde4-ae99-425e-9074-2abbf81d774f@github.com>

On Thu, 1 Apr 2021 15:02:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Lance's review - include tests for --extract long form option
>  - cleanup after each test
>  - Adjust test for new error messages
>  - Lance's review - add a code comment for xdestDir
>  - Lance's review - updates to the help messages in jar.properties
>  - Lance's review - add comment to the magic number 6 in the tests
>  - Lance's review - add comments to test methods

Still active. Been busy with a few other things and I just need to get back and implement some inputs from Lance.

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

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

From jjg at openjdk.java.net  Fri Apr 30 03:15:57 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 30 Apr 2021 03:15:57 GMT
Subject: RFR: 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: <im2VZvZ2g8Fm8sZ-sorhOuEuo8_bPm7ifE99PDpauL0=.d61a141b-d727-4ba9-9bfd-dc79791ded3d@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 is against the general philosophy of `DocCommentParser`, which is to try and retain input formatting as much as possible. 

It would be better to normalize the whitespace downstream (i.e. in javadoc HTML world) when creating output based on the signature.

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

Changes requested by jjg (Reviewer).

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

From vromero at openjdk.java.net  Fri Apr 30 17:39:40 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 30 Apr 2021 17:39:40 GMT
Subject: RFR: 8265319: implement Sealed Classes as a standard feature in
 Java, javax.lang.model changes [v2]
In-Reply-To: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
References: <1r5hw352LbLSDTkkiUo07yxZToOK12h23iPp9Q-vbFM=.1bbab48c-c7f5-4bf3-939f-bf1559acbc32@github.com>
Message-ID: <ZhTfc1Q_yIidNXTTfP3EXiI6nbuCK5VJs3cnOEhi6yA=.a8ec9a3e-40bf-4a8e-9982-1133141085ea@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 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

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

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

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

  Stats: 563569 lines in 5123 files changed: 45774 ins; 510854 del; 6941 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  Fri Apr 30 17:40:47 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 30 Apr 2021 17:40:47 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v5]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <jaaZysmhTCB_6_r-W7njinAlomxlcFIuOD5akEaxPZo=.bc25be8a-6c4a-420f-84b9-6d5efc0e3097@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 ten additional commits since the last revision:

 - 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
 - 8260517: Compiler implementation for Sealed Classes

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

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

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

  Stats: 506473 lines in 3844 files changed: 20558 ins; 483521 del; 2394 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 igraves at openjdk.java.net  Fri Apr 30 19:55:51 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 30 Apr 2021 19:55:51 GMT
Subject: Integrated: 8260560: convert jdeps and jdeprscan tools to use
 Stream.toList()
In-Reply-To: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
References: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
Message-ID: <QDr5ps3NXUb4Oa6Q3nQWfA3YPhHHs9U7sD-ugDn7_sU=.a1473d32-6b3e-4c5b-8992-4b5689ee6c97@github.com>

On Tue, 27 Apr 2021 00:20:49 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8260560: convert jdeps and jdeprscan tools to use Stream.toList()

This pull request has now been integrated.

Changeset: c36c63a0
Author:    Ian Graves <igraves at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c36c63a008fa5e8b00dfc36c887cd9497fb91ab5
Stats:     9 lines in 4 files changed: 0 ins; 0 del; 9 mod

8260560: convert jdeps and jdeprscan tools to use Stream.toList()

Reviewed-by: alanb, mchung, iris

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

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