From darcy at openjdk.org  Thu Sep  1 05:23:25 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 05:23:25 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac [v2]
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <PhjxTbUT9SG0f9E9xTuaJtcO2dXs2BXBUiykCQN0VR8=.e1d79c6c-208e-4aa9-bd60-266e6d387842@github.com>

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

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

 - Update copyrights.
 - Delete unneeded test.
 - Merge branch 'master' into JDK-8173605
 - Merge branch 'master' into JDK-8173605
 - Small refactoring to remove more stale code.
 - Remove effectively dead code.
 - Adjust data for CheckExamples test.
 - Partial restore of DEFAULT_METHODS Source.Feature for test java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java.
 - Merge branch 'master' into JDK-8173605
 - Fix MultiReleaseJars.java.
 - ... and 17 more: https://git.openjdk.org/jdk/compare/a81a20ee...b2039d68

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10074/files
  - new: https://git.openjdk.org/jdk/pull/10074/files/f3095350..b2039d68

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

  Stats: 14641 lines in 536 files changed: 4475 ins; 7382 del; 2784 mod
  Patch: https://git.openjdk.org/jdk/pull/10074.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10074/head:pull/10074

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

From jlahoda at openjdk.org  Thu Sep  1 12:28:15 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Sep 2022 12:28:15 GMT
Subject: RFR: 8290709: Incorrect dominance error for unconditional pattern
 vs. null
In-Reply-To: <Ir3ff4HHm4rCDRPYIuc-EfmQ1_RQ6dnYDDOnjLJVA38=.cca6a3f6-f30d-4c80-b99f-c0b05594b38b@github.com>
References: <Ir3ff4HHm4rCDRPYIuc-EfmQ1_RQ6dnYDDOnjLJVA38=.cca6a3f6-f30d-4c80-b99f-c0b05594b38b@github.com>
Message-ID: <Dn9t1Tx9Bd7roZwf751f1biQi9yjIPNvGXevaXv_6wE=.95df3349-d270-49e4-a4fc-059a7c3a6624@github.com>

On Wed, 3 Aug 2022 16:12:55 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The corresponding JLS rule (3rd preview feature of pattern switch) on unconditional patterns & null does not exist anymore:
> 
> Check:
> 
> - 2nd preview: https://cr.openjdk.java.net/~gbierman/jep420/jep420-20211208/specs/patterns-switch-jls.html#jls-14.11.1
> - 3rd preview: https://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-14.11.1
> 
> Effectively, the following restriction was lifted:
> 
> A switch label that has a pattern case label element p that is total for the type of the selector expression of the enclosing switch statement or switch expression dominates a switch label that has a null case label element.
> 
> 
> The corresponding neg-tests where now promoted as pos-tests.

Looks good.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.org  Thu Sep  1 12:49:09 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Sep 2022 12:49:09 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v2]
In-Reply-To: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
Message-ID: <n2xNGlNqdicNKzkuTGQOm3F7GZ0IIqhvoN5xPuyXvUI=.d6d9aa3a-80cd-4c5d-87d4-3082d7df8ad7@github.com>

> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
> 
> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
> -parsing only sources that were modified first,
> -computing an "API" hash for them,
> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
> 
> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
> 
> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
> 
> On my laptop, doing:
> 
> touch src/java.base/share/classes/java/lang/Object.java ; time make
> 
> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
> 
> The caveats of this patch include:
> -it is more involved than the existing plugin
> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently

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

  Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10104/files
  - new: https://git.openjdk.org/jdk/pull/10104/files/778a6719..f1e19e8b

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

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

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

From jlahoda at openjdk.org  Thu Sep  1 12:49:11 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Sep 2022 12:49:11 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v2]
In-Reply-To: <XqlECNe_yQWkz0useWv3mru_6Wb26we54omiI2-DSSQ=.f83f6788-8f54-4e5e-b1bd-99ab59c79ed4@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <XqlECNe_yQWkz0useWv3mru_6Wb26we54omiI2-DSSQ=.f83f6788-8f54-4e5e-b1bd-99ab59c79ed4@github.com>
Message-ID: <sVJysWK6TCtJTgqD4C9UJFChzuKfaDS0qaAkxijKcQs=.409c1d32-655a-46df-ab59-d4f364bf6229@github.com>

On Wed, 31 Aug 2022 20:02:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> make/common/JavaCompilation.gmk line 451:
> 
>> 449:     # $$($1_VARDEPS_FILE) is used as dependency to track changes in set of
>> 450:     # list of files.
>> 451:     $$($1_COMPILE_TARGET): $$($1_SRCS) $$($1_DEPENDS) \
> 
> What's the reason for inlining this recipe into the main compilation recipe? I would think generating the modfiles file in the FILELIST rule would help reduce the noise from non source files in the prerequisites list (as the old FILELIST rule had a lot less prerequisites listed). Keeping this recipe separate also limits regeneration of the FILELIST.

I've tried to fix this in:
https://github.com/openjdk/jdk/pull/10104/commits/f1e19e8b636ddf08500a6401ce1488265f7b9446

> make/common/JavaCompilation.gmk line 456:
> 
>> 454: 		$$(call LogWarn, Compiling up to $$(words $$($1_SRCS)) files for $1)
>> 455: 		$$(eval $$(call ListPathsSafely, $1_SRCS, $$($1_FILELIST)))
>> 456: 		$$(call WriteFile, "-XDmodifiedInputs=$$? ", $$@.modfiles)
> 
> I'm not sure WriteFile is safe to use here. `$?` could potentially contain all files in `$1_SRCS`, which is why we use ListPathsSafely in the first place. This is only a problem if using make <4.0, but as long as that's not prohibited, we need to keep it working without the file function.

Is there some recommendation on how to generate what is needed? Which is:

"-XDmodifiedFiles=<list-of-files> "


I was looking at the `WriteFile` rule, and it is not clear to be what is the problem there, but I'm not very knowledgeable of the build system.

I was trying to use `ListPathsSafely`, but wasn't able to find a way that would be working.

Thanks!

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

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

From erikj at openjdk.org  Thu Sep  1 13:15:11 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 1 Sep 2022 13:15:11 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v2]
In-Reply-To: <n2xNGlNqdicNKzkuTGQOm3F7GZ0IIqhvoN5xPuyXvUI=.d6d9aa3a-80cd-4c5d-87d4-3082d7df8ad7@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <n2xNGlNqdicNKzkuTGQOm3F7GZ0IIqhvoN5xPuyXvUI=.d6d9aa3a-80cd-4c5d-87d4-3082d7df8ad7@github.com>
Message-ID: <NoMM0e-DZFcyjgyXV3BJ0-WeaAehlpwafNVmUEW0-to=.761e23b2-7b37-46f9-b51c-5426f5fb7073@github.com>

On Thu, 1 Sep 2022 12:49:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Sorry, I was so focused on JavaCompilation.gmk yesterday so I forgot about the rest of the build changes.

make/CompileInterimLangtools.gmk line 56:

> 54: 	$(call MakeDir, $(@D))
> 55: 	$(SED) $(INTERIM_TOOL_PROVIDER_PATTERN) $< > $@
> 56: 

Could you introduce a new section here with a comment header briefly describing what this is doing and why? It's currently under a section describing module-info.java. Let the last line of each section be the `TARGETS += ...` line.

make/CompileInterimLangtools.gmk line 92:

> 90:           Standard.java, \
> 91:       EXTRA_FILES := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java \
> 92:                      $($1.interim_EXTRA_FILES), \

Style nit. We try to avoid aligning broken up lines like this. Please just use 4 space continuation indent. (See https://openjdk.org/groups/build/doc/code-conventions.html)

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

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

From erikj at openjdk.org  Thu Sep  1 13:31:20 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 1 Sep 2022 13:31:20 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v2]
In-Reply-To: <sVJysWK6TCtJTgqD4C9UJFChzuKfaDS0qaAkxijKcQs=.409c1d32-655a-46df-ab59-d4f364bf6229@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <XqlECNe_yQWkz0useWv3mru_6Wb26we54omiI2-DSSQ=.f83f6788-8f54-4e5e-b1bd-99ab59c79ed4@github.com>
 <sVJysWK6TCtJTgqD4C9UJFChzuKfaDS0qaAkxijKcQs=.409c1d32-655a-46df-ab59-d4f364bf6229@github.com>
Message-ID: <e7h-_jLCXWzWhClHEZSiGrD6yT38QwAnySSFGYiHpUQ=.48ea024c-c179-4ad1-a757-d331318ccffa@github.com>

On Thu, 1 Sep 2022 12:43:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> make/common/JavaCompilation.gmk line 456:
>> 
>>> 454: 		$$(call LogWarn, Compiling up to $$(words $$($1_SRCS)) files for $1)
>>> 455: 		$$(eval $$(call ListPathsSafely, $1_SRCS, $$($1_FILELIST)))
>>> 456: 		$$(call WriteFile, "-XDmodifiedInputs=$$? ", $$@.modfiles)
>> 
>> I'm not sure WriteFile is safe to use here. `$?` could potentially contain all files in `$1_SRCS`, which is why we use ListPathsSafely in the first place. This is only a problem if using make <4.0, but as long as that's not prohibited, we need to keep it working without the file function.
>
> Is there some recommendation on how to generate what is needed? Which is:
> 
> "-XDmodifiedFiles=<list-of-files> "
> 
> 
> I was looking at the `WriteFile` rule, and it is not clear to be what is the problem there, but I'm not very knowledgeable of the build system.
> 
> I was trying to use `ListPathsSafely`, but wasn't able to find a way that would be working.
> 
> Thanks!

Before make 4.0, there was no `$(file ...)` function in make. That meant that if you needed to write something to a file directly from the makefile, you had to do something like `$(shell echo "foo" > /my/file)`. This works ok as long as the amount of text you need to write is small enough, but when writing long lists of filenames, you will eventually hit OS limits on command line length (which are different on different OSes, most notably much shorter on Windows). Our solution to this was ListPathsSafely, which breaks up long lists of path names into manageable chunks (and also compresses parts of the path using sed).

In make 4.0, the $(file) function was introduced, which makes this so much easier. Since it was also more performant, I implemented a 4.0 version of ListPathsSafely. However, we haven't changed the build to require make >4.0, so we have to keep both implementations around.

The WriteFile macro was only intended writing smaller files, so doesn't have any of the command splitting functionality of ListPathsSafely. 

So to answer your question, no there isn't a good way to achieve what you are asking for today, not without modifying or extending the macros. One could imagine adding a flag to ListPathsSafely that made it use space instead of newline as separator. Another solution could be to have Depend.java accept something like 

"-XDmodifiedFilesFile=/path/to/file"

where the file is a list as ListPathsSafely would create it.

We could also consider requiring make 4.0, but that will need some socializing first.

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

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

From abimpoudis at openjdk.org  Thu Sep  1 16:13:21 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 1 Sep 2022 16:13:21 GMT
Subject: Integrated: 8290709: Incorrect dominance error for unconditional
 pattern vs. null
In-Reply-To: <Ir3ff4HHm4rCDRPYIuc-EfmQ1_RQ6dnYDDOnjLJVA38=.cca6a3f6-f30d-4c80-b99f-c0b05594b38b@github.com>
References: <Ir3ff4HHm4rCDRPYIuc-EfmQ1_RQ6dnYDDOnjLJVA38=.cca6a3f6-f30d-4c80-b99f-c0b05594b38b@github.com>
Message-ID: <748jy-tASvKQ077DSPXOplQziJF3TeGhWD04dMCB1tI=.a249f975-75fc-4b81-84a6-baa46bbc500b@github.com>

On Wed, 3 Aug 2022 16:12:55 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The corresponding JLS rule (3rd preview feature of pattern switch) on unconditional patterns & null does not exist anymore:
> 
> Check:
> 
> - 2nd preview: https://cr.openjdk.java.net/~gbierman/jep420/jep420-20211208/specs/patterns-switch-jls.html#jls-14.11.1
> - 3rd preview: https://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-14.11.1
> 
> Effectively, the following restriction was lifted:
> 
> A switch label that has a pattern case label element p that is total for the type of the selector expression of the enclosing switch statement or switch expression dominates a switch label that has a null case label element.
> 
> 
> The corresponding neg-tests where now promoted as pos-tests.

This pull request has now been integrated.

Changeset: 9444a081
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9444a081cc9873caa7b5c6a78df0d1aecda6e4f1
Stats:     66 lines in 6 files changed: 25 ins; 20 del; 21 mod

8290709: Incorrect dominance error for unconditional pattern vs. null

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.org  Thu Sep  1 16:39:11 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Sep 2022 16:39:11 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v2]
In-Reply-To: <e7h-_jLCXWzWhClHEZSiGrD6yT38QwAnySSFGYiHpUQ=.48ea024c-c179-4ad1-a757-d331318ccffa@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <XqlECNe_yQWkz0useWv3mru_6Wb26we54omiI2-DSSQ=.f83f6788-8f54-4e5e-b1bd-99ab59c79ed4@github.com>
 <sVJysWK6TCtJTgqD4C9UJFChzuKfaDS0qaAkxijKcQs=.409c1d32-655a-46df-ab59-d4f364bf6229@github.com>
 <e7h-_jLCXWzWhClHEZSiGrD6yT38QwAnySSFGYiHpUQ=.48ea024c-c179-4ad1-a757-d331318ccffa@github.com>
Message-ID: <uRPwDQVemRWe2oZtQqbUnpANnMQVQG8J9VT-1G5fDoE=.e659a281-0009-4da8-a3a6-941526601e0e@github.com>

On Thu, 1 Sep 2022 13:25:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Is there some recommendation on how to generate what is needed? Which is:
>> 
>> "-XDmodifiedFiles=<list-of-files> "
>> 
>> 
>> I was looking at the `WriteFile` rule, and it is not clear to be what is the problem there, but I'm not very knowledgeable of the build system.
>> 
>> I was trying to use `ListPathsSafely`, but wasn't able to find a way that would be working.
>> 
>> Thanks!
>
> Before make 4.0, there was no `$(file ...)` function in make. That meant that if you needed to write something to a file directly from the makefile, you had to do something like `$(shell echo "foo" > /my/file)`. This works ok as long as the amount of text you need to write is small enough, but when writing long lists of filenames, you will eventually hit OS limits on command line length (which are different on different OSes, most notably much shorter on Windows). Our solution to this was ListPathsSafely, which breaks up long lists of path names into manageable chunks (and also compresses parts of the path using sed).
> 
> In make 4.0, the $(file) function was introduced, which makes this so much easier. Since it was also more performant, I implemented a 4.0 version of ListPathsSafely. However, we haven't changed the build to require make >4.0, so we have to keep both implementations around.
> 
> The WriteFile macro was only intended writing smaller files, so doesn't have any of the command splitting functionality of ListPathsSafely. 
> 
> So to answer your question, no there isn't a good way to achieve what you are asking for today, not without modifying or extending the macros. One could imagine adding a flag to ListPathsSafely that made it use space instead of newline as separator. Another solution could be to have Depend.java accept something like 
> 
> "-XDmodifiedFilesFile=/path/to/file"
> 
> where the file is a list as ListPathsSafely would create it.
> 
> We could also consider requiring make 4.0, but that will need some socializing first.

I can change `Depend` for this, that is easy, but it is not clear how to write the file. I've tried the naive `$$(eval $$(call ListPathsSafely, $$?, $$($1_MODFILES)))` at the end of `$$($1_FILELIST):` but that does not seem to write the modified files into the file - it produces an empty file. Is there a way for me to write the modified files into the file? Thanks.

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

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

From darcy at openjdk.org  Thu Sep  1 16:46:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 16:46:21 GMT
Subject: Integrated: JDK-8173605: Remove support for source and target 1.7
 option in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <gbPQrgcQ4ahoMdC7kieutONxygrBOxirKmi5HmDu-10=.d68cd13f-d992-443b-9353-2a19ef40cd8d@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

This pull request has now been integrated.

Changeset: 2d18dda3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d18dda3f2074a4f8b9a0c62ece9ac6d5284e93b
Stats:     4595 lines in 156 files changed: 25 ins; 4413 del; 157 mod

8173605: Remove support for source and target 1.7 option in javac

Reviewed-by: vromero

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

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

From erikj at openjdk.org  Thu Sep  1 16:51:30 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 1 Sep 2022 16:51:30 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v2]
In-Reply-To: <uRPwDQVemRWe2oZtQqbUnpANnMQVQG8J9VT-1G5fDoE=.e659a281-0009-4da8-a3a6-941526601e0e@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <XqlECNe_yQWkz0useWv3mru_6Wb26we54omiI2-DSSQ=.f83f6788-8f54-4e5e-b1bd-99ab59c79ed4@github.com>
 <sVJysWK6TCtJTgqD4C9UJFChzuKfaDS0qaAkxijKcQs=.409c1d32-655a-46df-ab59-d4f364bf6229@github.com>
 <e7h-_jLCXWzWhClHEZSiGrD6yT38QwAnySSFGYiHpUQ=.48ea024c-c179-4ad1-a757-d331318ccffa@github.com>
 <uRPwDQVemRWe2oZtQqbUnpANnMQVQG8J9VT-1G5fDoE=.e659a281-0009-4da8-a3a6-941526601e0e@github.com>
Message-ID: <v9S-uR9e40inI7HlWjrthE2dmXjPwlO4aHM5Xu0Jkzk=.f40df061-a471-4994-84a4-1dfce869d012@github.com>

On Thu, 1 Sep 2022 16:36:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Before make 4.0, there was no `$(file ...)` function in make. That meant that if you needed to write something to a file directly from the makefile, you had to do something like `$(shell echo "foo" > /my/file)`. This works ok as long as the amount of text you need to write is small enough, but when writing long lists of filenames, you will eventually hit OS limits on command line length (which are different on different OSes, most notably much shorter on Windows). Our solution to this was ListPathsSafely, which breaks up long lists of path names into manageable chunks (and also compresses parts of the path using sed).
>> 
>> In make 4.0, the $(file) function was introduced, which makes this so much easier. Since it was also more performant, I implemented a 4.0 version of ListPathsSafely. However, we haven't changed the build to require make >4.0, so we have to keep both implementations around.
>> 
>> The WriteFile macro was only intended writing smaller files, so doesn't have any of the command splitting functionality of ListPathsSafely. 
>> 
>> So to answer your question, no there isn't a good way to achieve what you are asking for today, not without modifying or extending the macros. One could imagine adding a flag to ListPathsSafely that made it use space instead of newline as separator. Another solution could be to have Depend.java accept something like 
>> 
>> "-XDmodifiedFilesFile=/path/to/file"
>> 
>> where the file is a list as ListPathsSafely would create it.
>> 
>> We could also consider requiring make 4.0, but that will need some socializing first.
>
> I can change `Depend` for this, that is easy, but it is not clear how to write the file. I've tried the naive `$$(eval $$(call ListPathsSafely, $$?, $$($1_MODFILES)))` at the end of `$$($1_FILELIST):` but that does not seem to write the modified files into the file - it produces an empty file. Is there a way for me to write the modified files into the file? Thanks.

Oh right, ListPathsSafely takes the data to write by reference, not by value (as in you supply the name of a variable that contains the data, not the data itself). I doubt `?` can be sent into an eval as a variable name, but I may be wrong. Perhaps you could extract the value into another variable first in a separate line in the recipe, something like this:


        $$(eval $1_MODFILES := $$?)
        $$(eval $$(call ListPathsSafely, $1_MODFILES, $$($1_MODFILELIST)))

(note that I redefined $1_MODFILES to be the list of modified files and introduced a new variable $1_MODFILELIST for the filename where we print it)

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

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

From jlahoda at openjdk.org  Thu Sep  1 18:35:24 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Sep 2022 18:35:24 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
Message-ID: <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>

> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
> 
> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
> -parsing only sources that were modified first,
> -computing an "API" hash for them,
> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
> 
> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
> 
> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
> 
> On my laptop, doing:
> 
> touch src/java.base/share/classes/java/lang/Object.java ; time make
> 
> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
> 
> The caveats of this patch include:
> -it is more involved than the existing plugin
> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently

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

  Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10104/files
  - new: https://git.openjdk.org/jdk/pull/10104/files/f1e19e8b..23e3b756

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

  Stats: 26 lines in 3 files changed: 16 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10104.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10104/head:pull/10104

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

From jlahoda at openjdk.org  Thu Sep  1 18:35:25 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Sep 2022 18:35:25 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <v9S-uR9e40inI7HlWjrthE2dmXjPwlO4aHM5Xu0Jkzk=.f40df061-a471-4994-84a4-1dfce869d012@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <XqlECNe_yQWkz0useWv3mru_6Wb26we54omiI2-DSSQ=.f83f6788-8f54-4e5e-b1bd-99ab59c79ed4@github.com>
 <sVJysWK6TCtJTgqD4C9UJFChzuKfaDS0qaAkxijKcQs=.409c1d32-655a-46df-ab59-d4f364bf6229@github.com>
 <e7h-_jLCXWzWhClHEZSiGrD6yT38QwAnySSFGYiHpUQ=.48ea024c-c179-4ad1-a757-d331318ccffa@github.com>
 <uRPwDQVemRWe2oZtQqbUnpANnMQVQG8J9VT-1G5fDoE=.e659a281-0009-4da8-a3a6-941526601e0e@github.com>
 <v9S-uR9e40inI7HlWjrthE2dmXjPwlO4aHM5Xu0Jkzk=.f40df061-a471-4994-84a4-1dfce869d012@github.com>
Message-ID: <0ZqiRmvOUllIClJmDVR20sLJhIj1_Kjwvzpj7A-we7I=.d3324291-142a-4854-bd73-fce7803ba8ec@github.com>

On Thu, 1 Sep 2022 16:48:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Oh right, ListPathsSafely takes the data to write by reference, not by value (as in you supply the name of a variable that contains the data, not the data itself). I doubt `?` can be sent into an eval as a variable name, but I may be wrong. Perhaps you could extract the value into another variable first in a separate line in the recipe, something like this:
> 
> ```
>         $$(eval $1_MODFILES := $$?)
>         $$(eval $$(call ListPathsSafely, $1_MODFILES, $$($1_MODFILELIST)))
> ```
> 
> (note that I redefined $1_MODFILES to be the list of modified files and introduced a new variable $1_MODFILELIST for the filename where we print it)

Thanks! Done in:
https://github.com/openjdk/jdk/pull/10104/commits/23e3b75679908d26b76cc291a8efba06879c0d83

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

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

From jlahoda at openjdk.org  Thu Sep  1 18:39:42 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Sep 2022 18:39:42 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v5]
In-Reply-To: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
Message-ID: <IpOjBaRqFB0wejHSLVFVZDs0DQjYBbFrb4W59naisC0=.a17213e0-ea19-47d1-9ebb-f2d751c71db1@github.com>

> This is an attempt to improve the performance and scalability of switches with record patterns.
> 
> There are two main parts of this patch:
> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
> 
> switch (obj) {
>      case Box(String s) -> {}
>      case Box(Integer i) -> {}
>      case Box(Number n) -> {}
>      ...
> }
> =>
> switch (obj) {
>      case Box b ->
>           switch (b.o()) {
>               case String s -> {}
>               case Integer i -> {}
>               case Number n -> {}
>               default -> continue-with-outer-switch;
>           };
>     ...
> }
> 
> 
> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
> 
> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
> 
> I ran the new code through a JMH benchmark:
> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
> 
> The results are:
>  - for "long" testcase (a switch with many cases):
> 
> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
> 
>  - for "short" testcase (a switch with no so many cases):
> 
> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
> 
> 
> So, the performance seems to be improved, at least in these cases.
> 
> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).

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

 - Reflecting review feedback.
 - Merge branch 'master' into JDK-8291769
 - Using a custom record instead of a generic Pair.
 - Fixing test.
 - Properly handle null record components.
 - 8291769: Translation of switch with record patterns could be improved

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9746/files
  - new: https://git.openjdk.org/jdk/pull/9746/files/1ff63342..f880c156

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

  Stats: 79351 lines in 1546 files changed: 36286 ins; 34192 del; 8873 mod
  Patch: https://git.openjdk.org/jdk/pull/9746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9746/head:pull/9746

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

From erikj at openjdk.org  Thu Sep  1 20:48:11 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 1 Sep 2022 20:48:11 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
Message-ID: <0lRYvHfl8Dc4zxlrQJA0Y5n5eDoIovimmMm9Ph9BES0=.e1380b14-b098-4c9f-a0ad-6f0d794bc252@github.com>

On Thu, 1 Sep 2022 18:35:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Build changes look good!

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

Marked as reviewed by erikj (Reviewer).

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

From darcy at openjdk.org  Thu Sep  1 21:52:57 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 21:52:57 GMT
Subject: RFR: JDK-8293003: Review running time of Warn5 regression test
Message-ID: <Y0R86dFIDlcr5vR7Hd7mUWrWdX3YTfhCHx6eLMfz3bI=.691df50d-b6e3-4987-9b9d-6213ddf394e2@github.com>

Refactoring of the Warn5 regression test to reduce its running time by more than 50%.

Included a small refactoring in Warn4 to use text blocks too.

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

Commit messages:
 - JDK-8293003: Review running time of Warn5 regression test

Changes: https://git.openjdk.org/jdk/pull/10130/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293003
  Stats: 28 lines in 2 files changed: 9 ins; 1 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10130.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10130/head:pull/10130

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

From vromero at openjdk.org  Fri Sep  2 02:40:38 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Sep 2022 02:40:38 GMT
Subject: RFR: JDK-8293003: Review running time of Warn5 regression test
In-Reply-To: <Y0R86dFIDlcr5vR7Hd7mUWrWdX3YTfhCHx6eLMfz3bI=.691df50d-b6e3-4987-9b9d-6213ddf394e2@github.com>
References: <Y0R86dFIDlcr5vR7Hd7mUWrWdX3YTfhCHx6eLMfz3bI=.691df50d-b6e3-4987-9b9d-6213ddf394e2@github.com>
Message-ID: <TMFNlTh2A4ogdFOir1u25AbeyG3qw_9KXYD0GsyZhJ0=.b17914a0-e0e6-46a4-8685-a5bd172c3066@github.com>

On Thu, 1 Sep 2022 20:50:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Refactoring of the Warn5 regression test to reduce its running time by more than 50%.
> 
> Included a small refactoring in Warn4 to use text blocks too.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.org  Fri Sep  2 02:57:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Sep 2022 02:57:45 GMT
Subject: Integrated: JDK-8293003: Review running time of Warn5 regression test
In-Reply-To: <Y0R86dFIDlcr5vR7Hd7mUWrWdX3YTfhCHx6eLMfz3bI=.691df50d-b6e3-4987-9b9d-6213ddf394e2@github.com>
References: <Y0R86dFIDlcr5vR7Hd7mUWrWdX3YTfhCHx6eLMfz3bI=.691df50d-b6e3-4987-9b9d-6213ddf394e2@github.com>
Message-ID: <oMOBHzmOrpcDvH0_BSXgVhJ7HAlu6H87OVbL4ziR1KY=.67864f9d-557d-4777-bad3-2b59e0b55096@github.com>

On Thu, 1 Sep 2022 20:50:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Refactoring of the Warn5 regression test to reduce its running time by more than 50%.
> 
> Included a small refactoring in Warn4 to use text blocks too.

This pull request has now been integrated.

Changeset: 3ac91b08
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ac91b08cbe16bc1a347178f853513f930ffeaf3
Stats:     28 lines in 2 files changed: 9 ins; 1 del; 18 mod

8293003: Review running time of Warn5 regression test

Reviewed-by: vromero

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

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

From vromero at openjdk.org  Fri Sep  2 15:54:41 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Sep 2022 15:54:41 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
Message-ID: <RUj9eO_RJkdns22_OzKCbGidPcH3F-bxJy0MvS11HXc=.c8966264-a8fb-4d87-beb1-757b96a97ef8@github.com>

On Thu, 1 Sep 2022 18:35:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

javac changes looks good to me

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.org  Fri Sep  2 21:19:11 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Sep 2022 21:19:11 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7
Message-ID: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>

This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?

TIA

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

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

Commit messages:
 - 8293051: Further refactor javac after removal of -source/-target/--release 7

Changes: https://git.openjdk.org/jdk/pull/10150/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10150&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293051
  Stats: 255 lines in 21 files changed: 10 ins; 198 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/10150.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10150/head:pull/10150

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

From vromero at openjdk.org  Fri Sep  2 21:35:46 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Sep 2022 21:35:46 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
Message-ID: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>

> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
> 
> TIA
> 
> [1] https://github.com/openjdk/jdk/pull/10074

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

  fixing additional test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10150/files
  - new: https://git.openjdk.org/jdk/pull/10150/files/331e4392..29f0b8a0

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

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

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

From darcy at openjdk.org  Fri Sep  2 21:46:00 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Sep 2022 21:46:00 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
Message-ID: <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>

On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
>> 
>> TIA
>> 
>> [1] https://github.com/openjdk/jdk/pull/10074
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing additional test

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

> 214:         POLY(JDK8),
> 215:         LAMBDA(JDK8, Fragments.FeatureLambda, DiagKind.PLURAL),
> 216:         DEFAULT_METHODS(JDK8, Fragments.FeatureDefaultMethods, DiagKind.PLURAL),

As noted in https://github.com/openjdk/jdk/pull/10074#issuecomment-1230998246, if DEFAULT_METHODS is removed, there is a core libs test that will fail.

I believe the functionality request is a standard idiom for forcing a source file to be compiled as Preview. Merely setting -XDpreview (however that hidden option is spelled) is not sufficient. A feature that triggers a checkSourceLevel call is needed too.

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

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

From vromero at openjdk.org  Fri Sep  2 21:54:43 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Sep 2022 21:54:43 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
Message-ID: <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>

On Fri, 2 Sep 2022 21:42:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing additional test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 216:
> 
>> 214:         POLY(JDK8),
>> 215:         LAMBDA(JDK8, Fragments.FeatureLambda, DiagKind.PLURAL),
>> 216:         DEFAULT_METHODS(JDK8, Fragments.FeatureDefaultMethods, DiagKind.PLURAL),
> 
> As noted in https://github.com/openjdk/jdk/pull/10074#issuecomment-1230998246, if DEFAULT_METHODS is removed, there is a core libs test that will fail.
> 
> I believe the functionality request is a standard idiom for forcing a source file to be compiled as Preview. Merely setting -XDpreview (however that hidden option is spelled) is not sufficient. A feature that triggers a checkSourceLevel call is needed too.

that can be worked out I think as I did with other tests, it should show up in the mach5 run, are you referring to: `PreviewHiddenClass.java`?

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

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

From darcy at openjdk.org  Fri Sep  2 23:24:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Sep 2022 23:24:53 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
 <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
Message-ID: <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>

On Fri, 2 Sep 2022 21:47:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 216:
>> 
>>> 214:         POLY(JDK8),
>>> 215:         LAMBDA(JDK8, Fragments.FeatureLambda, DiagKind.PLURAL),
>>> 216:         DEFAULT_METHODS(JDK8, Fragments.FeatureDefaultMethods, DiagKind.PLURAL),
>> 
>> As noted in https://github.com/openjdk/jdk/pull/10074#issuecomment-1230998246, if DEFAULT_METHODS is removed, there is a core libs test that will fail.
>> 
>> I believe the functionality request is a standard idiom for forcing a source file to be compiled as Preview. Merely setting -XDpreview (however that hidden option is spelled) is not sufficient. A feature that triggers a checkSourceLevel call is needed too.
>
> that can be worked out I think as I did with other tests, it should show up in the mach5 run, are you referring to: `PreviewHiddenClass.java`?

Pretty sure the test in question was under java.lang.invoke in the libraries (i.e. test/jdk vs test/langtools) area.

If we come up for a supported idiom for this, there is at least one other test I'd want to update to use it; that can be done as future work.

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

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

From vromero at openjdk.org  Sat Sep  3 02:51:34 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 3 Sep 2022 02:51:34 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
 <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
 <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>
Message-ID: <bJkwLj2qAFEV908aXLrIG-k1NOzfwJXB5i4G3dzjDX8=.eaee3b50-46f4-421b-ac43-5db294ebe9af@github.com>

On Fri, 2 Sep 2022 23:20:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> that can be worked out I think as I did with other tests, it should show up in the mach5 run, are you referring to: `PreviewHiddenClass.java`?
>
> Pretty sure the test in question was under java.lang.invoke in the libraries (i.e. test/jdk vs test/langtools) area.
> 
> If we come up for a supported idiom for this, there is at least one other test I'd want to update to use it; that can be done as future work.

all tier1-3 tests are passing in mach5

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

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

From darcy at openjdk.org  Sat Sep  3 16:34:31 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Sep 2022 16:34:31 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
Message-ID: <sxlIH_5wLX99vToeTiz70ThFlwANYLc3y6Oh_X-y674=.8769ef12-3577-4f90-8d6f-c6839348274a@github.com>

On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
>> 
>> TIA
>> 
>> [1] https://github.com/openjdk/jdk/pull/10074
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing additional test

Marked as reviewed by darcy (Reviewer).

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

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

From darcy at openjdk.org  Sat Sep  3 16:34:32 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Sep 2022 16:34:32 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <bJkwLj2qAFEV908aXLrIG-k1NOzfwJXB5i4G3dzjDX8=.eaee3b50-46f4-421b-ac43-5db294ebe9af@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
 <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
 <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>
 <bJkwLj2qAFEV908aXLrIG-k1NOzfwJXB5i4G3dzjDX8=.eaee3b50-46f4-421b-ac43-5db294ebe9af@github.com>
Message-ID: <IFkoBgh6IU7kuBYciLIi84lf0xlsfPfqGqlC7jUGOS8=.8b6fa695-f1f2-4ab7-a607-b022ba31a3e1@github.com>

On Sat, 3 Sep 2022 02:47:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Pretty sure the test in question was under java.lang.invoke in the libraries (i.e. test/jdk vs test/langtools) area.
>> 
>> If we come up for a supported idiom for this, there is at least one other test I'd want to update to use it; that can be done as future work.
>
> all tier1-3 tests are passing in mach5, I guess you were referring to: `test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java` which I have modified to play with records.

Sounds good.

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

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

From vromero at openjdk.org  Sat Sep  3 18:02:50 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 3 Sep 2022 18:02:50 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <IFkoBgh6IU7kuBYciLIi84lf0xlsfPfqGqlC7jUGOS8=.8b6fa695-f1f2-4ab7-a607-b022ba31a3e1@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
 <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
 <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>
 <bJkwLj2qAFEV908aXLrIG-k1NOzfwJXB5i4G3dzjDX8=.eaee3b50-46f4-421b-ac43-5db294ebe9af@github.com>
 <IFkoBgh6IU7kuBYciLIi84lf0xlsfPfqGqlC7jUGOS8=.8b6fa695-f1f2-4ab7-a607-b022ba31a3e1@github.com>
Message-ID: <HaP8pLGcbtPIdthPgH1P_9uUGDGS8Fucsdt4AuTzPzs=.7bf7f205-44ea-4ac1-9961-1b4a0b566b9b@github.com>

On Sat, 3 Sep 2022 16:30:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> all tier1-3 tests are passing in mach5, I guess you were referring to: `test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java` which I have modified to play with records.
>
> Sounds good.

thanks for the review

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

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

From cstein at openjdk.org  Mon Sep  5 06:12:18 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 5 Sep 2022 06:12:18 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update configure to check for jtreg 7 or later
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Revert junit.java
   
   Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
   
   With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
   This change updates the hard-coded library tag value to the new JUnit JAR file.
   Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
   in order to unblock the "Update to use jtreg 7" PR 9393:
   https://github.com/openjdk/jdk/pull/9393
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - ... and 4 more: https://git.openjdk.org/jdk/compare/3464019d...16b140ab

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

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

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

From stuefe at openjdk.org  Mon Sep  5 06:39:21 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Sep 2022 06:39:21 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
Message-ID: <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>

On Mon, 5 Sep 2022 06:12:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update configure to check for jtreg 7 or later
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Revert junit.java
>    
>    Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update to new JUnit JAR file
>    
>    With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
>    This change updates the hard-coded library tag value to the new JUnit JAR file.
>    Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
>    in order to unblock the "Update to use jtreg 7" PR 9393:
>    https://github.com/openjdk/jdk/pull/9393
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/3464019d...16b140ab

Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version?

Thanks!

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

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

From cstein at openjdk.org  Mon Sep  5 07:21:41 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 5 Sep 2022 07:21:41 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
 <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>
Message-ID: <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com>

On Mon, 5 Sep 2022 06:36:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version?

Yes, down to JDK 11.

Quote from [Coming soon: jtreg 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html)

> Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it.

And it should have said more correctly: _...requires a recent release of JDK 11 **or later** to run it._

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

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

From stuefe at openjdk.org  Mon Sep  5 07:42:41 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Sep 2022 07:42:41 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
 <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>
 <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com>
Message-ID: <y1H-GRoi8DLRX5RBo2m_upPWFc6MVReLm2KMYQOxT_I=.3c7dc4dc-3e52-4b62-9442-03e701af5181@github.com>

On Mon, 5 Sep 2022 07:18:09 GMT, Christian Stein <cstein at openjdk.org> wrote:

> > Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version?
> 
> Yes, down to JDK 11.
> 
> Quote from [Coming soon: jtreg 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html)
> 
> > Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it.

I read this to mean JT_JAVA, so the JVM running jtreg, not the testee VM.

But you are saying that the testee VM (`-jdk` option) can be JDK11 or later? I wonder whether I can use jtreg7 to test downport JDKs, especially since you wrote 

"This did affect some existing JDK tests, but those tests that
relied on specific jar file names have already been updated."

So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right?

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

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

From cstein at openjdk.org  Mon Sep  5 07:50:33 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 5 Sep 2022 07:50:33 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <y1H-GRoi8DLRX5RBo2m_upPWFc6MVReLm2KMYQOxT_I=.3c7dc4dc-3e52-4b62-9442-03e701af5181@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
 <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>
 <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com>
 <y1H-GRoi8DLRX5RBo2m_upPWFc6MVReLm2KMYQOxT_I=.3c7dc4dc-3e52-4b62-9442-03e701af5181@github.com>
Message-ID: <AQk5-CjYT8YZknv6oZRuwHnTzE9f1ws9cMlTeExlexo=.d078f624-9fbb-42f7-94a0-c7ef50565e86@github.com>

On Mon, 5 Sep 2022 07:38:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right?

Yes. Otherwise those tests will fail as they still do depend on hard-coded names of 3rd-party JAR files. Find backport candidates listed as Sub-Tasks number 3 to 5 at https://bugs.openjdk.org/browse/JDK-8289798 (Sub-Tasks number 1 and 2 were closed without changes.)

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

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

From mcimadamore at openjdk.org  Mon Sep  5 08:50:46 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Sep 2022 08:50:46 GMT
Subject: RFR: 8290561: Coalesce incubator-module warnings for single-file
 source-code programs
In-Reply-To: <ZGC5hjaFFTPuZaiVWumsbXyNnLw5lL9BoewWEwlubvc=.23a364c2-ef92-43e9-88af-88a8f34624b3@github.com>
References: <ZGC5hjaFFTPuZaiVWumsbXyNnLw5lL9BoewWEwlubvc=.23a364c2-ef92-43e9-88af-88a8f34624b3@github.com>
Message-ID: <6Em_3PiMnnhcQgk6QkaVX_lzNMSQZeR6IVXDjJQy2lc=.32c24caf-d6f1-4f2c-a098-e04f8f15c2e9@github.com>

On Fri, 22 Jul 2022 06:58:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a trivial code like:
> 
> public class Main {
>      public static void main(String... args) {}
> }
> 
> 
> And an execution like:
> 
> $ java --add-modules jdk.incubator.concurrent Main.java 
> WARNING: Using incubator modules: jdk.incubator.concurrent
> warning: using incubating module(s): jdk.incubator.concurrent
> 1 warning
> 
> 
> Having two warnings (one from runtime, one from javac) seems unnecessary. The patch proposed herein tries to avoid the javac warning, keeping only the runtime one. The conditions under which an incubator module is ignored w.r.t. this warning are:
> 
>  * the boot Module layer has the module (hence, presumably, the runtime already provided the warning)
>  * the javac run is (likely) from the source launcher. This is being done using a custom javac option, `-XDsourceLauncher` (which can possibly be used in other cases).
> 
> This is to avoid cases where we would incorrectly suppress the incubator warning, e.g. when `-XDsourceLauncher` would be passed on the command line.
> 
> There are other ways to attempt to detect javac invocations from the source launcher - a distinct file manager is used by the source launcher (but detection of the specific file manager does not feel in line with general javac approach); or use of the `jdk.internal.javac.source` system property set by the native launcher (but this is only set when `--source` option is used, as far as I know, and javac also typically does not check system properties).
> 
> Note that there is JDK-8290563 to improve the text of the javac warning.

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

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

From ihse at openjdk.org  Mon Sep  5 12:23:25 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Sep 2022 12:23:25 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
Message-ID: <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>

On Thu, 1 Sep 2022 18:35:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

make/common/JavaCompilation.gmk line 455:

> 453: 		$$(call LogWarn, Compiling up to $$(words $$($1_SRCS)) files for $1)
> 454: 		$$(eval $$(call ListPathsSafely, $1_SRCS, $$($1_FILELIST)))
> 455: 		$$(eval $1_MODFILES := $$?)

I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't.

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

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

From mcimadamore at openjdk.org  Mon Sep  5 15:10:45 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Sep 2022 15:10:45 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
Message-ID: <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>

On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
>> 
>> TIA
>> 
>> [1] https://github.com/openjdk/jdk/pull/10074
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing additional test

Great cleanup - few test changes were not 100% clear to me, probably I'm missing some context.

test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java line 31:

> 29: public interface HiddenInterface {
> 30:     default void test() {
> 31:         record R() {}

surprised to see this change

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

> 74:     public void testCompilerTestFlagEnv() {
> 75:         test(new String[] {"-C", "-XDforcePreview"},
> 76:                 (a) -> assertCommandOutputContains(a, "Function<Integer,Integer> f = (var i) -> i + i",

surprised to see these changes

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

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

From jlahoda at openjdk.org  Mon Sep  5 16:22:59 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Sep 2022 16:22:59 GMT
Subject: RFR: 8293348: A false cyclic inheritance error reported
Message-ID: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com>

Consider these two classes:

non-sealed interface T2 extends T {}
sealed interface T permits T2 {}


With a bit non-standard set-up, it may happen that:
- as part of `TypeEnter.HierarchyPhase`, `Check.checkNonCyclicInternal` is called for `T2`,
- that will mark T2 as LOCKED, and call `checkNonCyclicInternal` for its supertype `T`, which is uncompleted,
- `T` will be completed, so `TypeEnter.HierarchyPhase` will be called for it,
- `TypeEnter.HierarchyPhase` for `T` will try to attribute the permitted types of `T`,
- that will invoke `Check.checkNonCyclicInternal` for `T2` again,
- but the class is already locked, and hence a cycle error is produced.

The proposed solution is to defer permitted type handling to a later point in time, specifically to the `HeaderPhase`. The `HierarchyPhase` should only handle the type hierarchy (i.e. the supertypes of a given type), and should not handle cycles. Hence the `HeaderPhase` seems like a better place to handle the permitted types, similarly to type variable bounds handling.

Setting `isPermittedExplicit` is moved to `Enter` - seems the value of the flag can be inferred easily from the AST node, and can simply be used later.

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

Commit messages:
 - 8293348: A false cyclic inheritance error reported

Changes: https://git.openjdk.org/jdk/pull/10171/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10171&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293348
  Stats: 110 lines in 3 files changed: 64 ins; 44 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10171/head:pull/10171

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

From jlahoda at openjdk.org  Mon Sep  5 16:36:42 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Sep 2022 16:36:42 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
Message-ID: <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>

On Mon, 5 Sep 2022 12:19:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't.

Hm, but `$$($1_SRCS)` contains all the source files of the given module, modified and unmodified, correct? The point of this patch is that we send the list of modified files to the `Depend` plugin (all sources are still passed to the javac invocation), and the plugin decides whether or not all files should be compiled, or only the modified files should be compiled.

The plugin could theoretically do the timestamp check from the sources, but it is more difficult to do, and the make has (presumably) already done that in a predictable way.

The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources.

Note that the modfiles are not sent to javac as such - all sources are still sent to javac. The modfiles are sent to the `Depend` plugin using a side channel.

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

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

From vromero at openjdk.org  Mon Sep  5 18:22:36 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 5 Sep 2022 18:22:36 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>
Message-ID: <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com>

On Mon, 5 Sep 2022 15:04:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing additional test
>
> test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java line 31:
> 
>> 29: public interface HiddenInterface {
>> 30:     default void test() {
>> 31:         record R() {}
> 
> surprised to see this change

this is was done because test: `test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java` is compiling this code with options `--enable-preview -source [latestSource] -XDforcePreview` and then checking that the obtained class file has 65535 as its minor version. This was working so far as `DEFAULT_METHODS` was one member of `com.sun.tools.javac.code.Source.Feature` but as this PR is removing `DEFAULT_METHODS` we are obtaining the same effect defining a record as `RECORDS` are still defined in `com.sun.tools.javac.code.Source.Feature`

> test/langtools/jdk/jshell/ToolEnablePreviewTest.java line 76:
> 
>> 74:     public void testCompilerTestFlagEnv() {
>> 75:         test(new String[] {"-C", "-XDforcePreview"},
>> 76:                 (a) -> assertCommandOutputContains(a, "Function<Integer,Integer> f = (var i) -> i + i",
> 
> surprised to see these changes

similar as comment before `LAMBDA` is being removed but `VAR_SYNTAX_IMPLICIT_LAMBDAS` is still there

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

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

From ihse at openjdk.org  Mon Sep  5 19:03:43 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Sep 2022 19:03:43 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
Message-ID: <v9BzqpWDFfzrKXogcpmZ3vrkYRz64qyIqS7MFocJDqs=.48251132-76ed-4173-9d49-9441b467ae29@github.com>

On Thu, 1 Sep 2022 18:35:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Marked as reviewed by ihse (Reviewer).

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

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

From ihse at openjdk.org  Mon Sep  5 19:03:44 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Sep 2022 19:03:44 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
Message-ID: <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>

On Mon, 5 Sep 2022 16:33:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> make/common/JavaCompilation.gmk line 455:
>> 
>>> 453: 		$$(call LogWarn, Compiling up to $$(words $$($1_SRCS)) files for $1)
>>> 454: 		$$(eval $$(call ListPathsSafely, $1_SRCS, $$($1_FILELIST)))
>>> 455: 		$$(eval $1_MODFILES := $$?)
>> 
>> I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't.
>
>> I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't.
> 
> Hm, but `$$($1_SRCS)` contains all the source files of the given module, modified and unmodified, correct? The point of this patch is that we send the list of modified files to the `Depend` plugin (all sources are still passed to the javac invocation), and the plugin decides whether or not all files should be compiled, or only the modified files should be compiled.
> 
> The plugin could theoretically do the timestamp check from the sources, but it is more difficult to do, and the make has (presumably) already done that in a predictable way.
> 
> The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources.
> 
> Note that the modfiles are not sent to javac as such - all sources are still sent to javac. The modfiles are sent to the `Depend` plugin using a side channel.

Right, I confused `$?` and `$+`. You are of course correct, this is the way to get the changed targets. I had a bit of bad luck when I though about this. ?  (Theoretically, we could filter out anything that is not in `$1_SRCS` from `$?` but that seems to more work than is reasonable.)

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

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

From jlahoda at openjdk.org  Tue Sep  6 09:31:51 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 6 Sep 2022 09:31:51 GMT
Subject: Integrated: 8290561: Coalesce incubator-module warnings for
 single-file source-code programs
In-Reply-To: <ZGC5hjaFFTPuZaiVWumsbXyNnLw5lL9BoewWEwlubvc=.23a364c2-ef92-43e9-88af-88a8f34624b3@github.com>
References: <ZGC5hjaFFTPuZaiVWumsbXyNnLw5lL9BoewWEwlubvc=.23a364c2-ef92-43e9-88af-88a8f34624b3@github.com>
Message-ID: <YsMYa3EUVXIXY08DZsABX0BlWFqfsXKoruFAS6dyzPo=.f45dcc2a-0799-4103-9099-2fe6c2c04f80@github.com>

On Fri, 22 Jul 2022 06:58:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a trivial code like:
> 
> public class Main {
>      public static void main(String... args) {}
> }
> 
> 
> And an execution like:
> 
> $ java --add-modules jdk.incubator.concurrent Main.java 
> WARNING: Using incubator modules: jdk.incubator.concurrent
> warning: using incubating module(s): jdk.incubator.concurrent
> 1 warning
> 
> 
> Having two warnings (one from runtime, one from javac) seems unnecessary. The patch proposed herein tries to avoid the javac warning, keeping only the runtime one. The conditions under which an incubator module is ignored w.r.t. this warning are:
> 
>  * the boot Module layer has the module (hence, presumably, the runtime already provided the warning)
>  * the javac run is (likely) from the source launcher. This is being done using a custom javac option, `-XDsourceLauncher` (which can possibly be used in other cases).
> 
> This is to avoid cases where we would incorrectly suppress the incubator warning, e.g. when `-XDsourceLauncher` would be passed on the command line.
> 
> There are other ways to attempt to detect javac invocations from the source launcher - a distinct file manager is used by the source launcher (but detection of the specific file manager does not feel in line with general javac approach); or use of the `jdk.internal.javac.source` system property set by the native launcher (but this is only set when `--source` option is used, as far as I know, and javac also typically does not check system properties).
> 
> Note that there is JDK-8290563 to improve the text of the javac warning.

This pull request has now been integrated.

Changeset: 26f2a978
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26f2a978f6c601e677a236054be4ddc39d9b6e55
Stats:     102 lines in 3 files changed: 100 ins; 0 del; 2 mod

8290561: Coalesce incubator-module warnings for single-file source-code programs

Reviewed-by: mcimadamore

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

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

From asotona at openjdk.org  Tue Sep  6 12:25:24 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 12:25:24 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v15]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <b5mMEanymucbX0tCOED4m3GZJ9hOrDP_RsxQWl4s-hc=.3330a4a4-d1bc-4286-9edf-1c9c7f7fee7f@github.com>

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

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 9 more: https://git.openjdk.org/jdk/compare/6a1e98cb...4a7ce942

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

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

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

From erikj at openjdk.org  Tue Sep  6 13:21:58 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Sep 2022 13:21:58 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
 <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
Message-ID: <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>

On Mon, 5 Sep 2022 19:00:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> I think you really mean `$$($1_SRCS)` here, since the vardeps file is a build internal file that javac do not and should not care about. While I'm sure it will ignore it, the code here will be clearer if we don't pass it around when we shouldn't.
>> 
>> Hm, but `$$($1_SRCS)` contains all the source files of the given module, modified and unmodified, correct? The point of this patch is that we send the list of modified files to the `Depend` plugin (all sources are still passed to the javac invocation), and the plugin decides whether or not all files should be compiled, or only the modified files should be compiled.
>> 
>> The plugin could theoretically do the timestamp check from the sources, but it is more difficult to do, and the make has (presumably) already done that in a predictable way.
>> 
>> The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources.
>> 
>> Note that the modfiles are not sent to javac as such - all sources are still sent to javac. The modfiles are sent to the `Depend` plugin using a side channel.
>
> Right, I confused `$?` and `$+`. You are of course correct, this is the way to get the changed targets. I had a bit of bad luck when I though about this. ?  (Theoretically, we could filter out anything that is not in `$1_SRCS` from `$?` but that seems to more work than is reasonable.)

> The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources.

Ah, I had missed that and that's clever! That also means there is a reason to generate MODFILES in the actual compile recipe instead of the separate rule as I suggested earlier. For this to be "safe" we need `$$?` to really contain all the updated prereqs, otherwise we may miss compiling everything when something external actually should make us do just that.

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

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

From ihse at openjdk.org  Tue Sep  6 14:36:47 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Sep 2022 14:36:47 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
 <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
 <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>
Message-ID: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com>

On Tue, 6 Sep 2022 13:19:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Right, I confused `$?` and `$+`. You are of course correct, this is the way to get the changed targets. I had a bit of bad luck when I though about this. ?  (Theoretically, we could filter out anything that is not in `$1_SRCS` from `$?` but that seems to more work than is reasonable.)
>
>> The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources.
> 
> Ah, I had missed that and that's clever! That also means there is a reason to generate MODFILES in the actual compile recipe instead of the separate rule as I suggested earlier. For this to be "safe" we need `$$?` to really contain all the updated prereqs, otherwise we may miss compiling everything when something external actually should make us do just that.

... and also that we *must* include the vardeps file, since any change there should trigger a complete rebuild.

The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing?

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

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

From jlahoda at openjdk.org  Wed Sep  7 14:01:05 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Sep 2022 14:01:05 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v4]
In-Reply-To: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
Message-ID: <3Ql6LJMb5h5W9Cgu2zN7P1Vs1uxgw2wZ2YiLUXb1YME=.77a52ef2-ba28-401b-b672-8d0830e4246e@github.com>

> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
> 
> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
> -parsing only sources that were modified first,
> -computing an "API" hash for them,
> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
> 
> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
> 
> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
> 
> On my laptop, doing:
> 
> touch src/java.base/share/classes/java/lang/Object.java ; time make
> 
> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
> 
> The caveats of this patch include:
> -it is more involved than the existing plugin
> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently

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

  Adding comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10104/files
  - new: https://git.openjdk.org/jdk/pull/10104/files/23e3b756..6c1a83b2

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

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

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

From jlahoda at openjdk.org  Wed Sep  7 14:01:05 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Sep 2022 14:01:05 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
 <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
 <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>
 <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com>
Message-ID: <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com>

On Tue, 6 Sep 2022 14:33:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> The `Depend` plugin will do a full build if a non-Java file is present in the list, which I hope should lead to a more reliable recompilation for some complex changes among the sources.
>> 
>> Ah, I had missed that and that's clever! That also means there is a reason to generate MODFILES in the actual compile recipe instead of the separate rule as I suggested earlier. For this to be "safe" we need `$$?` to really contain all the updated prereqs, otherwise we may miss compiling everything when something external actually should make us do just that.
>
> ... and also that we *must* include the vardeps file, since any change there should trigger a complete rebuild.
> 
> The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing?

> ... and also that we _must_ include the vardeps file, since any change there should trigger a complete rebuild.
> 
> The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing?

How about:
https://github.com/openjdk/jdk/pull/10104/commits/6c1a83b28ee72a99bf24e7f66c96d1294ad485dd

Thanks,
    Jan

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

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

From cstein at openjdk.org  Wed Sep  7 15:17:53 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 7 Sep 2022 15:17:53 GMT
Subject: Integrated: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <k1uDsY_ME1eyOmdh6X8FPYC4Gu_VfA7DZh1o1BbPVGU=.dadd0e4b-5982-4786-988c-b2871d04a783@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

This pull request has now been integrated.

Changeset: 1ee59adc
Author:    Christian Stein <cstein at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ee59adcfead2128316556121c1711d308c7ea01
Stats:     11 lines in 8 files changed: 0 ins; 0 del; 11 mod

8289798: Update to use jtreg 7

Reviewed-by: ihse, jpai

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

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

From erikj at openjdk.org  Wed Sep  7 16:34:41 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 7 Sep 2022 16:34:41 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
 <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
 <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>
 <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com>
 <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com>
Message-ID: <y3jumYQCk7Um1vXW2QP8pf1utmxSi2gjsedCtF0g06Q=.8fe2ffea-2e32-4c40-8190-045a7036e091@github.com>

On Wed, 7 Sep 2022 13:57:45 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> ... and also that we *must* include the vardeps file, since any change there should trigger a complete rebuild.
>> 
>> The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing?
>
>> ... and also that we _must_ include the vardeps file, since any change there should trigger a complete rebuild.
>> 
>> The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing?
> 
> How about:
> https://github.com/openjdk/jdk/pull/10104/commits/6c1a83b28ee72a99bf24e7f66c96d1294ad485dd
> 
> Thanks,
>     Jan

To clarify my last post. The Main compile rule has this prereq declaration:


$$($1_COMPILE_TARGET): $$($1_SRCS) $$($1_FILELIST) $$($1_DEPENDS) \
        $$($1_VARDEPS_FILE) $$($1_EXTRA_DEPS) $$($1_JAVAC_SERVER_CONFIG)

The `$$($1_DEPENDS)` and `$$($1_EXTRA_DEPS)` may contain prereqs/dependencies that we probably should always recompile everything for. The EXTRA_DEPS is where we get the API changes from other modules. The DEPENDS variable is set by the caller and can be anything. Both of these are (deliberately) missing from the FILELIST generation rule, but I think MODFILES generation needs them. Because of this, I think the new MODFILES logic needs to move to the main compilation rule (like in your original patch) but the FILELIST rule should still be left alone.

We need to verify that this still gives us the expected speedup in the common case though. I'm not sure in what situations other dependencies may be included in `$?` here.

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

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

From vromero at openjdk.org  Wed Sep  7 18:25:45 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 7 Sep 2022 18:25:45 GMT
Subject: RFR: 8293348: A false cyclic inheritance error reported
In-Reply-To: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com>
References: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com>
Message-ID: <_WV9pihNcGLyTCGDd-iKbV7MdXGfKUObEOl_YTnsHM0=.56169e84-37da-47cf-9374-240710eba9f5@github.com>

On Mon, 5 Sep 2022 16:10:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these two classes:
> 
> non-sealed interface T2 extends T {}
> sealed interface T permits T2 {}
> 
> 
> With a bit non-standard set-up, it may happen that:
> - as part of `TypeEnter.HierarchyPhase`, `Check.checkNonCyclicInternal` is called for `T2`,
> - that will mark T2 as LOCKED, and call `checkNonCyclicInternal` for its supertype `T`, which is uncompleted,
> - `T` will be completed, so `TypeEnter.HierarchyPhase` will be called for it,
> - `TypeEnter.HierarchyPhase` for `T` will try to attribute the permitted types of `T`,
> - that will invoke `Check.checkNonCyclicInternal` for `T2` again,
> - but the class is already locked, and hence a cycle error is produced.
> 
> The proposed solution is to defer permitted type handling to a later point in time, specifically to the `HeaderPhase`. The `HierarchyPhase` should only handle the type hierarchy (i.e. the supertypes of a given type), and should not handle cycles. Hence the `HeaderPhase` seems like a better place to handle the permitted types, similarly to type variable bounds handling.
> 
> Setting `isPermittedExplicit` is moved to `Enter` - seems the value of the flag can be inferred easily from the AST node, and can simply be used later.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From dcubed at openjdk.org  Wed Sep  7 18:33:48 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 18:33:48 GMT
Subject: RFR: 8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java
 - launch timeout
In-Reply-To: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
References: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
Message-ID: <5xzd8QAs_3F876p7P8wYCFRmcN1_3PHE5imqj0u4df0=.a97d2a13-3edd-4b61-81ad-1e552cb15601@github.com>

On Fri, 26 Aug 2022 19:30:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor.
> Also cleaned up an incorrect comment.

Used the latest patch in my jdk-20+13 stress runs on linux-x64 and
macosx-aarch64 and there were no failures.

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

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

From dcubed at openjdk.org  Wed Sep  7 18:33:49 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 18:33:49 GMT
Subject: Integrated: 8207166:
 jdk/jshell/JdiHangingLaunchExecutionControlTest.java - launch timeout
In-Reply-To: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
References: <vKQpITdvl1L4S5St8QxZaO1Alp3ADbZmrHD2NKpcqAE=.60b9e77b-396f-4000-9da6-2949f59305b8@github.com>
Message-ID: <BZmpT2mi_bCB38NZ_6bUMHYNA3dWYn7p2fopPheXPps=.124c929b-d4af-4574-aec2-a1a520946d7e@github.com>

On Fri, 26 Aug 2022 19:30:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to scale time values for HangingRemoteAgent.java by JTREG timeoutFactor.
> Also cleaned up an incorrect comment.

This pull request has now been integrated.

Changeset: 02dce24b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02dce24b59ab53f00309a71ee94f45067c880b5c
Stats:     9 lines in 2 files changed: 3 ins; 0 del; 6 mod

8207166: jdk/jshell/JdiHangingLaunchExecutionControlTest.java - launch timeout

Reviewed-by: vromero

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

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

From ihse at openjdk.org  Thu Sep  8 09:43:44 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Sep 2022 09:43:44 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <y3jumYQCk7Um1vXW2QP8pf1utmxSi2gjsedCtF0g06Q=.8fe2ffea-2e32-4c40-8190-045a7036e091@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
 <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
 <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>
 <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com>
 <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com>
 <y3jumYQCk7Um1vXW2QP8pf1utmxSi2gjsedCtF0g06Q=.8fe2ffea-2e32-4c40-8190-045a7036e091@github.com>
Message-ID: <whppSAkhiMPR5je8cLJGQClVXj-Wrpp9jw-YIE-tfaw=.0042549c-dd6c-41a0-ac6d-76682f6d9248@github.com>

On Wed, 7 Sep 2022 16:30:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> ... and also that we _must_ include the vardeps file, since any change there should trigger a complete rebuild.
>>> 
>>> The logic here seems correct, but apparently somewhat hard to fully understand correctly. Maybe a few lines of comments summarizing the important points raised here would be a good thing?
>> 
>> How about:
>> https://github.com/openjdk/jdk/pull/10104/commits/6c1a83b28ee72a99bf24e7f66c96d1294ad485dd
>> 
>> Thanks,
>>     Jan
>
> To clarify my last post. The Main compile rule has this prereq declaration:
> 
> 
> $$($1_COMPILE_TARGET): $$($1_SRCS) $$($1_FILELIST) $$($1_DEPENDS) \
>         $$($1_VARDEPS_FILE) $$($1_EXTRA_DEPS) $$($1_JAVAC_SERVER_CONFIG)
> 
> The `$$($1_DEPENDS)` and `$$($1_EXTRA_DEPS)` may contain prereqs/dependencies that we probably should always recompile everything for. The EXTRA_DEPS is where we get the API changes from other modules. The DEPENDS variable is set by the caller and can be anything. Both of these are (deliberately) missing from the FILELIST generation rule, but I think MODFILES generation needs them. Because of this, I think the new MODFILES logic needs to move to the main compilation rule (like in your original patch) but the FILELIST rule should still be left alone.
> 
> We need to verify that this still gives us the expected speedup in the common case though. I'm not sure in what situations other dependencies may be included in `$?` here.

Actually, this is not an entirely correct description. EXTRA_DEPS points to the `depend` javac plugin itself in buildtools. Once built, this is unlikely to change. Dependency on the API changes themselves happen on a higher level, in `CompileJavaModules.gmk`, where we add a dependency of the outputted `pubapi` file for modules we depend on. 

(I did have to look this up, though)

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

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

From ihse at openjdk.org  Thu Sep  8 09:48:41 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Sep 2022 09:48:41 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <whppSAkhiMPR5je8cLJGQClVXj-Wrpp9jw-YIE-tfaw=.0042549c-dd6c-41a0-ac6d-76682f6d9248@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
 <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
 <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>
 <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com>
 <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com>
 <y3jumYQCk7Um1vXW2QP8pf1utmxSi2gjsedCtF0g06Q=.8fe2ffea-2e32-4c40-8190-045a7036e091@github.com>
 <whppSAkhiMPR5je8cLJGQClVXj-Wrpp9jw-YIE-tfaw=.0042549c-dd6c-41a0-ac6d-76682f6d9248@github.com>
Message-ID: <pyYueEJEeNINFS3EOzi4n6KWkr0aqvfrYaSRadFKbjk=.3f186688-edbf-4160-8b47-90693ca59fdd@github.com>

On Thu, 8 Sep 2022 09:40:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> To clarify my last post. The Main compile rule has this prereq declaration:
>> 
>> 
>> $$($1_COMPILE_TARGET): $$($1_SRCS) $$($1_FILELIST) $$($1_DEPENDS) \
>>         $$($1_VARDEPS_FILE) $$($1_EXTRA_DEPS) $$($1_JAVAC_SERVER_CONFIG)
>> 
>> The `$$($1_DEPENDS)` and `$$($1_EXTRA_DEPS)` may contain prereqs/dependencies that we probably should always recompile everything for. The EXTRA_DEPS is where we get the API changes from other modules. The DEPENDS variable is set by the caller and can be anything. Both of these are (deliberately) missing from the FILELIST generation rule, but I think MODFILES generation needs them. Because of this, I think the new MODFILES logic needs to move to the main compilation rule (like in your original patch) but the FILELIST rule should still be left alone.
>> 
>> We need to verify that this still gives us the expected speedup in the common case though. I'm not sure in what situations other dependencies may be included in `$?` here.
>
> Actually, this is not an entirely correct description. EXTRA_DEPS points to the `depend` javac plugin itself in buildtools. Once built, this is unlikely to change. Dependency on the API changes themselves happen on a higher level, in `CompileJavaModules.gmk`, where we add a dependency of the outputted `pubapi` file for modules we depend on. 
> 
> (I did have to look this up, though)

I looked up what kind of dependencies we are passing in through `DEPEND`. None, it turns out. It is not used. So that is not a worry. We might consider removing it. Sending in exceptional dependencies like that is never a good design decision. If it ever happens again that this would be the only acceptable solution, we can re-add the `DEPEND` argument.

But that basically mean that Jan's patch might be okay, after all. `DEPENDS` does not exist, and I want to remove it. `EXTRA_DEPS` is only modified if we change the `depend` javac plugin. I am willing to sacrifice automatic recompilation of all Java classes if that is changed.

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

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

From mcimadamore at openjdk.org  Thu Sep  8 13:04:48 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 Sep 2022 13:04:48 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
Message-ID: <oCSb7On3WWM1Nk-yaUSbh9MjkyPxMq534sOnKYeE4TQ=.f806313c-109e-4c45-820e-1ee67cc68d8b@github.com>

On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
>> 
>> TIA
>> 
>> [1] https://github.com/openjdk/jdk/pull/10074
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing additional test

Marked as reviewed by mcimadamore (Reviewer).

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

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

From mcimadamore at openjdk.org  Thu Sep  8 13:04:49 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 Sep 2022 13:04:49 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>
 <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com>
Message-ID: <FXaMGUF_vi6NcrAS4G67UoDMQsuxZFSXMSPPTJujn3c=.dc1437e2-61aa-4ce9-9b9e-81757c8bd672@github.com>

On Mon, 5 Sep 2022 18:19:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java line 31:
>> 
>>> 29: public interface HiddenInterface {
>>> 30:     default void test() {
>>> 31:         record R() {}
>> 
>> surprised to see this change
>
> this is was done because test: `test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java` is compiling this code with options `--enable-preview -source [latestSource] -XDforcePreview` and then checking that the obtained class file has 65535 as its minor version. This was working so far as `DEFAULT_METHODS` was one member of `com.sun.tools.javac.code.Source.Feature` but as this PR is removing `DEFAULT_METHODS` we are obtaining the same effect defining a record as `RECORDS` are still defined in `com.sun.tools.javac.code.Source.Feature`

I see. I understand what the fix does then.
I wonder if, moving forward, it wouldn't be better to tweak the semantics of forcePreview so that it always pollutes the classfile not matter what (which seems to be what some of the tests want). Otherwise we're stuck with these fragile tricks of using this or that feature to force javac's preview system into submission.

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

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

From erikj at openjdk.org  Thu Sep  8 13:58:51 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 8 Sep 2022 13:58:51 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <pyYueEJEeNINFS3EOzi4n6KWkr0aqvfrYaSRadFKbjk=.3f186688-edbf-4160-8b47-90693ca59fdd@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
 <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
 <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>
 <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com>
 <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com>
 <y3jumYQCk7Um1vXW2QP8pf1utmxSi2gjsedCtF0g06Q=.8fe2ffea-2e32-4c40-8190-045a7036e091@github.com>
 <whppSAkhiMPR5je8cLJGQClVXj-Wrpp9jw-YIE-tfaw=.0042549c-dd6c-41a0-ac6d-76682f6d9248@github.com>
 <pyYueEJEeNINFS3EOzi4n6KWkr0aqvfrYaS
 RadFKbjk=.3f186688-edbf-4160-8b47-90693ca59fdd@github.com>
Message-ID: <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com>

On Thu, 8 Sep 2022 09:45:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Actually, this is not an entirely correct description. EXTRA_DEPS points to the `depend` javac plugin itself in buildtools. Once built, this is unlikely to change. Dependency on the API changes themselves happen on a higher level, in `CompileJavaModules.gmk`, where we add a dependency of the outputted `pubapi` file for modules we depend on. 
>> 
>> (I did have to look this up, though)
>
> I looked up what kind of dependencies we are passing in through `DEPEND`. None, it turns out. It is not used. So that is not a worry. We might consider removing it. Sending in exceptional dependencies like that is never a good design decision. If it ever happens again that this would be the only acceptable solution, we can re-add the `DEPEND` argument.
> 
> But that basically mean that Jan's patch might be okay, after all. `DEPENDS` does not exist, and I want to remove it. `EXTRA_DEPS` is only modified if we change the `depend` javac plugin. I am willing to sacrifice automatic recompilation of all Java classes if that is changed.

Ok I was wrong about what EXTRA_DEPS was used for, I read the code too hastily. However, the dependency declaration for the pubapi files from other modules is added in make/CompileJavaModules.gmk like this:


$($(MODULE)_COMPILE_TARGET): $(foreach d, $(call FindDepsForModule, $(MODULE)), \
    $(call SetupJavaCompilationApiTarget, $d, \
        $(if $($d_BIN), $($d_BIN), $(JDK_OUTPUTDIR)/modules/$d)))


So this still doesn't change my main point. The pubapi files only appear on the dependency declaration for `$($(MODULE)_COMPILE_TARGET)`. This means that with the current patch, we will not recompile the full module when a parent module has a change to the pubapi. The Depend plugin needs to see the pubapi files in `$$?` for that to happen.

One could also make the case for using DEPEND when adding such a dependency instead of referencing `$($(MODULE)_COMPILE_TARGET)` in explicit rules. It would be more inline with more recent design patterns.

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

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

From jlahoda at openjdk.org  Thu Sep  8 14:14:28 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 8 Sep 2022 14:14:28 GMT
Subject: Integrated: 8293348: A false cyclic inheritance error reported
In-Reply-To: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com>
References: <5IbdolUE2I9yTGPYe8boTCfTnvYdBJgvabKQb_hISCM=.9d0e3783-39d7-4358-a14a-1eb12754eed4@github.com>
Message-ID: <oVbD7JcV6SXEy0xltCUAh1I96PbdrhfuCbJornDjlCU=.9eee412b-cd37-42af-b3a3-46a8b83f3380@github.com>

On Mon, 5 Sep 2022 16:10:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these two classes:
> 
> non-sealed interface T2 extends T {}
> sealed interface T permits T2 {}
> 
> 
> With a bit non-standard set-up, it may happen that:
> - as part of `TypeEnter.HierarchyPhase`, `Check.checkNonCyclicInternal` is called for `T2`,
> - that will mark T2 as LOCKED, and call `checkNonCyclicInternal` for its supertype `T`, which is uncompleted,
> - `T` will be completed, so `TypeEnter.HierarchyPhase` will be called for it,
> - `TypeEnter.HierarchyPhase` for `T` will try to attribute the permitted types of `T`,
> - that will invoke `Check.checkNonCyclicInternal` for `T2` again,
> - but the class is already locked, and hence a cycle error is produced.
> 
> The proposed solution is to defer permitted type handling to a later point in time, specifically to the `HeaderPhase`. The `HierarchyPhase` should only handle the type hierarchy (i.e. the supertypes of a given type), and should not handle cycles. Hence the `HeaderPhase` seems like a better place to handle the permitted types, similarly to type variable bounds handling.
> 
> Setting `isPermittedExplicit` is moved to `Enter` - seems the value of the flag can be inferred easily from the AST node, and can simply be used later.

This pull request has now been integrated.

Changeset: c0ee30a2
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0ee30a25abda2f93806bbfaf940ba8638b864bf
Stats:     110 lines in 3 files changed: 64 ins; 44 del; 2 mod

8293348: A false cyclic inheritance error reported

Reviewed-by: vromero

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

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

From vromero at openjdk.org  Thu Sep  8 14:24:52 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 Sep 2022 14:24:52 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <FXaMGUF_vi6NcrAS4G67UoDMQsuxZFSXMSPPTJujn3c=.dc1437e2-61aa-4ce9-9b9e-81757c8bd672@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>
 <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com>
 <FXaMGUF_vi6NcrAS4G67UoDMQsuxZFSXMSPPTJujn3c=.dc1437e2-61aa-4ce9-9b9e-81757c8bd672@github.com>
Message-ID: <ulo5n5x6SyQpzCXRN7-uMC9soHdTEovoS3R0Zvb7jxQ=.a9a6622d-3aca-4842-bace-7ca47a6a069d@github.com>

On Thu, 8 Sep 2022 13:02:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> this is was done because test: `test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java` is compiling this code with options `--enable-preview -source [latestSource] -XDforcePreview` and then checking that the obtained class file has 65535 as its minor version. This was working so far as `DEFAULT_METHODS` was one member of `com.sun.tools.javac.code.Source.Feature` but as this PR is removing `DEFAULT_METHODS` we are obtaining the same effect defining a record as `RECORDS` are still defined in `com.sun.tools.javac.code.Source.Feature`
>
> I see. I understand what the fix does then.
> I wonder if, moving forward, it wouldn't be better to tweak the semantics of forcePreview so that it always pollutes the classfile not matter what (which seems to be what some of the tests want). Otherwise we're stuck with these fragile tricks of using this or that feature to force javac's preview system into submission.

yes that would be a sensible change going forward. Thanks for the review

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

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

From vromero at openjdk.org  Thu Sep  8 14:39:05 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 Sep 2022 14:39:05 GMT
Subject: Integrated: 8293051: Further refactor javac after removal of
 -source/-target/--release 7
In-Reply-To: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
Message-ID: <nvLLOO0-QOz-Nf2gZV2-CQ5hwKJxhqxscVhGDUInY8s=.3f56391c-8f44-45e3-99f0-ab7607c085a3@github.com>

On Fri, 2 Sep 2022 21:11:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
> 
> TIA
> 
> [1] https://github.com/openjdk/jdk/pull/10074

This pull request has now been integrated.

Changeset: 46e6e41b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46e6e41b9a35c8665eb31be2f8c36bbdcc90564a
Stats:     256 lines in 22 files changed: 11 ins; 198 del; 47 mod

8293051: Further refactor javac after removal of -source/-target/--release 7

Reviewed-by: darcy, mcimadamore

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

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

From jlahoda at openjdk.org  Thu Sep  8 16:54:16 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 8 Sep 2022 16:54:16 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
Message-ID: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>

Consider this snippet sent to JShell:

interface I {
    void test() {
        try {
        } catch (IllegalStateException ex) {
            throw new RuntimeException(ex);
        }
    }
}


This leads to a crash:

Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
        at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
        at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
        at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
        at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
        at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
        at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
        at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
        at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
        at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
        at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
        at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
        at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
        at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
        at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
        ... 18 more
Caused by: java.lang.StackOverflowError
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
...


The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.

The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

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

Commit messages:
 - 8292755: Non-default method in interface leads to a stack overflow in JShell

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

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

From jlahoda at openjdk.org  Fri Sep  9 11:41:08 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 9 Sep 2022 11:41:08 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v5]
In-Reply-To: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
Message-ID: <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>

> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
> 
> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
> -parsing only sources that were modified first,
> -computing an "API" hash for them,
> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
> 
> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
> 
> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
> 
> On my laptop, doing:
> 
> touch src/java.base/share/classes/java/lang/Object.java ; time make
> 
> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
> 
> The caveats of this patch include:
> -it is more involved than the existing plugin
> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently

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

  Regenerating modfiles as necessary.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10104/files
  - new: https://git.openjdk.org/jdk/pull/10104/files/6c1a83b2..c3455660

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

  Stats: 26 lines in 2 files changed: 14 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10104.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10104/head:pull/10104

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

From jlahoda at openjdk.org  Fri Sep  9 11:41:08 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 9 Sep 2022 11:41:08 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
 <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
 <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>
 <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com>
 <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com>
 <y3jumYQCk7Um1vXW2QP8pf1utmxSi2gjsedCtF0g06Q=.8fe2ffea-2e32-4c40-8190-045a7036e091@github.com>
 <whppSAkhiMPR5je8cLJGQClVXj-Wrpp9jw-YIE-tfaw=.0042549c-dd6c-41a0-ac6d-76682f6d9248@github.com>
 <pyYueEJEeNINFS3EOzi4n6KWkr0aqvfrYaS
 RadFKbjk=.3f186688-edbf-4160-8b47-90693ca59fdd@github.com>
 <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com>
Message-ID: <RHyTyGswJ8WjxzKR_aIB4gNbKsbg1w7_-gxuf5lyvE8=.67ad0720-b088-4b7c-b29d-1ed6f6752c75@github.com>

On Thu, 8 Sep 2022 13:54:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I looked up what kind of dependencies we are passing in through `DEPEND`. None, it turns out. It is not used. So that is not a worry. We might consider removing it. Sending in exceptional dependencies like that is never a good design decision. If it ever happens again that this would be the only acceptable solution, we can re-add the `DEPEND` argument.
>> 
>> But that basically mean that Jan's patch might be okay, after all. `DEPENDS` does not exist, and I want to remove it. `EXTRA_DEPS` is only modified if we change the `depend` javac plugin. I am willing to sacrifice automatic recompilation of all Java classes if that is changed.
>
> Ok I was wrong about what EXTRA_DEPS was used for, I read the code too hastily. However, the dependency declaration for the pubapi files from other modules is added in make/CompileJavaModules.gmk like this:
> 
> 
> $($(MODULE)_COMPILE_TARGET): $(foreach d, $(call FindDepsForModule, $(MODULE)), \
>     $(call SetupJavaCompilationApiTarget, $d, \
>         $(if $($d_BIN), $($d_BIN), $(JDK_OUTPUTDIR)/modules/$d)))
> 
> 
> So this still doesn't change my main point. The pubapi files only appear on the dependency declaration for `$($(MODULE)_COMPILE_TARGET)`. This means that with the current patch, we will not recompile the full module when a parent module has a change to the pubapi. The Depend plugin needs to see the pubapi files in `$$?` for that to happen.
> 
> One could also make the case for using DEPEND when adding such a dependency instead of referencing `$($(MODULE)_COMPILE_TARGET)` in explicit rules. It would be more inline with more recent design patterns.

Hmm, how about this?
https://github.com/openjdk/jdk/pull/10104/commits/c3455660310bea8a33b1b5b5cb05c792f5d825a2

that seems to work (hopefully), although I am not sure if that is not breaking some overall concept in the build.

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

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

From ihse at openjdk.org  Fri Sep  9 11:54:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Sep 2022 11:54:59 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v5]
In-Reply-To: <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
Message-ID: <UvbyKifvBWNo0u0H4w8KmAuhHF3V7KdFYWuLFR9AaIk=.4f084193-8d95-4ce2-8a92-52b73b5355b6@github.com>

On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Regenerating modfiles as necessary.

I think this looks good now. But this is apparently tricky business, with the three of us taking turns of thinking wrongly about this. :-) Let's hear what Erik has to say, too.

Have you verified that it still does the correct things in cases like:
1) only non-visible changes in individual files
2) visible-changes in individual files
3) changes in a dependent module
4) changes in javac setup, like an added Xlint option
5) and some combinations, where I think 1+3 is most relevant

?

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

Marked as reviewed by ihse (Reviewer).

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

From ihse at openjdk.org  Fri Sep  9 11:57:24 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Sep 2022 11:57:24 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v3]
In-Reply-To: <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <uLEz-6at4sazGrYWK5g0x3wFwGaL1R8iIdztLFIU7GI=.cc703821-f05a-4847-96de-b01b965876cf@github.com>
 <jObGOX_STe069gJtIARYQTltVHfZGMwAdC0zCtZXUO0=.c0c5a04b-c473-4dcb-90da-285a5eb9c4f1@github.com>
 <cieFNrW0X9ZlT6e9t1kn8x8ipS1Qd61yBW74c7oNWsQ=.1bc35d76-e9fc-4440-9530-03de9abe1f96@github.com>
 <nP0MHQFmHiQP6_7skM-CIgORS5k1DJCmFCyBh6uVZvI=.a3fb36d8-324b-4b11-a1fc-abba1c829708@github.com>
 <H6lNws6FD5Ykzdz_NxPvRfseeLQUM3b52vto7-UyrQY=.2c5299d4-7332-4ae6-b82b-efeb9491dd9e@github.com>
 <7dAhNO5mWFrXDyXHt9f0OMlqm2bX2Vhd_5CI249Kfvg=.8c3d28fd-33ee-4ed8-8ac1-3931dc662b4d@github.com>
 <2Ydq_U6pRtbb4j599bntLHrU6flD6fnVHneJPT0dFR0=.7790df14-d894-489a-a8f0-6f4d2a120c37@github.com>
 <y3jumYQCk7Um1vXW2QP8pf1utmxSi2gjsedCtF0g06Q=.8fe2ffea-2e32-4c40-8190-045a7036e091@github.com>
 <whppSAkhiMPR5je8cLJGQClVXj-Wrpp9jw-YIE-tfaw=.0042549c-dd6c-41a0-ac6d-76682f6d9248@github.com>
 <pyYueEJEeNINFS3EOzi4n6KWkr0aqvfrYaS
 RadFKbjk=.3f186688-edbf-4160-8b47-90693ca59fdd@github.com>
 <57sDT_S9CdpZiKrmXZkv7bsCrVrPMWuSbyuIyFs0ikM=.7a5ea89b-3a23-4887-9b2d-fc62db60dd0e@github.com>
Message-ID: <RmhLx-KjJ5dWfsA3kBGrsyQ-fBQR6dnqPdJd_EQpG8Y=.447a1938-dee3-4aea-ad61-3f7aa927f389@github.com>

On Thu, 8 Sep 2022 13:54:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I looked up what kind of dependencies we are passing in through `DEPEND`. None, it turns out. It is not used. So that is not a worry. We might consider removing it. Sending in exceptional dependencies like that is never a good design decision. If it ever happens again that this would be the only acceptable solution, we can re-add the `DEPEND` argument.
>> 
>> But that basically mean that Jan's patch might be okay, after all. `DEPENDS` does not exist, and I want to remove it. `EXTRA_DEPS` is only modified if we change the `depend` javac plugin. I am willing to sacrifice automatic recompilation of all Java classes if that is changed.
>
> Ok I was wrong about what EXTRA_DEPS was used for, I read the code too hastily. However, the dependency declaration for the pubapi files from other modules is added in make/CompileJavaModules.gmk like this:
> 
> 
> $($(MODULE)_COMPILE_TARGET): $(foreach d, $(call FindDepsForModule, $(MODULE)), \
>     $(call SetupJavaCompilationApiTarget, $d, \
>         $(if $($d_BIN), $($d_BIN), $(JDK_OUTPUTDIR)/modules/$d)))
> 
> 
> So this still doesn't change my main point. The pubapi files only appear on the dependency declaration for `$($(MODULE)_COMPILE_TARGET)`. This means that with the current patch, we will not recompile the full module when a parent module has a change to the pubapi. The Depend plugin needs to see the pubapi files in `$$?` for that to happen.
> 
> One could also make the case for using DEPEND when adding such a dependency instead of referencing `$($(MODULE)_COMPILE_TARGET)` in explicit rules. It would be more inline with more recent design patterns.

@erikj79 I agree that setting DEPEND would be better. I hate those weird "injection attacks" where we fake arguments to functions, they make the code hopeless to understand (and I'd like to forbid them in `NamedParamsMacroTemplate`, but I can't just now since we still use it in so many places).

But can we really do that? I don't think we have that dependency information available when setting up the module java compilation. (In any case, that is a separate cleanup)

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

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

From erikj at openjdk.org  Fri Sep  9 12:54:58 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Sep 2022 12:54:58 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v5]
In-Reply-To: <UvbyKifvBWNo0u0H4w8KmAuhHF3V7KdFYWuLFR9AaIk=.4f084193-8d95-4ce2-8a92-52b73b5355b6@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
 <UvbyKifvBWNo0u0H4w8KmAuhHF3V7KdFYWuLFR9AaIk=.4f084193-8d95-4ce2-8a92-52b73b5355b6@github.com>
Message-ID: <2klNmfZaHNi5XGjGR5tMYM2IQK7QjCNxDve9TkH28JE=.3348ee36-5172-4b7e-8a6d-57a146f76039@github.com>

On Fri, 9 Sep 2022 11:51:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I think this looks good now. But this is apparently tricky business, with the three of us taking turns of thinking wrongly about this. :-) Let's hear what Erik has to say, too.
> 
> Have you verified that it still does the correct things in cases like:
> 
> 1. only non-visible changes in individual files
> 2. visible-changes in individual files
> 3. changes in a dependent module
> 4. changes in javac setup, like an added Xlint option
> 5. and some combinations, where I think 1+3 is most relevant
> 
> ?

This is indeed tricky business, and I thank you for hanging in there while we figure it out. It's certainly much better to discover and rethink at the review stage than in followup bugs. I think this solution is good, pending confirmation that you tried all the cases Magnus listed.

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

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

From erikj at openjdk.org  Fri Sep  9 12:54:59 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Sep 2022 12:54:59 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v5]
In-Reply-To: <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
Message-ID: <OZQW05KOOnW3cdldGoi2j3JblRK8Jwd4YkN7jXV0F1I=.d04b53d2-00c5-4a94-b1ad-145762fc3d71@github.com>

On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Regenerating modfiles as necessary.

make/common/JavaCompilation.gmk line 466:

> 464:     # it will be considered to be a significant change, and all module source will
> 465:     # be recompiled
> 466:     $$($1_MODFILELIST):  $$($1_SRCS) $$($1_DEPENDS) \

Looks like an extra space snuck in, otherwise this seems good.

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

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

From abimpoudis at openjdk.org  Fri Sep  9 15:11:14 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 9 Sep 2022 15:11:14 GMT
Subject: RFR: 8291657: Javac assertion when compiling a method call with switch
 expression as argument
Message-ID: <tEl5O10qyAL3r-Efyg5UdhIpfo9lPAFGRGWw5cietEc=.af98a422-ca22-418b-8b06-7cdc337620aa@github.com>

The following crashes on `Gen` when emitting code at `visitYield`.

        return (B) switch (o) {
            default -> new A();
        };

Why? Because the `yield` is retyped in `TransTypes` to `(B) new A()` and during `visitYield` in `Gen.java`, there is a check that essentially says: check the last type and assert if its a super-type of the current type.

That retype in `TransTypes` is exercised in one test regarding intersection types.

Now, if I write a redundant cast:

        return (B) (A) switch (o) {
            default -> new A();
        };

it works. because the `Yield` is not retyped. This PR translates the cases with the correct prototype (of the type of the switch itself -- `A` in the aforementioned examples).

WDYT?

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

Commit messages:
 - 8291657: Javac assertion when compiling a method call with switch expression as argument

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

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

From vromero at openjdk.org  Mon Sep 12 15:17:50 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Sep 2022 15:17:50 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
Message-ID: <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com>

On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this snippet sent to JShell:
> 
> interface I {
>     void test() {
>         try {
>         } catch (IllegalStateException ex) {
>             throw new RuntimeException(ex);
>         }
>     }
> }
> 
> 
> This leads to a crash:
> 
> Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>         at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
>         at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
>         at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
>         at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>         at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
>         ... 18 more
> Caused by: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
> ...
> 
> 
> The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.
> 
> The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output

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

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

From jlahoda at openjdk.org  Mon Sep 12 20:37:51 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 Sep 2022 20:37:51 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v5]
In-Reply-To: <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
Message-ID: <1_kz64sRf3r7tV6hbGwag-ytgM_HJJ0nZn1XFP5rFJE=.4a60b3c4-6f62-4a73-9793-cac777f4a2a9@github.com>

On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Regenerating modfiles as necessary.

I ran some tests (in a semi-automated fashion), results seem reasonable:

## Non-API change in java.base:

sed -e 's/^}//* */}/' <src/java.base/share/classes/java/lang/Object.java.orig >src/java.base/share/classes/java/lang/Object.java
time make


result:

Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
Compiling up to 3192 files for java.base
[stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: false, non-Java modified files: 
Stopping sjavac server
Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'

real	0m3,414s
user	0m5,188s
sys	0m1,328s


## Non-API change in java.compiler:

sed -e 's/^}//* */}/' <src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java.orig >src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
time make


result:

Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
Compiling up to 127 files for BUILD_java.compiler.interim
Compiling up to 127 files for java.compiler
[stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: false, non-Java modified files: 
Stopping sjavac server
Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'

real	0m15,530s
user	0m22,948s
sys	0m2,337s


## Package-private method added to java.base:

sed -e 's/^}/static void testMethod() {} }/' <src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java.orig >src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
time make


result:

Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
Compiling up to 3192 files for java.base
[stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: 
Optimizing the exploded image
Stopping sjavac server
Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'

real	0m30,190s
user	0m6,852s
sys	0m1,548s


## Package-private method added to java.compiler:

sed -e 's/^}/static void testMethod() {} }/' <src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java.orig >src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
time make | tee -a test-output


result:

Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
Compiling up to 127 files for BUILD_java.compiler.interim
Compiling up to 127 files for java.compiler
[stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: 
Optimizing the exploded image
Stopping sjavac server
Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'

real	0m17,368s
user	0m23,831s
sys	0m2,328s


## Public method added to java.base:


sed -e 's/^}//** test. */public static void testMethod() {} }/' <src/java.base/share/classes/java/lang/Object.java.orig >src/java.base/share/classes/java/lang/Object.java
time make


result:

Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
Compiling up to 3192 files for java.base
[stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: 
[stderr] compiling module: java.datatransfer, all Java inputs: 18, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.instrument, all Java inputs: 10, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.logging, all Java inputs: 35, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.scripting, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.net.http, all Java inputs: 142, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.management, all Java inputs: 330, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.transaction.xa, all Java inputs: 5, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.smartcardio, all Java inputs: 22, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.internal.jvmstat, all Java inputs: 61, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.zipfs, all Java inputs: 14, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.charsets, all Java inputs: 120, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.crypto.ec, all Java inputs: 35, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.xml, all Java inputs: 1848, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.internal.ed, all Java inputs: 3, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.dynalink, all Java inputs: 68, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.httpserver, all Java inputs: 60, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.incubator.concurrent, all Java inputs: 4, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.internal.opt, all Java inputs: 51, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.incubator.vector, all Java inputs: 50, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.internal.le, all Java inputs: 103, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jartool, all Java inputs: 31, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.internal.vm.ci, all Java inputs: 203, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.management, all Java inputs: 24, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jdwp.agent, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jfr, all Java inputs: 260, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jsobject, all Java inputs: 4, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.net, all Java inputs: 9, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.nio.mapmode, all Java inputs: 2, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.random, all Java inputs: 11, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.sctp, all Java inputs: 33, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.unsupported, all Java inputs: 9, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.security.sasl, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.rmi, all Java inputs: 106, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.attach, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.crypto.cryptoki, all Java inputs: 76, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.internal.vm.compiler, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.localedata, all Java inputs: 1838, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.internal.vm.compiler.management, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jcmd, all Java inputs: 40, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.compiler, all Java inputs: 413, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jstatd, all Java inputs: 11, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jdi, all Java inputs: 254, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.management.jfr, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.naming, all Java inputs: 198, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.naming.dns, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.naming.rmi, all Java inputs: 8, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.management.rmi, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.security.jgss, all Java inputs: 212, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.sql, all Java inputs: 77, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.prefs, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.xml.dom, all Java inputs: 94, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.xml.crypto, all Java inputs: 271, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.management.agent, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.sql.rowset, all Java inputs: 56, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.security.jgss, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.security.auth, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jdeps, all Java inputs: 139, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jshell, all Java inputs: 97, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.javadoc, all Java inputs: 243, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jlink, all Java inputs: 90, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.desktop, all Java inputs: 2769, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: java.se, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.unsupported.desktop, all Java inputs: 8, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.editpad, all Java inputs: 3, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.accessibility, all Java inputs: 18, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jconsole, all Java inputs: 64, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.jpackage, all Java inputs: 57, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
[stderr] compiling module: jdk.hotspot.agent, all Java inputs: 940, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
Optimizing the exploded image
Stopping sjavac server
Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'

real    1m27,775s
user    0m52,536s
sys     0m7,856s


## Public method added to java.compiler:


sed -e 's/^}//** test. */public static void testMethod() {} }/' <src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java.orig >src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
time make


result:

Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
Compiling up to 127 files for BUILD_java.compiler.interim
Compiling up to 127 files for java.compiler
[stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: 
[stderr] compiling module: java.se, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
[stderr] compiling module: jdk.compiler, all Java inputs: 413, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
[stderr] compiling module: jdk.jdeps, all Java inputs: 139, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
[stderr] compiling module: jdk.jshell, all Java inputs: 97, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
[stderr] compiling module: jdk.javadoc, all Java inputs: 243, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
Optimizing the exploded image
Stopping sjavac server
Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'

real    0m36,685s
user    0m30,044s
sys     0m3,273s


## Error in a newly added added public method to java.base:


sed -e 's/^}/public static void testMethod() {} }/' <src/java.base/share/classes/java/lang/Object.java.orig >src/java.base/share/classes/java/lang/Object.java
time make
git diff src/java.base/share/classes/java/lang/Object.java | patch -R -p1
sed -e 's/^}//** test. */public static void testMethod() {} }/' <src/java.base/share/classes/java/lang/Object.java.orig >src/java.base/share/classes/java/lang/Object.java
echo Fixed:
time make


result:

Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
Compiling up to 3192 files for java.base
[stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files:

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

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

From erikj at openjdk.org  Mon Sep 12 21:03:44 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 12 Sep 2022 21:03:44 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v5]
In-Reply-To: <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
Message-ID: <igR1LhD1YDVzrL3c8bGaGzDUXsuKMfrRNuGuw8wq30g=.acfe54ba-b477-4fbb-b3e6-9a636f344175@github.com>

On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Regenerating modfiles as necessary.

This looks good to me now. Thank you for fixing this!

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

Marked as reviewed by erikj (Reviewer).

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

From jlahoda at openjdk.org  Tue Sep 13 09:31:12 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 13 Sep 2022 09:31:12 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
 <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com>
Message-ID: <ykq4IhuxXqh45UBQ9sBBptSA-aYnXxsZPJPyh6vpgY8=.76e66f44-2fdb-4cd2-b43c-1499edef7e74@github.com>

On Mon, 12 Sep 2022 15:15:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output

Yes, there may be some more error generated (if the body is erroneous), but I don't see it as a big problem: the errors are there, and when the user adds the `default` keyword (or removes a wrong keyword), the errors will show anyway. To me, it is not clear that a broken modifier is a problem big enough to stop attributing the body - there are many other problems that we find during the attribution of the method header that will not stop method body attribution. Like:


$ cat Test.java 
public interface Test {
    default void test(Unknown1 t) {
        Unknown2 tt;
    }
}
$ javac Test.java 
Test.java:2: error: cannot find symbol
    default void test(Unknown1 t) {
                      ^
  symbol:   class Unknown1
  location: interface Test
Test.java:3: error: cannot find symbol
        Unknown2 tt;
        ^
  symbol:   class Unknown2
  location: interface Test
2 errors


I am a bit worried that generating more stub data will lead only to a whack-a-mole trying to cover all corner cases where the stub data are not good enough, while simply letting the attribution proceed should cover the cases as it does for normal methods.

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

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

From ihse at openjdk.org  Tue Sep 13 11:23:47 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Sep 2022 11:23:47 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v5]
In-Reply-To: <1_kz64sRf3r7tV6hbGwag-ytgM_HJJ0nZn1XFP5rFJE=.4a60b3c4-6f62-4a73-9793-cac777f4a2a9@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <wnEdNb9IPyGFvXwex04cCDbAs_hvPOVyKowSlH5SlEI=.a08d97cb-e74d-4da5-87f8-9b8d53a7ca3e@github.com>
 <1_kz64sRf3r7tV6hbGwag-ytgM_HJJ0nZn1XFP5rFJE=.4a60b3c4-6f62-4a73-9793-cac777f4a2a9@github.com>
Message-ID: <ur3ZAxMqWjibvcYJuzVj9H5JnCevHiMzG3qIcd9Xx68=.a7efe1b0-2179-4913-9f3d-adf5143e7a36@github.com>

On Mon, 12 Sep 2022 20:35:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Regenerating modfiles as necessary.
>
> I ran some tests (in a semi-automated fashion), results seem reasonable:
> 
> ## Non-API change in java.base:
> 
> sed -e 's/^}//* */}/' <src/java.base/share/classes/java/lang/Object.java.orig >src/java.base/share/classes/java/lang/Object.java
> time make
> 
> 
> result:
> 
> Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> Compiling up to 3192 files for java.base
> [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: false, non-Java modified files: 
> Stopping sjavac server
> Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> 
> real	0m3,414s
> user	0m5,188s
> sys	0m1,328s
> 
> 
> ## Non-API change in java.compiler:
> 
> sed -e 's/^}//* */}/' <src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java.orig >src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
> time make
> 
> 
> result:
> 
> Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> Compiling up to 127 files for BUILD_java.compiler.interim
> Compiling up to 127 files for java.compiler
> [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: false, non-Java modified files: 
> Stopping sjavac server
> Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> 
> real	0m15,530s
> user	0m22,948s
> sys	0m2,337s
> 
> 
> ## Package-private method added to java.base:
> 
> sed -e 's/^}/static void testMethod() {} }/' <src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java.orig >src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
> time make
> 
> 
> result:
> 
> Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> Compiling up to 3192 files for java.base
> [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: 
> Optimizing the exploded image
> Stopping sjavac server
> Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> 
> real	0m30,190s
> user	0m6,852s
> sys	0m1,548s
> 
> 
> ## Package-private method added to java.compiler:
> 
> sed -e 's/^}/static void testMethod() {} }/' <src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java.orig >src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
> time make | tee -a test-output
> 
> 
> result:
> 
> Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> Compiling up to 127 files for BUILD_java.compiler.interim
> Compiling up to 127 files for java.compiler
> [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: 
> Optimizing the exploded image
> Stopping sjavac server
> Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> 
> real	0m17,368s
> user	0m23,831s
> sys	0m2,328s
> 
> 
> ## Public method added to java.base:
> 
> 
> sed -e 's/^}//** test. */public static void testMethod() {} }/' <src/java.base/share/classes/java/lang/Object.java.orig >src/java.base/share/classes/java/lang/Object.java
> time make
> 
> 
> result:
> 
> Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> Compiling up to 3192 files for java.base
> [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: 
> [stderr] compiling module: java.datatransfer, all Java inputs: 18, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.instrument, all Java inputs: 10, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.logging, all Java inputs: 35, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.scripting, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.net.http, all Java inputs: 142, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.management, all Java inputs: 330, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.transaction.xa, all Java inputs: 5, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.smartcardio, all Java inputs: 22, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.internal.jvmstat, all Java inputs: 61, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.zipfs, all Java inputs: 14, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.charsets, all Java inputs: 120, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.crypto.ec, all Java inputs: 35, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.xml, all Java inputs: 1848, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.internal.ed, all Java inputs: 3, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.dynalink, all Java inputs: 68, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.httpserver, all Java inputs: 60, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.incubator.concurrent, all Java inputs: 4, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.internal.opt, all Java inputs: 51, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.incubator.vector, all Java inputs: 50, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.internal.le, all Java inputs: 103, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jartool, all Java inputs: 31, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.internal.vm.ci, all Java inputs: 203, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.management, all Java inputs: 24, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jdwp.agent, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jfr, all Java inputs: 260, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jsobject, all Java inputs: 4, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.net, all Java inputs: 9, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.nio.mapmode, all Java inputs: 2, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.random, all Java inputs: 11, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.sctp, all Java inputs: 33, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.unsupported, all Java inputs: 9, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.security.sasl, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.rmi, all Java inputs: 106, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.attach, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.crypto.cryptoki, all Java inputs: 76, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.internal.vm.compiler, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.localedata, all Java inputs: 1838, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.internal.vm.compiler.management, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jcmd, all Java inputs: 40, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.compiler, all Java inputs: 413, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jstatd, all Java inputs: 11, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jdi, all Java inputs: 254, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.management.jfr, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.naming, all Java inputs: 198, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.naming.dns, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.naming.rmi, all Java inputs: 8, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.management.rmi, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.security.jgss, all Java inputs: 212, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.sql, all Java inputs: 77, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.prefs, all Java inputs: 15, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.xml.dom, all Java inputs: 94, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.xml.crypto, all Java inputs: 271, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.management.agent, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.sql.rowset, all Java inputs: 56, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.security.jgss, all Java inputs: 16, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.security.auth, all Java inputs: 30, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jdeps, all Java inputs: 139, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jshell, all Java inputs: 97, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.javadoc, all Java inputs: 243, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jlink, all Java inputs: 90, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.desktop, all Java inputs: 2769, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: java.se, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.unsupported.desktop, all Java inputs: 8, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.editpad, all Java inputs: 3, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.accessibility, all Java inputs: 18, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jconsole, all Java inputs: 64, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.jpackage, all Java inputs: 57, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> [stderr] compiling module: jdk.hotspot.agent, all Java inputs: 940, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_pubapi
> Optimizing the exploded image
> Stopping sjavac server
> Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> 
> real    1m27,775s
> user    0m52,536s
> sys     0m7,856s
> 
> 
> ## Public method added to java.compiler:
> 
> 
> sed -e 's/^}//** test. */public static void testMethod() {} }/' <src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java.orig >src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
> time make
> 
> 
> result:
> 
> Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> Compiling up to 127 files for BUILD_java.compiler.interim
> Compiling up to 127 files for java.compiler
> [stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: 
> [stderr] compiling module: java.se, all Java inputs: 1, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
> [stderr] compiling module: jdk.compiler, all Java inputs: 413, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
> [stderr] compiling module: jdk.jdeps, all Java inputs: 139, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
> [stderr] compiling module: jdk.jshell, all Java inputs: 97, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
> [stderr] compiling module: jdk.javadoc, all Java inputs: 243, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/jdk/modules/java.compiler/_the.java.compiler_pubapi
> Optimizing the exploded image
> Stopping sjavac server
> Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> 
> real    0m36,685s
> user    0m30,044s
> sys     0m3,273s
> 
> 
> ## Error in a newly added added public method to java.base:
> 
> 
> sed -e 's/^}/public static void testMethod() {} }/' <src/java.base/share/classes/java/lang/Object.java.orig >src/java.base/share/classes/java/lang/Object.java
> time make
> git diff src/java.base/share/classes/java/lang/Object.java | patch -R -p1
> sed -e 's/^}//** test. */public static void testMethod() {} }/' <src/java.base/share/classes/java/lang/Object.java.orig >src/java.base/share/classes/java/lang/Object.java
> echo Fixed:
> time make
> 
> 
> result:
> 
> Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> Compiling up to 3192 files for java.base
> [stderr] compiling module: java.base, all Java inputs: 3192, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files:

@lahodaj The `[stderr] compiling module: java.compiler, all Java inputs: 127, modified files (Java or non-Java): 1, full recompile: true, non-Java modified files: ` lines look very nice for debugging. How did you get these? Could you make it so that they are always turned on if `$LOG_LEVEL` is `DEBUG` or `TRACE`?

Otherwise, I'm satisfied with your results.

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

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

From jlahoda at openjdk.org  Tue Sep 13 13:09:50 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 13 Sep 2022 13:09:50 GMT
Subject: RFR: 8291657: Javac assertion when compiling a method call with
 switch expression as argument
In-Reply-To: <tEl5O10qyAL3r-Efyg5UdhIpfo9lPAFGRGWw5cietEc=.af98a422-ca22-418b-8b06-7cdc337620aa@github.com>
References: <tEl5O10qyAL3r-Efyg5UdhIpfo9lPAFGRGWw5cietEc=.af98a422-ca22-418b-8b06-7cdc337620aa@github.com>
Message-ID: <YmShLjHYOlg2D3uoVoKGvZS6PJaerH59Al4FbGJ3AVI=.670a0542-a3f2-40de-9291-206f02f77e69@github.com>

On Fri, 9 Sep 2022 15:04:13 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The following crashes on `Gen` when emitting code at `visitYield`.
> 
>         return (B) switch (o) {
>             default -> new A();
>         };
> 
> Why? Because the `yield` is retyped in `TransTypes` to `(B) new A()` and during `visitYield` in `Gen.java`, there is a check that essentially says: check the last type and assert if its a super-type of the current type.
> 
> That retype in `TransTypes` is exercised in one test regarding intersection types.
> 
> Now, if I write a redundant cast:
> 
>         return (B) (A) switch (o) {
>             default -> new A();
>         };
> 
> it works. because the `Yield` is not retyped. This PR translates the cases with the correct prototype (of the type of the switch itself -- `A` in the aforementioned examples).
> 
> WDYT?

Seems reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From vromero at openjdk.org  Tue Sep 13 13:44:00 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 13 Sep 2022 13:44:00 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
Message-ID: <6_eEE5ZIEpezCdN-BuYozkoq9B-Hl8cNKYmSj_LX6Z0=.43ad170e-854f-4c7a-addf-c3f21344a766@github.com>

On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this snippet sent to JShell:
> 
> interface I {
>     void test() {
>         try {
>         } catch (IllegalStateException ex) {
>             throw new RuntimeException(ex);
>         }
>     }
> }
> 
> 
> This leads to a crash:
> 
> Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>         at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
>         at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
>         at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
>         at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>         at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
>         ... 18 more
> Caused by: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
> ...
> 
> 
> The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.
> 
> The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.org  Tue Sep 13 13:44:00 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 13 Sep 2022 13:44:00 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <ykq4IhuxXqh45UBQ9sBBptSA-aYnXxsZPJPyh6vpgY8=.76e66f44-2fdb-4cd2-b43c-1499edef7e74@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
 <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com>
 <ykq4IhuxXqh45UBQ9sBBptSA-aYnXxsZPJPyh6vpgY8=.76e66f44-2fdb-4cd2-b43c-1499edef7e74@github.com>
Message-ID: <Lr-Tsx6OA9Hwqg1zfeIeL9ysShpNxnA8EP1sQ2p32fs=.d134a4c3-081b-460c-af57-52a796dc3bfa@github.com>

On Tue, 13 Sep 2022 09:27:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output
> 
> Yes, there may be some more error generated (if the body is erroneous), but I don't see it as a big problem: the errors are there, and when the user adds the `default` keyword (or removes a wrong keyword), the errors will show anyway. To me, it is not clear that a broken modifier is a problem big enough to stop attributing the body - there are many other problems that we find during the attribution of the method header that will not stop method body attribution. Like:
> 
> ```
> $ cat Test.java 
> public interface Test {
>     default void test(Unknown1 t) {
>         Unknown2 tt;
>     }
> }
> $ javac Test.java 
> Test.java:2: error: cannot find symbol
>     default void test(Unknown1 t) {
>                       ^
>   symbol:   class Unknown1
>   location: interface Test
> Test.java:3: error: cannot find symbol
>         Unknown2 tt;
>         ^
>   symbol:   class Unknown2
>   location: interface Test
> 2 errors
> ```
> 
> I am a bit worried that generating more stub data will lead only to a whack-a-mole trying to cover all corner cases where the stub data are not good enough, while simply letting the attribution proceed should cover the cases as it does for normal methods.

I see your point, totally agree

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

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

From darcy at openjdk.org  Wed Sep 14 01:33:02 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 14 Sep 2022 01:33:02 GMT
Subject: RFR: JDK-8293768: Add links to JLS 19 and 20 from SourceVersion enum
 constants
Message-ID: <yvXo2wJ_PASmhXlsyLD-VUT-feuuV_Dcv_A0ZhpzIsY=.70c1d1d8-8f68-4851-b7c3-6cf2cd389649@github.com>

Originally, I was only going to add a link to JLS 19 for when the docs for Java SE 19 went live, but at time of writing the JLS 19 link goes to the specifications landing page rather than giving a 404. Therefore, adding links to both JLS 19 and 20 know aren't dead links per se and will become better links as the JLS 19 and 20 pages are published in the future.

When the resolved JLS-version-specific links resolving the specification home page, the future I'll add the link to the specific JLS version when I add a new SourceVersion constant.

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

Commit messages:
 - JDK-8293768: Add links to JLS 19 and 20 from SourceVersion enum constants

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

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

From iris at openjdk.org  Wed Sep 14 03:33:19 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 14 Sep 2022 03:33:19 GMT
Subject: RFR: JDK-8293768: Add links to JLS 19 and 20 from SourceVersion
 enum constants
In-Reply-To: <yvXo2wJ_PASmhXlsyLD-VUT-feuuV_Dcv_A0ZhpzIsY=.70c1d1d8-8f68-4851-b7c3-6cf2cd389649@github.com>
References: <yvXo2wJ_PASmhXlsyLD-VUT-feuuV_Dcv_A0ZhpzIsY=.70c1d1d8-8f68-4851-b7c3-6cf2cd389649@github.com>
Message-ID: <TDSe9vRs3sKbGfszUxGspRCFuEWYKt911QejSdQgqeU=.50c44e75-b994-4ae0-9ee7-f490d135667a@github.com>

On Wed, 14 Sep 2022 01:24:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Originally, I was only going to add a link to JLS 19 for when the docs for Java SE 19 went live, but at time of writing the JLS 19 link goes to the specifications landing page rather than giving a 404. Therefore, adding links to both JLS 19 and 20 know aren't dead links per se and will become better links as the JLS 19 and 20 pages are published in the future.
> 
> When the resolved JLS-version-specific links resolving the specification home page, the future I'll add the link to the specific JLS version when I add a new SourceVersion constant.

Links look good assuming current pattern of link names.  Specification landing page rather than 404 verified.

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

Marked as reviewed by iris (Reviewer).

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

From abimpoudis at openjdk.org  Wed Sep 14 06:51:11 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 14 Sep 2022 06:51:11 GMT
Subject: Integrated: 8291657: Javac assertion when compiling a method call with
 switch expression as argument
In-Reply-To: <tEl5O10qyAL3r-Efyg5UdhIpfo9lPAFGRGWw5cietEc=.af98a422-ca22-418b-8b06-7cdc337620aa@github.com>
References: <tEl5O10qyAL3r-Efyg5UdhIpfo9lPAFGRGWw5cietEc=.af98a422-ca22-418b-8b06-7cdc337620aa@github.com>
Message-ID: <-qRwj7KzoqifZsoPPSY9y9aG-4UtuT51K7p6DC6OJjs=.ea676483-08de-4646-a4a3-010d964866ee@github.com>

On Fri, 9 Sep 2022 15:04:13 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The following crashes on `Gen` when emitting code at `visitYield`.
> 
>         return (B) switch (o) {
>             default -> new A();
>         };
> 
> Why? Because the `yield` is retyped in `TransTypes` to `(B) new A()` and during `visitYield` in `Gen.java`, there is a check that essentially says: check the last type and assert if its a super-type of the current type.
> 
> That retype in `TransTypes` is exercised in one test regarding intersection types.
> 
> Now, if I write a redundant cast:
> 
>         return (B) (A) switch (o) {
>             default -> new A();
>         };
> 
> it works. because the `Yield` is not retyped. This PR translates the cases with the correct prototype (of the type of the switch itself -- `A` in the aforementioned examples).
> 
> WDYT?

This pull request has now been integrated.

Changeset: 1169a159
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1169a1593660242375400e9d6b9ca11a872cdf02
Stats:     46 lines in 2 files changed: 45 ins; 0 del; 1 mod

8291657: Javac assertion when compiling a method call with switch expression as argument

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.org  Wed Sep 14 08:53:32 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Sep 2022 08:53:32 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
Message-ID: <EwvsUISxXJN2tifqc7y6rR9kM719wnMOzdxKd56Ef58=.4f2fa3e7-baaf-4019-966f-ecf3d6c1c759@github.com>

On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this snippet sent to JShell:
> 
> interface I {
>     void test() {
>         try {
>         } catch (IllegalStateException ex) {
>             throw new RuntimeException(ex);
>         }
>     }
> }
> 
> 
> This leads to a crash:
> 
> Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>         at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
>         at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
>         at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
>         at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>         at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
>         ... 18 more
> Caused by: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
> ...
> 
> 
> The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.
> 
> The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

Thanks, Vicente!

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

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

From jlahoda at openjdk.org  Wed Sep 14 08:53:33 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Sep 2022 08:53:33 GMT
Subject: Integrated: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
Message-ID: <htAaWqklZM-EENEx9IruqFGP-xGfKBfHnce63sZWZcE=.802ffb2c-190f-40f1-936c-b868a8051bd9@github.com>

On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this snippet sent to JShell:
> 
> interface I {
>     void test() {
>         try {
>         } catch (IllegalStateException ex) {
>             throw new RuntimeException(ex);
>         }
>     }
> }
> 
> 
> This leads to a crash:
> 
> Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>         at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
>         at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
>         at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
>         at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>         at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
>         ... 18 more
> Caused by: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
> ...
> 
> 
> The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.
> 
> The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

This pull request has now been integrated.

Changeset: 2a387918
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a3879180e63aa0a7a19479f061fe78d7885da7b
Stats:     194 lines in 3 files changed: 185 ins; 8 del; 1 mod

8292755: Non-default method in interface leads to a stack overflow in JShell

Reviewed-by: vromero

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

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

From asotona at openjdk.org  Wed Sep 14 11:10:15 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Sep 2022 11:10:15 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v16]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <C_FYdM2XDe98ShJRXMXZq3m7kyt30HOhvleFxV8hK4E=.cbb2971e-a4de-4d51-af0a-5e6bc3628081@github.com>

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

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5

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

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

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

From asotona at openjdk.org  Wed Sep 14 11:25:38 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Sep 2022 11:25:38 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v16]
In-Reply-To: <C_FYdM2XDe98ShJRXMXZq3m7kyt30HOhvleFxV8hK4E=.cbb2971e-a4de-4d51-af0a-5e6bc3628081@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <C_FYdM2XDe98ShJRXMXZq3m7kyt30HOhvleFxV8hK4E=.cbb2971e-a4de-4d51-af0a-5e6bc3628081@github.com>
Message-ID: <7HAZTQI9U8tr8hrc3uRhkeAnZU4yjyjVDhTB2vXd00E=.69ffd410-c37e-45ec-b812-69bf4a2782ea@github.com>

On Wed, 14 Sep 2022 11:10:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
>  - Added man-page line about lossy-conversion lint
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - 8244681: Add a warning for possibly lossy conversion in compound assignments
>    re-enabled warnings for java.base, java.rmi and java.smartcardio
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5

Please review also linked Release Note issue.

Thanks,
Adam

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

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

From asotona at openjdk.org  Wed Sep 14 11:35:03 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Sep 2022 11:35:03 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v17]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <k9Qdyal0bxpvBIXY0gfBLch7SG9PO7LjV5zNhQumCWQ=.34d833b1-fe0d-481b-bb40-59b154689842@github.com>

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

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  re-enabled lossy-conversions warnings for jdk.hotspot.agent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8599/files
  - new: https://git.openjdk.org/jdk/pull/8599/files/4b78b1c5..0b93c284

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15-16

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

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

From jlahoda at openjdk.org  Wed Sep 14 17:26:28 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Sep 2022 17:26:28 GMT
Subject: RFR: 8293578: Duplicate ldc generated by javac
Message-ID: <or47I7XjErVxRCwyqJXy0uey_wnNdcqAqkHmZ-RCh5g=.ba5902ef-6502-48c4-82aa-841d67e95571@github.com>

Consider code like:

var testC = "incorrect".getClass();
var testV = testC.getConstructor(String.class)
                           .newInstance("correct");
System.err.println(testV);


javac has a concept of types with attached constants (to support proper behavior of constant expressions). Normally, these constants are cleared as specific places. But, in the above case, the type of `testC` is actually `Class<? extends String["incorrect"]>`, the constant then gets propagated, and eventually the type of `testV` is `String["incorrect"]`, and the code generator will then replace reads from `testV` with a ldc for the constant, so the code above prints "incorrect" instead of "correct".

The solution is to invoke `.baseType()` to remove the constant value when constructing the synthetic `.getClass()`'s type (so the type of `testC` is `Class<? extends String>`), and also a tweak to `checkLocalVarType`, as suggested in the bug.

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

Commit messages:
 - 8293578: Duplicate ldc generated by javac

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

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

From jjg at openjdk.org  Wed Sep 14 21:02:00 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 14 Sep 2022 21:02:00 GMT
Subject: RFR: JDK-8293768: Add links to JLS 19 and 20 from SourceVersion
 enum constants
In-Reply-To: <yvXo2wJ_PASmhXlsyLD-VUT-feuuV_Dcv_A0ZhpzIsY=.70c1d1d8-8f68-4851-b7c3-6cf2cd389649@github.com>
References: <yvXo2wJ_PASmhXlsyLD-VUT-feuuV_Dcv_A0ZhpzIsY=.70c1d1d8-8f68-4851-b7c3-6cf2cd389649@github.com>
Message-ID: <ImwI48qqft4gMwtCDmHZuUfsq7gwhgJHB_Yx1fg2gf4=.df494c7c-20b5-45b6-a2bd-960709be7b13@github.com>

On Wed, 14 Sep 2022 01:24:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Originally, I was only going to add a link to JLS 19 for when the docs for Java SE 19 went live, but at time of writing the JLS 19 link goes to the specifications landing page rather than giving a 404. Therefore, adding links to both JLS 19 and 20 know aren't dead links per se and will become better links as the JLS 19 and 20 pages are published in the future.
> 
> When the resolved JLS-version-specific links resolving the specification home page, the future I'll add the link to the specific JLS version when I add a new SourceVersion constant.

Marked as reviewed by jjg (Reviewer).

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

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

From darcy at openjdk.org  Wed Sep 14 21:06:59 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 14 Sep 2022 21:06:59 GMT
Subject: Integrated: JDK-8293768: Add links to JLS 19 and 20 from SourceVersion
 enum constants
In-Reply-To: <yvXo2wJ_PASmhXlsyLD-VUT-feuuV_Dcv_A0ZhpzIsY=.70c1d1d8-8f68-4851-b7c3-6cf2cd389649@github.com>
References: <yvXo2wJ_PASmhXlsyLD-VUT-feuuV_Dcv_A0ZhpzIsY=.70c1d1d8-8f68-4851-b7c3-6cf2cd389649@github.com>
Message-ID: <3ckzOTvwx6_q1oKmLoTUtSozvHb0gxgo9nxEth4tVic=.7c37aa65-0e0e-4b05-8de5-6e714e3445e7@github.com>

On Wed, 14 Sep 2022 01:24:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Originally, I was only going to add a link to JLS 19 for when the docs for Java SE 19 went live, but at time of writing the JLS 19 link goes to the specifications landing page rather than giving a 404. Therefore, adding links to both JLS 19 and 20 know aren't dead links per se and will become better links as the JLS 19 and 20 pages are published in the future.
> 
> When the resolved JLS-version-specific links resolving the specification home page, the future I'll add the link to the specific JLS version when I add a new SourceVersion constant.

This pull request has now been integrated.

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

8293768: Add links to JLS 19 and 20 from SourceVersion enum constants

Reviewed-by: iris, jjg

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

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

From asotona at openjdk.org  Thu Sep 15 10:12:53 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Sep 2022 10:12:53 GMT
Subject: Integrated: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <z-bQGuu0bN_VqBmdbjUEkFe7TyQXUo47sVNnCXKvuvU=.23ec3739-9d31-484d-a296-11d5991ed934@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: aff5ff14
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aff5ff14b208b3c2be93d7b4fab8b07c5be12f3e
Stats:     438 lines in 13 files changed: 437 ins; 0 del; 1 mod

8244681: Add a warning for possibly lossy conversion in compound assignments
8293797: Release Note: Javac warns about type casts in compound assignments with possible lossy conversions

Reviewed-by: erikj, prr

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

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

From mcimadamore at openjdk.org  Thu Sep 15 15:14:45 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 Sep 2022 15:14:45 GMT
Subject: RFR: 8293578: Duplicate ldc generated by javac
In-Reply-To: <or47I7XjErVxRCwyqJXy0uey_wnNdcqAqkHmZ-RCh5g=.ba5902ef-6502-48c4-82aa-841d67e95571@github.com>
References: <or47I7XjErVxRCwyqJXy0uey_wnNdcqAqkHmZ-RCh5g=.ba5902ef-6502-48c4-82aa-841d67e95571@github.com>
Message-ID: <iifZ5vEF41ogjEXjRsoO3HNZxuHWMAPkc-tCMJ5AWOA=.42c56089-5f2f-478f-90d2-7ea3a0f2080e@github.com>

On Wed, 14 Sep 2022 17:15:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> var testC = "incorrect".getClass();
> var testV = testC.getConstructor(String.class)
>                            .newInstance("correct");
> System.err.println(testV);
> 
> 
> javac has a concept of types with attached constants (to support proper behavior of constant expressions). Normally, these constants are cleared as specific places. But, in the above case, the type of `testC` is actually `Class<? extends String["incorrect"]>`, the constant then gets propagated, and eventually the type of `testV` is `String["incorrect"]`, and the code generator will then replace reads from `testV` with a ldc for the constant, so the code above prints "incorrect" instead of "correct".
> 
> The solution is to invoke `.baseType()` to remove the constant value when constructing the synthetic `.getClass()`'s type (so the type of `testC` is `Class<? extends String>`), and also a tweak to `checkLocalVarType`, as suggested in the bug.

Looks good

test/langtools/tools/javac/lvti/ConstantTypes.java line 99:

> 97:     }
> 98: 
> 99: }

watch out for newline

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

Marked as reviewed by mcimadamore (Reviewer).

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

From jlahoda at openjdk.org  Fri Sep 16 11:40:54 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 Sep 2022 11:40:54 GMT
Subject: Integrated: 8293578: Duplicate ldc generated by javac
In-Reply-To: <or47I7XjErVxRCwyqJXy0uey_wnNdcqAqkHmZ-RCh5g=.ba5902ef-6502-48c4-82aa-841d67e95571@github.com>
References: <or47I7XjErVxRCwyqJXy0uey_wnNdcqAqkHmZ-RCh5g=.ba5902ef-6502-48c4-82aa-841d67e95571@github.com>
Message-ID: <11S5hoLQKE-AseV4bFiL_X9SLeTgF4Hvf3Zv0dPmFBM=.f8f471a8-f336-4fcd-88c5-c517accdda9a@github.com>

On Wed, 14 Sep 2022 17:15:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> var testC = "incorrect".getClass();
> var testV = testC.getConstructor(String.class)
>                            .newInstance("correct");
> System.err.println(testV);
> 
> 
> javac has a concept of types with attached constants (to support proper behavior of constant expressions). Normally, these constants are cleared as specific places. But, in the above case, the type of `testC` is actually `Class<? extends String["incorrect"]>`, the constant then gets propagated, and eventually the type of `testV` is `String["incorrect"]`, and the code generator will then replace reads from `testV` with a ldc for the constant, so the code above prints "incorrect" instead of "correct".
> 
> The solution is to invoke `.baseType()` to remove the constant value when constructing the synthetic `.getClass()`'s type (so the type of `testC` is `Class<? extends String>`), and also a tweak to `checkLocalVarType`, as suggested in the bug.

This pull request has now been integrated.

Changeset: 39cd1635
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39cd1635bf07f42857e1a704734db66b2c2fa882
Stats:     103 lines in 3 files changed: 99 ins; 0 del; 4 mod

8293578: Duplicate ldc generated by javac

Reviewed-by: mcimadamore

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

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

From jai.forums2013 at gmail.com  Mon Sep 19 13:44:59 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 19 Sep 2022 19:14:59 +0530
Subject: Better error message instead of "record header expected"?
Message-ID: <b81f291b-612b-55c0-95f5-08931a23dd9d@gmail.com>

Please consider this trivial code:

public record Record {

}

Trying to compile this results in:

javac Record.java

Record.java:1: error: record header expected

public record Record {
 ????????? ^

1 error

It isn't too clear what that error message means. It took me a while to 
realize that I had missed using the () after the record's name. Changing 
the source to:

public record Record() {

}

is what the error was trying to convey. Could this error message be 
improved?

By the way, notice that the error message was pointing to the "r" letter 
of the "record" keyword with the ^ sign. Is that right place for this 
error or should it have been after the "d" of the "Record" name, similar 
to what appears to be reported for constructors of classes, for example:

public class Event {
 ?? ?public Event {

 ?? ?}
}

javac Event.java

Event.java:2: error: <identifier> expected
 ?? ?public Event {
 ????????????????????? ^
1 error

(not sure if mail clients will preserve the spacing - that ^ appears 
between the "t" and the "{")

-Jaikiran


From vicente.romero at oracle.com  Mon Sep 19 14:28:07 2022
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 19 Sep 2022 10:28:07 -0400
Subject: Better error message instead of "record header expected"?
In-Reply-To: <b81f291b-612b-55c0-95f5-08931a23dd9d@gmail.com>
References: <b81f291b-612b-55c0-95f5-08931a23dd9d@gmail.com>
Message-ID: <c97ccdb1-0bcb-64cf-0ebc-8f5d44cec583@oracle.com>

Hi Jaikiran,

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

Thanks,
Vicente

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

On 9/19/22 09:44, Jaikiran Pai wrote:
> Please consider this trivial code:
>
> public record Record {
>
> }
>
> Trying to compile this results in:
>
> javac Record.java
>
> Record.java:1: error: record header expected
>
> public record Record {
> ????????? ^
>
> 1 error
>
> It isn't too clear what that error message means. It took me a while 
> to realize that I had missed using the () after the record's name. 
> Changing the source to:
>
> public record Record() {
>
> }
>
> is what the error was trying to convey. Could this error message be 
> improved?
>
> By the way, notice that the error message was pointing to the "r" 
> letter of the "record" keyword with the ^ sign. Is that right place 
> for this error or should it have been after the "d" of the "Record" 
> name, similar to what appears to be reported for constructors of 
> classes, for example:
>
> public class Event {
> ?? ?public Event {
>
> ?? ?}
> }
>
> javac Event.java
>
> Event.java:2: error: <identifier> expected
> ?? ?public Event {
> ????????????????????? ^
> 1 error
>
> (not sure if mail clients will preserve the spacing - that ^ appears 
> between the "t" and the "{")
>
> -Jaikiran
>


From ethan at mccue.dev  Mon Sep 19 16:58:40 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 19 Sep 2022 12:58:40 -0400
Subject: Better error message instead of "record header expected"?
In-Reply-To: <c97ccdb1-0bcb-64cf-0ebc-8f5d44cec583@oracle.com>
References: <b81f291b-612b-55c0-95f5-08931a23dd9d@gmail.com>
 <c97ccdb1-0bcb-64cf-0ebc-8f5d44cec583@oracle.com>
Message-ID: <CA+NR86hzJivhFDjdcVGepGg9rcT4wUhj-J4r2kTXSGE3XnnFZA@mail.gmail.com>

Ideally, the error message could be something like

    error[E0123]: record header expected
     --> src/Record.java:1:20
      |
    1 |     public record Record {
      |                         ^ record header required here
      |
    help: to make a record with no components, use an empty header
      |
    1 | public record Record() {
      |

    For more information about this error, try `javac --explain E0123`.

I'm sorry that I haven't had my life in enough of a line to make that full
proposal though.

On Mon, Sep 19, 2022 at 10:29 AM Vicente Romero <vicente.romero at oracle.com>
wrote:

> Hi Jaikiran,
>
> Thanks for the report, I have filed [1] to track this issue,
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.org/browse/JDK-8294020
>
> On 9/19/22 09:44, Jaikiran Pai wrote:
> > Please consider this trivial code:
> >
> > public record Record {
> >
> > }
> >
> > Trying to compile this results in:
> >
> > javac Record.java
> >
> > Record.java:1: error: record header expected
> >
> > public record Record {
> >           ^
> >
> > 1 error
> >
> > It isn't too clear what that error message means. It took me a while
> > to realize that I had missed using the () after the record's name.
> > Changing the source to:
> >
> > public record Record() {
> >
> > }
> >
> > is what the error was trying to convey. Could this error message be
> > improved?
> >
> > By the way, notice that the error message was pointing to the "r"
> > letter of the "record" keyword with the ^ sign. Is that right place
> > for this error or should it have been after the "d" of the "Record"
> > name, similar to what appears to be reported for constructors of
> > classes, for example:
> >
> > public class Event {
> >     public Event {
> >
> >     }
> > }
> >
> > javac Event.java
> >
> > Event.java:2: error: <identifier> expected
> >     public Event {
> >                       ^
> > 1 error
> >
> > (not sure if mail clients will preserve the spacing - that ^ appears
> > between the "t" and the "{")
> >
> > -Jaikiran
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220919/cfbcaa4b/attachment-0001.htm>

From jlahoda at openjdk.org  Mon Sep 19 18:20:34 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 Sep 2022 18:20:34 GMT
Subject: RFR: 8292756: java.lang.AssertionError at at
 jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)
Message-ID: <kB6JRzKm1_pyldevhGyrVsiizT9jKNuTYfF2L_BVlZA=.2e078af9-ebf2-4bb2-8cd8-1af3e2fbcca8@github.com>

Consider code like:

public class JDK_8292756 {
    private int test(Object o) {
        int i1, i2, i3, i4, i5, i6, i7;
        return switch(o) {
            case Object oo when oo != null -> 0;
            default -> 0;
        };
    }
}


Compiling this leads to a crash:

$ javac --enable-preview -source 19 /tmp/JDK_8292756.java 
Note: /tmp/JDK_8292756.java uses preview features of Java SE 19.
Note: Recompile with -Xlint:preview for details.
An exception has occurred in the compiler (19-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError
        at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
        at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
        at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5621)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5512)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5336)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5275)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)
printing javac parameters to: /tmp/javac.20220919_200140.args


The reason for the failure is this: in `Attr.handleSwitch`, there is an input scope `env`, and a sub-scope of it, `switchEnv`, is created for the switch. Eventually, another (shared) sub-scope is created for the guard expression, `bodyEnv`. All `env`, `switchEnv` and `bodyEnv` share an internal table. But, the `bodyEnv` sub-scope is created from `env`, not from `switchEnv` (as it should). Which mostly works, but if the internal table for `bodyEnv` is resized, it will correctly fix only `env`, but not `switchEnv`.

The solution to this problem is to simply base the `bodyEnv` on `switchEnv`, not on `env`. But, in addition to that, it does not seem right the scopes don't protect from an accident like this. So the proposed patch here is enhancing the assertions in `Scope` so that a shared duplicate of a Scope can only be done from a leaf Scope.

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

Commit messages:
 - 8292756: java.lang.AssertionError at at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)

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

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

From jlahoda at openjdk.org  Mon Sep 19 18:37:20 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 Sep 2022 18:37:20 GMT
Subject: RFR: 8293897: Synthetic final modifier is part of the AST for a
 try-with-resource resource
Message-ID: <YRq0IVFziI7GSX7wV1kjvSGRSr7XyXVaR-lR99wUhMU=.01b85674-8205-4320-8716-9679b22e415f@github.com>

The resources in try-with-resource are implicitly final (unless they are marked as final in the source code). But, in javac, the `FINAL` modifier is part of the modifiers on the AST, which is in contrary to the usual direction of having the AST closely model the source code.

The proposal here is to not add the synthetic `FINAL` modifier to the AST, but add it to the given `VarSymbol`. The positions of the `ModifiersTree` are also tweaked, so that for a synthetic tree, the positions are `NOPOS`.

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

Commit messages:
 - 8293897: Final modifier auto inserted as part of try with resources statement

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

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

From vicente.romero at oracle.com  Mon Sep 19 19:12:45 2022
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 19 Sep 2022 15:12:45 -0400
Subject: [External] : Re: Better error message instead of "record header
 expected"?
In-Reply-To: <CA+NR86hzJivhFDjdcVGepGg9rcT4wUhj-J4r2kTXSGE3XnnFZA@mail.gmail.com>
References: <b81f291b-612b-55c0-95f5-08931a23dd9d@gmail.com>
 <c97ccdb1-0bcb-64cf-0ebc-8f5d44cec583@oracle.com>
 <CA+NR86hzJivhFDjdcVGepGg9rcT4wUhj-J4r2kTXSGE3XnnFZA@mail.gmail.com>
Message-ID: <9b7d70b9-46fe-158c-3e84-4fee031e3add@oracle.com>

thanks for your proposal, the final version will probably be a bit 
shorter but this one could be a good start

Vicente

On 9/19/22 12:58, Ethan McCue wrote:
> Ideally, the error message could be something like
>
> ? ? error[E0123]: record header expected
> ? ? ?--> src/Record.java:1:20
> ? ? ? |
> ? ? 1 | ? ? public record Record {
> ? ? ? | ? ?^ record header required here
> ? ? ? |
> ? ? help: to make a record with no components, use an empty header
> ? ? ? |
> ? ? 1 | public record Record() {
> ? ? ? |
>
> ? ? For more information about this error, try `javac --explain E0123`.
>
> I'm sorry that I haven't had my life in enough of a line to make that 
> full proposal though.
>
> On Mon, Sep 19, 2022 at 10:29 AM Vicente Romero 
> <vicente.romero at oracle.com> wrote:
>
>     Hi Jaikiran,
>
>     Thanks for the report, I have filed [1] to track this issue,
>
>     Thanks,
>     Vicente
>
>     [1] https://bugs.openjdk.org/browse/JDK-8294020
>
>     On 9/19/22 09:44, Jaikiran Pai wrote:
>     > Please consider this trivial code:
>     >
>     > public record Record {
>     >
>     > }
>     >
>     > Trying to compile this results in:
>     >
>     > javac Record.java
>     >
>     > Record.java:1: error: record header expected
>     >
>     > public record Record {
>     > ????????? ^
>     >
>     > 1 error
>     >
>     > It isn't too clear what that error message means. It took me a
>     while
>     > to realize that I had missed using the () after the record's name.
>     > Changing the source to:
>     >
>     > public record Record() {
>     >
>     > }
>     >
>     > is what the error was trying to convey. Could this error message be
>     > improved?
>     >
>     > By the way, notice that the error message was pointing to the "r"
>     > letter of the "record" keyword with the ^ sign. Is that right place
>     > for this error or should it have been after the "d" of the "Record"
>     > name, similar to what appears to be reported for constructors of
>     > classes, for example:
>     >
>     > public class Event {
>     > ?? ?public Event {
>     >
>     > ?? ?}
>     > }
>     >
>     > javac Event.java
>     >
>     > Event.java:2: error: <identifier> expected
>     > ?? ?public Event {
>     > ????????????????????? ^
>     > 1 error
>     >
>     > (not sure if mail clients will preserve the spacing - that ^
>     appears
>     > between the "t" and the "{")
>     >
>     > -Jaikiran
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220919/c3680abc/attachment-0001.htm>

From jlahoda at openjdk.org  Tue Sep 20 09:50:00 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Sep 2022 09:50:00 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v6]
In-Reply-To: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
Message-ID: <u4sgCqn71TkHVLzGYnbvh1ZgFbEHaCakr9BJJlUykMQ=.08bdae4d-6491-44e3-b327-b6fd9262c9bf@github.com>

> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
> 
> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
> -parsing only sources that were modified first,
> -computing an "API" hash for them,
> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
> 
> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
> 
> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
> 
> On my laptop, doing:
> 
> touch src/java.base/share/classes/java/lang/Object.java ; time make
> 
> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
> 
> The caveats of this patch include:
> -it is more involved than the existing plugin
> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently

Jan Lahoda 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:

 - Adding LOG_LEVEL based debugging to the Depend Plugin.
 - Merge branch 'master' into JDK-8293116
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293116
 - Regenerating modfiles as necessary.
 - Adding comment.
 - Reflecting review feedback.
 - Reflecting review feedback.
 - 8293116: Incremental JDK build could be sped up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10104/files
  - new: https://git.openjdk.org/jdk/pull/10104/files/c3455660..661f9072

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

  Stats: 75927 lines in 1333 files changed: 36116 ins; 31717 del; 8094 mod
  Patch: https://git.openjdk.org/jdk/pull/10104.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10104/head:pull/10104

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

From jlahoda at openjdk.org  Tue Sep 20 10:07:35 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Sep 2022 10:07:35 GMT
Subject: RFR: 8293897: Synthetic final modifier is part of the AST for a
 try-with-resource resource [v2]
In-Reply-To: <YRq0IVFziI7GSX7wV1kjvSGRSr7XyXVaR-lR99wUhMU=.01b85674-8205-4320-8716-9679b22e415f@github.com>
References: <YRq0IVFziI7GSX7wV1kjvSGRSr7XyXVaR-lR99wUhMU=.01b85674-8205-4320-8716-9679b22e415f@github.com>
Message-ID: <j9JgEsWGEm6qjZ2f7BV390t-qPWj29QEL6WTi5B-MLA=.55836bca-ed55-4013-9258-4630dffd8192@github.com>

> The resources in try-with-resource are implicitly final (unless they are marked as final in the source code). But, in javac, the `FINAL` modifier is part of the modifiers on the AST, which is in contrary to the usual direction of having the AST closely model the source code.
> 
> The proposal here is to not add the synthetic `FINAL` modifier to the AST, but add it to the given `VarSymbol`. The positions of the `ModifiersTree` are also tweaked, so that for a synthetic tree, the positions are `NOPOS`.

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

  Adding a test with explicit final modifier.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10348/files
  - new: https://git.openjdk.org/jdk/pull/10348/files/a719a34f..4a2459b0

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

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

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

From sundar at openjdk.org  Tue Sep 20 10:17:40 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 20 Sep 2022 10:17:40 GMT
Subject: RFR: 8293897: Synthetic final modifier is part of the AST for a
 try-with-resource resource [v2]
In-Reply-To: <j9JgEsWGEm6qjZ2f7BV390t-qPWj29QEL6WTi5B-MLA=.55836bca-ed55-4013-9258-4630dffd8192@github.com>
References: <YRq0IVFziI7GSX7wV1kjvSGRSr7XyXVaR-lR99wUhMU=.01b85674-8205-4320-8716-9679b22e415f@github.com>
 <j9JgEsWGEm6qjZ2f7BV390t-qPWj29QEL6WTi5B-MLA=.55836bca-ed55-4013-9258-4630dffd8192@github.com>
Message-ID: <XF3iY_bgAkYqmZxl6L_MKTU9hsKWm-v-j5WgDqYbAfA=.82271f96-79cc-4ac9-8c8c-70c8640ccaa7@github.com>

On Tue, 20 Sep 2022 10:07:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The resources in try-with-resource are implicitly final (unless they are marked as final in the source code). But, in javac, the `FINAL` modifier is part of the modifiers on the AST, which is in contrary to the usual direction of having the AST closely model the source code.
>> 
>> The proposal here is to not add the synthetic `FINAL` modifier to the AST, but add it to the given `VarSymbol`. The positions of the `ModifiersTree` are also tweaked, so that for a synthetic tree, the positions are `NOPOS`.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a test with explicit final modifier.

LGTM

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

Marked as reviewed by sundar (Reviewer).

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

From jlahoda at openjdk.org  Tue Sep 20 13:33:14 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Sep 2022 13:33:14 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
Message-ID: <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>

> This is an attempt to improve the performance and scalability of switches with record patterns.
> 
> There are two main parts of this patch:
> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
> 
> switch (obj) {
>      case Box(String s) -> {}
>      case Box(Integer i) -> {}
>      case Box(Number n) -> {}
>      ...
> }
> =>
> switch (obj) {
>      case Box b ->
>           switch (b.o()) {
>               case String s -> {}
>               case Integer i -> {}
>               case Number n -> {}
>               default -> continue-with-outer-switch;
>           };
>     ...
> }
> 
> 
> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
> 
> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
> 
> I ran the new code through a JMH benchmark:
> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
> 
> The results are:
>  - for "long" testcase (a switch with many cases):
> 
> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
> 
>  - for "short" testcase (a switch with no so many cases):
> 
> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
> 
> 
> So, the performance seems to be improved, at least in these cases.
> 
> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).

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

 - Merge branch 'master' into JDK-8291769
 - Merge branch 'master' into JDK-8291769
 - Reflecting review feedback.
 - Merge branch 'master' into JDK-8291769
 - Using a custom record instead of a generic Pair.
 - Fixing test.
 - Properly handle null record components.
 - 8291769: Translation of switch with record patterns could be improved

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

Changes: https://git.openjdk.org/jdk/pull/9746/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=05
  Stats: 1368 lines in 12 files changed: 1199 ins; 78 del; 91 mod
  Patch: https://git.openjdk.org/jdk/pull/9746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9746/head:pull/9746

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

From ihse at openjdk.org  Tue Sep 20 17:27:48 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Sep 2022 17:27:48 GMT
Subject: RFR: 8293116: Incremental JDK build could be sped up [v6]
In-Reply-To: <u4sgCqn71TkHVLzGYnbvh1ZgFbEHaCakr9BJJlUykMQ=.08bdae4d-6491-44e3-b327-b6fd9262c9bf@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
 <u4sgCqn71TkHVLzGYnbvh1ZgFbEHaCakr9BJJlUykMQ=.08bdae4d-6491-44e3-b327-b6fd9262c9bf@github.com>
Message-ID: <si0bGDKJ4iyIQko4lf8e0T0HaQn20d2oft7EaI59FnY=.a2fa27fd-ab50-45d4-90bc-df0c770641c4@github.com>

On Tue, 20 Sep 2022 09:50:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
>> 
>> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
>> -parsing only sources that were modified first,
>> -computing an "API" hash for them,
>> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
>> 
>> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
>> 
>> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
>> 
>> On my laptop, doing:
>> 
>> touch src/java.base/share/classes/java/lang/Object.java ; time make
>> 
>> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
>> 
>> The caveats of this patch include:
>> -it is more involved than the existing plugin
>> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
>> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
>> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
>> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently
>
> Jan Lahoda 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:
> 
>  - Adding LOG_LEVEL based debugging to the Depend Plugin.
>  - Merge branch 'master' into JDK-8293116
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293116
>  - Regenerating modfiles as necessary.
>  - Adding comment.
>  - Reflecting review feedback.
>  - Reflecting review feedback.
>  - 8293116: Incremental JDK build could be sped up

Thanks for adding the logging! And thank you for hanging in there. Javac/build integration is a minefield of unstated assumptions. :-/

I am very eager to see this go in now. I hope everyone doing incremental Java development will see nice benefits.

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

Marked as reviewed by ihse (Reviewer).

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

From jjg at openjdk.org  Wed Sep 21 01:06:31 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 21 Sep 2022 01:06:31 GMT
Subject: RFR: JDK-8293877: Rewrite MineField test
Message-ID: <sYd9zJCF6N8-lM_G9lwzWQdQts2diPVWTSGKtRc1AjE=.c06c13e4-609a-47a2-ab96-25a257532d89@github.com>

Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code.

This will be an awkward/difficult/tedious (choose your adjective) review.  The old files have been deleted, and the new code is different enough to defeat any `diff` program.  That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter.  It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together.

The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience.

Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`.

The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation.

Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature.

On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed.  But any change would be a difference in the old and new code, and should arguably be done separately.  So, the existence and use of `cleanup` methods is as before.

Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code.

The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort.  

Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests.  For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases.

Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR.

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

Commit messages:
 - JDK-8293877: Rewrite MineField test

Changes: https://git.openjdk.org/jdk/pull/10366/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10366&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293877
  Stats: 3256 lines in 15 files changed: 1979 ins; 1276 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10366.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10366/head:pull/10366

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

From darcy at openjdk.org  Wed Sep 21 03:08:51 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 21 Sep 2022 03:08:51 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
Message-ID: <9KFOfO_3tQ2qn9IxVRqnX1XLSATF0mP322Vd4UFLWqo=.188afd04-1f93-4304-99ee-dd136ecfaef6@github.com>

On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update visitor; all langtools regression tests pass.
>  - Merge branch 'master' into JDK-8042981
>  - JDK-8042981: Strip type annotations in Types' utility methods

Keep alive again.

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

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

From duke at openjdk.org  Wed Sep 21 06:14:46 2022
From: duke at openjdk.org (Hannes Greule)
Date: Wed, 21 Sep 2022 06:14:46 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v5]
In-Reply-To: <6e64srLbjHyJ8Ub60mBRjPJzPaNNYcWm-MI5ETketgo=.68200038-aaa7-4a91-b023-3526e1449cca@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <6e64srLbjHyJ8Ub60mBRjPJzPaNNYcWm-MI5ETketgo=.68200038-aaa7-4a91-b023-3526e1449cca@github.com>
Message-ID: <DKpw5Yci3i2oYM4sv--V_Pjh0IgCqdrdeOyYNrhl9BU=.fb41e8fd-b8cd-47fe-8fb0-210549b83c58@github.com>

On Tue, 23 Aug 2022 19:39:48 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

Hi, is there anything else that needs to be done from my side?

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

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

From jlahoda at openjdk.org  Wed Sep 21 10:31:16 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 Sep 2022 10:31:16 GMT
Subject: Integrated: 8293116: Incremental JDK build could be sped up
In-Reply-To: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
References: <Plss_aPnGfJ-C6pNR-VRozk2vGNycK2wF-IE013oPiU=.135ddbba-b84d-4669-bbef-83ad5b95c780@github.com>
Message-ID: <SGs-vdpejVN9VK1QVzr2ApHIXo95h2ZQHQ4Ov3aR-eU=.c7a9bd01-4c4c-4b18-965b-087455758888@github.com>

On Wed, 31 Aug 2022 17:51:31 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, when doing a small change inside a module that does not affect the API of the module, the build system will skip rebuild of the dependent modules. If there's a change that affects the module's API, the dependent modules are recompiled. So far, this seems to work reasonably.
> 
> But, for large modules, like `java.base`, any change to any of the module's sources will cause a full rebuild of that module, which may take tens of seconds. This patch strives to improve that, by:
> -parsing only sources that were modified first,
> -computing an "API" hash for them,
> -if there is not a significant change in the file(s), only recompile the files, if there are significant changes to the files, recompile the whole module, as before
> 
> There is no attempt made to determine the minimal set of files that needs to be reparsed, all module's files are reparsed when the internal API check fails. This is in line with the existing code to skip the build of dependent modules.
> 
> Sadly, this is overall a bit more difficult to do, so the implementation uses some javac internals. The existing build-only `Depend` plugin is enhanced so that parsing of the initial files is redirected to go through the plugin, and it decides parses either only the modified files, or all files. This redirection requires a change to `main/JavaCompiler`, which is not in the boot JDK, so reflection is currently used to install the redirection. Once the new classes are in a boot JDK, we could clean up, and avoid the reflection.
> 
> On my laptop, doing:
> 
> touch src/java.base/share/classes/java/lang/Object.java ; time make
> 
> can take well over 30s without this patch. With this patch, it takes <5s for me. Changes to e.g. only method bodies should typically not require rebuild of the whole module.
> 
> The caveats of this patch include:
> -it is more involved than the existing plugin
> -it only speeds up only incremental Java compilation, so the other tasks the build system is doing when running `make`, like timestamp checks or starting the build server, are still happening. This may slow down builds on platforms with slow I/O
> -for modules that are part of the interim toolchain (like jdk.compiler), the interim build is not using this new approach, and it will likely be slow. We might try to improve once the required hooks are part of the boot JDK
> -as the check for modified "internal" API cannot use attribution (as it runs too early), it tries to be safe, and will mark some changes as "internal API changes", even if they in fact don't affect the file's API. This may be especially true for some changes to imports.
> -it is necessary to store an (internal) API hash for every file, in addition to one for every module which is stored currently

This pull request has now been integrated.

Changeset: cd1cdcdb
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd1cdcdb0d56131d1ad1bdc453c7e261afa73a3a
Stats:     590 lines in 7 files changed: 566 ins; 0 del; 24 mod

8293116: Incremental JDK build could be sped up

Reviewed-by: erikj, vromero, ihse

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

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

From jlahoda at openjdk.org  Wed Sep 21 11:32:52 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 Sep 2022 11:32:52 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
Message-ID: <WB_wJoKBzr1Hnv-XoXro27d6cRNaDb5bw0dPLf_o-18=.c2090a07-7357-4335-927c-20a73aa52b3f@github.com>

On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update visitor; all langtools regression tests pass.
>  - Merge branch 'master' into JDK-8042981
>  - JDK-8042981: Strip type annotations in Types' utility methods

src/java.compiler/share/classes/javax/lang/model/util/Types.java line 241:

> 239:      * @param extendsBound  the extends (upper) bound, or {@code null} if none
> 240:      * @param superBound    the super (lower) bound, or {@code null} if none
> 241:      * @throws IllegalArgumentException if bounds are not valid

Should annotation also be preserved (and also documented to be preserved) for `getDeclaredType`?

test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java line 137:

> 135:     // public static @TypeAnnotation("foo4") java.util.Set foo4() {return null;}
> 136: 
> 137:     // public static @TypeAnnotation("foo4") String[] foo4() {return null;}

It would be good to have a test verifying the annotation on the array component is removed by `erasure`.

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

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

From jlahoda at openjdk.org  Wed Sep 21 12:33:50 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 Sep 2022 12:33:50 GMT
Subject: Integrated: 8293897: Synthetic final modifier is part of the AST for a
 try-with-resource resource
In-Reply-To: <YRq0IVFziI7GSX7wV1kjvSGRSr7XyXVaR-lR99wUhMU=.01b85674-8205-4320-8716-9679b22e415f@github.com>
References: <YRq0IVFziI7GSX7wV1kjvSGRSr7XyXVaR-lR99wUhMU=.01b85674-8205-4320-8716-9679b22e415f@github.com>
Message-ID: <UlzejMe6e2j42Sarae4sQtzoszv-pcu9hWEnSfmq1x4=.a997f3fa-0a24-4b1d-a7da-cde27b237cfa@github.com>

On Mon, 19 Sep 2022 18:28:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The resources in try-with-resource are implicitly final (unless they are marked as final in the source code). But, in javac, the `FINAL` modifier is part of the modifiers on the AST, which is in contrary to the usual direction of having the AST closely model the source code.
> 
> The proposal here is to not add the synthetic `FINAL` modifier to the AST, but add it to the given `VarSymbol`. The positions of the `ModifiersTree` are also tweaked, so that for a synthetic tree, the positions are `NOPOS`.

This pull request has now been integrated.

Changeset: 95ec2eac
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/95ec2eaca3845bc971d3e711e5f61052c2951fa8
Stats:     88 lines in 3 files changed: 84 ins; 1 del; 3 mod

8293897: Synthetic final modifier is part of the AST for a try-with-resource resource

Reviewed-by: sundar

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

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

From vromero at openjdk.org  Wed Sep 21 14:55:17 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 21 Sep 2022 14:55:17 GMT
Subject: RFR: 8292756: java.lang.AssertionError at at
 jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)
In-Reply-To: <kB6JRzKm1_pyldevhGyrVsiizT9jKNuTYfF2L_BVlZA=.2e078af9-ebf2-4bb2-8cd8-1af3e2fbcca8@github.com>
References: <kB6JRzKm1_pyldevhGyrVsiizT9jKNuTYfF2L_BVlZA=.2e078af9-ebf2-4bb2-8cd8-1af3e2fbcca8@github.com>
Message-ID: <AoW3mq36myZDG1JQISOEdCPxxUjLA4eZ1D_R6jy2zrs=.87080c4b-6abe-4dc8-b924-64856be345a9@github.com>

On Mon, 19 Sep 2022 18:13:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class JDK_8292756 {
>     private int test(Object o) {
>         int i1, i2, i3, i4, i5, i6, i7;
>         return switch(o) {
>             case Object oo when oo != null -> 0;
>             default -> 0;
>         };
>     }
> }
> 
> 
> Compiling this leads to a crash:
> 
> $ javac --enable-preview -source 19 /tmp/JDK_8292756.java 
> Note: /tmp/JDK_8292756.java uses preview features of Java SE 19.
> Note: Recompile with -Xlint:preview for details.
> An exception has occurred in the compiler (19-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5621)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5512)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5336)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5275)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)
> printing javac parameters to: /tmp/javac.20220919_200140.args
> 
> 
> The reason for the failure is this: in `Attr.handleSwitch`, there is an input scope `env`, and a sub-scope of it, `switchEnv`, is created for the switch. Eventually, another (shared) sub-scope is created for the guard expression, `bodyEnv`. All `env`, `switchEnv` and `bodyEnv` share an internal table. But, the `bodyEnv` sub-scope is created from `env`, not from `switchEnv` (as it should). Which mostly works, but if the internal table for `bodyEnv` is resized, it will correctly fix only `env`, but not `switchEnv`.
> 
> The solution to this problem is to simply base the `bodyEnv` on `switchEnv`, not on `env`. But, in addition to that, it does not seem right the scopes don't protect from an accident like this. So the proposed patch here is enhancing the assertions in `Scope` so that a shared duplicate of a Scope can only be done from a leaf Scope.

looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java line 277:

> 275:         /** true if this scope's hash table is shared with a nested scope.
> 276:          */
> 277:         private boolean shared;

great!

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

Marked as reviewed by vromero (Reviewer).

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

From duke at openjdk.org  Wed Sep 21 23:12:52 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 21 Sep 2022 23:12:52 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field.
Message-ID: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>

This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`.

This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this:

LambdaFieldInit.java:6: error: variable x might already have been assigned
        Runnable r1 = () -> x = "hi";
                            ^


This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins).

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

Commit messages:
 - 8043179: Lambda expression can mutate final field.

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

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

From jjg at openjdk.org  Thu Sep 22 03:41:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Sep 2022 03:41:23 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v14]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <KQgjRB_m69iOVas99r1baWJvb9q4nwtv-MZfbBhRoX4=.87397a53-aae3-425f-bc39-b52e7f1a78c5@github.com>

> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Fix merge issue
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge with upstream/master
 - Fix typo and merge error
 - Merge with upstream/master
 - Update @since tags
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Updates for latest repo
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - ... and 12 more: https://git.openjdk.org/jdk/compare/2283c324...be7510e5

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

Changes: https://git.openjdk.org/jdk/pull/8439/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=13
  Stats: 1502 lines in 41 files changed: 1474 ins; 6 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8439/head:pull/8439

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

From iris at openjdk.org  Thu Sep 22 08:15:29 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 22 Sep 2022 08:15:29 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v14]
In-Reply-To: <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
Message-ID: <1E7Yr-7zxnhTReLJBrPYCQJNOo-slOt8bI7WKuPWvm4=.159d5e6f-fdb6-4516-b0df-c95d0134b509@github.com>

On Tue, 3 May 2022 13:22:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Fix merge issue
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - Merge with upstream/master
>>  - Fix typo and merge error
>>  - Merge with upstream/master
>>  - Update @since tags
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - Updates for latest repo
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2283c324...be7510e5
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java line 192:
> 
>> 190:      *
>> 191:      * @param element  the element that owns the doc comment
>> 192:      * @param specTags the array of @spec tags.
> 
> Naked tags that aren't meant to be interpreted by javadoc make me uncomfortable.

`{@code @spec}` similar to line 200?

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

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

From jlahoda at openjdk.org  Thu Sep 22 14:35:51 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 Sep 2022 14:35:51 GMT
Subject: Integrated: 8292756: java.lang.AssertionError at at
 jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)
In-Reply-To: <kB6JRzKm1_pyldevhGyrVsiizT9jKNuTYfF2L_BVlZA=.2e078af9-ebf2-4bb2-8cd8-1af3e2fbcca8@github.com>
References: <kB6JRzKm1_pyldevhGyrVsiizT9jKNuTYfF2L_BVlZA=.2e078af9-ebf2-4bb2-8cd8-1af3e2fbcca8@github.com>
Message-ID: <p9sN1uAiBkqV3y6Toh3URzvEXyQ8FbKUT5WnhunxpSk=.bea26553-b54d-4e45-a39c-dc22ebb69460@github.com>

On Mon, 19 Sep 2022 18:13:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class JDK_8292756 {
>     private int test(Object o) {
>         int i1, i2, i3, i4, i5, i6, i7;
>         return switch(o) {
>             case Object oo when oo != null -> 0;
>             default -> 0;
>         };
>     }
> }
> 
> 
> Compiling this leads to a crash:
> 
> $ javac --enable-preview -source 19 /tmp/JDK_8292756.java 
> Note: /tmp/JDK_8292756.java uses preview features of Java SE 19.
> Note: Recompile with -Xlint:preview for details.
> An exception has occurred in the compiler (19-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5621)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5512)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5336)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5275)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)
> printing javac parameters to: /tmp/javac.20220919_200140.args
> 
> 
> The reason for the failure is this: in `Attr.handleSwitch`, there is an input scope `env`, and a sub-scope of it, `switchEnv`, is created for the switch. Eventually, another (shared) sub-scope is created for the guard expression, `bodyEnv`. All `env`, `switchEnv` and `bodyEnv` share an internal table. But, the `bodyEnv` sub-scope is created from `env`, not from `switchEnv` (as it should). Which mostly works, but if the internal table for `bodyEnv` is resized, it will correctly fix only `env`, but not `switchEnv`.
> 
> The solution to this problem is to simply base the `bodyEnv` on `switchEnv`, not on `env`. But, in addition to that, it does not seem right the scopes don't protect from an accident like this. So the proposed patch here is enhancing the assertions in `Scope` so that a shared duplicate of a Scope can only be done from a leaf Scope.

This pull request has now been integrated.

Changeset: 0be2b2c2
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0be2b2c2f1b670bbcd3a8e17bc9b43a534909da5
Stats:     119 lines in 3 files changed: 106 ins; 0 del; 13 mod

8292756: java.lang.AssertionError at at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)

Reviewed-by: vromero

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

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

From cushon at openjdk.org  Thu Sep 22 16:54:23 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 22 Sep 2022 16:54:23 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
Message-ID: <la7NSChfspXEzKCeWhj7AMdNsi-tZfph0hH0IIN3JCA=.118b1131-33c1-48e0-9fa3-abb960667831@github.com>

On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update visitor; all langtools regression tests pass.
>  - Merge branch 'master' into JDK-8042981
>  - JDK-8042981: Strip type annotations in Types' utility methods

src/java.compiler/share/classes/javax/lang/model/util/Types.java line 40:

> 38:  * Where a method returns a type mirror or a collection of type
> 39:  * mirrors, any type mirrors represent types with no type annotations,
> 40:  * unless otherwise indicated.

I'm seeing `erasure` preserve type annotations on the array type (but not its component) after this change: `erasure(@A int @B []) = int @B []`. (Here's the [repro](https://gist.github.com/cushon/e0a59cc291c3b83204b9139addb01340).)

Is that deliberate, or is this still work in progress?

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

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

From cushon at openjdk.org  Thu Sep 22 16:56:24 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 22 Sep 2022 16:56:24 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
Message-ID: <uBkfUgYOyeIiMypgShWBptCk0MAtIvVedzcDb_tY5KU=.8023cf1a-ccbf-49b3-9409-3690f937acda@github.com>

On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update visitor; all langtools regression tests pass.
>  - Merge branch 'master' into JDK-8042981
>  - JDK-8042981: Strip type annotations in Types' utility methods

FWIW I did some testing with the current version of the patch, and didn't see any compatibility impact.

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

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

From martin at openjdk.org  Thu Sep 22 19:24:30 2022
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 22 Sep 2022 19:24:30 GMT
Subject: RFR: JDK-8293877: Rewrite MineField test
In-Reply-To: <sYd9zJCF6N8-lM_G9lwzWQdQts2diPVWTSGKtRc1AjE=.c06c13e4-609a-47a2-ab96-25a257532d89@github.com>
References: <sYd9zJCF6N8-lM_G9lwzWQdQts2diPVWTSGKtRc1AjE=.c06c13e4-609a-47a2-ab96-25a257532d89@github.com>
Message-ID: <UkCYNqu49atx8jltGrpSJRmNfl9XVGf0n_yzzWv-QnM=.ebde4e31-bff7-44de-96e5-8c1480cf9b85@github.com>

On Wed, 21 Sep 2022 00:57:22 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code.
> 
> This will be an awkward/difficult/tedious (choose your adjective) review.  The old files have been deleted, and the new code is different enough to defeat any `diff` program.  That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter.  It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together.
> 
> The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience.
> 
> Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`.
> 
> The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation.
> 
> Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature.
> 
> On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed.  But any change would be a difference in the old and new code, and should arguably be done separately.  So, the existence and use of `cleanup` methods is as before.
> 
> Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code.
> 
> The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort.  
> 
> Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests.  For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases.
> 
> Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR.

Explicit OS command invocation and ToolProvider invocation both seem important to test.
IIRC there were times when they were not in fact equivalent in effect.
Consider library infrastructure to run both variants and ensure results are identical.

I recall being slightly proud when writing the first iteration of this test - it allowed a very terse test description in shell.
But terseness is not universally admired, and even I (in my dotage) have joined the camp of writing tests in more verbose junit style.

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

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

From darcy at openjdk.org  Fri Sep 23 05:48:12 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Sep 2022 05:48:12 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <uBkfUgYOyeIiMypgShWBptCk0MAtIvVedzcDb_tY5KU=.8023cf1a-ccbf-49b3-9409-3690f937acda@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <uBkfUgYOyeIiMypgShWBptCk0MAtIvVedzcDb_tY5KU=.8023cf1a-ccbf-49b3-9409-3690f937acda@github.com>
Message-ID: <tphVh8I9jxdF7LFnI_iCn6HsNK0ip_RHYe3WjuUa9YU=.b9fe9d5f-23fc-4f17-96bd-44d1d3499b74@github.com>

On Thu, 22 Sep 2022 16:54:08 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> FWIW I did some testing with the current version of the patch, and didn't see any compatibility impact.

Thanks for the testing Liam. Completing this patch has gotten swapped out for me, but I intend to swap it back in for JDK 20.

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

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

From imkiva at islovely.icu  Fri Sep 23 12:43:32 2022
From: imkiva at islovely.icu (Kiva)
Date: Fri, 23 Sep 2022 20:43:32 +0800
Subject: Javac throws AssertionError randomly for nested pattern matching
Message-ID: <3jsb56s6st-1@m0246573.ppops.net>

Hello! I found a severe bug when pattern-matching switches are nested.

My Java version:

openjdk 19 2022-09-20
OpenJDK Runtime Environment (build 19+37)
OpenJDK 64-Bit Server VM (build 19+37, mixed mode, sharing)

The code that triggers ICE (just a ordinary unification algorithm):

public class Bug {
  sealed interface Term {
    record Mula(Formula formula) implements Term {}
    record I() implements Term {}
    record U() implements Term {}
  }
  sealed interface Formula {
    record Lit(boolean left) implements Formula {}
    record Inv(Term i) implements Formula {}
  }

  public static Term compare(Term preLhs, Term preRhs) {
    return switch (preLhs) {
      case Term.I i -> new Term.U();
      case Term.U u -> new Term.U();
      case Term.Mula lhs -> {
        if (!(preRhs instanceof Term.Mula rhs)) yield null;
        var happy = switch (lhs.formula()) {
          case Formula.Lit ll when rhs.formula() instanceof Formula.Lit rr -> ll.left() == rr.left();
          case Formula.Inv ll when rhs.formula() instanceof Formula.Inv rr ->
            compare(ll.i(), rr.i()) != null;
          default -> false;
        };
        yield happy ? new Term.I() : null;
      }
    };
  }

  public static void main(String[] args) {
    System.out.println(System.getProperty("java.version"));
  }
}


Throws this error randomly:

An exception has occurred in the compiler (19). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError
	at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
	at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
	at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465)
	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253)
	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5601)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5492)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5316)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5255)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
	at org.gradle.internal.compiler.java.IncrementalCompileTask.call(IncrementalCompileTask.java:89)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220923/81a9dcef/attachment.htm>

From hannesw at openjdk.org  Fri Sep 23 14:18:26 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 23 Sep 2022 14:18:26 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v14]
In-Reply-To: <KQgjRB_m69iOVas99r1baWJvb9q4nwtv-MZfbBhRoX4=.87397a53-aae3-425f-bc39-b52e7f1a78c5@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <KQgjRB_m69iOVas99r1baWJvb9q4nwtv-MZfbBhRoX4=.87397a53-aae3-425f-bc39-b52e7f1a78c5@github.com>
Message-ID: <rqtvVUzi3TSJfRXRz02KUCi3Y_0aR16DODhtJfDNT9o=.ca37a67a-483b-4349-b71f-014da4dd3103@github.com>

On Thu, 22 Sep 2022 03:41:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Fix merge issue
>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>  - Merge with upstream/master
>  - Fix typo and merge error
>  - Merge with upstream/master
>  - Update @since tags
>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>  - Updates for latest repo
>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2283c324...be7510e5

All looks very good! The only place that looks suspicious to me is the `inherit` implementation in `SpecTaglet.java`, which also seems not to be covered by the test. 

I guess the best way to examine the output of the new tag is via test output. I'll have a look at that to see the HTML and CSS in action before giving a thumbs up.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 65:

> 63:                     ? ch.getFirstSentenceTrees(output.holderTag)
> 64:                     : ch.getReference(output.holderTag);
> 65:         }

This implementation seems to be copied from SeeTaglet.java. Is it fully functional in this context? The use of CommentHelper.getReference looks suspicious to me.

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

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

From jjg at openjdk.org  Fri Sep 23 17:17:41 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Sep 2022 17:17:41 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v14]
In-Reply-To: <rqtvVUzi3TSJfRXRz02KUCi3Y_0aR16DODhtJfDNT9o=.ca37a67a-483b-4349-b71f-014da4dd3103@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <KQgjRB_m69iOVas99r1baWJvb9q4nwtv-MZfbBhRoX4=.87397a53-aae3-425f-bc39-b52e7f1a78c5@github.com>
 <rqtvVUzi3TSJfRXRz02KUCi3Y_0aR16DODhtJfDNT9o=.ca37a67a-483b-4349-b71f-014da4dd3103@github.com>
Message-ID: <qc0wGsyxnZX-l7Bvhl7g7r5tO-PTIIKIUioz3_Ozt_k=.5d5a7b58-83e6-464c-86a7-0514489c0178@github.com>

On Fri, 23 Sep 2022 13:53:46 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Fix merge issue
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - Merge with upstream/master
>>  - Fix typo and merge error
>>  - Merge with upstream/master
>>  - Update @since tags
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - Updates for latest repo
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2283c324...be7510e5
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 65:
> 
>> 63:                     ? ch.getFirstSentenceTrees(output.holderTag)
>> 64:                     : ch.getReference(output.holderTag);
>> 65:         }
> 
> This implementation seems to be copied from SeeTaglet.java. Is it fully functional in this context? The use of CommentHelper.getReference looks suspicious to me.

Thanks for the comment; I'll investigate

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

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

From jjg at openjdk.org  Fri Sep 23 17:27:50 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Sep 2022 17:27:50 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v14]
In-Reply-To: <qc0wGsyxnZX-l7Bvhl7g7r5tO-PTIIKIUioz3_Ozt_k=.5d5a7b58-83e6-464c-86a7-0514489c0178@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <KQgjRB_m69iOVas99r1baWJvb9q4nwtv-MZfbBhRoX4=.87397a53-aae3-425f-bc39-b52e7f1a78c5@github.com>
 <rqtvVUzi3TSJfRXRz02KUCi3Y_0aR16DODhtJfDNT9o=.ca37a67a-483b-4349-b71f-014da4dd3103@github.com>
 <qc0wGsyxnZX-l7Bvhl7g7r5tO-PTIIKIUioz3_Ozt_k=.5d5a7b58-83e6-464c-86a7-0514489c0178@github.com>
Message-ID: <dIf7xlUssO1NNMEWs6Jgk7lmWRwgUrfpXrI9U6wtUKE=.4b38912d-2fc6-4f5f-87c1-bfed75afa9e3@github.com>

On Fri, 23 Sep 2022 17:15:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 65:
>> 
>>> 63:                     ? ch.getFirstSentenceTrees(output.holderTag)
>>> 64:                     : ch.getReference(output.holderTag);
>>> 65:         }
>> 
>> This implementation seems to be copied from SeeTaglet.java. Is it fully functional in this context? The use of CommentHelper.getReference looks suspicious to me.
>
> Thanks for the comment; I'll investigate

Good catch;

Yes, the use of `getReference` is indeed questionable, given its implementation, which is specific to `@see`.   Given ongoing recent work, it's also not clear that the `@spec` tag should be inheritable.

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

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

From jjg at openjdk.org  Fri Sep 23 17:50:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Sep 2022 17:50:23 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v14]
In-Reply-To: <dIf7xlUssO1NNMEWs6Jgk7lmWRwgUrfpXrI9U6wtUKE=.4b38912d-2fc6-4f5f-87c1-bfed75afa9e3@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <KQgjRB_m69iOVas99r1baWJvb9q4nwtv-MZfbBhRoX4=.87397a53-aae3-425f-bc39-b52e7f1a78c5@github.com>
 <rqtvVUzi3TSJfRXRz02KUCi3Y_0aR16DODhtJfDNT9o=.ca37a67a-483b-4349-b71f-014da4dd3103@github.com>
 <qc0wGsyxnZX-l7Bvhl7g7r5tO-PTIIKIUioz3_Ozt_k=.5d5a7b58-83e6-464c-86a7-0514489c0178@github.com>
 <dIf7xlUssO1NNMEWs6Jgk7lmWRwgUrfpXrI9U6wtUKE=.4b38912d-2fc6-4f5f-87c1-bfed75afa9e3@github.com>
Message-ID: <eglJCaVfKRLkQw5cJ1U0qiRnX9p1vEJnZMeL2ytNfvU=.96d58f2e-cd83-429b-a940-cfa7a7845b18@github.com>

On Fri, 23 Sep 2022 17:24:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Thanks for the comment; I'll investigate
>
> Good catch;
> 
> Yes, the use of `getReference` is indeed questionable, given its implementation, which is specific to `@see`.   Given ongoing recent work, it's also not clear that the `@spec` tag should be inheritable.

For now, I'll change it to `getTags`, pending discussions on whether the tag should be inheritable.

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

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

From jjg at openjdk.org  Fri Sep 23 21:47:30 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Sep 2022 21:47:30 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v15]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <rn4drHuLt7fOg9Vv3R5hJ_lRa715VsT5-7NKd30s1Eo=.1b3a7a7a-cc97-4f7d-ab9e-87c260add20d@github.com>

> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8439/files
  - new: https://git.openjdk.org/jdk/pull/8439/files/be7510e5..97301921

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=13-14

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

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

From jjg at openjdk.org  Fri Sep 23 21:49:07 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Sep 2022 21:49:07 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v14]
In-Reply-To: <eglJCaVfKRLkQw5cJ1U0qiRnX9p1vEJnZMeL2ytNfvU=.96d58f2e-cd83-429b-a940-cfa7a7845b18@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <KQgjRB_m69iOVas99r1baWJvb9q4nwtv-MZfbBhRoX4=.87397a53-aae3-425f-bc39-b52e7f1a78c5@github.com>
 <rqtvVUzi3TSJfRXRz02KUCi3Y_0aR16DODhtJfDNT9o=.ca37a67a-483b-4349-b71f-014da4dd3103@github.com>
 <qc0wGsyxnZX-l7Bvhl7g7r5tO-PTIIKIUioz3_Ozt_k=.5d5a7b58-83e6-464c-86a7-0514489c0178@github.com>
 <dIf7xlUssO1NNMEWs6Jgk7lmWRwgUrfpXrI9U6wtUKE=.4b38912d-2fc6-4f5f-87c1-bfed75afa9e3@github.com>
 <eglJCaVfKRLkQw5cJ1U0qiRnX9p1vEJnZMeL2ytNfvU=.96d58f2e-cd83-429b-a940-cfa7a7845b18@github.com>
Message-ID: <904pGLMooArW2T1H3Fpwt0HeFsFdtqO1YOisJCCe7F0=.91279180-2a3e-4e44-9fdb-64bd947d3870@github.com>

On Fri, 23 Sep 2022 17:48:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Good catch;
>> 
>> Yes, the use of `getReference` is indeed questionable, given its implementation, which is specific to `@see`.   Given ongoing recent work, it's also not clear that the `@spec` tag should be inheritable.
>
> For now, I'll change it to `getTags`, pending discussions on whether the tag should be inheritable.

With the latest update, toy examples show that tag inherits works as expected, as least as far as parity with `@see`.

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

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

From jjg at openjdk.org  Fri Sep 23 22:46:06 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Sep 2022 22:46:06 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v16]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <CifjHjhdcCCg3XYxa6NCJg7XPwgokwBR63UEQM9IUlA=.5022fb1f-a55a-49df-9e1e-447b53bc727b@github.com>

> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Update DPrinter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8439/files
  - new: https://git.openjdk.org/jdk/pull/8439/files/97301921..30a43968

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=14-15

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

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

From jai.forums2013 at gmail.com  Sat Sep 24 06:23:28 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 24 Sep 2022 11:53:28 +0530
Subject: Javac throws AssertionError randomly for nested pattern matching
In-Reply-To: <3jsb56s6st-1@m0246573.ppops.net>
References: <3jsb56s6st-1@m0246573.ppops.net>
Message-ID: <478957b5-1847-97e2-78d6-3d519620fafc@gmail.com>

Hello Kiva,

I haven't been able to reproduce this issue. But more importantly, this 
output that you pasted looks odd:

On 23/09/22 6:13 pm, Kiva wrote:
> ...
>
> My Java version:
>
> openjdk 19 2022-09-20
>
> OpenJDK Runtime Environment (build 19+37)
>
> OpenJDK 64-Bit Server VM (build 19+37, mixed mode, sharing)
>
Where did you get this Java downloaded from and which OS are you on? As 
far as I know from the release announcement (and even comparing against 
my local install), OpenJDK 19 build is:

openjdk 19 2022-09-20
OpenJDK Runtime Environment (build 19+36-2238)
OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode, sharing)

So that "build 19+37" looks odd in your output.

-Jaikiran

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220924/5fd94090/attachment.htm>

From jai.forums2013 at gmail.com  Sat Sep 24 06:28:18 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 24 Sep 2022 11:58:18 +0530
Subject: Javac throws AssertionError randomly for nested pattern matching
In-Reply-To: <478957b5-1847-97e2-78d6-3d519620fafc@gmail.com>
References: <3jsb56s6st-1@m0246573.ppops.net>
 <478957b5-1847-97e2-78d6-3d519620fafc@gmail.com>
Message-ID: <753ddcab-55ec-fa88-f03e-d733a79348cd@gmail.com>

After I sent this mail, I noticed a recent PR which fixed this issue 
https://bugs.openjdk.org/browse/JDK-8292756.

-Jaikiran

On 24/09/22 11:53 am, Jaikiran Pai wrote:
>
> Hello Kiva,
>
> I haven't been able to reproduce this issue. But more importantly, 
> this output that you pasted looks odd:
>
> On 23/09/22 6:13 pm, Kiva wrote:
>> ...
>>
>> My Java version:
>>
>> openjdk 19 2022-09-20
>>
>> OpenJDK Runtime Environment (build 19+37)
>>
>> OpenJDK 64-Bit Server VM (build 19+37, mixed mode, sharing)
>>
> Where did you get this Java downloaded from and which OS are you on? 
> As far as I know from the release announcement (and even comparing 
> against my local install), OpenJDK 19 build is:
>
> openjdk 19 2022-09-20
> OpenJDK Runtime Environment (build 19+36-2238)
> OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode, sharing)
>
> So that "build 19+37" looks odd in your output.
>
> -Jaikiran
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220924/9164a652/attachment.htm>

From duke at openjdk.org  Sun Sep 25 00:30:05 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sun, 25 Sep 2022 00:30:05 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v2]
In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
Message-ID: <bZZdv6isIGYTJXq7gRd7vfgYw-1jyrhuIoQ3zjs5Sw4=.904f1816-9dcd-4b94-9c5e-1869ad810ffb@github.com>

> This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`.
> 
> This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this:
> 
> LambdaFieldInit.java:6: error: variable x might already have been assigned
>         Runnable r1 = () -> x = "hi";
>                             ^
> 
> 
> This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins).

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

  8043179: Lambda expression can mutate final field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10381/files
  - new: https://git.openjdk.org/jdk/pull/10381/files/df8a09a1..47df9c96

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

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

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

From duke at openjdk.org  Sun Sep 25 00:30:08 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sun, 25 Sep 2022 00:30:08 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field
In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
Message-ID: <UJDP-DawyvLM4REYhK5HNDjr1k3WDiYJyH3Q6mZicNE=.50c8760c-5e8e-4809-85c7-c37787dbd3f7@github.com>

On Wed, 21 Sep 2022 23:03:45 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`.
> 
> This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this:
> 
> LambdaFieldInit.java:6: error: variable x might already have been assigned
>         Runnable r1 = () -> x = "hi";
>                             ^
> 
> 
> This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins).

I've updated this pull request to include a new unit test (apologies for omitting it previously).

Also there are a couple of changes to other unit tests which get broken because this change reflects changes to the JLS spec per [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176). I'm a little unclear on precisely what the new behavior is supposed to be, but in any case the actual behavior now makes a lot more sense: basically, everything that happens in a lambda is assumed to happen some indefinite time later in the future (same as if you were instantiating the equivalent local class), so the previous errors expected by `T8024809/SelfInitializerInLambdaTestb.java` regarding instance field initialization are no longer errors.

In summary:
* Added new unit test `LambdaMutateFinalField.java` testing [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) directly.
* Unit test [`lambda/self_initializer/T8024809/SelfInitializerInLambdaTestb.java`](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/lambda/self_initializer/T8024809/SelfInitializerInLambdaTestb.java) is now obsolete. Now it compiles successfully.
* Unit test [`lambda/lambdaExpression/EffectivelyFinal_neg.java`](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.java) still works, but no longer generates a duplicate error. I think this is a good thing? The expected test output has been updated.

With the above changes now all javac tests should succeed.

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

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

From duke at openjdk.org  Sun Sep 25 00:55:12 2022
From: duke at openjdk.org (Tesla I. =?UTF-8?B?WmhhbmfigK4=?=)
Date: Sun, 25 Sep 2022 00:55:12 GMT
Subject: RFR: 8292756: java.lang.AssertionError at at
 jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)
In-Reply-To: <kB6JRzKm1_pyldevhGyrVsiizT9jKNuTYfF2L_BVlZA=.2e078af9-ebf2-4bb2-8cd8-1af3e2fbcca8@github.com>
References: <kB6JRzKm1_pyldevhGyrVsiizT9jKNuTYfF2L_BVlZA=.2e078af9-ebf2-4bb2-8cd8-1af3e2fbcca8@github.com>
Message-ID: <IG_cNqN13qqpsEekEh-V7ixXLSl1xVkw4db0zMkv-qI=.42a17e46-7536-4e33-ae72-d44ce4e71896@github.com>

On Mon, 19 Sep 2022 18:13:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class JDK_8292756 {
>     private int test(Object o) {
>         int i1, i2, i3, i4, i5, i6, i7;
>         return switch(o) {
>             case Object oo when oo != null -> 0;
>             default -> 0;
>         };
>     }
> }
> 
> 
> Compiling this leads to a crash:
> 
> $ javac --enable-preview -source 19 /tmp/JDK_8292756.java 
> Note: /tmp/JDK_8292756.java uses preview features of Java SE 19.
> Note: Recompile with -Xlint:preview for details.
> An exception has occurred in the compiler (19-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.code.Scope$ScopeImpl.leave(Scope.java:386)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1465)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1253)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5621)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5512)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5336)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5275)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)
> printing javac parameters to: /tmp/javac.20220919_200140.args
> 
> 
> The reason for the failure is this: in `Attr.handleSwitch`, there is an input scope `env`, and a sub-scope of it, `switchEnv`, is created for the switch. Eventually, another (shared) sub-scope is created for the guard expression, `bodyEnv`. All `env`, `switchEnv` and `bodyEnv` share an internal table. But, the `bodyEnv` sub-scope is created from `env`, not from `switchEnv` (as it should). Which mostly works, but if the internal table for `bodyEnv` is resized, it will correctly fix only `env`, but not `switchEnv`.
> 
> The solution to this problem is to simply base the `bodyEnv` on `switchEnv`, not on `env`. But, in addition to that, it does not seem right the scopes don't protect from an accident like this. So the proposed patch here is enhancing the assertions in `Scope` so that a shared duplicate of a Scope can only be done from a leaf Scope.

Any chance this can be backported to JDK 19?

Several benefits of backporting to JDK 19:

+ Build tools like Gradle wouldn't support JDK 20 until GA, so having a serious bug in JDK 19 = having a JDK 19 without record patterns at all.
+ Users won't be able to extensively test the feature without being able to use the feature. Preview features are supposed to be tested.
+ Bug-fix updates are supposed to deliver bug-fixes, and this is a bug-fix.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk,
 test/jdk/jni
Message-ID: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>

8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

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

Commit messages:
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294321
  Stats: 317 lines in 108 files changed: 0 ins; 195 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

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

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.

Done: https://bugs.openjdk.org/browse/SKARA-1566

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

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

From jpai at openjdk.org  Sun Sep 25 17:04:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
Message-ID: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>

On Thu, 25 Aug 2022 19:55:47 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
>> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.
> 
> Done: https://bugs.openjdk.org/browse/SKARA-1566

Hello Michael @mernst, these changes are mostly fine. However, they are spread across files which reside in different areas of the JDK. For changes like these, we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Would you be willing to split this PR into separate ones. I would recommend starting with one PR which includes changes that are part of `test/jdk/java`, `test/jdk/jdk` and `test/jdk/jni`. If you can come up with that PR, then I'll go ahead and create a JBS issue for it and you can then link the PR against that issue.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
Message-ID: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>

On Mon, 5 Sep 2022 06:32:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> these changes are mostly fine.

Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?  It doesn't seem useful to make a pull request with known deficiencies.

> we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

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

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

From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
 <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
Message-ID: <RWGt4_adstjnxq1OHM-jBMqSjzlLdAqNrpTu3JozTYM=.36dbfb8e-bbfc-4853-ad43-dbeb78bfd92d@github.com>

On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?

These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification.

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

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

From jpai at openjdk.org  Sun Sep 25 17:04:39 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Hello Michael,

> > these changes are mostly fine.
> 
> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies.

I wasn't implying this PR had deficiencies. What I meant was, to be able to have this reviewed, in addition to code changes this will also need a issue to be created and linked to this PR (and the PR title changed to the form `<bugid>: <bug summary>`). 
I have now created https://bugs.openjdk.org/browse/JDK-8294321. Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
Message-ID: <kqbMO6iHpa3xNDX1Ooa6zLtG9rZJK7mBogbO83RQQLs=.b1cb0e4a-032b-438e-b1a4-7644680ecd6b@github.com>

On Sat, 24 Sep 2022 10:41:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

OK.  I'll repeat my comment from before:

> Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
Message-ID: <MnLhhKzLqR1jb7PbtrJu2AlU4xQ5EolX_Zi7TUsJ96g=.e03c2f32-7815-40e8-9450-b66e425c31ef@github.com>

On Sun, 25 Sep 2022 16:51:27 GMT, SWinxy <duke at openjdk.org> wrote:

> Oh no what happened

Oops!  Thanks for pointing out the goof.  It seems to be fixed now.

It has now been a month since I opened the pull request, and I have responded to each substantive comment promptly.  It would be great to merge this pull request to avoid the need for more merges.

> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:
> 
>> 1051:    * fetch will take place at index 1.
>> 1052:    *
>> 1053:    * @return The current position index.
> 
> Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

Thanks for pointing out the inconsistency.  I have fixed it.  (I noticed many violations of the official Javadoc style, but this is not the right pull request to fix them.)

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

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

From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Oh no what happened
![image](https://user-images.githubusercontent.com/8303399/192155378-4bb439fa-d27a-417d-8a3c-cf7f7329458f.png)

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:

> 1051:    * fetch will take place at index 1.
> 1052:    *
> 1053:    * @return The current position index.

Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

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

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

From alanb at openjdk.org  Sun Sep 25 17:04:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

src/java.base/share/native/libzip/zlib/zlib.h line 756:

> 754:    If this is done, the old level and strategy will be applied to the data
> 755:    compressed before deflateParams(), and the new level and strategy will be
> 756:    applied to the data compressed after deflateParams().

This is an issue for the upstream zlib project, we probably don't want to change it here.

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

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

From lancea at openjdk.org  Sun Sep 25 17:04:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
Message-ID: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>

On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> src/java.base/share/native/libzip/zlib/zlib.h line 756:
> 
>> 754:    If this is done, the old level and strategy will be applied to the data
>> 755:    compressed before deflateParams(), and the new level and strategy will be
>> 756:    applied to the data compressed after deflateParams().
> 
> This is an issue for the upstream zlib project, we probably don't want to change it here.

Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

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

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

From mernst at openjdk.org  Sun Sep 25 17:04:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
 <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
Message-ID: <rIuyz9yAlhyXwOpBnnAnmL0xQZbMk6bbr8QP4iogfzk=.33cce124-d245-46de-bb74-f3eaf9dbdfd8@github.com>

On Tue, 30 Aug 2022 09:55:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/native/libzip/zlib/zlib.h line 756:
>> 
>>> 754:    If this is done, the old level and strategy will be applied to the data
>>> 755:    compressed before deflateParams(), and the new level and strategy will be
>>> 756:    applied to the data compressed after deflateParams().
>> 
>> This is an issue for the upstream zlib project, we probably don't want to change it here.
>
> Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

OK.  I backed out the change to zlib.

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

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

From duke at openjdk.org  Sun Sep 25 17:23:28 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:23:28 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <l_BuZBAL5oEJ3CbI12q_XE9gFcXd-qEwGsRrSaIJDd0=.dea17f4e-b629-43e4-bc7e-47fccac4cb3a@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would.

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

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

From archie.cobbs at gmail.com  Sun Sep 25 21:02:32 2022
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 25 Sep 2022 16:02:32 -0500
Subject: 8043179: Lambda expression can mutate final field
Message-ID: <CANSoFxuKmroWOA9nzBvdj-3Mcc0fvJNd3v_djDJZaYdkyDW6Qg@mail.gmail.com>

Hi folks,

Hello, I'm new here.

As a result of trying to be less of a complainer and more of a problem
solver in life, I've decided to try to contribute fixes to some javac bugs
that have particularly annoyed me over the years.

Unfortunately I already screwed up and submitted my first PR before
discovering The OpenJDK Developer's Guide <http://openjdk.java.net/guide/>
- my apologies. A very handy reference!

Now I'm enlightened, and so first I need to backfill and...

2. Socialize your change
>
> Once the OCA is signed, please restrain your urge to create a PR just a
> little while longer. In order to prepare the community for your patch,
> please socialize your idea on the relevant mailing lists.
>

OK let's talk about this bug and this fix. The bug JDK-8043179
<https://bugs.openjdk.org/browse/JDK-8043179> is really due to a more
general problem with the JLS, which is described in JDK-8043176
<https://bugs.openjdk.org/browse/JDK-8043176>:

Chapter 16 is missing rules for handling DA/DU analysis of lambda
> expressions... To detect assignments to blank final fields, a field is
> *never* DU before the lambda body. (The intuition is that the timing of the
> body invocation is unknown, so we don't know whether the variable has been
> initialized or not.)
>

That spec bug was fixed a long time ago; now the spec says
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-16.html#jls-16.1.10>
:

> If an expression is a lambda expression, then the following rules apply:
>
>    -
>
>    V is [un]assigned after the expression iff V is [un]assigned before
>    the expression.
>    -
>
>    V is definitely assigned before the expression or block that is the
>    lambda body (?15.27.2
>    <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.27.2>)
>    iff V is definitely assigned before the lambda expression.
>
>    No rule allows V to be definitely unassigned before a lambda body.
>    This is by design: a variable that was definitely unassigned before the
>    lambda body may end up being assigned to later on, so we cannot conclude
>    that the variable will be unassigned when the body is executed.
>
> I'm not a JLS expert, so I'd appreciate confirmation, but what I think
this is in effect saying is that the DA/DU rules for what you can do with
instance fields in a lambda are the same as if that lambda were replaced
with the equivalent anonymous inner class - which would make perfect sense!
Here's an example of the existing discrepancy:

    import java.util.function.*;
    public class WhyAreTheseDifferent {
        final Object obj;

        final Supplier<Object> supplier1 = new Supplier<Object>() {
            @Override
            public Object get() {
                return WhyAreTheseDifferent.this.obj;  // no error here
            }
        };

        final Supplier<Object> supplier2 =
                       () -> { return this.obj; };     // error here

        WhyAreTheseDifferent(Object obj) {
            this.obj = obj;
        }
    }

If the above interpretation is correct, then the good news is that this is
an easy three line fix
<https://github.com/openjdk/jdk/pull/10381/files#diff-8973dfc1d0ee2ff1319d8753daec3f0be7e9bd0a63e9512c38a0eeed68e5bcaa>,
which is to ignore instance fields when performing DA/DU analysis, in
exactly the same way we do when visiting any normal non-initial-constructor
method during flow analysis (see this code in Flow.java
<https://github.com/openjdk/jdk/blob/3675f4c2afd10b5042948fc79e62caee5f3874ce/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java#L2287-L2291>
).

Thanks for any comments/feedback.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220925/9954cc14/attachment.htm>

From duke at openjdk.org  Sun Sep 25 21:06:32 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sun, 25 Sep 2022 21:06:32 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v3]
In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
Message-ID: <xchSg-JJaQ5cqw9WwwFAQQqRETPXtgfV0AXZuzMc-Ag=.2704de2a-5367-44b4-828f-2824edfe27f8@github.com>

> This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`.
> 
> This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this:
> 
> LambdaFieldInit.java:6: error: variable x might already have been assigned
>         Runnable r1 = () -> x = "hi";
>                             ^
> 
> 
> This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins).

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Move unit test into a more appropriate subdirectory.
 - Use /nodynamiccopyright/ for "golden file" test per instructions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10381/files
  - new: https://git.openjdk.org/jdk/pull/10381/files/47df9c96..6ae0fca3

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

  Stats: 54 lines in 4 files changed: 16 ins; 38 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10381.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381

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

From hannesw at openjdk.org  Mon Sep 26 12:36:23 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 26 Sep 2022 12:36:23 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v16]
In-Reply-To: <CifjHjhdcCCg3XYxa6NCJg7XPwgokwBR63UEQM9IUlA=.5022fb1f-a55a-49df-9e1e-447b53bc727b@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <CifjHjhdcCCg3XYxa6NCJg7XPwgokwBR63UEQM9IUlA=.5022fb1f-a55a-49df-9e1e-447b53bc727b@github.com>
Message-ID: <CyQK-DpTIc_j3EAMNK5noWjow6CFesTfD1BgWLVSoXE=.c19ab632-c50e-453a-9956-8b1b7c123c24@github.com>

On Fri, 23 Sep 2022 22:46:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update DPrinter

I don't know if you want to further discuss inheritability of the new tag, but the code looks good to me. I've also looked at the generated output and it also looks good.

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

Marked as reviewed by hannesw (Reviewer).

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

From joehw at openjdk.org  Mon Sep 26 16:16:34 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 16:16:34 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <pGtnJ74g_UpsFiU5TaZ6E9jk1p0koWYtWUaoecRoxxk=.e98efc77-50d4-4959-a289-23e6a54380b8@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

We have discussed several times in the past that we don't touch upstream (in this case, Apache) code unless the change is essential. In general, if you fix a bug in a class, it's fine to fix other non-essential things within the class, such as code styles, javadocs, typos as in this case, etc.  Otherwise, I would suggest you contribute such changes to the upstream projects.  Thanks.

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

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

From mernst at openjdk.org  Mon Sep 26 16:51:36 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Mon, 26 Sep 2022 16:51:36 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

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

 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

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

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=01
  Stats: 85 lines in 76 files changed: 0 ins; 0 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

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

From joehw at openjdk.org  Mon Sep 26 17:04:25 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 17:04:25 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <tTqHK2uU740KHuTMKapHnLcgfUbNs-4NqM-tQpds9HQ=.ba0b289d-011f-4f84-beeb-e20dd15a7d67@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Thanks for the update!

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

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

From lancea at openjdk.org  Mon Sep 26 19:38:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Sep 2022 19:38:20 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Thank you for your efforts on the cleaning up these typos

I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.  

I realize the changes are fairly trivial but this will most likely expedite getting your changes back

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

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

From jjg at openjdk.org  Mon Sep 26 21:07:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 26 Sep 2022 21:07:23 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v16]
In-Reply-To: <CyQK-DpTIc_j3EAMNK5noWjow6CFesTfD1BgWLVSoXE=.c19ab632-c50e-453a-9956-8b1b7c123c24@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <CifjHjhdcCCg3XYxa6NCJg7XPwgokwBR63UEQM9IUlA=.5022fb1f-a55a-49df-9e1e-447b53bc727b@github.com>
 <CyQK-DpTIc_j3EAMNK5noWjow6CFesTfD1BgWLVSoXE=.c19ab632-c50e-453a-9956-8b1b7c123c24@github.com>
Message-ID: <zAWykXk-DWbB0FVyxoPNX_1Kk4oQdegbE_Na9yu_KAM=.2df37ac5-e139-4ba4-8bb2-48042f97bc11@github.com>

On Mon, 26 Sep 2022 12:32:46 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> I don't know if you want to further discuss inheritability of the new tag, but the code looks good to me. I've also looked at the generated output and it also looks good.

I think of `@spec` as a highly specialized form of `@see` with the significant side effect of generating an extra summary page. So, I'm happy/OK that the support for inheritability is on a par with `@see`. It's not great, since it will only inherit one tag (!!) and you cannot specify which one, but the code is sufficiently similar so when we fix one (later) we should be able to easily fix the other.

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

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

From jjg at openjdk.org  Mon Sep 26 21:31:53 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 26 Sep 2022 21:31:53 GMT
Subject: Integrated: JDK-6251738: Want a top-level summary page that itemizes
 all spec documents referenced from javadocs (OEM spec)
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <1fCLKKNXfUNpMOJeld9cHXB0rPq9I3iGWVJE2TIf5Sg=.e23d4b7c-d1bd-49a0-ad7d-18050c3a20f5@github.com>

On Thu, 28 Apr 2022 02:05:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.

This pull request has now been integrated.

Changeset: b88ee1ee
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b88ee1ee22a4ea859f2a7bdf80a12c1d56fe6fd2
Stats:     1536 lines in 42 files changed: 1490 ins; 22 del; 24 mod

6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec)

Reviewed-by: hannesw

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

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

From amaembo at gmail.com  Tue Sep 27 10:03:32 2022
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 27 Sep 2022 12:03:32 +0200
Subject: Effectively final local variable cannot be declared as final
Message-ID: <CAE+3fjYyg6W=v9GJU2GoZTwKHV4c_08kQaBimKzUDaTgGx5jJA@mail.gmail.com>

Hello!

Consider the following code:

public class Demo {
    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            Runnable r = () -> System.out.println(i);
            r.run();
            break;
        }
    }
}

It can be compiled with javac (version 19), successfully executed and
prints 0. As only effectively final locals are allowed to be captured
in lambda, I conclude that `i` is effectively final. I also assumed
that for every effectively final variable, it's possible to write an
explicit `final` modifier. However, this is not the case. The
following code fails with the compilation error:

public class Demo {
    public static void main(String[] args) {
        for (final int i = 0; i < 10; i++) {
            Runnable r = () -> System.out.println(i);
            r.run();
            break;
        }
    }
}
Demo.java:3: error: cannot assign a value to final variable i
        for (final int i = 0; i < 10; i++) {
                                      ^
1 error
error: compilation failed

In my opinion, either both should be accepted or both should be
rejected. According to JLS 4.12.4, I'm inclined that both should be
rejected:

A local variable whose declarator has an initializer (?14.4.2) is
effectively final if all of the following are true:
- It is not declared final.
- It never occurs as the left hand side in an assignment expression
(?15.26). (Note that the local variable declarator containing the
initializer is not an assignment expression.)
- It never occurs as the operand of a prefix or postfix increment or
decrement operator (?15.14, ?15.15).

Here, `i` has an initializer and also occurs as the operand of prefix
increment, so it cannot be effectively final.

What do you think?

With best regards,
Tagir Valeev.

From sundararajan.athijegannathan at oracle.com  Tue Sep 27 13:22:36 2022
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 27 Sep 2022 13:22:36 +0000
Subject: Effectively final local variable cannot be declared as final
Message-ID: <DM6PR10MB2954E27FE6EFC0ACD8B31F0DEA559@DM6PR10MB2954.namprd10.prod.outlook.com>

Hi,

Thanks for reporting this issue.  Filed https://bugs.openjdk.org/browse/JDK-8294461

PS. This is in response to

https://mail.openjdk.org/pipermail/compiler-dev/2022-September/020481.html

-Sundar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220927/fbbe0240/attachment.htm>

From vromero at openjdk.org  Tue Sep 27 19:36:39 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 27 Sep 2022 19:36:39 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
Message-ID: <YJeb5lLP7CB6OW52xHUBgtlvYsaA4Xgtw9SufA1_GFI=.5734af4f-342e-43e9-bf5e-672bf7d15f3f@github.com>

On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Using a custom record instead of a generic Pair.
>  - Fixing test.
>  - Properly handle null record components.
>  - 8291769: Translation of switch with record patterns could be improved

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

> 716:                     Assert.checkNonNull(commonBinding);
> 717:                     Assert.checkNonNull(commonNestedExpression);
> 718:                     Assert.checkNonNull(commonNestedBinding);

nit: consider folding these three assertion checks into one.

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

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

From vromero at openjdk.org  Tue Sep 27 20:32:28 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 27 Sep 2022 20:32:28 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
Message-ID: <knWUm9lynt0cCck7RvcLgPwzzoDWJYpO9b8klkLB1Q4=.cadb4715-f749-46d7-8be3-8ae0ab1bcf99@github.com>

On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Using a custom record instead of a generic Pair.
>  - Fixing test.
>  - Properly handle null record components.
>  - 8291769: Translation of switch with record patterns could be improved

not strictly related to this patch but for this code:

record Box(Object o) {}

class Test {
    private int test(Object obj) {
        return switch (obj) {
            case Box(String s) -> 0;
            case Box(Integer i) -> 0;
            case Box(Number n) -> 0;
            case Box(CharSequence cs) -> 0;

            default -> -1;
        };
    }
}

after compiling it without the preview options set as in: `javac Test.java`, javac issues two errors in the same line:


Test.java:6: error: patterns in switch statements are a preview feature and are disabled by default.
            case Box(String s) -> 0;
                 ^
  (use --enable-preview to enable patterns in switch statements)
Test.java:6: error: deconstruction patterns are a preview feature and are disabled by default.
            case Box(String s) -> 0;
                    ^
  (use --enable-preview to enable deconstruction patterns)
2 errors

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

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

From vromero at openjdk.org  Tue Sep 27 20:41:27 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 27 Sep 2022 20:41:27 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
Message-ID: <zffnYObSUrP8YE8vo_2bQAD_B5dkTVvyXGaVNNgKwJE=.7725dcff-0cf4-4cb5-8392-6bb2845a2ce3@github.com>

On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Using a custom record instead of a generic Pair.
>  - Fixing test.
>  - Properly handle null record components.
>  - 8291769: Translation of switch with record patterns could be improved

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

> 401:                     ? syms.objectType
> 402:                     : selector.type;
> 403:             Assert.check(preview.isEnabled());

side: not part of your patch but, do we need to check if preview is enabled at this point?

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

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

From maurizio.cimadamore at oracle.com  Tue Sep 27 21:25:29 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 27 Sep 2022 22:25:29 +0100
Subject: Effectively final local variable cannot be declared as final
In-Reply-To: <CAE+3fjYyg6W=v9GJU2GoZTwKHV4c_08kQaBimKzUDaTgGx5jJA@mail.gmail.com>
References: <CAE+3fjYyg6W=v9GJU2GoZTwKHV4c_08kQaBimKzUDaTgGx5jJA@mail.gmail.com>
Message-ID: <e20265c2-653c-e95e-60e2-d1c7ed0a6267@oracle.com>

Hi Tagir,
I believe this is a bug in how the compiler determines effective 
finality. Javac does this while computing DA/DU. This is because locals 
that are assigned "at most once" are considered effectively final (as 
per the JLS).

In the case of for loop, the DA/DU logic is tripping us up: when we see 
the initializer of "i" in the for loop, we know that "i" is DA and not 
DU. But then we scan the loop body, and there's a break. And, per JLS, 
after a break, any variable is both DA and DU. In other words, the DA/DU 
status is reset.

That means that, by the time we reach "i++", javac thinks it's an 
assignment to a variable that is still DU, so the assignment will not 
make the variable lose its effectively final status.

In a way, what the compiler does is correct - the variable is assigned 
only once, and can only have value 0, but I agree that there's an 
inconsistency with the JLS and, more broadly, with what happens if you 
add an explicit "final". There is also some code in Flow to deal with 
assignment of "final" variables in loop, for instance in cases like this:

```
final int x;
for (int i = 0; i < 10 ; i++) {
 ?? x = 2; // error: variable might be assigned in loop
}
```

And the logic is exactly the same as the one we use for effectively 
final. But variables declared as `final` also gets an extra check in an 
earlier compiler pass (Attr), which simply looks at assignments, and if 
the target of the assignment is final, then it reports an error (and 
that's where the discrepancy comes from).

It looks like the javac logic based on DA/DU should be dialled back a 
bit to only be applied in cases when the variable doesn't have an 
initializer.

Thanks
Maurizio


On 27/09/2022 11:03, Tagir Valeev wrote:
> Hello!
>
> Consider the following code:
>
> public class Demo {
>      public static void main(String[] args) {
>          for (int i = 0; i < 10; i++) {
>              Runnable r = () -> System.out.println(i);
>              r.run();
>              break;
>          }
>      }
> }
>
> It can be compiled with javac (version 19), successfully executed and
> prints 0. As only effectively final locals are allowed to be captured
> in lambda, I conclude that `i` is effectively final. I also assumed
> that for every effectively final variable, it's possible to write an
> explicit `final` modifier. However, this is not the case. The
> following code fails with the compilation error:
>
> public class Demo {
>      public static void main(String[] args) {
>          for (final int i = 0; i < 10; i++) {
>              Runnable r = () -> System.out.println(i);
>              r.run();
>              break;
>          }
>      }
> }
> Demo.java:3: error: cannot assign a value to final variable i
>          for (final int i = 0; i < 10; i++) {
>                                        ^
> 1 error
> error: compilation failed
>
> In my opinion, either both should be accepted or both should be
> rejected. According to JLS 4.12.4, I'm inclined that both should be
> rejected:
>
> A local variable whose declarator has an initializer (?14.4.2) is
> effectively final if all of the following are true:
> - It is not declared final.
> - It never occurs as the left hand side in an assignment expression
> (?15.26). (Note that the local variable declarator containing the
> initializer is not an assignment expression.)
> - It never occurs as the operand of a prefix or postfix increment or
> decrement operator (?15.14, ?15.15).
>
> Here, `i` has an initializer and also occurs as the operand of prefix
> increment, so it cannot be effectively final.
>
> What do you think?
>
> With best regards,
> Tagir Valeev.

From vromero at openjdk.org  Tue Sep 27 23:05:19 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 27 Sep 2022 23:05:19 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
Message-ID: <Dv5qkf9B4AB6jp7lcv89OaF9AxuUP5jJ94a5cKcoA0g=.05c4c265-d674-40a5-abf9-92eac3bc6828@github.com>

On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Using a custom record instead of a generic Pair.
>  - Fixing test.
>  - Properly handle null record components.
>  - 8291769: Translation of switch with record patterns could be improved

another side comment but given that we are retouching this code, I'm seeing that TransPatterns is a phase that is run always regardless of the presence or not of patterns. Shouldn't we do something similar as for LambdaToMethod that is executed only if there are lambdas? Of course there is no need to address this as part of this patch

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

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

From mernst at openjdk.org  Tue Sep 27 23:16:16 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Sep 2022 23:16:16 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
Message-ID: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>

On Mon, 26 Sep 2022 19:36:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Thank you for your efforts on the cleaning up these typos
> 
> I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.
> 
> I realize the changes are fairly trivial but this will most likely expedite getting your changes back

Feel free to break up the pull request if that is what is needed to free it from red tape.
Thanks.

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

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

From vromero at openjdk.org  Tue Sep 27 23:42:21 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 27 Sep 2022 23:42:21 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
Message-ID: <5wmYANFtMHXPXR2oHon2AeKw8JSG2Adp6NEFMBpnoyc=.fe9329d9-bbe3-411f-87a7-615770c319dd@github.com>

On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Using a custom record instead of a generic Pair.
>  - Fixing test.
>  - Properly handle null record components.
>  - 8291769: Translation of switch with record patterns could be improved

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

> 367:             nestedPatterns = nestedPatterns.tail;
> 368:         }
> 369:         Assert.check(components.isEmpty() == nestedPatterns.isEmpty());

is it possible for this assertion not to hold under some conditions? can it be removed?

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

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

From vromero at openjdk.org  Wed Sep 28 01:04:44 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Sep 2022 01:04:44 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
Message-ID: <nMrdMG7T53P8YZHaepZiA6X0M_UywoLZBoG-qr52_2c=.1c0cb5e7-25e5-49f1-9710-985d0afecb72@github.com>

On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Using a custom record instead of a generic Pair.
>  - Fixing test.
>  - Properly handle null record components.
>  - 8291769: Translation of switch with record patterns could be improved

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

> 788: 
> 789:             if (c.head.labels.size() == 1 &&
> 790:                 c.head.labels.head instanceof JCPatternCaseLabel patternLabel &&

nit:

               (c.head.labels.size() == 1 &&
                c.head.labels.head instanceof JCPatternCaseLabel patternLabel)

seems to be a common condition that could be evaluated twice in this `if` and in the one in the `else if` below, consider evaluating it only once

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

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

From vromero at openjdk.org  Wed Sep 28 03:03:43 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Sep 2022 03:03:43 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
Message-ID: <fCL-ZxRKdCbidAoJxbpXajgsXmPb2R8oyFOg8MR6cew=.dab2619c-6249-42d1-bf5a-e4892f3a0d6f@github.com>

On Tue, 20 Sep 2022 13:33:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Using a custom record instead of a generic Pair.
>  - Fixing test.
>  - Properly handle null record components.
>  - 8291769: Translation of switch with record patterns could be improved

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

> 817:                 }
> 818:             } else if (currentBinding != null &&
> 819:                        commonBinding.type.tsym == currentBinding.type.tsym &&

question, what about having a map relating commonBindings and accumulators, shouldn't this allow you to group common patterns even if they are not consecutive?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 648:

> 646:         result =
> 647:                 scan(tree.mods, that.mods)
> 648:                         && (tree.name == that.name || synthetic)

I think that considering two variables equal if one is synthetic should be something that probably shouldn't occur by default, IMO there should be a way for clients of `TreeDiffer` to op-in if they want this behavior

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

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

From dfuchs at openjdk.org  Wed Sep 28 13:24:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 13:24:26 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
 <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
Message-ID: <aY7BXF5EIYZFFZcE_IWj3PwKjQLD35cJPnaJkvQpQmU=.5464c3b4-6a6b-4841-b24f-969b371dfc74@github.com>

On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Feel free to break up the pull request if that is what is needed to free it from red tape.

Only you can do that @mernst

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

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

From mernst at openjdk.org  Wed Sep 28 14:49:20 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 14:49:20 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Regarding breaking up the pull request:
 * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
 * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
 * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.

I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to corrections.

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

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

From dfuchs at openjdk.org  Wed Sep 28 15:13:39 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 15:13:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
Message-ID: <kTzLFBRbJQt3hKHD094hV-0zXH9FY4Fg2wdrOvFeK34=.c79081a5-df9a-4ea0-b481-19f903f56bd9@github.com>

On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> Regarding breaking up the pull request:
>  * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
>  * Despite my repeated requests, no one has justified that *this particular pull request* needs the expertise of different teams.  The only reasons stated have been custom and bureaucracy.
>  * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
>  * I was condescendingly told "We have discussed several times in the past ..." even though I was not privy to those discussions.  No pointer to documentation in the JDK itself, about pull requests, was given.
>  * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.
> 
> I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to contributions.

Hi @mernst, sorry if this is how it appears. Pull requests that involve changes spanning a large set of files are notoriously harder to review since they require a reviewer from each different area to chime in. Basically you will need one reviewer from each of these areas:

-     client
-     compiler
-     core-libs
-     hotspot
-     i18n
-     javadoc
-     jmx
-     net
-     nio
-     security
-     serviceability

Jaikiran suggested to reduce the scope of this PR in his first comment:
https://github.com/openjdk/jdk/pull/10029#issuecomment-1236588632

as did several other reviewers. Sorry if the meaning (or reason) was not clear.

best regards,

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

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

From aivanov at openjdk.org  Wed Sep 28 15:28:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 15:28:24 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

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

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

From mernst at openjdk.org  Wed Sep 28 15:35:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 15:35:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
Message-ID: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>

On Wed, 28 Sep 2022 15:26:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

The title was edited by someone other than me, as you can see from the PR history.

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

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

From duke at openjdk.org  Wed Sep 28 16:45:10 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 28 Sep 2022 16:45:10 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v4]
In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
Message-ID: <Sn3lkTTC7YWeD40MGEqTLT9MJcfWRlqnVvxXZdPN5oc=.f5b51774-a1f8-420d-861c-a3cf7e92176c@github.com>

> This patch causes lambdas to be treated like non-constructor methods with respect to field initialization in `Flow.AssignAnalyzer`.
> 
> This fixes [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179); the test program in the bug now gives this:
> 
> LambdaFieldInit.java:6: error: variable x might already have been assigned
>         Runnable r1 = () -> x = "hi";
>                             ^
> 
> 
> This also aligns the compiler with the proposed spec fix in [JDK-8043176](https://bugs.openjdk.org/browse/JDK-8043176) and fixes the inconsistency between lambdas and inner class methods shown [here](https://stackoverflow.com/questions/39881295/why-are-java-lambdas-treated-differently-from-nested-classes-with-respect-to-ins).

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Fix @author in test to match github username per instructions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10381/files
  - new: https://git.openjdk.org/jdk/pull/10381/files/6ae0fca3..b7bc0b6d

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

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

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

From jjg at openjdk.org  Wed Sep 28 22:45:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 28 Sep 2022 22:45:32 GMT
Subject: RFR: JDK-8293877: Rewrite MineField test
In-Reply-To: <UkCYNqu49atx8jltGrpSJRmNfl9XVGf0n_yzzWv-QnM=.ebde4e31-bff7-44de-96e5-8c1480cf9b85@github.com>
References: <sYd9zJCF6N8-lM_G9lwzWQdQts2diPVWTSGKtRc1AjE=.c06c13e4-609a-47a2-ab96-25a257532d89@github.com>
 <UkCYNqu49atx8jltGrpSJRmNfl9XVGf0n_yzzWv-QnM=.ebde4e31-bff7-44de-96e5-8c1480cf9b85@github.com>
Message-ID: <l2y71zPRZ4T3T404dtv9nMvgWSZoWn6Y_KAFzUOSaBs=.b5ef219a-3453-4dbe-b1b5-a02ea5421672@github.com>

On Thu, 22 Sep 2022 19:20:38 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> Explicit OS command invocation and ToolProvider invocation both seem important to test. IIRC there were times when they were not in fact equivalent in effect. Consider library infrastructure to run both variants and ensure results are identical.
> 

@Martin-Buchholz 
Thanks for the feedback. While I understand what you are suggesting, I think it is potentially for a different test.

The goal here was to try and do a reasonably direct translation of the original code from shell to Java. And OK, I did do some minor optimizations to use javac's `ToolProvider` where possible, to save exec-ing processes unnecessarily.

Rewriting the test to do both (where that is even possible) would either be a significant rewrite or maybe involve running all of the test twice, in both modes. 

And, for javac, it might be even worse, because there is the `javax.tools.JavaCompiler` API as well.

There is no reason to suspect the functionality might be semantically different in these different ways to invoke javac. Once you get down into the compiler, the code paths are the same.   The difference is the _availability_ of features ... such as the _classpath wildcard_ feature, which is only available when using the native launcher.   So, if we were to write anything more in the way of tests, it would be to test the specified difference in availability of the features, without necessarily exercising the full functionality and comparing everything against the launcher for the Java runtime, `java`.

One other outcome from the overall work here: as a result of (re)discovering the _classpath wildcard_ feature, we realized that there were enough differences between the native launcher and the `ToolProvider` interface (and `JavaCompiler`) to justify a spec update for the `idk.compiler` module. This is being tracked in [JDK-8294546](https://bugs.openjdk.org/browse/JDK-8294546).

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

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

From jlahoda at openjdk.org  Thu Sep 29 14:29:58 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 29 Sep 2022 14:29:58 GMT
Subject: RFR: 8294550: Sealed check for casts isn't applied to array components
Message-ID: <km9-ISdPmzINoV_8Y8ICPFw8b9xahkN8Rqo-SIM9aeA=.95337522-b77b-4300-88e5-3d7dd0db7dd3@github.com>

For code like:

sealed interface I permits A {}
final class A implements I {}
interface J {}

J j = null;
I i = (I) j; //error reported here, as no instance of J can implement I
J[] jj = null;
I[] i = (I[]) jj; //incorrectly no error reported here, despite JLS saying there must be a narrowing conversion from J to I in this case, which there isn't as per the case above


The cause for this is that we check the sealed constraints at the end of `Types.isCastable`, and only for classes, not for arrays. It would be possible to enhance the check to include array types, but feels clearer and more reliable to recurse, and do a full castability check on the element types.

A sketch of a CSR is here:
https://bugs.openjdk.org/browse/JDK-8294586

Feedback is welcome!

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

Commit messages:
 - 8294550: Sealed check for casts isn't applied to array components

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

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

From archie.cobbs at gmail.com  Thu Sep 29 17:54:06 2022
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 29 Sep 2022 12:54:06 -0500
Subject: 8043179: Lambda expression can mutate final field
In-Reply-To: <CANSoFxuKmroWOA9nzBvdj-3Mcc0fvJNd3v_djDJZaYdkyDW6Qg@mail.gmail.com>
References: <CANSoFxuKmroWOA9nzBvdj-3Mcc0fvJNd3v_djDJZaYdkyDW6Qg@mail.gmail.com>
Message-ID: <CANSoFxtmVJJFAKToW5XdNJQP87uZ-QjWQzwKgmDMdvZepCVS4g@mail.gmail.com>

Hi folks,

On Sun, Sep 25, 2022 at 4:02 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> then the good news is that this is an easy three line fix
> <https://github.com/openjdk/jdk/pull/10381/files#diff-8973dfc1d0ee2ff1319d8753daec3f0be7e9bd0a63e9512c38a0eeed68e5bcaa>
>

I'm still looking for any thoughts or comments on this proposed fix for
8043179.

I'm also looking for someone who is willing to consider being a sponsor for
me. I've got this PR and a couple of other fixes in the hopper. In return I
promise to be a good listener and hopefully a net positive contributor.

Also, I have a question - is anyone else having trouble building the JDK on
macos 12.6 and Xcode 14.0?

I'm getting two build failures in the latest code
jdk-20+17-23-g0d8e3ce6b6e, one in GTest and one in JniInvocationTest.

The GTest build errors start like this:

Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s)
In file included from /Users/archie/proj/googletest/
googlemock/src/gmock-all.cc:39:
In file included from /Users/archie/proj/googletest/
googlemock/include/gmock/gmock.h:59:
/Users/archie/proj/googletest/googlemock/include/gmock/gmock-actions.h:484:3:
error: definition of implicit copy constructor for
'PolymorphicAction<testing::internal::ReturnNullAction>' is deprecated
because it has a user-declared copy assignment operator
[-Werror,-Wdeprecated-copy]
  GTEST_DISALLOW_ASSIGN_(PolymorphicAction);
  ^
/Users/archie/proj/googletest/googletest/include/gtest/internal/gtest-port.h:928:8:
note: expanded from macro 'GTEST_DISALLOW_ASSIGN_'
  void operator=(type const &) GTEST_CXX11_EQUALS_DELETE_
       ^
/Users/archie/proj/googletest/googlemock/include/gmock/gmock-actions.h:1125:10:
note: in implicit copy constructor for 'testing::PolymorphicAction<
testing::internal::ReturnNullAction>' first required here
  return MakePolymorphicAction(internal::ReturnNullAction());
         ^

These are the JniInvocationTest errors:

Creating support/test/jdk/jtreg/native/bin/JniInvocationTest from 1 file(s)
/Users/archie/proj/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132:
error: parameter 'SizeOfTag' set but not used
[-Werror,-Wunused-but-set-parameter]
void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self,
cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)

                                                       ^
/Users/archie/proj/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125:
error: parameter 'SizeOfTag' set but not used
[-Werror,-Wunused-but-set-parameter]
void *Type_Dictionary_Read(struct _cms_typehandler_struct* self,
cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)

                                                ^
2 errors generated.

The latter error is easy to workaround. I haven't tried fixing the former.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220929/cf948140/attachment.htm>

From darcy at openjdk.org  Fri Sep 30 00:40:24 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 00:40:24 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
Message-ID: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>

With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.

Updates were made using a shell script. I"ll run a copyright updater before any push.

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

Commit messages:
 - JDK-8294618: Update openjdk.java.net => openjdk.org

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

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

From darcy at openjdk.org  Fri Sep 30 00:54:05 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 00:54:05 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright.
 - Revert unintended update to binary file.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/b12d774f..2f257762

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

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

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

From mikael at openjdk.org  Fri Sep 30 00:54:08 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 30 Sep 2022 00:54:08 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>

On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Switch to https where needed/applicable while at it?

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

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

From mikael at openjdk.org  Fri Sep 30 00:54:06 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 30 Sep 2022 00:54:06 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
In-Reply-To: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>
Message-ID: <dFUTds1k1M7DaK_xGvMGBDegFeXy76CIcZ_PLh6gYC4=.188412c8-2ca0-42bb-a284-910d88d53422@github.com>

On Fri, 30 Sep 2022 00:50:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright.
>  - Revert unintended update to binary file.

Marked as reviewed by mikael (Reviewer).

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

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

From darcy at openjdk.org  Fri Sep 30 01:01:29 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:01:29 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v3]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <boxVctVZD3zFCVCc9kH4kEwNs-yE1UY9fP1YMTqCWlc=.171a92b3-ddf2-4e51-b3ec-ae5c5a265487@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

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

  Undo manpage update.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/2f257762..04dfc3ef

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

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

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

From darcy at openjdk.org  Fri Sep 30 01:11:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:11:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

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

  http -> https

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/04dfc3ef..cee96d0a

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

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

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

From darcy at openjdk.org  Fri Sep 30 01:11:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:11:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>
Message-ID: <uBCZJHk7h3OFdIKNzXs7DXXlCJUbhiSGt7HZOnDf51Q=.c58467fe-b9cd-4edf-83af-ae99c17c196a@github.com>

On Fri, 30 Sep 2022 00:48:02 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Switch to https where needed/applicable while at it?

Good idea; might as well do the update in a single changeset.

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

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

From iris at openjdk.org  Fri Sep 30 04:11:19 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 30 Sep 2022 04:11:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

Marked as reviewed by iris (Reviewer).

src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:

> 32:  * the following link:
> 33:  *
> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c

The domain for hg wasn't changed to openjdk.org.  The original URL is correct.

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

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

From jlahoda at openjdk.org  Fri Sep 30 12:21:58 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 30 Sep 2022 12:21:58 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v7]
In-Reply-To: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
Message-ID: <rsZ3O6gOPGAi_K8OZ_xA9QHgVQxt2bpXDJkTq8GOEWw=.31feb432-60d1-429c-960e-5b9839193912@github.com>

> This is an attempt to improve the performance and scalability of switches with record patterns.
> 
> There are two main parts of this patch:
> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
> 
> switch (obj) {
>      case Box(String s) -> {}
>      case Box(Integer i) -> {}
>      case Box(Number n) -> {}
>      ...
> }
> =>
> switch (obj) {
>      case Box b ->
>           switch (b.o()) {
>               case String s -> {}
>               case Integer i -> {}
>               case Number n -> {}
>               default -> continue-with-outer-switch;
>           };
>     ...
> }
> 
> 
> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
> 
> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
> 
> I ran the new code through a JMH benchmark:
> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
> 
> The results are:
>  - for "long" testcase (a switch with many cases):
> 
> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
> 
>  - for "short" testcase (a switch with no so many cases):
> 
> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
> 
> 
> So, the performance seems to be improved, at least in these cases.
> 
> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).

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

 - Reflecting review feedback.
 - Merge branch 'master' into JDK-8291769
 - Merge branch 'master' into JDK-8291769
 - Merge branch 'master' into JDK-8291769
 - Reflecting review feedback.
 - Merge branch 'master' into JDK-8291769
 - Using a custom record instead of a generic Pair.
 - Fixing test.
 - Properly handle null record components.
 - 8291769: Translation of switch with record patterns could be improved

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

Changes: https://git.openjdk.org/jdk/pull/9746/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=06
  Stats: 1458 lines in 13 files changed: 1277 ins; 83 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/9746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9746/head:pull/9746

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

From jlahoda at openjdk.org  Fri Sep 30 12:26:24 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 30 Sep 2022 12:26:24 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v7]
In-Reply-To: <rsZ3O6gOPGAi_K8OZ_xA9QHgVQxt2bpXDJkTq8GOEWw=.31feb432-60d1-429c-960e-5b9839193912@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <rsZ3O6gOPGAi_K8OZ_xA9QHgVQxt2bpXDJkTq8GOEWw=.31feb432-60d1-429c-960e-5b9839193912@github.com>
Message-ID: <TyovelfTOFe_ha4tEsj2EfaWWCpyo7BcB_Sons9hC-w=.93264177-1252-41f7-9688-696690866d9c@github.com>

On Fri, 30 Sep 2022 12:21:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Using a custom record instead of a generic Pair.
>  - Fixing test.
>  - Properly handle null record components.
>  - 8291769: Translation of switch with record patterns could be improved

Thanks for all the comments! I've reflected the feedback here:
https://github.com/openjdk/jdk/pull/9746/commits/4f9f7f9859c98f6312675455bdfa02f02b0015c7

and added additional comments.

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

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

From jlahoda at openjdk.org  Fri Sep 30 12:26:27 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 30 Sep 2022 12:26:27 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <5wmYANFtMHXPXR2oHon2AeKw8JSG2Adp6NEFMBpnoyc=.fe9329d9-bbe3-411f-87a7-615770c319dd@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
 <5wmYANFtMHXPXR2oHon2AeKw8JSG2Adp6NEFMBpnoyc=.fe9329d9-bbe3-411f-87a7-615770c319dd@github.com>
Message-ID: <_fgFAvWJj_xpfQAVG1AWxKviTm7mzyy2N43gFagAPHs=.3ee0a962-a0cf-4cb0-811d-a56b08a18073@github.com>

On Tue, 27 Sep 2022 23:40:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into JDK-8291769
>>  - Merge branch 'master' into JDK-8291769
>>  - Reflecting review feedback.
>>  - Merge branch 'master' into JDK-8291769
>>  - Using a custom record instead of a generic Pair.
>>  - Fixing test.
>>  - Properly handle null record components.
>>  - 8291769: Translation of switch with record patterns could be improved
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 369:
> 
>> 367:             nestedPatterns = nestedPatterns.tail;
>> 368:         }
>> 369:         Assert.check(components.isEmpty() == nestedPatterns.isEmpty());
> 
> is it possible for this assertion not to hold under some conditions? can it be removed?

This is mostly to ensure that if there would be a bug in `Attr` that would not produce an error in case the number of record components, and the number of nested patterns would not match, javac will fail consistently.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 403:
> 
>> 401:                     ? syms.objectType
>> 402:                     : selector.type;
>> 403:             Assert.check(preview.isEnabled());
> 
> side: not part of your patch but, do we need to check if preview is enabled at this point?

The ordinary checks should have happened in the parser and/or `Attr`, this is mostly s safeguard in case some of the checks would be missing for any reason.

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

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

From jlahoda at openjdk.org  Fri Sep 30 12:33:31 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 30 Sep 2022 12:33:31 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <fCL-ZxRKdCbidAoJxbpXajgsXmPb2R8oyFOg8MR6cew=.dab2619c-6249-42d1-bf5a-e4892f3a0d6f@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
 <fCL-ZxRKdCbidAoJxbpXajgsXmPb2R8oyFOg8MR6cew=.dab2619c-6249-42d1-bf5a-e4892f3a0d6f@github.com>
Message-ID: <0ZmUt3AJoNdEPvMML_-HCaruEBJ0YbRhDltKr2ASH5g=.5cc148f0-a115-4aef-a54b-f510dadbf86f@github.com>

On Wed, 28 Sep 2022 03:00:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into JDK-8291769
>>  - Merge branch 'master' into JDK-8291769
>>  - Reflecting review feedback.
>>  - Merge branch 'master' into JDK-8291769
>>  - Using a custom record instead of a generic Pair.
>>  - Fixing test.
>>  - Properly handle null record components.
>>  - 8291769: Translation of switch with record patterns could be improved
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 819:
> 
>> 817:                 }
>> 818:             } else if (currentBinding != null &&
>> 819:                        commonBinding.type.tsym == currentBinding.type.tsym &&
> 
> question, what about having a map relating commonBindings and accumulators, shouldn't this allow you to group common patterns even if they are not consecutive?

This would mean we would change the order of the cases, which is something I'd like to avoid in this patch, for several reasons. Partly because there's a fairly big set of cases where it is unclear if we can do the reordering (and the exact rules when we can do reordering are debatable, and sometimes depend on very particular aspects of the spec), and partly because this patch seems complex enough without reordering.

One possibility we could do case reordering as a separate step before coalescing the prefixes, as simple use of map would not necessarily allow to avoid coalescing in cases like:

switch (o) {
     case I1 i when <condition1> -> {}
     case I2 i when <condition2> -> {}
     case I1 i when <condition3> -> {}
}

(where `I1` and `I2` are unrelated interfaces, we cannot easily change the order of the cases here, as `o` may be an object that implements both, and `<condition1>` might be `false`).

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

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

From ihse at openjdk.org  Fri Sep 30 14:01:18 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Sep 2022 14:01:18 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

$ grep -rl doc make -e openjdk.java.net
doc/hotspot-unit-tests.html
doc/hotspot-style.html
doc/building.html
doc/hotspot-unit-tests.md
doc/hotspot-style.md
doc/building.md
make/Doctor.gmk
make/jdk/src/classes/build/tools/taglet/Incubating.java
make/autoconf/configure.ac
make/conf/branding.conf


Think you can fix those as well?

Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

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

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

From weijun at openjdk.org  Fri Sep 30 14:18:28 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 Sep 2022 14:18:28 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
Message-ID: <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>

On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   http -> https
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
> 
>> 32:  * the following link:
>> 33:  *
>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> 
> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.

Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?

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

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

From vromero at openjdk.org  Fri Sep 30 15:19:23 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 Sep 2022 15:19:23 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v6]
In-Reply-To: <0ZmUt3AJoNdEPvMML_-HCaruEBJ0YbRhDltKr2ASH5g=.5cc148f0-a115-4aef-a54b-f510dadbf86f@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <BS0Ldsg_fp_Gw-db_eQawloYUM_cCUF6-JBr7G09spU=.f14444a8-03de-4419-958d-d2bb1696d43b@github.com>
 <fCL-ZxRKdCbidAoJxbpXajgsXmPb2R8oyFOg8MR6cew=.dab2619c-6249-42d1-bf5a-e4892f3a0d6f@github.com>
 <0ZmUt3AJoNdEPvMML_-HCaruEBJ0YbRhDltKr2ASH5g=.5cc148f0-a115-4aef-a54b-f510dadbf86f@github.com>
Message-ID: <naPlZHU64ErQbiV05bG8z5ysOMft70y0EClTeaAIq8E=.ad588539-96b9-47e2-9204-c5a8f9326bdd@github.com>

On Fri, 30 Sep 2022 12:31:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 819:
>> 
>>> 817:                 }
>>> 818:             } else if (currentBinding != null &&
>>> 819:                        commonBinding.type.tsym == currentBinding.type.tsym &&
>> 
>> question, what about having a map relating commonBindings and accumulators, shouldn't this allow you to group common patterns even if they are not consecutive?
>
> This would mean we would change the order of the cases, which is something I'd like to avoid in this patch, for several reasons. Partly because there's a fairly big set of cases where it is unclear if we can do the reordering (and the exact rules when we can do reordering are debatable, and sometimes depend on very particular aspects of the spec), and partly because this patch seems complex enough without reordering.
> 
> One possibility we could do case reordering as a separate step before coalescing the prefixes, as simple use of map would not necessarily allow to avoid coalescing in cases like:
> 
> switch (o) {
>      case I1 i when <condition1> -> {}
>      case I2 i when <condition2> -> {}
>      case I1 i when <condition3> -> {}
> }
> 
> (where `I1` and `I2` are unrelated interfaces, we cannot easily change the order of the cases here, as `o` may be an object that implements both, and `<condition1>` might be `false`).

got it I agree, thanks

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

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

From vromero at openjdk.org  Fri Sep 30 15:27:34 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 Sep 2022 15:27:34 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v7]
In-Reply-To: <rsZ3O6gOPGAi_K8OZ_xA9QHgVQxt2bpXDJkTq8GOEWw=.31feb432-60d1-429c-960e-5b9839193912@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <rsZ3O6gOPGAi_K8OZ_xA9QHgVQxt2bpXDJkTq8GOEWw=.31feb432-60d1-429c-960e-5b9839193912@github.com>
Message-ID: <8T5xnwzlgKq6moiq676hwAtxQjuUrKtMbUlkXYjLvig=.005b7697-825f-4e22-8d61-63474d2df2fa@github.com>

On Fri, 30 Sep 2022 12:21:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Using a custom record instead of a generic Pair.
>  - Fixing test.
>  - Properly handle null record components.
>  - 8291769: Translation of switch with record patterns could be improved

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.org  Fri Sep 30 16:30:30 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 Sep 2022 16:30:30 GMT
Subject: RFR: 8294550: Sealed check for casts isn't applied to array
 components
In-Reply-To: <km9-ISdPmzINoV_8Y8ICPFw8b9xahkN8Rqo-SIM9aeA=.95337522-b77b-4300-88e5-3d7dd0db7dd3@github.com>
References: <km9-ISdPmzINoV_8Y8ICPFw8b9xahkN8Rqo-SIM9aeA=.95337522-b77b-4300-88e5-3d7dd0db7dd3@github.com>
Message-ID: <sKQYnI7oyK-SakZr7NoT4-vuLOV4DXy31JujLPykSc0=.88af4d4e-a212-44c9-b418-65020dd3f024@github.com>

On Thu, 29 Sep 2022 14:24:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like:
> 
> sealed interface I permits A {}
> final class A implements I {}
> interface J {}
> 
> J j = null;
> I i = (I) j; //error reported here, as no instance of J can implement I
> J[] jj = null;
> I[] i = (I[]) jj; //incorrectly no error reported here, despite JLS saying there must be a narrowing conversion from J to I in this case, which there isn't as per the case above
> 
> 
> The cause for this is that we check the sealed constraints at the end of `Types.isCastable`, and only for classes, not for arrays. It would be possible to enhance the check to include array types, but feels clearer and more reliable to recurse, and do a full castability check on the element types.
> 
> A sketch of a CSR is here:
> https://bugs.openjdk.org/browse/JDK-8294586
> 
> Feedback is welcome!

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From prr at openjdk.org  Fri Sep 30 17:42:29 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 17:42:29 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
Message-ID: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>

On Fri, 30 Sep 2022 14:16:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
>> 
>>> 32:  * the following link:
>>> 33:  *
>>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
>> 
>> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.
>
> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?

This is correct.
AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

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

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

From joehw at openjdk.org  Fri Sep 30 18:12:25 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 30 Sep 2022 18:12:25 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <e9sYCA3vCcVdXUjRRnPbEK3Z7Ik5WANQMziL6OStdts=.aa1ad3f4-5d91-485d-b48f-3c59579f1869@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

The ones in java.xml look good to me.

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

Marked as reviewed by joehw (Reviewer).

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

From vromero at openjdk.org  Fri Sep 30 18:38:16 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 Sep 2022 18:38:16 GMT
Subject: RFR: JDK-8293877: Rewrite MineField test
In-Reply-To: <sYd9zJCF6N8-lM_G9lwzWQdQts2diPVWTSGKtRc1AjE=.c06c13e4-609a-47a2-ab96-25a257532d89@github.com>
References: <sYd9zJCF6N8-lM_G9lwzWQdQts2diPVWTSGKtRc1AjE=.c06c13e4-609a-47a2-ab96-25a257532d89@github.com>
Message-ID: <vhNkhEBxUwigEaOW_ejsO95z9ER6yN691_QgFZsj7-0=.dc4ea1ca-d656-48cc-8d08-ebb6996422a6@github.com>

On Wed, 21 Sep 2022 00:57:22 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code.
> 
> This will be an awkward/difficult/tedious (choose your adjective) review.  The old files have been deleted, and the new code is different enough to defeat any `diff` program.  That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter.  It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together.
> 
> The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience.
> 
> Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`.
> 
> The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation.
> 
> Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature.
> 
> On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed.  But any change would be a difference in the old and new code, and should arguably be done separately.  So, the existence and use of `cleanup` methods is as before.
> 
> Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code.
> 
> The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort.  
> 
> Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests.  For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases.
> 
> Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR.

test/langtools/tools/javac/Paths/ClassPath.java line 130:

> 128: 
> 129:         /*
> 130:          * The following lines are commented out in the original,

I think these old comments could be removed

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

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

From darcy at openjdk.org  Fri Sep 30 20:29:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:20 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v5]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <amUS-nAMV81aBx2GLfnDtuk_O_MhFE1Oi0Sxs2DYy2o=.d8155a10-80d6-4ab2-9f2a-4bc8ee61b96b@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

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

 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - Revert unintended update to binary file.
 - JDK-8294618: Update openjdk.java.net => openjdk.org

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/cee96d0a..fbaf3d4c

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

  Stats: 2670 lines in 133 files changed: 1729 ins; 406 del; 535 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

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

From darcy at openjdk.org  Fri Sep 30 20:29:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:21 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
Message-ID: <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>

On Fri, 30 Sep 2022 13:59:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

Yes; I think it is sufficient to update src and doc with this PR.

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

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

From darcy at openjdk.org  Fri Sep 30 20:29:22 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:22 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
 <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
Message-ID: <q7j-egb4NojCIVKfF-PxraFVvU3FucPfulisSzexu30=.888b04a2-1624-4de1-a81c-e65e747ccd73@github.com>

On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race <prr at openjdk.org> wrote:

> This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

Update to persistent git links.

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

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

From vromero at openjdk.org  Fri Sep 30 23:42:40 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 Sep 2022 23:42:40 GMT
Subject: RFR: JDK-8293877: Rewrite MineField test
In-Reply-To: <sYd9zJCF6N8-lM_G9lwzWQdQts2diPVWTSGKtRc1AjE=.c06c13e4-609a-47a2-ab96-25a257532d89@github.com>
References: <sYd9zJCF6N8-lM_G9lwzWQdQts2diPVWTSGKtRc1AjE=.c06c13e4-609a-47a2-ab96-25a257532d89@github.com>
Message-ID: <1aVIGSEHuoo2Xs72rAzd6djwF9Lo4RUW4eNIOyAhD50=.53af99b6-f96e-414c-b03d-c40bf8af7547@github.com>

On Wed, 21 Sep 2022 00:57:22 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code.
> 
> This will be an awkward/difficult/tedious (choose your adjective) review.  The old files have been deleted, and the new code is different enough to defeat any `diff` program.  That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter.  It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together.
> 
> The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience.
> 
> Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`.
> 
> The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation.
> 
> Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature.
> 
> On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed.  But any change would be a difference in the old and new code, and should arguably be done separately.  So, the existence and use of `cleanup` methods is as before.
> 
> Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code.
> 
> The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort.  
> 
> Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests.  For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases.
> 
> Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR.

I have gone through all the changes, I think semantically the original tests have been preserved as closed as possible. After a first review iteration I think it could make sense to clean up a bit an remove dead code etc

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

Marked as reviewed by vromero (Reviewer).

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

From joe.darcy at oracle.com  Fri Sep 30 04:41:12 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 30 Sep 2022 04:41:12 -0000
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
Message-ID: <857259f1-daa2-46a0-ded8-24d866482707@oracle.com>

Thanks for catching that Iris; I'll changes those to git URLs.

-Joe

On 9/29/2022 9:11 PM, Iris Clark wrote:
> On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>>>
>>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    http -> https
> Marked as reviewed by iris (Reviewer).
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
>
>> 32:  * the following link:
>> 33:  *
>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10501