From jlahoda at openjdk.org Mon Jul 1 12:05:46 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 1 Jul 2024 12:05:46 GMT Subject: RFR: 8335385: javac crash on unattributed piece of AST Message-ID: Consider the following sources: //B.java package p; public class B { public interface I {} } Test.java import p.B.I; Then compile `B`, remove the `I` nested interface, and try to compile `Test` with the remaining classfiles of `B` on the classpath: $ javac -d out B.java $ rm out/p/B$I.class $ javac -classpath out -XDdev Test.java Test.java:1: error: cannot access I import p.B.I; ^ class file for p.B$I not found 1 error An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://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.NullPointerException: Cannot read field "owner" because "s.sym" is null at jdk.compiler/com.sun.tools.javac.comp.Check.isCanonical(Check.java:4264) at jdk.compiler/com.sun.tools.javac.comp.Check.checkCanonical(Check.java:4256) at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doImport(TypeEnter.java:466) at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:416) at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389) at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.lambda$ensureImportsChecked$0(TypeEnter.java:165) at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.finishImports(TypeEnter.java:217) at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.ensureImportsChecked(TypeEnter.java:165) at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:650) at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:600) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1077) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:948) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178) at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66) at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52) printing javac parameters to: /tmp/javac.20240701_092709.args The reason is that when the import is attributed, `Resolve.findIdentInType` is called to find `I` in `p.B`. It will, however, fail with a `CompletionFailure`, as `I` does not exist. And the `CompletionFailure` won't be called sooner than in `Attr.attribTree`, and as a consequence, the `sym` field of the `p.B.I` select will remain `null`, as the code that sets it will be skipped due to the `CompletionFailure`. This then leads to the follow-up NPE. The proposal herein is to change `Resolve.findIdentInType` and `Resolve.findIdent` to handle `CompletionFailures` immediately, report an error, and return a "missing" `Symbol`. Note that `Resolve.findIdentInPackage` will not throw `CompletionFailure`s, as it uses `Resolve.loadClass`, which handles `CompletionFailure`s. So, this should be making the behavior consistent across `findIdent`, `findIdentInPackage` and `findIdentInType`. ------------- Commit messages: - 8335385: javac crash on unattributed piece of AST Changes: https://git.openjdk.org/jdk/pull/19969/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19969&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335385 Stats: 337 lines in 3 files changed: 329 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19969/head:pull/19969 PR: https://git.openjdk.org/jdk/pull/19969 From jlahoda at openjdk.org Mon Jul 1 14:14:29 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 1 Jul 2024 14:14:29 GMT Subject: RFR: 8332474: Tighten up ToolBox' JavacTask to not silently access javac crash as a failure Message-ID: Tests for javac use several test frameworks, and one of them is the "toolbox", which provides `JavacTask` that allows to conveniently run javac on a given set of sources. The problem with `JavacTask` is that, by default, when a compilation failure is expected, javac crash (exit code 4) is tolerated by the `JavacTask`. And the test must manually select a specific exit code to overwrite this behavior. This then leads to bugs like [https://bugs.openjdk.org/browse/JDK-8335385], which are silently ignored by `JavacTask`. The proposal herein is to tighten up the `JavacTask`, and effectively disallow exit code 4 for `JavacTask` (but permit any other exit code, as javac is using several exit codes). The base implements in `AbstractTask` is changed to use a validator for the exit codes, which is then leveraged by `JavacTask`. This patch depends on PR #19969, as that fixes JDK-8335385, where the javac crash is ignored. It also tweaks module attribution to not leave empty `JCModuleDecl.sym` for duplicate modules, and set it to an erroneous module. The empty (`null`) symbol here crashes javac in the `test/langtools/tools/javac/modules/MultiModuleModeTest.java#testDuplicateModules`, and the test wouldn't pass with this more strict `JavacTask`. ------------- Depends on: https://git.openjdk.org/jdk/pull/19969 Commit messages: - Fixing expect semantics - Cleanup. - Cleanup. - Merge branch 'JDK-8335385' into JDK-8332474 - 8332474: Tighten up ToolBox' JavacTask to not silently access javac crash as a failure Changes: https://git.openjdk.org/jdk/pull/19972/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19972&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332474 Stats: 73 lines in 3 files changed: 64 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19972/head:pull/19972 PR: https://git.openjdk.org/jdk/pull/19972 From jwaters at openjdk.org Mon Jul 1 14:22:22 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 1 Jul 2024 14:22:22 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v10] In-Reply-To: References: Message-ID: <1_svN_dr71GK3QSvKsqyRyva5qwFMlrG0VAWC8Ei-gE=.c7562293-3835-4416-8e61-055c3b2f5948@github.com> On Fri, 28 Jun 2024 19:43:36 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > use instance resolveAndBind + use junit in tests Build Changes look ok ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2151527800 From jvernee at openjdk.org Mon Jul 1 14:56:51 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 1 Jul 2024 14:56:51 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v11] In-Reply-To: References: Message-ID: > This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. > - tier 1-3 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: ofInvokeInstruction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/c597f247..5afb3561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=09-10 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774 PR: https://git.openjdk.org/jdk/pull/19774 From jlahoda at openjdk.org Mon Jul 1 15:39:21 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 1 Jul 2024 15:39:21 GMT Subject: RFR: 8334757: AssertionError: Missing type variable in where clause In-Reply-To: References: Message-ID: On Sat, 22 Jun 2024 01:10:01 GMT, Liam Miller-Cushon wrote: > Please consider this fix for [JDK-8334757](https://bugs.openjdk.org/browse/JDK-8334757). > > This adds a missing case to argument preprocessing in `RichDiagnosticFormatter` to handle the `JCDiagnostic.AnnotatedType` wrapper types, which avoids a crash when types with type variables appear as arguments for diagnostics that use `JCDiagnostic.AnnotatedType`. > > The wrapper type was introduced by [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643) and is only used by the diagnostics introduced in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226), so backing out JDK-8043226 could also be considered. Looks sensible to me. Thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19840#pullrequestreview-2151699644 From jjg at openjdk.org Mon Jul 1 18:27:19 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 1 Jul 2024 18:27:19 GMT Subject: RFR: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure In-Reply-To: References: Message-ID: <5-JFwnjjemqkLG7c-_dcpK_pBEQIXrK4IL-jZnzk_sE=.27d1320c-112c-4585-9429-15f95c97bff1@github.com> On Mon, 1 Jul 2024 14:09:39 GMT, Jan Lahoda wrote: > Tests for javac use several test frameworks, and one of them is the "toolbox", which provides `JavacTask` that allows to conveniently run javac on a given set of sources. The problem with `JavacTask` is that, by default, when a compilation failure is expected, javac crash (exit code 4) is tolerated by the `JavacTask`. And the test must manually select a specific exit code to overwrite this behavior. > > This then leads to bugs like https://bugs.openjdk.org/browse/JDK-8335385, which are silently ignored by `JavacTask`. > > The proposal herein is to tighten up the `JavacTask`, and effectively disallow exit code 4 for `JavacTask` (but permit any other exit code, as javac is using several exit codes). The base implementation in `AbstractTask` is changed to use a validator for the exit codes, which is then leveraged by `JavacTask`. > > This patch depends on PR #19969, as that fixes JDK-8335385, where the javac crash is ignored. It also tweaks module attribution to not leave empty `JCModuleDecl.sym` for duplicate modules, and set it to an erroneous module. The empty (`null`) symbol here crashes javac in the `test/langtools/tools/javac/modules/MultiModuleModeTest.java#testDuplicateModules`, and the test wouldn't pass with this more strict `JavacTask`. test/langtools/tools/lib/toolbox/AbstractTask.java line 94: > 92: * @param exitCodeValidator an exit code validator. The first parameter will > 93: * be the actual exit code, the second test name, > 94: * should throw TaskError is the exit code is not typo: "is the exit code" -> "if the exit code" test/langtools/tools/lib/toolbox/JavacTask.java line 331: > 329: @Override > 330: public Result run(Expect expect, int exitCode) { > 331: if (exitCode == 4) { I guess we never expect `javac` to crash, and should not be able to test that it does, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19972#discussion_r1661398227 PR Review Comment: https://git.openjdk.org/jdk/pull/19972#discussion_r1661400077 From jlahoda at openjdk.org Tue Jul 2 12:59:31 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 2 Jul 2024 12:59:31 GMT Subject: RFR: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure [v2] In-Reply-To: References: Message-ID: > Tests for javac use several test frameworks, and one of them is the "toolbox", which provides `JavacTask` that allows to conveniently run javac on a given set of sources. The problem with `JavacTask` is that, by default, when a compilation failure is expected, javac crash (exit code 4) is tolerated by the `JavacTask`. And the test must manually select a specific exit code to overwrite this behavior. > > This then leads to bugs like https://bugs.openjdk.org/browse/JDK-8335385, which are silently ignored by `JavacTask`. > > The proposal herein is to tighten up the `JavacTask`, and effectively disallow exit code 4 for `JavacTask` (but permit any other exit code, as javac is using several exit codes). The base implementation in `AbstractTask` is changed to use a validator for the exit codes, which is then leveraged by `JavacTask`. > > This patch depends on PR #19969, as that fixes JDK-8335385, where the javac crash is ignored. It also tweaks module attribution to not leave empty `JCModuleDecl.sym` for duplicate modules, and set it to an erroneous module. The empty (`null`) symbol here crashes javac in the `test/langtools/tools/javac/modules/MultiModuleModeTest.java#testDuplicateModules`, and the test wouldn't pass with this more strict `JavacTask`. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing typo, as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19972/files - new: https://git.openjdk.org/jdk/pull/19972/files/c957aedd..b60ef691 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19972&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19972&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19972/head:pull/19972 PR: https://git.openjdk.org/jdk/pull/19972 From jlahoda at openjdk.org Tue Jul 2 12:59:31 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 2 Jul 2024 12:59:31 GMT Subject: RFR: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure [v2] In-Reply-To: <5-JFwnjjemqkLG7c-_dcpK_pBEQIXrK4IL-jZnzk_sE=.27d1320c-112c-4585-9429-15f95c97bff1@github.com> References: <5-JFwnjjemqkLG7c-_dcpK_pBEQIXrK4IL-jZnzk_sE=.27d1320c-112c-4585-9429-15f95c97bff1@github.com> Message-ID: On Mon, 1 Jul 2024 18:22:15 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing typo, as suggested. > > test/langtools/tools/lib/toolbox/AbstractTask.java line 94: > >> 92: * @param exitCodeValidator an exit code validator. The first parameter will >> 93: * be the actual exit code, the second test name, >> 94: * should throw TaskError is the exit code is not > > typo: "is the exit code" -> "if the exit code" Thanks, fixed now! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19972#discussion_r1662468630 From jlahoda at openjdk.org Tue Jul 2 13:11:20 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 2 Jul 2024 13:11:20 GMT Subject: RFR: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure [v2] In-Reply-To: <5-JFwnjjemqkLG7c-_dcpK_pBEQIXrK4IL-jZnzk_sE=.27d1320c-112c-4585-9429-15f95c97bff1@github.com> References: <5-JFwnjjemqkLG7c-_dcpK_pBEQIXrK4IL-jZnzk_sE=.27d1320c-112c-4585-9429-15f95c97bff1@github.com> Message-ID: <1Jf96g63fCTj_Dgnk5dE0EuDNTeJ0BKm94ND7fdn-3E=.7741b00c-df5f-4b19-a549-bcdfca02525e@github.com> On Mon, 1 Jul 2024 18:24:18 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing typo, as suggested. > > test/langtools/tools/lib/toolbox/JavacTask.java line 331: > >> 329: @Override >> 330: public Result run(Expect expect, int exitCode) { >> 331: if (exitCode == 4) { > > I guess we never expect `javac` to crash, and should not be able to test that it does, right? I am not too worried about a test that would intentionally crash javac, and would need to test for that. It is not clear to me what would be the purpose of the test. And, assuming this need would indeed be rare, there are other ways to test for that. So, I opted for a more strict approach. OTOH, I don't have a too strong opinion on this, so I can re-allow exit code 4 here if desired. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19972#discussion_r1662486180 From vromero at openjdk.org Tue Jul 2 15:52:18 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 2 Jul 2024 15:52:18 GMT Subject: RFR: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure [v2] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 12:59:31 GMT, Jan Lahoda wrote: >> Tests for javac use several test frameworks, and one of them is the "toolbox", which provides `JavacTask` that allows to conveniently run javac on a given set of sources. The problem with `JavacTask` is that, by default, when a compilation failure is expected, javac crash (exit code 4) is tolerated by the `JavacTask`. And the test must manually select a specific exit code to overwrite this behavior. >> >> This then leads to bugs like https://bugs.openjdk.org/browse/JDK-8335385, which are silently ignored by `JavacTask`. >> >> The proposal herein is to tighten up the `JavacTask`, and effectively disallow exit code 4 for `JavacTask` (but permit any other exit code, as javac is using several exit codes). The base implementation in `AbstractTask` is changed to use a validator for the exit codes, which is then leveraged by `JavacTask`. >> >> This patch depends on PR #19969, as that fixes JDK-8335385, where the javac crash is ignored. It also tweaks module attribution to not leave empty `JCModuleDecl.sym` for duplicate modules, and set it to an erroneous module. The empty (`null`) symbol here crashes javac in the `test/langtools/tools/javac/modules/MultiModuleModeTest.java#testDuplicateModules`, and the test wouldn't pass with this more strict `JavacTask`. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing typo, as suggested. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19972#pullrequestreview-2154244622 From vromero at openjdk.org Tue Jul 2 17:27:18 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 2 Jul 2024 17:27:18 GMT Subject: RFR: 8334757: AssertionError: Missing type variable in where clause In-Reply-To: References: Message-ID: On Sat, 22 Jun 2024 01:10:01 GMT, Liam Miller-Cushon wrote: > Please consider this fix for [JDK-8334757](https://bugs.openjdk.org/browse/JDK-8334757). > > This adds a missing case to argument preprocessing in `RichDiagnosticFormatter` to handle the `JCDiagnostic.AnnotatedType` wrapper types, which avoids a crash when types with type variables appear as arguments for diagnostics that use `JCDiagnostic.AnnotatedType`. > > The wrapper type was introduced by [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643) and is only used by the diagnostics introduced in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226), so backing out JDK-8043226 could also be considered. looks good ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19840#pullrequestreview-2154449224 From vromero at openjdk.org Tue Jul 2 19:19:21 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 2 Jul 2024 19:19:21 GMT Subject: RFR: 8335385: javac crash on unattributed piece of AST In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 12:00:14 GMT, Jan Lahoda wrote: > Consider the following sources: > > //B.java > package p; > > public class B { > public interface I {} > } > > > Test.java > import p.B.I; > > > Then compile `B`, remove the `I` nested interface, and try to compile `Test` with the remaining classfiles of `B` on the classpath: > > $ javac -d out B.java > $ rm out/p/B$I.class > $ javac -classpath out -XDdev Test.java > Test.java:1: error: cannot access I > import p.B.I; > ^ > class file for p.B$I not found > 1 error > An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://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.NullPointerException: Cannot read field "owner" because "s.sym" is null > at jdk.compiler/com.sun.tools.javac.comp.Check.isCanonical(Check.java:4264) > at jdk.compiler/com.sun.tools.javac.comp.Check.checkCanonical(Check.java:4256) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doImport(TypeEnter.java:466) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:416) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.lambda$ensureImportsChecked$0(TypeEnter.java:165) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.finishImports(TypeEnter.java:217) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.ensureImportsChecked(TypeEnter.java:165) > at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:650) > at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:600) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1077) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:948) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52) > printing javac parameters to: /tmp/javac.20240701_092709.args > > > The reason is that when the import is attributed, `Resolve.findIdentInType` is called to find `I` in `p.B`. It will, however... src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2427: > 2425: Symbol findIdent(DiagnosticPosition pos, Env env, Name name, KindSelector kind) { > 2426: try { > 2427: return checkNonExistentType(checkRestrictedType(pos, findIdentInternal(pos, env, name, kind), name)); should the new code be moved into `checkNonExistentType` so that all of its clients benefit from it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19969#discussion_r1663040672 From jlahoda at openjdk.org Wed Jul 3 06:24:18 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 3 Jul 2024 06:24:18 GMT Subject: RFR: 8335385: javac crash on unattributed piece of AST In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 12:00:14 GMT, Jan Lahoda wrote: > Consider the following sources: > > //B.java > package p; > > public class B { > public interface I {} > } > > > Test.java > import p.B.I; > > > Then compile `B`, remove the `I` nested interface, and try to compile `Test` with the remaining classfiles of `B` on the classpath: > > $ javac -d out B.java > $ rm out/p/B$I.class > $ javac -classpath out -XDdev Test.java > Test.java:1: error: cannot access I > import p.B.I; > ^ > class file for p.B$I not found > 1 error > An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://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.NullPointerException: Cannot read field "owner" because "s.sym" is null > at jdk.compiler/com.sun.tools.javac.comp.Check.isCanonical(Check.java:4264) > at jdk.compiler/com.sun.tools.javac.comp.Check.checkCanonical(Check.java:4256) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doImport(TypeEnter.java:466) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:416) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.lambda$ensureImportsChecked$0(TypeEnter.java:165) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.finishImports(TypeEnter.java:217) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.ensureImportsChecked(TypeEnter.java:165) > at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:650) > at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:600) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1077) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:948) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52) > printing javac parameters to: /tmp/javac.20240701_092709.args > > > The reason is that when the import is attributed, `Resolve.findIdentInType` is called to find `I` in `p.B`. It will, however... test/langtools/tools/javac/importscope/BadClassFileDuringImport.java line 57: > 55: .sources("package p; public class A { }", > 56: "package p; public class B { public static class I { } }", > 57: "package m; public class A { }", The existing tests were for bad classfile only. Adding another set of tests for missing classfile; mostly duplicating the existing tests. test/langtools/tools/javac/importscope/BadClassFileDuringImport.java line 135: > 133: "I i;", > 134: "Test.java:2:11: compiler.err.cant.access: p.B.I, (compiler.misc.bad.class.file.header: B$I.class, (compiler.misc.illegal.start.of.class.file))", > 135: "Test.java:2:35: compiler.err.cant.resolve.location: kindname.class, I, , , (compiler.misc.location: kindname.class, Test, null)", We are reporting an additional error here, because originally, javac crashed before reporting the error. test/langtools/tools/javac/importscope/BadClassFileDuringImport.java line 145: > 143: "void test() { I i; }", > 144: "Test.java:2:11: compiler.err.cant.access: p.B.I, (compiler.misc.bad.class.file.header: B$I.class, (compiler.misc.illegal.start.of.class.file))", > 145: "Test.java:2:49: compiler.err.cant.resolve.location: kindname.class, I, , , (compiler.misc.location: kindname.class, Test, null)", We are reporting an additional error here, because originally, javac crashed before reporting the error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19969#discussion_r1660943003 PR Review Comment: https://git.openjdk.org/jdk/pull/19969#discussion_r1660943567 PR Review Comment: https://git.openjdk.org/jdk/pull/19969#discussion_r1660943662 From jlahoda at openjdk.org Wed Jul 3 06:36:18 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 3 Jul 2024 06:36:18 GMT Subject: RFR: 8335385: javac crash on unattributed piece of AST In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 19:16:28 GMT, Vicente Romero wrote: >> Consider the following sources: >> >> //B.java >> package p; >> >> public class B { >> public interface I {} >> } >> >> >> Test.java >> import p.B.I; >> >> >> Then compile `B`, remove the `I` nested interface, and try to compile `Test` with the remaining classfiles of `B` on the classpath: >> >> $ javac -d out B.java >> $ rm out/p/B$I.class >> $ javac -classpath out -XDdev Test.java >> Test.java:1: error: cannot access I >> import p.B.I; >> ^ >> class file for p.B$I not found >> 1 error >> An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://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.NullPointerException: Cannot read field "owner" because "s.sym" is null >> at jdk.compiler/com.sun.tools.javac.comp.Check.isCanonical(Check.java:4264) >> at jdk.compiler/com.sun.tools.javac.comp.Check.checkCanonical(Check.java:4256) >> at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doImport(TypeEnter.java:466) >> at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:416) >> at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389) >> at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.lambda$ensureImportsChecked$0(TypeEnter.java:165) >> at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.finishImports(TypeEnter.java:217) >> at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.ensureImportsChecked(TypeEnter.java:165) >> at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:650) >> at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:600) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1077) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:948) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178) >> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66) >> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52) >> printing javac parameters to: /tmp/javac.20240701_092709.args >> >> >> The reason is that when the impo... > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2427: > >> 2425: Symbol findIdent(DiagnosticPosition pos, Env env, Name name, KindSelector kind) { >> 2426: try { >> 2427: return checkNonExistentType(checkRestrictedType(pos, findIdentInternal(pos, env, name, kind), name)); > > should the new code be moved into `checkNonExistentType` so that all of its clients benefit from it? The `CompletionFailure` happens inside `findIdentInternal` or `findIdentInTypeInternal`, so handling this in `checkNonExistentType` is too late, I'm afraid. I was thinking of having a method encapsulating the try-catch, but that would mean the code to lookup the type would need to be in a capturing lambda, which seemed a bit heavyweight for this place. But that would surely be doable, if preferred. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19969#discussion_r1663582888 From vromero at openjdk.org Wed Jul 3 13:01:19 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 3 Jul 2024 13:01:19 GMT Subject: RFR: 8335385: javac crash on unattributed piece of AST In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 06:33:22 GMT, Jan Lahoda wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2427: >> >>> 2425: Symbol findIdent(DiagnosticPosition pos, Env env, Name name, KindSelector kind) { >>> 2426: try { >>> 2427: return checkNonExistentType(checkRestrictedType(pos, findIdentInternal(pos, env, name, kind), name)); >> >> should the new code be moved into `checkNonExistentType` so that all of its clients benefit from it? > > The `CompletionFailure` happens inside `findIdentInternal` or `findIdentInTypeInternal`, so handling this in `checkNonExistentType` is too late, I'm afraid. I was thinking of having a method encapsulating the try-catch, but that would mean the code to lookup the type would need to be in a capturing lambda, which seemed a bit heavyweight for this place. But that would surely be doable, if preferred. I'm OK with the current solution given that you considered the alternative ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19969#discussion_r1664152312 From vromero at openjdk.org Wed Jul 3 13:01:18 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 3 Jul 2024 13:01:18 GMT Subject: RFR: 8335385: javac crash on unattributed piece of AST In-Reply-To: References: Message-ID: <2_Q7urRaArPcR9Ocj3xjMm3ZIrMBl3ViQuVIvpJGtnM=.c0a7009b-1166-4084-9b5f-e3d781cfaaff@github.com> On Mon, 1 Jul 2024 12:00:14 GMT, Jan Lahoda wrote: > Consider the following sources: > > //B.java > package p; > > public class B { > public interface I {} > } > > > Test.java > import p.B.I; > > > Then compile `B`, remove the `I` nested interface, and try to compile `Test` with the remaining classfiles of `B` on the classpath: > > $ javac -d out B.java > $ rm out/p/B$I.class > $ javac -classpath out -XDdev Test.java > Test.java:1: error: cannot access I > import p.B.I; > ^ > class file for p.B$I not found > 1 error > An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://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.NullPointerException: Cannot read field "owner" because "s.sym" is null > at jdk.compiler/com.sun.tools.javac.comp.Check.isCanonical(Check.java:4264) > at jdk.compiler/com.sun.tools.javac.comp.Check.checkCanonical(Check.java:4256) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doImport(TypeEnter.java:466) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:416) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.lambda$ensureImportsChecked$0(TypeEnter.java:165) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.finishImports(TypeEnter.java:217) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.ensureImportsChecked(TypeEnter.java:165) > at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:650) > at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:600) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1077) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:948) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52) > printing javac parameters to: /tmp/javac.20240701_092709.args > > > The reason is that when the import is attributed, `Resolve.findIdentInType` is called to find `I` in `p.B`. It will, however... lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19969#pullrequestreview-2156383418 From jlahoda at openjdk.org Thu Jul 4 08:39:25 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 4 Jul 2024 08:39:25 GMT Subject: Integrated: 8335385: javac crash on unattributed piece of AST In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 12:00:14 GMT, Jan Lahoda wrote: > Consider the following sources: > > //B.java > package p; > > public class B { > public interface I {} > } > > > Test.java > import p.B.I; > > > Then compile `B`, remove the `I` nested interface, and try to compile `Test` with the remaining classfiles of `B` on the classpath: > > $ javac -d out B.java > $ rm out/p/B$I.class > $ javac -classpath out -XDdev Test.java > Test.java:1: error: cannot access I > import p.B.I; > ^ > class file for p.B$I not found > 1 error > An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://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.NullPointerException: Cannot read field "owner" because "s.sym" is null > at jdk.compiler/com.sun.tools.javac.comp.Check.isCanonical(Check.java:4264) > at jdk.compiler/com.sun.tools.javac.comp.Check.checkCanonical(Check.java:4256) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doImport(TypeEnter.java:466) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:416) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.lambda$ensureImportsChecked$0(TypeEnter.java:165) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.finishImports(TypeEnter.java:217) > at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.ensureImportsChecked(TypeEnter.java:165) > at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:650) > at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:600) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1077) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:948) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52) > printing javac parameters to: /tmp/javac.20240701_092709.args > > > The reason is that when the import is attributed, `Resolve.findIdentInType` is called to find `I` in `p.B`. It will, however... This pull request has now been integrated. Changeset: 3e3f83f6 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/3e3f83f62c67caf960ca031439b022f915e1102a Stats: 337 lines in 3 files changed: 329 ins; 0 del; 8 mod 8335385: javac crash on unattributed piece of AST Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/19969 From jlahoda at openjdk.org Thu Jul 4 10:53:51 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 4 Jul 2024 10:53:51 GMT Subject: RFR: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure [v3] In-Reply-To: References: Message-ID: <62g3PJ-z0oxFBe-fUb2WpRSt5Expqe8_KJE7g5dLqZs=.927a02c9-ec81-43af-9715-133c6025df0d@github.com> > Tests for javac use several test frameworks, and one of them is the "toolbox", which provides `JavacTask` that allows to conveniently run javac on a given set of sources. The problem with `JavacTask` is that, by default, when a compilation failure is expected, javac crash (exit code 4) is tolerated by the `JavacTask`. And the test must manually select a specific exit code to overwrite this behavior. > > This then leads to bugs like https://bugs.openjdk.org/browse/JDK-8335385, which are silently ignored by `JavacTask`. > > The proposal herein is to tighten up the `JavacTask`, and effectively disallow exit code 4 for `JavacTask` (but permit any other exit code, as javac is using several exit codes). The base implementation in `AbstractTask` is changed to use a validator for the exit codes, which is then leveraged by `JavacTask`. > > This patch depends on PR #19969, as that fixes JDK-8335385, where the javac crash is ignored. It also tweaks module attribution to not leave empty `JCModuleDecl.sym` for duplicate modules, and set it to an erroneous module. The empty (`null`) symbol here crashes javac in the `test/langtools/tools/javac/modules/MultiModuleModeTest.java#testDuplicateModules`, and the test wouldn't pass with this more strict `JavacTask`. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'JDK-8332474' of github.com:lahodaj/jdk into JDK-8332474 - Fixing typo, as suggested. - Merge branch 'master' into JDK-8332474 - Fixing expect semantics - Cleanup. - Cleanup. - Merge branch 'JDK-8335385' into JDK-8332474 - 8335385: javac crash on unattributed piece of AST - 8332474: Tighten up ToolBox' JavacTask to not silently access javac crash as a failure ------------- Changes: https://git.openjdk.org/jdk/pull/19972/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19972&range=02 Stats: 73 lines in 3 files changed: 64 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19972/head:pull/19972 PR: https://git.openjdk.org/jdk/pull/19972 From duke at openjdk.org Fri Jul 5 03:26:33 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Jul 2024 03:26:33 GMT Subject: Withdrawn: 8324651: Compiler Implementation for Derived Record Creation (Preview) In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 10:24:51 GMT, Jan Lahoda wrote: > This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is: > https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html > > The current CSR is here: > https://bugs.openjdk.org/browse/JDK-8328637 > > The patch is mostly straightforward, with two notable changes: > - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago. > - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18509 From jvernee at openjdk.org Fri Jul 5 13:44:46 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Jul 2024 13:44:46 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: > This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. > - tier 1-3 Jorn Vernee 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 29 additional commits since the last revision: - Merge branch 'master' into jnativescan - ofInvokeInstruction - use instance resolveAndBind + use junit in tests - de-dupe on path, not module name - Add support for module directories + class path directories - sort output for easier diffs - Jan comments - add extra test for missing root modules - review comments Alan - update man page header to be consisten with the others - ... and 19 more: https://git.openjdk.org/jdk/compare/a27659e6...1d1ff010 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/5afb3561..1d1ff010 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=10-11 Stats: 36188 lines in 816 files changed: 23655 ins; 8432 del; 4101 mod Patch: https://git.openjdk.org/jdk/pull/19774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774 PR: https://git.openjdk.org/jdk/pull/19774 From jvernee at openjdk.org Fri Jul 5 14:33:38 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Jul 2024 14:33:38 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee 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 29 additional commits since the last revision: > > - Merge branch 'master' into jnativescan > - ofInvokeInstruction > - use instance resolveAndBind + use junit in tests > - de-dupe on path, not module name > - Add support for module directories + class path directories > - sort output for easier diffs > - Jan comments > - add extra test for missing root modules > - review comments Alan > - update man page header to be consisten with the others > - ... and 19 more: https://git.openjdk.org/jdk/compare/33bfce23...1d1ff010 I'm running one more tier 1-3 job before integrating. Will need a final sign-off from a reviewer for that as well. (Either way, I'll save the integration until next week) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2210982590 From darcy at openjdk.org Sun Jul 7 21:36:58 2024 From: darcy at openjdk.org (Joe Darcy) Date: Sun, 7 Jul 2024 21:36:58 GMT Subject: RFR: 8333826: Update --release 23 symbol information for JDK 23 build 29 Message-ID: Update symbol files to include changes from JDK-8335133. (No API updates in JDK 23 b30.) ------------- Commit messages: - JDK-8333826: Update --release 23 symbol information for JDK 23 build 29 Changes: https://git.openjdk.org/jdk/pull/20064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20064&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333826 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20064/head:pull/20064 PR: https://git.openjdk.org/jdk/pull/20064 From iris at openjdk.org Mon Jul 8 05:59:35 2024 From: iris at openjdk.org (Iris Clark) Date: Mon, 8 Jul 2024 05:59:35 GMT Subject: RFR: 8333826: Update --release 23 symbol information for JDK 23 build 29 In-Reply-To: References: Message-ID: On Sun, 7 Jul 2024 21:32:35 GMT, Joe Darcy wrote: > Update symbol files to include changes from JDK-8335133. > > (No API updates in JDK 23 b30.) Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20064#pullrequestreview-2162329716 From alanb at openjdk.org Mon Jul 8 08:07:46 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Jul 2024 08:07:46 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee 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 29 additional commits since the last revision: > > - Merge branch 'master' into jnativescan > - ofInvokeInstruction > - use instance resolveAndBind + use junit in tests > - de-dupe on path, not module name > - Add support for module directories + class path directories > - sort output for easier diffs > - Jan comments > - add extra test for missing root modules > - review comments Alan > - update man page header to be consisten with the others > - ... and 19 more: https://git.openjdk.org/jdk/compare/a6e3a992...1d1ff010 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2162567660 From jlahoda at openjdk.org Mon Jul 8 10:09:00 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 8 Jul 2024 10:09:00 GMT Subject: RFR: 8324859: Improve error recovery Message-ID: Consider code like: package tests; public class TestB { public static boolean test() // <--- missing open brace return true; } public static boolean test2() { return true; } } In JDK 17, it used to produce 3 compile-time errors: $ javac /tmp/TestB.java /tmp/TestB.java:3: error: ';' expected public static boolean test() // <--- missing open brace ^ /tmp/TestB.java:6: error: class, interface, enum, or record expected public static boolean test2() { ^ /tmp/TestB.java:8: error: class, interface, enum, or record expected } ^ 3 errors Currently, it produces 4: $ javac /tmp/TestB.java /tmp/TestB.java:3: error: ';' expected public static boolean test() // <--- missing open brace ^ /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default. public static boolean test2() { ^ (use --enable-preview to enable implicitly declared classes) /tmp/TestB.java:9: error: class, interface, enum, or record expected } ^ /tmp/TestB.java:1: error: implicitly declared class should not have package declaration package tests; ^ 4 errors Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior. In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input. For the case above, it would be much better if javac parsed the code following the missing opening brace as a block. This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows: - if it is an opening brace, parse the follow up as a block - if it is a statement keyword (like `if`), parse the follow up as a block, - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the file - if yes, parse the follow up as a block, - otherwise, try to speculatively parse the follow up - if it looks like a well-formed block, let the main parser parse it as a block. There is a small trick by checking whether the parameters were parsed OK - and not do most of the above if there was a problem while parsing the parameters. This is to keep the existing behavior in the `testImplicitlyDeclaredClassesConfusion6` case. ------------- Commit messages: - More cases. - Improving error message for attributes with default value. - Handling another testcase. - Merge branch 'master' into JDK-8324859 - Tweaking the error recovery. - 8324859: Improve error recovery Changes: https://git.openjdk.org/jdk/pull/20070/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20070&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324859 Stats: 595 lines in 2 files changed: 592 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20070.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20070/head:pull/20070 PR: https://git.openjdk.org/jdk/pull/20070 From jvernee at openjdk.org Mon Jul 8 12:42:44 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Jul 2024 12:42:44 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: <-_t41gD7U_3zgK5CVSa_KPhOzxYbP2xqgfIYR63JnIQ=.62100b2e-85da-49f5-9e7a-0fe8f1525d79@github.com> On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee 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 29 additional commits since the last revision: > > - Merge branch 'master' into jnativescan > - ofInvokeInstruction > - use instance resolveAndBind + use junit in tests > - de-dupe on path, not module name > - Add support for module directories + class path directories > - sort output for easier diffs > - Jan comments > - add extra test for missing root modules > - review comments Alan > - update man page header to be consisten with the others > - ... and 19 more: https://git.openjdk.org/jdk/compare/e850014f...1d1ff010 I've lowered the number of reviewers to 1 again, required for the final sign-off. The number of reviewers was set to 2 by Magnus [here](https://github.com/openjdk/jdk/pull/19774#pullrequestreview-2128470410), because he only reviewed the build changes, but those didn't change since his last review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2213965740 From jvernee at openjdk.org Mon Jul 8 12:42:45 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Jul 2024 12:42:45 GMT Subject: Integrated: 8317611: Add a tool like jdeprscan to find usage of restricted methods In-Reply-To: References: Message-ID: On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote: > This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. > - tier 1-3 This pull request has now been integrated. Changeset: cec222e4 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/cec222e46065fc15db3f2eb241d3607d605ab580 Stats: 2250 lines in 37 files changed: 2235 ins; 0 del; 15 mod 8317611: Add a tool like jdeprscan to find usage of restricted methods Reviewed-by: alanb, ihse, mcimadamore, jlahoda, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/19774 From jvernee at openjdk.org Mon Jul 8 13:13:46 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Jul 2024 13:13:46 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v10] In-Reply-To: References: Message-ID: On Sat, 29 Jun 2024 06:26:57 GMT, Alan Bateman wrote: > I assume you'll create follow-up issues in JBS for the Class-Path attribute, improvement the usage/help output to replace the "Path"/"String" types. I've filed: https://bugs.openjdk.org/browse/JDK-8335877 and https://bugs.openjdk.org/browse/JDK-8335878 ------------- PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2214037164 From jlahoda at openjdk.org Mon Jul 8 15:17:34 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 8 Jul 2024 15:17:34 GMT Subject: RFR: 8333826: Update --release 23 symbol information for JDK 23 build 29 In-Reply-To: References: Message-ID: On Sun, 7 Jul 2024 21:32:35 GMT, Joe Darcy wrote: > Update symbol files to include changes from JDK-8335133. > > (No API updates in JDK 23 b30.) Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20064#pullrequestreview-2163652065 From darcy at openjdk.org Mon Jul 8 16:23:37 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 8 Jul 2024 16:23:37 GMT Subject: Integrated: 8333826: Update --release 23 symbol information for JDK 23 build 29 In-Reply-To: References: Message-ID: <4cR7dRkWRSYI_hS1xvBLWr3ra7TzrV8cdum2QGSGifg=.e5af2e4c-e71d-4dc7-ae91-2ce1718047cd@github.com> On Sun, 7 Jul 2024 21:32:35 GMT, Joe Darcy wrote: > Update symbol files to include changes from JDK-8335133. > > (No API updates in JDK 23 b30.) This pull request has now been integrated. Changeset: a9b7f42f Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/a9b7f42f29120a3cca0d341350ff03cae485e68b Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8333826: Update --release 23 symbol information for JDK 23 build 29 Reviewed-by: iris, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/20064 From cushon at openjdk.org Mon Jul 8 17:23:34 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 8 Jul 2024 17:23:34 GMT Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version In-Reply-To: References: Message-ID: On Fri, 24 May 2024 15:32:09 GMT, Liam Miller-Cushon wrote: > This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`. > > The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks. bridgekeeper please keep this open for now ------------- PR Comment: https://git.openjdk.org/jdk/pull/19397#issuecomment-2214759381 From cushon at openjdk.org Mon Jul 8 17:29:03 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 8 Jul 2024 17:29:03 GMT Subject: RFR: 8334757: AssertionError: Missing type variable in where clause [v2] In-Reply-To: References: Message-ID: > Please consider this fix for [JDK-8334757](https://bugs.openjdk.org/browse/JDK-8334757). > > This adds a missing case to argument preprocessing in `RichDiagnosticFormatter` to handle the `JCDiagnostic.AnnotatedType` wrapper types, which avoids a crash when types with type variables appear as arguments for diagnostics that use `JCDiagnostic.AnnotatedType`. > > The wrapper type was introduced by [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643) and is only used by the diagnostics introduced in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226), so backing out JDK-8043226 could also be considered. Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8334757 - 8334757: AssertionError: Missing type variable in where clause ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19840/files - new: https://git.openjdk.org/jdk/pull/19840/files/895c852c..61aa86bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19840&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19840&range=00-01 Stats: 22769 lines in 711 files changed: 14997 ins; 4875 del; 2897 mod Patch: https://git.openjdk.org/jdk/pull/19840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19840/head:pull/19840 PR: https://git.openjdk.org/jdk/pull/19840 From acobbs at openjdk.org Mon Jul 8 18:05:42 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 8 Jul 2024 18:05:42 GMT Subject: RFR: 8322882: Null pointer error when compiling Static initializer in a local class In-Reply-To: References: Message-ID: On Mon, 17 Jun 2024 17:23:03 GMT, Archie Cobbs wrote: > A local class can capture a free variable from its enclosing scope. The variable's value is passed to the local class constructor via a synthetic constructor parameter, and then stored in a synthetic proxy field in the local class. Therefore, at any point at which such a local class is instantiated, it must also be possible to access the captured free variable's value so it can be passed to the constructor. > > The compiler was incorrectly assuming that within the local class itself, this would always be the case, because of the existence of the synthetic proxy field. Prior to JDK 16, local classes were not allowed to have static methods, so this was a safe assumption. However, that assumption is no longer safe, and violating results in a `NullPointerException`, for example with this class: > > > class LocalFreeVarStaticInstantiate { > static void foo(Object there) { > class Local { > { > there.hashCode(); > } > static { > new Local(); // can't get there from here > } > } > } > } > > > This patch adds the missing check for the situation where access to a proxy variable instance field is required for a synthetic constructor parameter, but the instantiation is occurring within a static method of the class containing the field and so the field can't be accessed. > > **Note:** With this change, the following test fails to compile until Maurizio's refactoring relating to lambda's and outer instances (see "javac-pre-capture" Jira bug label) has been applied: > > * `test/langtools/tools/javac/lambda/T8209407/VerifierErrorInnerPlusLambda.java` Closing this PR as it is superceded by PR #19904. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19754#issuecomment-2214845972 From acobbs at openjdk.org Mon Jul 8 18:05:43 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 8 Jul 2024 18:05:43 GMT Subject: Withdrawn: 8322882: Null pointer error when compiling Static initializer in a local class In-Reply-To: References: Message-ID: On Mon, 17 Jun 2024 17:23:03 GMT, Archie Cobbs wrote: > A local class can capture a free variable from its enclosing scope. The variable's value is passed to the local class constructor via a synthetic constructor parameter, and then stored in a synthetic proxy field in the local class. Therefore, at any point at which such a local class is instantiated, it must also be possible to access the captured free variable's value so it can be passed to the constructor. > > The compiler was incorrectly assuming that within the local class itself, this would always be the case, because of the existence of the synthetic proxy field. Prior to JDK 16, local classes were not allowed to have static methods, so this was a safe assumption. However, that assumption is no longer safe, and violating results in a `NullPointerException`, for example with this class: > > > class LocalFreeVarStaticInstantiate { > static void foo(Object there) { > class Local { > { > there.hashCode(); > } > static { > new Local(); // can't get there from here > } > } > } > } > > > This patch adds the missing check for the situation where access to a proxy variable instance field is required for a synthetic constructor parameter, but the instantiation is occurring within a static method of the class containing the field and so the field can't be accessed. > > **Note:** With this change, the following test fails to compile until Maurizio's refactoring relating to lambda's and outer instances (see "javac-pre-capture" Jira bug label) has been applied: > > * `test/langtools/tools/javac/lambda/T8209407/VerifierErrorInnerPlusLambda.java` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19754 From jjg at openjdk.org Mon Jul 8 18:35:23 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 8 Jul 2024 18:35:23 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc Message-ID: Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. ------------- Commit messages: - Cleanup pass - Merge doclint into html: part 2: TagName/HtmlTag - Merge doclint support classes into html: part 1: attributes - Move basic classes from internal.doclets.formats.html.markup to internal.html Changes: https://git.openjdk.org/jdk/pull/19916/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335122 Stats: 2724 lines in 106 files changed: 861 ins; 992 del; 871 mod Patch: https://git.openjdk.org/jdk/pull/19916.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19916/head:pull/19916 PR: https://git.openjdk.org/jdk/pull/19916 From hannesw at openjdk.org Mon Jul 8 18:35:23 2024 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 8 Jul 2024 18:35:23 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 23:00:27 GMT, Jonathan Gibbons wrote: > Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. > > Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. > > There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. > > A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. > > There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. I'm not sure if this is intentional (it makes changes easier to review), but I notice that imports of classes in the new package are generally mixed with classes remaining in the old package, and therefore not in alphabetic order. ------------- PR Review: https://git.openjdk.org/jdk/pull/19916#pullrequestreview-2148044997 From jjg at openjdk.org Mon Jul 8 18:35:23 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 8 Jul 2024 18:35:23 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc In-Reply-To: References: Message-ID: <9TAVtUtP4EXtVYcYatWAvu6I4x3GUD89fJpwl0NRmw8=.0108880f-b6c0-429f-930e-09483c2688f2@github.com> On Fri, 28 Jun 2024 13:36:47 GMT, Hannes Walln?fer wrote: > I'm not sure if this is intentional (it makes changes easier to review), but I notice that imports of classes in the new package are generally mixed with classes remaining in the old package, and therefore not in alphabetic order. Yes, accident. I'll do a commit that just fixes imports ------------- PR Comment: https://git.openjdk.org/jdk/pull/19916#issuecomment-2214901023 From jjg at openjdk.org Mon Jul 8 19:18:21 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 8 Jul 2024 19:18:21 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v2] In-Reply-To: References: Message-ID: > Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. > > Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. > > There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. > > A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. > > There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: reorder imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19916/files - new: https://git.openjdk.org/jdk/pull/19916/files/7baa96d5..11608acd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=00-01 Stats: 549 lines in 71 files changed: 271 ins; 258 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/19916.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19916/head:pull/19916 PR: https://git.openjdk.org/jdk/pull/19916 From cushon at openjdk.org Mon Jul 8 20:11:40 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 8 Jul 2024 20:11:40 GMT Subject: Integrated: 8334757: AssertionError: Missing type variable in where clause In-Reply-To: References: Message-ID: On Sat, 22 Jun 2024 01:10:01 GMT, Liam Miller-Cushon wrote: > Please consider this fix for [JDK-8334757](https://bugs.openjdk.org/browse/JDK-8334757). > > This adds a missing case to argument preprocessing in `RichDiagnosticFormatter` to handle the `JCDiagnostic.AnnotatedType` wrapper types, which avoids a crash when types with type variables appear as arguments for diagnostics that use `JCDiagnostic.AnnotatedType`. > > The wrapper type was introduced by [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643) and is only used by the diagnostics introduced in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226), so backing out JDK-8043226 could also be considered. This pull request has now been integrated. Changeset: babf6df7 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/babf6df7d97e4beedb25e689634d999412c1e950 Stats: 24 lines in 3 files changed: 24 ins; 0 del; 0 mod 8334757: AssertionError: Missing type variable in where clause Reviewed-by: jlahoda, vromero ------------- PR: https://git.openjdk.org/jdk/pull/19840 From cushon at openjdk.org Mon Jul 8 20:21:43 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 8 Jul 2024 20:21:43 GMT Subject: [jdk23] RFR: 8334757: AssertionError: Missing type variable in where clause Message-ID: Please review this clean backport of #19840 to JDK 23, which avoids a crash when types with type variables appear as arguments for diagnostics that use `JCDiagnostic.AnnotatedType`. ------------- Commit messages: - Backport babf6df7d97e4beedb25e689634d999412c1e950 Changes: https://git.openjdk.org/jdk/pull/20085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20085&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334757 Stats: 24 lines in 3 files changed: 24 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20085/head:pull/20085 PR: https://git.openjdk.org/jdk/pull/20085 From jlahoda at openjdk.org Tue Jul 9 08:31:01 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 9 Jul 2024 08:31:01 GMT Subject: RFR: 8335766: Switch case with pattern matching and guard clause compiles inconsistently Message-ID: When javac parser see a `case` label, it needs to disambiguate between expressions (constant labels) and patterns. But, for code like: case R(int x) when (x > 0) the parser will try to parse the label as an expression, which is obviously not correct. The problem is that it does not disambiguate before `when`, and there indeed is an expression after `when`. The proposal is to disambiguate as a pattern once there is `when` after a closing parenthesis at the top-level. This should prevent the code to even look at the `when` expression ------------- Commit messages: - 8335766: Switch case with pattern matching and guard clause compiles inconsistently Changes: https://git.openjdk.org/jdk/pull/20093/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20093&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335766 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20093.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20093/head:pull/20093 PR: https://git.openjdk.org/jdk/pull/20093 From abimpoudis at openjdk.org Tue Jul 9 09:29:32 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 9 Jul 2024 09:29:32 GMT Subject: RFR: 8335766: Switch case with pattern matching and guard clause compiles inconsistently In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 08:26:50 GMT, Jan Lahoda wrote: > When javac parser see a `case` label, it needs to disambiguate between expressions (constant labels) and patterns. But, for code like: > > case R(int x) when (x > 0) > > > the parser will try to parse the label as an expression, which is obviously not correct. The problem is that it does not disambiguate before `when`, and there indeed is an expression after `when`. > > The proposal is to disambiguate as a pattern once there is `when` after a closing parenthesis at the top-level. This should prevent the code to even look at the `when` expression Looks good. ------------- Marked as reviewed by abimpoudis (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20093#pullrequestreview-2165659910 From cstein at openjdk.org Tue Jul 9 10:57:42 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 9 Jul 2024 10:57:42 GMT Subject: RFR: 8335896: Source launcher should set TCCL Message-ID: Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." ------------- Commit messages: - JDK-8335896: Source launcher should set TCCL Changes: https://git.openjdk.org/jdk/pull/20097/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20097&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335896 Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20097.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20097/head:pull/20097 PR: https://git.openjdk.org/jdk/pull/20097 From jlahoda at openjdk.org Tue Jul 9 13:11:34 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 9 Jul 2024 13:11:34 GMT Subject: [jdk23] RFR: 8334757: AssertionError: Missing type variable in where clause In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 20:16:42 GMT, Liam Miller-Cushon wrote: > Please review this clean backport of #19840 to JDK 23, which avoids a crash when types with type variables appear as arguments for diagnostics that use `JCDiagnostic.AnnotatedType`. Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20085#pullrequestreview-2166279063 From vromero at openjdk.org Tue Jul 9 15:00:33 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 9 Jul 2024 15:00:33 GMT Subject: [jdk23] RFR: 8334757: AssertionError: Missing type variable in where clause In-Reply-To: References: Message-ID: <3RAcAiyuYDAfi1hJ7FB8vRs7KIp4fAJ8fwM-_mBQk4w=.dcd57c20-3f79-4e14-ac01-92f200c8f00c@github.com> On Mon, 8 Jul 2024 20:16:42 GMT, Liam Miller-Cushon wrote: > Please review this clean backport of #19840 to JDK 23, which avoids a crash when types with type variables appear as arguments for diagnostics that use `JCDiagnostic.AnnotatedType`. looks good ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20085#pullrequestreview-2166578010 From cstein at openjdk.org Tue Jul 9 15:56:49 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 9 Jul 2024 15:56:49 GMT Subject: RFR: 8334761: Source launcher fails with "Module reads more than one module named" error Message-ID: Please review this change to fix the setup of the optional module layer for user-supplied modules. This fix is composed of two parts: - modules already resolved in the boot layer are no longer part of the parent layer - the parent layer configuration does no longer bind services ------------- Commit messages: - Add test case - 8334761: Source launcher fails with "Module reads more than one module named" error Changes: https://git.openjdk.org/jdk/pull/19842/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19842&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334761 Stats: 70 lines in 2 files changed: 66 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19842/head:pull/19842 PR: https://git.openjdk.org/jdk/pull/19842 From cushon at openjdk.org Tue Jul 9 16:08:38 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Jul 2024 16:08:38 GMT Subject: [jdk23] Integrated: 8334757: AssertionError: Missing type variable in where clause In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 20:16:42 GMT, Liam Miller-Cushon wrote: > Please review this clean backport of #19840 to JDK 23, which avoids a crash when types with type variables appear as arguments for diagnostics that use `JCDiagnostic.AnnotatedType`. This pull request has now been integrated. Changeset: ca37a482 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/ca37a482cce9ad2bd57221f7ae34ac8246cd1843 Stats: 24 lines in 3 files changed: 24 ins; 0 del; 0 mod 8334757: AssertionError: Missing type variable in where clause Reviewed-by: jlahoda, vromero Backport-of: babf6df7d97e4beedb25e689634d999412c1e950 ------------- PR: https://git.openjdk.org/jdk/pull/20085 From aturbanov at openjdk.org Tue Jul 9 20:05:18 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 9 Jul 2024 20:05:18 GMT Subject: RFR: 8335159: Move method reference to lambda desugaring before Lower [v2] In-Reply-To: References: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> Message-ID: On Thu, 27 Jun 2024 10:03:23 GMT, Maurizio Cimadamore wrote: >> As we recently [moved](https://github.com/openjdk/jdk/pull/19836) the translation of "simple" method references from `LambdaToMethod` to `Lower`, it became clearer that this step in fact would benefit from running even *earlier*, as it depends on the synthetic casts generated by `TransTypes` (e.g. if one or more desugared lambda parameters have a type that is either an intersection or a union type). >> Moving the translation earlier would allow us not to *guess* which casts would need to be introduced, and just running `TransTypes::translate` on the desugaring code would take into account the type mismatches. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java line 629: > 627: */ > 628: boolean isPrivateInOtherClass(JCMemberReference tree) { > 629: return (tree.sym.flags() & PRIVATE) != 0 && Suggestion: return (tree.sym.flags() & PRIVATE) != 0 && ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19903#discussion_r1671163465 From aturbanov at openjdk.org Tue Jul 9 20:03:15 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 9 Jul 2024 20:03:15 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 19:18:21 GMT, Jonathan Gibbons wrote: >> Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. >> >> Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. >> >> There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. >> >> A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. >> >> There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > reorder imports src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlTag.java line 435: > 433: // This class exists to avoid warnings from using parameterized vararg type > 434: // Map in signature of HtmlTag constructor. > 435: private static class AttrMap extends EnumMap { Suggestion: private static class AttrMap extends EnumMap { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1671159565 From liach at openjdk.org Tue Jul 9 21:48:42 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 21:48:42 GMT Subject: RFR: 8335905: CompoundElement API cleanup Message-ID: `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`, thus we can remove `Iterable elements()` and `forEachElements(Consumer)`. ------------- Commit messages: - Missed tests - 8335905: CompoundElement API cleanup Changes: https://git.openjdk.org/jdk/pull/20103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20103&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335905 Stats: 83 lines in 32 files changed: 2 ins; 11 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/20103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20103/head:pull/20103 PR: https://git.openjdk.org/jdk/pull/20103 From duke at openjdk.org Wed Jul 10 09:18:21 2024 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Wed, 10 Jul 2024 09:18:21 GMT Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is failing on Japanese Windows In-Reply-To: References: Message-ID: <04lGsnheZQo5QBSLS4BUW_rfBUvlFOAU4LfjlKAbXUU=.44d43449-4d0c-4674-9b9e-8d60d6e4b6c1@github.com> On Fri, 14 Jun 2024 07:08:42 GMT, Jaikiran Pai wrote: >> I fixed to get Charset from native.encoding instead of Charset.defaultCharset() when reading a file to which the output of javac run in the test was redirected. >> The modified code is based on the alternatives given in JEP400. >> I verified that the test passed on Windows in both Japanese and English locales with this fix. > > test/langtools/tools/javac/newlines/NewLineTest.java line 61: > >> 59: .run(Task.Expect.FAIL); >> 60: >> 61: String encoding = System.getProperty("native.encoding"); > > Hello @tkiriyama, I don't have experience in javac area or this test, but I had a brief look at this change. What I understand is that `javac` will print to `STDOUT` using a `PrinterWriter` for `System.out`, which as per the documentation https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#out will use `stdout.encoding` value for the character encoding. The default value of `stdout.encoding` standard system property https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#stdout.encoding is currently not mentioned but I checked with people familiar with this area and it defaults to platform specific values. It is not guaranteed that `stdout.encoding` will be the same value as `native.encoding`. So the proposed change here isn't guaranteed to (always) work. > > I think to make this deterministic, you might have to update the `javac` launch command (a few lines above) to pass `-J-Dstdout.encoding=UTF-8` and then when reading from the file to which the content was redirected, use `StandardCharsets.UTF_8`. > Can you give that change a try on your setup and see if it solves the issue for you? @jaikiran Just a friendly reminder that I need your view. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1671923721 From jlahoda at openjdk.org Wed Jul 10 20:09:29 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 10 Jul 2024 20:09:29 GMT Subject: RFR: 8335817: javac AssertionError addLocalVar checkNull Message-ID: Consider pattern matching with deconstruction patter, like: boolean b = o instanceof R(String s); This will get desugared into code similar to `o instanceof R r && r.component() instanceof String s`, except that the call to `component()` is guarded with a try-catch, wrapping any exception with a `MatchException`. The internal javac implementation is to create a synthetic catch clause, and attach it to the relevant enclosing block. Now, consider an expression lambda with a deconstruction pattern matching, like `o -> o instanceof R(String s)`. There is no block in the lambda to which the catch could be attached. So, `TransPatterns` will expand the expression lambda to a block lambda, and inject the synthetic catches. But, `TransPatterns` will always do `return ;`, even if the type of `` is void. This then leads to a crash during Gen, as a variable of type `void` is created. The patch proposed here avoid creating `return ;` for void-type expression. ------------- Commit messages: - 8335817: javac AssertionError addLocalVar checkNull Changes: https://git.openjdk.org/jdk/pull/20110/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20110&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335817 Stats: 157 lines in 2 files changed: 155 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20110/head:pull/20110 PR: https://git.openjdk.org/jdk/pull/20110 From cushon at openjdk.org Wed Jul 10 20:28:47 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 10 Jul 2024 20:28:47 GMT Subject: RFR: 8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226 In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 01:15:09 GMT, Liam Miller-Cushon wrote: > Please consider this fix for [JDK-8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226](https://bugs.openjdk.org/browse/JDK-8334055), which partially reverts some logic originally added by the fix for [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226). > > The core of JDK-8043226 is preserved, improved diagnostics are still reported where 'scoping construct cannot be annotated' diagnostics were emitted previously. > > The reverted logic affects attribution of type annotations on package names, which was intended to enable better diagnostics, but also affected diagnostics for type annotations on missing symbols. > > > CantAnnotateMissingSymbol.java:12: error: unexpected type > List<@TA NoSuch> x; > ^ > required: reference > found: NoSuch > > > The restored behavior is: > > > CantAnnotateMissingSymbol.java:12: error: cannot find symbol > List<@TA NoSuch> x; > ^ > symbol: class NoSuch > location: class CantAnnotateMissingSymbol bridgekeeper please keep this open ------------- PR Comment: https://git.openjdk.org/jdk/pull/19667#issuecomment-2221348786 From jlahoda at openjdk.org Wed Jul 10 20:29:15 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 10 Jul 2024 20:29:15 GMT Subject: [jdk23] RFR: 8335766: Switch case with pattern matching and guard clause compiles inconsistently Message-ID: Hi all, This pull request contains a backport of commit [537d20af](https://github.com/openjdk/jdk/commit/537d20afbff255489a7b1bdb0410b9d1aba715b7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Jan Lahoda on 10 Jul 2024 and was reviewed by Aggelos Biboudis. Thanks! Original description: When javac parser see a `case` label, it needs to disambiguate between expressions (constant labels) and patterns. But, for code like: case R(int x) when (x > 0) the parser will try to parse the label as an expression, which is obviously not correct. The problem is that it does not disambiguate before `when`, and there indeed is an expression after `when`. The proposal is to disambiguate as a pattern once there is `when` after a closing parenthesis at the top-level. This should prevent the code to even look at the `when` expression ------------- Commit messages: - Backport 537d20afbff255489a7b1bdb0410b9d1aba715b7 Changes: https://git.openjdk.org/jdk/pull/20111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335766 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20111/head:pull/20111 PR: https://git.openjdk.org/jdk/pull/20111 From vromero at openjdk.org Thu Jul 11 01:49:00 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 11 Jul 2024 01:49:00 GMT Subject: [jdk23] RFR: 8335766: Switch case with pattern matching and guard clause compiles inconsistently In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 12:24:38 GMT, Jan Lahoda wrote: > Hi all, > > This pull request contains a backport of commit [537d20af](https://github.com/openjdk/jdk/commit/537d20afbff255489a7b1bdb0410b9d1aba715b7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jan Lahoda on 10 Jul 2024 and was reviewed by Aggelos Biboudis. > > Thanks! > > Original description: > When javac parser see a `case` label, it needs to disambiguate between expressions (constant labels) and patterns. But, for code like: > > case R(int x) when (x > 0) > > > the parser will try to parse the label as an expression, which is obviously not correct. The problem is that it does not disambiguate before `when`, and there indeed is an expression after `when`. > > The proposal is to disambiguate as a pattern once there is `when` after a closing parenthesis at the top-level. This should prevent the code to even look at the `when` expression lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20111#pullrequestreview-2170713037 From vromero at openjdk.org Thu Jul 11 01:59:56 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 11 Jul 2024 01:59:56 GMT Subject: RFR: 8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226 In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 01:15:09 GMT, Liam Miller-Cushon wrote: > Please consider this fix for [JDK-8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226](https://bugs.openjdk.org/browse/JDK-8334055), which partially reverts some logic originally added by the fix for [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226). > > The core of JDK-8043226 is preserved, improved diagnostics are still reported where 'scoping construct cannot be annotated' diagnostics were emitted previously. > > The reverted logic affects attribution of type annotations on package names, which was intended to enable better diagnostics, but also affected diagnostics for type annotations on missing symbols. > > > CantAnnotateMissingSymbol.java:12: error: unexpected type > List<@TA NoSuch> x; > ^ > required: reference > found: NoSuch > > > The restored behavior is: > > > CantAnnotateMissingSymbol.java:12: error: cannot find symbol > List<@TA NoSuch> x; > ^ > symbol: class NoSuch > location: class CantAnnotateMissingSymbol lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19667#pullrequestreview-2170726738 From cushon at openjdk.org Thu Jul 11 02:33:39 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 11 Jul 2024 02:33:39 GMT Subject: RFR: 8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226 [v2] In-Reply-To: References: Message-ID: > Please consider this fix for [JDK-8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226](https://bugs.openjdk.org/browse/JDK-8334055), which partially reverts some logic originally added by the fix for [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226). > > The core of JDK-8043226 is preserved, improved diagnostics are still reported where 'scoping construct cannot be annotated' diagnostics were emitted previously. > > The reverted logic affects attribution of type annotations on package names, which was intended to enable better diagnostics, but also affected diagnostics for type annotations on missing symbols. > > > CantAnnotateMissingSymbol.java:12: error: unexpected type > List<@TA NoSuch> x; > ^ > required: reference > found: NoSuch > > > The restored behavior is: > > > CantAnnotateMissingSymbol.java:12: error: cannot find symbol > List<@TA NoSuch> x; > ^ > symbol: class NoSuch > location: class CantAnnotateMissingSymbol Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8334055 - Add a regression test - 8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19667/files - new: https://git.openjdk.org/jdk/pull/19667/files/b4955142..fca8f55b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19667&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19667&range=00-01 Stats: 50189 lines in 1259 files changed: 33400 ins; 10891 del; 5898 mod Patch: https://git.openjdk.org/jdk/pull/19667.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19667/head:pull/19667 PR: https://git.openjdk.org/jdk/pull/19667 From jpai at openjdk.org Thu Jul 11 07:05:57 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Jul 2024 07:05:57 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 10:52:46 GMT, Christian Stein wrote: > Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. > > For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." Hello Christian, as far as I can see, in the current mainline, both source mode launch and the regular compiled launch, already have the Thread context classloader set to the application classloader. For example, this trivial example: public class Foo { public static void main(final String[] args) throws Exception { System.out.println("Thread context classloader: " + Thread.currentThread().getContextClassLoader()); } } When you run it in compiled mode as follows: javac Foo.java java Foo results in: Thread context classloader: jdk.internal.loader.ClassLoaders$AppClassLoader at 18ff02e4 When running into source mode: rm Foo.class java Foo.java also results in: Thread context classloader: jdk.internal.loader.ClassLoaders$AppClassLoader at 5a07e868 As for the example noted in the JBS issue's description - I don't think it is expected to work: public class Prog { public static class Enclosed implements Runnable { @Override public void run() { System.out.println(getClass()); } } public static void main(String... args) { // Thread.currentThread().setContextClassLoader(Prog.class.getClassLoader()); java.util.ServiceLoader.load(Runnable.class).forEach(Runnable::run); } } The example tries to load `Runnable` as a service. The ServiceLoader mechanism expects services to deployed either in the classpath or as a module. In the classpath mechanism, the service provider is expected to be declared in a file named `META-INF/services/` containing a line which points to the service provider implementation class. The JBS description also states that: > That's why for example the following program doesn't print anything, until either the comment-out line is included or the `ServiceLoader.load(Class, ClassLoader)` variant is used with `Prog.class.getClassLoader()` as the second argument. I was surprised that it would pick up the `Runnable` implementing classes dynamically as services. So I uncommented that commented line and ran the program (in source launch mode). It doesn't locate the `Runnable` implementation as a service and continues to not print anything. Same with passing `Prog.class.getClassLoader()` as the second argument to the `ServiceLoader.load(...)` call - the `Runnable` doesn't get located. This behaviour is understandable and as expected. Would you happen to have the additional details about the setup (and JDK version?) where that example ends up returning a Runnable class as a service provider and prints some output? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20097#issuecomment-2222186891 From cstein at openjdk.org Thu Jul 11 09:32:54 2024 From: cstein at openjdk.org (Christian Stein) Date: Thu, 11 Jul 2024 09:32:54 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 10:52:46 GMT, Christian Stein wrote: > Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. > > For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." I forgot to add two more files to the JBS issue. Namely the `module-info.java` file: module test { uses Runnable; provides Runnable with test.Prog.Enclosed, test.TopLevel; } and also the `test/TopLevel.java` file: package test; public class TopLevel implements Runnable { @Override public void run() { System.out.println(getClass()); } } With all those file in place, you get the following output using JDK 24: `java --show-version test/Prog.java` openjdk 24-ea 2025-03-18 [...] With `Thread.currentThread().setContextClassLoader(Prog.class.getClassLoader());` activated in `Prog.java` you'll see the `Runnable`s being loaded and executed: `java --show-version test/Prog.java` openjdk 24-ea 2025-03-18 [...] class test.Prog$Enclosed class test.TopLevel ------------- PR Comment: https://git.openjdk.org/jdk/pull/20097#issuecomment-2222462093 From cstein at openjdk.org Thu Jul 11 09:35:54 2024 From: cstein at openjdk.org (Christian Stein) Date: Thu, 11 Jul 2024 09:35:54 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: <6OHIpzY41qNf7Xe3iWlaP6PKkUKoOm0aqOdHL_SnqV0=.ca69ee63-ee27-4118-b48c-e8570ca27e54@github.com> On Thu, 11 Jul 2024 07:02:49 GMT, Jaikiran Pai wrote: > [...] already have the Thread context classloader set to the application classloader. This change will set the TCCL to the in-memory classloader in source launcher mode - which differs from the initial application classloader that was created for the `java test/Prog.java` process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20097#issuecomment-2222469904 From vromero at openjdk.org Thu Jul 11 10:20:55 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 11 Jul 2024 10:20:55 GMT Subject: RFR: 8335817: javac AssertionError addLocalVar checkNull In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 12:16:58 GMT, Jan Lahoda wrote: > Consider pattern matching with deconstruction patter, like: > > boolean b = o instanceof R(String s); > > > This will get desugared into code similar to `o instanceof R r && r.component() instanceof String s`, except that the call to `component()` is guarded with a try-catch, wrapping any exception with a `MatchException`. The internal javac implementation is to create a synthetic catch clause, and attach it to the relevant enclosing block. > > Now, consider an expression lambda with a deconstruction pattern matching, like `o -> o instanceof R(String s)`. There is no block in the lambda to which the catch could be attached. So, `TransPatterns` will expand the expression lambda to a block lambda, and inject the synthetic catches. But, `TransPatterns` will always do `return ;`, even if the type of `` is void. This then leads to a crash during Gen, as a variable of type `void` is created. > > The patch proposed here avoid creating `return ;` for void-type expression. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20110#pullrequestreview-2171502704 From jlahoda at openjdk.org Thu Jul 11 11:11:02 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 11 Jul 2024 11:11:02 GMT Subject: [jdk23] Integrated: 8335766: Switch case with pattern matching and guard clause compiles inconsistently In-Reply-To: References: Message-ID: <2aXiFAAkgyRLaQEdRawhi6gEoIerUovl9Yxn0Ebsgaw=.0d18da36-1a67-438a-85f6-3711350e3a35@github.com> On Wed, 10 Jul 2024 12:24:38 GMT, Jan Lahoda wrote: > Hi all, > > This pull request contains a backport of commit [537d20af](https://github.com/openjdk/jdk/commit/537d20afbff255489a7b1bdb0410b9d1aba715b7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jan Lahoda on 10 Jul 2024 and was reviewed by Aggelos Biboudis. > > Thanks! > > Original description: > When javac parser see a `case` label, it needs to disambiguate between expressions (constant labels) and patterns. But, for code like: > > case R(int x) when (x > 0) > > > the parser will try to parse the label as an expression, which is obviously not correct. The problem is that it does not disambiguate before `when`, and there indeed is an expression after `when`. > > The proposal is to disambiguate as a pattern once there is `when` after a closing parenthesis at the top-level. This should prevent the code to even look at the `when` expression This pull request has now been integrated. Changeset: e991c0f9 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/e991c0f921768debdb8cb849acd5006ce81c989a Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod 8335766: Switch case with pattern matching and guard clause compiles inconsistently Reviewed-by: vromero Backport-of: 537d20afbff255489a7b1bdb0410b9d1aba715b7 ------------- PR: https://git.openjdk.org/jdk/pull/20111 From cstein at openjdk.org Thu Jul 11 12:58:32 2024 From: cstein at openjdk.org (Christian Stein) Date: Thu, 11 Jul 2024 12:58:32 GMT Subject: RFR: 8334761: Source launcher fails with "Module reads more than one module named" error [v2] In-Reply-To: References: Message-ID: <4dLiKJ3HQLcINmhbXaIK1b1VUYQWpG7SgHhpgK5FDnc=.c59195b3-b1e2-4697-a61b-fc1fb0c50b07@github.com> > Please review this change to fix the setup of the optional module layer for user-supplied modules. > > This fix is composed of two parts: > - modules already resolved in the boot layer are no longer part of the parent layer > - the parent layer configuration does no longer bind services Christian Stein has updated the pull request incrementally with one additional commit since the last revision: In source launch mode, add all modules on the module path by default. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19842/files - new: https://git.openjdk.org/jdk/pull/19842/files/a4776ef6..c5c437f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19842&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19842&range=00-01 Stats: 33 lines in 2 files changed: 1 ins; 27 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/19842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19842/head:pull/19842 PR: https://git.openjdk.org/jdk/pull/19842 From vromero at openjdk.org Thu Jul 11 15:30:57 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 11 Jul 2024 15:30:57 GMT Subject: RFR: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure [v3] In-Reply-To: <62g3PJ-z0oxFBe-fUb2WpRSt5Expqe8_KJE7g5dLqZs=.927a02c9-ec81-43af-9715-133c6025df0d@github.com> References: <62g3PJ-z0oxFBe-fUb2WpRSt5Expqe8_KJE7g5dLqZs=.927a02c9-ec81-43af-9715-133c6025df0d@github.com> Message-ID: On Thu, 4 Jul 2024 10:53:51 GMT, Jan Lahoda wrote: >> Tests for javac use several test frameworks, and one of them is the "toolbox", which provides `JavacTask` that allows to conveniently run javac on a given set of sources. The problem with `JavacTask` is that, by default, when a compilation failure is expected, javac crash (exit code 4) is tolerated by the `JavacTask`. And the test must manually select a specific exit code to overwrite this behavior. >> >> This then leads to bugs like https://bugs.openjdk.org/browse/JDK-8335385, which are silently ignored by `JavacTask`. >> >> The proposal herein is to tighten up the `JavacTask`, and effectively disallow exit code 4 for `JavacTask` (but permit any other exit code, as javac is using several exit codes). The base implementation in `AbstractTask` is changed to use a validator for the exit codes, which is then leveraged by `JavacTask`. >> >> This patch depends on PR #19969, as that fixes JDK-8335385, where the javac crash is ignored. It also tweaks module attribution to not leave empty `JCModuleDecl.sym` for duplicate modules, and set it to an erroneous module. The empty (`null`) symbol here crashes javac in the `test/langtools/tools/javac/modules/MultiModuleModeTest.java#testDuplicateModules`, and the test wouldn't pass with this more strict `JavacTask`. > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'JDK-8332474' of github.com:lahodaj/jdk into JDK-8332474 > - Fixing typo, as suggested. > - Merge branch 'master' into JDK-8332474 > - Fixing expect semantics > - Cleanup. > - Cleanup. > - Merge branch 'JDK-8335385' into JDK-8332474 > - 8335385: javac crash on unattributed piece of AST > - 8332474: Tighten up ToolBox' JavacTask to not silently access javac crash as a failure lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19972#pullrequestreview-2172297211 From cushon at openjdk.org Thu Jul 11 19:57:07 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 11 Jul 2024 19:57:07 GMT Subject: Integrated: 8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226 In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 01:15:09 GMT, Liam Miller-Cushon wrote: > Please consider this fix for [JDK-8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226](https://bugs.openjdk.org/browse/JDK-8334055), which partially reverts some logic originally added by the fix for [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226). > > The core of JDK-8043226 is preserved, improved diagnostics are still reported where 'scoping construct cannot be annotated' diagnostics were emitted previously. > > The reverted logic affects attribution of type annotations on package names, which was intended to enable better diagnostics, but also affected diagnostics for type annotations on missing symbols. > > > CantAnnotateMissingSymbol.java:12: error: unexpected type > List<@TA NoSuch> x; > ^ > required: reference > found: NoSuch > > > The restored behavior is: > > > CantAnnotateMissingSymbol.java:12: error: cannot find symbol > List<@TA NoSuch> x; > ^ > symbol: class NoSuch > location: class CantAnnotateMissingSymbol This pull request has now been integrated. Changeset: 9eb611e7 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/9eb611e7f07ebb6eb0cbcca32d644abf8352c991 Stats: 41 lines in 7 files changed: 23 ins; 13 del; 5 mod 8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226 Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/19667 From duke at openjdk.org Thu Jul 11 21:18:08 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 21:18:08 GMT Subject: RFR: 8332109: Convert remaining tests using com.sun.tools.classfile to ClassFile API In-Reply-To: References: Message-ID: On Sun, 12 May 2024 08:36:44 GMT, Chen Liang wrote: > Some tests are not migrated to the ClassFile API in previous migrations. > > - Some are simple oversights that didn't remove usages of com.sun.tools.classfile; > - The CallerSensitive ones used an old utility, replaced by CF API-based new code; > - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`; > - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs. > > Testing: all modified tests pass. @liach Your change (at version 4880f3a375ff46a4be94d0fe483f8ec927f1933a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19206#issuecomment-2117386568 From duke at openjdk.org Thu Jul 11 21:18:00 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 21:18:00 GMT Subject: RFR: 8331855: Convert jdk.jdeps jdeprscan and jdeps to use the Classfile API [v2] In-Reply-To: <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com> References: <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com> Message-ID: On Sun, 12 May 2024 02:42:32 GMT, Chen Liang wrote: >> Summary of the changes: >> - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps; they are exclusively used by jdeps in sources, and they are not used in any tests too. This will ease the removal of `com.sun.tools.classfile` later. >> - A few visitor patterns have been rewritten with pattern matching, notably in: >> - `CPEntries`/`CPSelector` (removed) >> - `Dependencies.BasicDependencyFinder.Visitor` has been rewritten to use pattern matching to capture dependencies. >> - `MethodSig` and its tests have been removed in favor of `MethodTypeDesc`. >> - Otherwise, the changes are mostly mechanical replacements. >> >> All tests in `test/langtools/tools/jdeprscan` and `test/langtools/tools/jdeps` pass. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Migrate omitted getdeps test in langtools @liach Your change (at version be8c25b1175911e6c4c414ca30760abd3c198c1f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19193#issuecomment-2117387196 From duke at openjdk.org Thu Jul 11 21:19:10 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 21:19:10 GMT Subject: RFR: 8323707: Adjust Classfile API's type arg model to better represent the embodied type [v5] In-Reply-To: References: Message-ID: On Wed, 1 May 2024 22:39:05 GMT, Chen Liang wrote: >> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html >> >> Additional questions: >> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE` > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Missing since tags > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - Missed renaming in tests, thanks to Adam Sotona > > Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com> > - Rename no wildcard indicator, improve docs slightly > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - Merge branch 'master' into fix/typearg-model > - redundant line > - Fix a test in langtools, copyright year > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - ... and 5 more: https://git.openjdk.org/jdk/compare/0a24daec...f9af4182 @liach Your change (at version f9af4182c35a8ed2e6cc3d2eb230419b3d69f347) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16517#issuecomment-2091977070 From vromero at openjdk.org Thu Jul 11 21:43:16 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 11 Jul 2024 21:43:16 GMT Subject: RFR: 8332600: javac uses record components source position during compilation Message-ID: javac uses the source position of record components to find and later probably remove a given record component during compilation. This could be necessary if annotation processors are present. This is done in part to provide better error messages for silly record definitions like: record R(int i, float i) {} // two record components with the same name but this is brittle and can backfire if the record is read from a class file as the source positions are not stored there. See [JDK-8332297](https://bugs.openjdk.org/browse/JDK-8332297) for some context The idea of this fix is not to use the source position but only the name to find a given record component. This could imply that if the user defines an erroneous record like the one above, then the record could end up with less record components than expected but records like this wouldn't compile anyway TIA ------------- Commit messages: - 8332600: javac uses record components source position during compilation Changes: https://git.openjdk.org/jdk/pull/20148/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20148&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332600 Stats: 11 lines in 4 files changed: 2 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20148/head:pull/20148 PR: https://git.openjdk.org/jdk/pull/20148 From jlahoda at openjdk.org Fri Jul 12 12:19:57 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 12 Jul 2024 12:19:57 GMT Subject: Integrated: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 14:09:39 GMT, Jan Lahoda wrote: > Tests for javac use several test frameworks, and one of them is the "toolbox", which provides `JavacTask` that allows to conveniently run javac on a given set of sources. The problem with `JavacTask` is that, by default, when a compilation failure is expected, javac crash (exit code 4) is tolerated by the `JavacTask`. And the test must manually select a specific exit code to overwrite this behavior. > > This then leads to bugs like https://bugs.openjdk.org/browse/JDK-8335385, which are silently ignored by `JavacTask`. > > The proposal herein is to tighten up the `JavacTask`, and effectively disallow exit code 4 for `JavacTask` (but permit any other exit code, as javac is using several exit codes). The base implementation in `AbstractTask` is changed to use a validator for the exit codes, which is then leveraged by `JavacTask`. > > This patch depends on PR #19969, as that fixes JDK-8335385, where the javac crash is ignored. It also tweaks module attribution to not leave empty `JCModuleDecl.sym` for duplicate modules, and set it to an erroneous module. The empty (`null`) symbol here crashes javac in the `test/langtools/tools/javac/modules/MultiModuleModeTest.java#testDuplicateModules`, and the test wouldn't pass with this more strict `JavacTask`. This pull request has now been integrated. Changeset: 559826c2 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/559826c2922851dbe45ead23ad1d73b1846334ac Stats: 73 lines in 3 files changed: 64 ins; 1 del; 8 mod 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/19972 From jlahoda at openjdk.org Fri Jul 12 13:05:53 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 12 Jul 2024 13:05:53 GMT Subject: RFR: 8332600: javac uses record components source position during compilation In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 21:36:40 GMT, Vicente Romero wrote: > javac uses the source position of record components to find and later probably remove a given record component during compilation. This could be necessary if annotation processors are present. This is done in part to provide better error messages for silly record definitions like: > > record R(int i, float i) {} // two record components with the same name > > but this is brittle and can backfire if the record is read from a class file as the source positions are not stored there. See [JDK-8332297](https://bugs.openjdk.org/browse/JDK-8332297) for some context > > The idea of this fix is not to use the source position but only the name to find a given record component. This could imply that if the user defines an erroneous record like the one above, then the record could end up with less record components than expected but records like this wouldn't compile anyway > > TIA src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1142: > 1140: boolean paramIsVarArgs = (param.sym.flags_field & VARARGS) != 0; > 1141: if (!types.isSameType(param.type, recordFieldTypes.head) || > 1142: (recordComponents.head != null && I am afraid `recordComponents.head != null` (which is basically `recordComponents.isEmpty()`, I think) is probably insufficient here. Consider e.g.: record R(int x, int x, int x) {} which will fail as `recordComponents` itself will be `null`, due to `tail` being `null`. Looking at the last record component (`.last()`) might be one of the solutions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20148#discussion_r1675832203 From vromero at openjdk.org Fri Jul 12 20:24:23 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 12 Jul 2024 20:24:23 GMT Subject: RFR: 8332600: javac uses record components source position during compilation [v2] In-Reply-To: References: Message-ID: > javac uses the source position of record components to find and later probably remove a given record component during compilation. This could be necessary if annotation processors are present. This is done in part to provide better error messages for silly record definitions like: > > record R(int i, float i) {} // two record components with the same name > > but this is brittle and can backfire if the record is read from a class file as the source positions are not stored there. See [JDK-8332297](https://bugs.openjdk.org/browse/JDK-8332297) for some context > > The idea of this fix is not to use the source position but only the name to find a given record component. This could imply that if the user defines an erroneous record like the one above, then the record could end up with less record components than expected but records like this wouldn't compile anyway > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20148/files - new: https://git.openjdk.org/jdk/pull/20148/files/49d0ad16..e7647e22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20148&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20148&range=00-01 Stats: 42 lines in 4 files changed: 22 ins; 12 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20148/head:pull/20148 PR: https://git.openjdk.org/jdk/pull/20148 From vromero at openjdk.org Fri Jul 12 20:45:54 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 12 Jul 2024 20:45:54 GMT Subject: RFR: 8332600: javac uses record components source position during compilation [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 13:03:02 GMT, Jan Lahoda wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1142: > >> 1140: boolean paramIsVarArgs = (param.sym.flags_field & VARARGS) != 0; >> 1141: if (!types.isSameType(param.type, recordFieldTypes.head) || >> 1142: (recordComponents.head != null && > > I am afraid `recordComponents.head != null` (which is basically `recordComponents.isEmpty()`, I think) is probably insufficient here. Consider e.g.: > > record R(int x, int x, int x) {} > > > which will fail as `recordComponents` itself will be `null`, due to `tail` being `null`. > > Looking at the last record component (`.last()`) might be one of the solutions? I have changed the code a bit, I think it make more sense now, thanks for the comments ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20148#discussion_r1676441264 From liach at openjdk.org Sun Jul 14 22:36:17 2024 From: liach at openjdk.org (Chen Liang) Date: Sun, 14 Jul 2024 22:36:17 GMT Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant Message-ID: Remove `AnnotationConstantValueEntry` and `AnnotationValue.OfConstant`. This is a relic of the old model from https://github.com/openjdk/jdk-sandbox/commit/bb7e29474ecfcfbd1eb01d237593eb80d062944f. In addition, this is bug-prone: the byte, short, char, and boolean constants use the int entry, and getting the `ConstantDesc` for them will return an `Integer`, which cannot be inversed back into the respective annotation values via `AnnotationValue.of(Object)` factory. ------------- Commit messages: - Redundant since tags - Remove AnnotationValue.OfConstant - Merge branch 'master' of https://github.com/openjdk/jdk into fix/acve - Merge branch 'm3' into fix/acve - Remove AnnotationConstantValueEntry Changes: https://git.openjdk.org/jdk/pull/20176/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20176&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335927 Stats: 391 lines in 19 files changed: 129 ins; 105 del; 157 mod Patch: https://git.openjdk.org/jdk/pull/20176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20176/head:pull/20176 PR: https://git.openjdk.org/jdk/pull/20176 From mcimadamore at openjdk.org Mon Jul 15 09:58:08 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 09:58:08 GMT Subject: RFR: 8335159: Move method reference to lambda desugaring before Lower [v3] In-Reply-To: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> References: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> Message-ID: <6Tide8UkHbn9N-dAqvtTAymdKZnGAg7fKvanm55jWkw=.40d65a0b-757e-4502-bff6-f3f82543fa19@github.com> > As we recently [moved](https://github.com/openjdk/jdk/pull/19836) the translation of "simple" method references from `LambdaToMethod` to `Lower`, it became clearer that this step in fact would benefit from running even *earlier*, as it depends on the synthetic casts generated by `TransTypes` (e.g. if one or more desugared lambda parameters have a type that is either an intersection or a union type). > Moving the translation earlier would allow us not to *guess* which casts would need to be introduced, and just running `TransTypes::translate` on the desugaring code would take into account the type mismatches. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19903/files - new: https://git.openjdk.org/jdk/pull/19903/files/9ef90711..c4ea895a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19903&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19903&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19903.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19903/head:pull/19903 PR: https://git.openjdk.org/jdk/pull/19903 From mcimadamore at openjdk.org Mon Jul 15 10:03:43 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 10:03:43 GMT Subject: RFR: 8335159: Move method reference to lambda desugaring before Lower [v4] In-Reply-To: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> References: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> Message-ID: > As we recently [moved](https://github.com/openjdk/jdk/pull/19836) the translation of "simple" method references from `LambdaToMethod` to `Lower`, it became clearer that this step in fact would benefit from running even *earlier*, as it depends on the synthetic casts generated by `TransTypes` (e.g. if one or more desugared lambda parameters have a type that is either an intersection or a union type). > Moving the translation earlier would allow us not to *guess* which casts would need to be introduced, and just running `TransTypes::translate` on the desugaring code would take into account the type mismatches. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into mref_trans_types - Add test for 8336320 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java Co-authored-by: Andrey Turbanov - Address review comment - Initial push ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19903/files - new: https://git.openjdk.org/jdk/pull/19903/files/c4ea895a..f74b0314 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19903&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19903&range=02-03 Stats: 23069 lines in 832 files changed: 14808 ins; 4665 del; 3596 mod Patch: https://git.openjdk.org/jdk/pull/19903.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19903/head:pull/19903 PR: https://git.openjdk.org/jdk/pull/19903 From mcimadamore at openjdk.org Mon Jul 15 11:24:50 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 11:24:50 GMT Subject: RFR: 8335817: javac AssertionError addLocalVar checkNull In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 12:16:58 GMT, Jan Lahoda wrote: > Consider pattern matching with deconstruction patter, like: > > boolean b = o instanceof R(String s); > > > This will get desugared into code similar to `o instanceof R r && r.component() instanceof String s`, except that the call to `component()` is guarded with a try-catch, wrapping any exception with a `MatchException`. The internal javac implementation is to create a synthetic catch clause, and attach it to the relevant enclosing block. > > Now, consider an expression lambda with a deconstruction pattern matching, like `o -> o instanceof R(String s)`. There is no block in the lambda to which the catch could be attached. So, `TransPatterns` will expand the expression lambda to a block lambda, and inject the synthetic catches. But, `TransPatterns` will always do `return ;`, even if the type of `` is void. This then leads to a crash during Gen, as a variable of type `void` is created. > > The patch proposed here avoid creating `return ;` for void-type expression. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20110#pullrequestreview-2177452427 From jlahoda at openjdk.org Mon Jul 15 11:28:57 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 15 Jul 2024 11:28:57 GMT Subject: Integrated: 8335817: javac AssertionError addLocalVar checkNull In-Reply-To: References: Message-ID: <8GLR10rWSKxVnsdL3jlsMzNESsK13_cfWMRw2w5x2PY=.be080a9d-91c7-41d9-94de-c7f5d67c116b@github.com> On Wed, 10 Jul 2024 12:16:58 GMT, Jan Lahoda wrote: > Consider pattern matching with deconstruction patter, like: > > boolean b = o instanceof R(String s); > > > This will get desugared into code similar to `o instanceof R r && r.component() instanceof String s`, except that the call to `component()` is guarded with a try-catch, wrapping any exception with a `MatchException`. The internal javac implementation is to create a synthetic catch clause, and attach it to the relevant enclosing block. > > Now, consider an expression lambda with a deconstruction pattern matching, like `o -> o instanceof R(String s)`. There is no block in the lambda to which the catch could be attached. So, `TransPatterns` will expand the expression lambda to a block lambda, and inject the synthetic catches. But, `TransPatterns` will always do `return ;`, even if the type of `` is void. This then leads to a crash during Gen, as a variable of type `void` is created. > > The patch proposed here avoid creating `return ;` for void-type expression. This pull request has now been integrated. Changeset: 2b0adfc2 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/2b0adfc2decf47f6f49f072549c96f301f275285 Stats: 157 lines in 2 files changed: 155 ins; 0 del; 2 mod 8335817: javac AssertionError addLocalVar checkNull Reviewed-by: vromero, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/20110 From jlahoda at openjdk.org Mon Jul 15 13:27:55 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 15 Jul 2024 13:27:55 GMT Subject: RFR: 8335159: Move method reference to lambda desugaring before Lower [v4] In-Reply-To: References: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> Message-ID: On Mon, 15 Jul 2024 10:03:43 GMT, Maurizio Cimadamore wrote: >> As we recently [moved](https://github.com/openjdk/jdk/pull/19836) the translation of "simple" method references from `LambdaToMethod` to `Lower`, it became clearer that this step in fact would benefit from running even *earlier*, as it depends on the synthetic casts generated by `TransTypes` (e.g. if one or more desugared lambda parameters have a type that is either an intersection or a union type). >> Moving the translation earlier would allow us not to *guess* which casts would need to be introduced, and just running `TransTypes::translate` on the desugaring code would take into account the type mismatches. > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into mref_trans_types > - Add test for 8336320 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java > > Co-authored-by: Andrey Turbanov > - Address review comment > - Initial push test/langtools/tools/javac/SuperInit/MrefDoubleTrans.java line 36: > 34: } > 35: > 36: static class I { To make the test fail without this patch: Suggestion: class I { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19903#discussion_r1677828820 From duke at openjdk.org Mon Jul 15 13:28:54 2024 From: duke at openjdk.org (ExE Boss) Date: Mon, 15 Jul 2024 13:28:54 GMT Subject: RFR: 8334714: Class-File API leaves preview In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 11:56:37 GMT, Adam Sotona wrote: > Class-File API is leaving preview. > This is a removal of all `@PreviewFeature` annotations from Class-File API. > It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. > > Please review. > > Thanks, > Adam Note?that `Utf8Entry::equalsString` has?inconsistent behaviour when?called with?a?`null`?value, which?I?ve?reported as?[JI?9077307], and?should probably be?fixed before this?API leaves?preview. [JI?9077307]: https://bugs.openjdk.org/browse/JI-9077307 "JI?9077307: Inconsistent?NPE?behaviour of?`Utf8Entry::equalsString`" ------------- PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2228504207 From mcimadamore at openjdk.org Mon Jul 15 13:35:05 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 13:35:05 GMT Subject: RFR: 8335159: Move method reference to lambda desugaring before Lower [v5] In-Reply-To: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> References: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> Message-ID: > As we recently [moved](https://github.com/openjdk/jdk/pull/19836) the translation of "simple" method references from `LambdaToMethod` to `Lower`, it became clearer that this step in fact would benefit from running even *earlier*, as it depends on the synthetic casts generated by `TransTypes` (e.g. if one or more desugared lambda parameters have a type that is either an intersection or a union type). > Moving the translation earlier would allow us not to *guess* which casts would need to be introduced, and just running `TransTypes::translate` on the desugaring code would take into account the type mismatches. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19903/files - new: https://git.openjdk.org/jdk/pull/19903/files/f74b0314..ee3345d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19903&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19903&range=03-04 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/19903.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19903/head:pull/19903 PR: https://git.openjdk.org/jdk/pull/19903 From jlahoda at openjdk.org Mon Jul 15 13:35:05 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 15 Jul 2024 13:35:05 GMT Subject: RFR: 8335159: Move method reference to lambda desugaring before Lower [v5] In-Reply-To: References: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> Message-ID: On Mon, 15 Jul 2024 13:32:16 GMT, Maurizio Cimadamore wrote: >> As we recently [moved](https://github.com/openjdk/jdk/pull/19836) the translation of "simple" method references from `LambdaToMethod` to `Lower`, it became clearer that this step in fact would benefit from running even *earlier*, as it depends on the synthetic casts generated by `TransTypes` (e.g. if one or more desugared lambda parameters have a type that is either an intersection or a union type). >> Moving the translation earlier would allow us not to *guess* which casts would need to be introduced, and just running `TransTypes::translate` on the desugaring code would take into account the type mismatches. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix test Looks good! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19903#pullrequestreview-2177729884 From mcimadamore at openjdk.org Mon Jul 15 14:26:58 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 14:26:58 GMT Subject: Integrated: 8335159: Move method reference to lambda desugaring before Lower In-Reply-To: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> References: <45xbvB40GP7_2RaT4GJxZ5qf2u3LuWDvr6b73Q8wnt0=.08b2ba00-a202-4718-8299-43cd35d291ba@github.com> Message-ID: <8zPyaQKR0TKlZzZ5QpkM65YnP-yq4H3E7JwD3cjLvXs=.9a6d09fd-c6c6-45fa-89a6-37c3de2584ec@github.com> On Wed, 26 Jun 2024 11:00:23 GMT, Maurizio Cimadamore wrote: > As we recently [moved](https://github.com/openjdk/jdk/pull/19836) the translation of "simple" method references from `LambdaToMethod` to `Lower`, it became clearer that this step in fact would benefit from running even *earlier*, as it depends on the synthetic casts generated by `TransTypes` (e.g. if one or more desugared lambda parameters have a type that is either an intersection or a union type). > Moving the translation earlier would allow us not to *guess* which casts would need to be introduced, and just running `TransTypes::translate` on the desugaring code would take into account the type mismatches. This pull request has now been integrated. Changeset: 46355319 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/4635531950dbcfcd3ee2f13a57f0909af78a94c7 Stats: 660 lines in 3 files changed: 307 ins; 353 del; 0 mod 8335159: Move method reference to lambda desugaring before Lower 8336320: NullPointerException: Cannot invoke Type.getTag because type is null after JDK-8334037 Reviewed-by: jlahoda, vromero ------------- PR: https://git.openjdk.org/jdk/pull/19903 From jpai at openjdk.org Mon Jul 15 14:28:37 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 14:28:37 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory [v8] In-Reply-To: References: Message-ID: > Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? > > The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. > > As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. > > The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). > > The commit also includes a jtreg testcase which verifies the usage of this new option. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - merge latest from master branch - merge latest from master branch - merge latest from master branch - cleanup testExtractNoDestDirWithPFlag() test - merge latest from master branch - merge latest from master branch - convert the new test to junit - merge latest from master branch - Lance's review - include tests for --extract long form option - cleanup after each test - ... and 8 more: https://git.openjdk.org/jdk/compare/a253e0ff...ece49f9f ------------- Changes: https://git.openjdk.org/jdk/pull/2752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=07 Stats: 569 lines in 4 files changed: 558 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752 PR: https://git.openjdk.org/jdk/pull/2752 From jlahoda at openjdk.org Mon Jul 15 15:07:21 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 15 Jul 2024 15:07:21 GMT Subject: [jdk23] RFR: 8335817: javac AssertionError addLocalVar checkNull Message-ID: <-wflmrIYabuDdOv8Z8sVxYSZTUWqtadkgu2IuD_-csc=.47be1901-4282-4fbc-89fa-d845a26d8eca@github.com> Hi all, This pull request contains a backport of commit [2b0adfc2](https://github.com/openjdk/jdk/commit/2b0adfc2decf47f6f49f072549c96f301f275285) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Jan Lahoda on 15 Jul 2024 and was reviewed by Vicente Romero and Maurizio Cimadamore. Thanks! Original description: Consider pattern matching with deconstruction patter, like: boolean b = o instanceof R(String s); This will get desugared into code similar to `o instanceof R r && r.component() instanceof String s`, except that the call to `component()` is guarded with a try-catch, wrapping any exception with a `MatchException`. The internal javac implementation is to create a synthetic catch clause, and attach it to the relevant enclosing block. Now, consider an expression lambda with a deconstruction pattern matching, like `o -> o instanceof R(String s)`. There is no block in the lambda to which the catch could be attached. So, `TransPatterns` will expand the expression lambda to a block lambda, and inject the synthetic catches. But, `TransPatterns` will always do `return ;`, even if the type of `` is void. This then leads to a crash during Gen, as a variable of type `void` is created. The patch proposed here avoid creating `return ;` for void-type expression. ------------- Commit messages: - Backport 2b0adfc2decf47f6f49f072549c96f301f275285 Changes: https://git.openjdk.org/jdk/pull/20183/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20183&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335817 Stats: 157 lines in 2 files changed: 155 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20183/head:pull/20183 PR: https://git.openjdk.org/jdk/pull/20183 From mcimadamore at openjdk.org Mon Jul 15 15:31:02 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 15:31:02 GMT Subject: Integrated: 8334121: Anonymous class capturing two enclosing instances fails to compile In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 10:04:18 GMT, Maurizio Cimadamore wrote: > This PR contains a fix for an issue when translating local/anon classes. Currently, javac assumes that a local/anon class C must have an enclosing instance whose type is the innermost enclosing class of C. But this is not always true - there are cases where the innermost enclosing instance is in early construction context, so we can't really refer to its members from the local class. Moreover, even if the innermost class _was_ accessible, there could be cases where the enclosing instance of that innermost enclosing class is _not_ accessible. > > In other words, we cannot rely on the assumption that, given a local/anonymous class, there exist a chain of enclosing instances from the innermost to the outermost. Some chain exists, but it might not start from the innermost enclosing class, and it might have holes. > > The core of the fix is the addition of a new function in `Symbol`, namely `Symbol::innermostAccessibleEnclosingClass`. As the name implies, the goal of this function is to return the class symbol corresponding to the innermost enclosing type **that is accessible** from the symbol's class. This is used by `Lower` to determine the type of `this$0`, which allows us to construct a chain of enclosing instances that skips over all the inaccessible types. > > I've also updated the `Symbol::hasOuterInstance` method, so that it, too, will skip over inaccessible enclosing type (and only return `true` if some accessible enclosing type is found). > > This cleanup brings a lot of simplifications to `Lower.FreeVarCollector`. That class is used to compute the set of captured variables inside a local/anon class. There is a workaround in this class so that if a local/anon class occurs in a pre-construction context (where the enclosing `this` is not accessible), we say that the local/anon class captures the enclosing constructor parameter of the place where the local/anon class occurs (e.g. the enclosing `'this`'s enclosing `this`). This adds complexity to the code, as now the set of captured variables depends on the state of `Lower`. With this PR, all that logic is now gone, and `FreeVarCollector` is effectively a stateless visitor. This pull request has now been integrated. Changeset: 9dfcd75e Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/9dfcd75ec4f6c1fb60e5416fa6fc759c969a24fb Stats: 138 lines in 4 files changed: 88 ins; 44 del; 6 mod 8334121: Anonymous class capturing two enclosing instances fails to compile Reviewed-by: jlahoda, vromero ------------- PR: https://git.openjdk.org/jdk/pull/19900 From alanb at openjdk.org Mon Jul 15 15:58:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 15:58:53 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: <6OHIpzY41qNf7Xe3iWlaP6PKkUKoOm0aqOdHL_SnqV0=.ca69ee63-ee27-4118-b48c-e8570ca27e54@github.com> References: <6OHIpzY41qNf7Xe3iWlaP6PKkUKoOm0aqOdHL_SnqV0=.ca69ee63-ee27-4118-b48c-e8570ca27e54@github.com> Message-ID: On Thu, 11 Jul 2024 09:33:42 GMT, Christian Stein wrote: > This change will set the TCCL to the in-memory classloader in source launcher mode - which differs from the initial application classloader that was created for the `java test/Prog.java` process. Right, it need to the set to the in-memory class loader, otherwise service lookup and everything else that uses the TCCL will not locate classes or resources that are co-located in the child layer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20097#issuecomment-2228846367 From alanb at openjdk.org Mon Jul 15 16:09:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 16:09:54 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 10:52:46 GMT, Christian Stein wrote: > Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. > > For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 204: > 202: ClassLoader loader = context.newClassLoaderFor(parentLoader, firstClassName); > 203: firstClass = Class.forName(firstClassName, false, loader); > 204: Thread.currentThread().setContextClassLoader(loader); Are you sure this it the right place? It might be, but seeing it in a try-catch is surprising. It should be set before the initializer for the main class runs, which might be here but checking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20097#discussion_r1678076491 From jpai at openjdk.org Mon Jul 15 16:17:52 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 16:17:52 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 10:52:46 GMT, Christian Stein wrote: > Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. > > For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 204: > 202: ClassLoader loader = context.newClassLoaderFor(parentLoader, firstClassName); > 203: firstClass = Class.forName(firstClassName, false, loader); > 204: Thread.currentThread().setContextClassLoader(loader); Hello Christian, a typical pattern for such Thread context classloader switches is to reset the context classloader back to the previous one, once the "work" is done. That way it doesn't influence the code after the completion of the work. So something like the following might be more safer: ClassLoader loader; try { loader = context.newClassLoaderFor(parentLoader, firstClassName); firstClass = Class.forName(firstClassName, false, loader); } catch (ClassNotFoundException e) { throw new Fault(Errors.CantFindClass(firstClassName)); } final ClassLoader prevTCCL = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(loader); try { Method mainMethod = MethodFinder.findMainMethod(firstClass); ... // rest of the existing code return mainClass; } finally { Thread.currentThread().setContextClassLoader(prevTCCL); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20097#discussion_r1678086420 From alanb at openjdk.org Mon Jul 15 16:21:50 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 16:21:50 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 16:15:04 GMT, Jaikiran Pai wrote: >> Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. >> >> For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." > > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 204: > >> 202: ClassLoader loader = context.newClassLoaderFor(parentLoader, firstClassName); >> 203: firstClass = Class.forName(firstClassName, false, loader); >> 204: Thread.currentThread().setContextClassLoader(loader); > > Hello Christian, a typical pattern for such Thread context classloader switches is to reset the context classloader back to the previous one, once the "work" is done. That way it doesn't influence the code after the completion of the work. > > So something like the following might be more safer: > > > ClassLoader loader; > try { > loader = context.newClassLoaderFor(parentLoader, firstClassName); > firstClass = Class.forName(firstClassName, false, loader); > } catch (ClassNotFoundException e) { > throw new Fault(Errors.CantFindClass(firstClassName)); > } > final ClassLoader prevTCCL = Thread.currentThread().getContextClassLoader(); > Thread.currentThread().setContextClassLoader(loader); > try { > Method mainMethod = MethodFinder.findMainMethod(firstClass); > ... // rest of the existing code > return mainClass; > } finally { > Thread.currentThread().setContextClassLoader(prevTCCL); > } @jaikiran The PR is the equivalent of System.initPhase3 where it sets the TCCL for the main thread. With the source code launcher, the defining loader of the source "main" is a child of the system (usually application) class loader. So it's not meant to be temporary setting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20097#discussion_r1678092825 From jpai at openjdk.org Mon Jul 15 16:28:51 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 16:28:51 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 16:19:20 GMT, Alan Bateman wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 204: >> >>> 202: ClassLoader loader = context.newClassLoaderFor(parentLoader, firstClassName); >>> 203: firstClass = Class.forName(firstClassName, false, loader); >>> 204: Thread.currentThread().setContextClassLoader(loader); >> >> Hello Christian, a typical pattern for such Thread context classloader switches is to reset the context classloader back to the previous one, once the "work" is done. That way it doesn't influence the code after the completion of the work. >> >> So something like the following might be more safer: >> >> >> ClassLoader loader; >> try { >> loader = context.newClassLoaderFor(parentLoader, firstClassName); >> firstClass = Class.forName(firstClassName, false, loader); >> } catch (ClassNotFoundException e) { >> throw new Fault(Errors.CantFindClass(firstClassName)); >> } >> final ClassLoader prevTCCL = Thread.currentThread().getContextClassLoader(); >> Thread.currentThread().setContextClassLoader(loader); >> try { >> Method mainMethod = MethodFinder.findMainMethod(firstClass); >> ... // rest of the existing code >> return mainClass; >> } finally { >> Thread.currentThread().setContextClassLoader(prevTCCL); >> } > > @jaikiran The PR is the equivalent of System.initPhase3 where it sets the TCCL for the main thread. With the source code launcher, the defining loader of the source "main" is a child of the system (usually application) class loader. So it's not meant to be temporary setting. Thank you Alan for that detail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20097#discussion_r1678101644 From cstein at openjdk.org Tue Jul 16 08:11:51 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 16 Jul 2024 08:11:51 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 16:07:12 GMT, Alan Bateman wrote: >> Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. >> >> For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." > > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 204: > >> 202: ClassLoader loader = context.newClassLoaderFor(parentLoader, firstClassName); >> 203: firstClass = Class.forName(firstClassName, false, loader); >> 204: Thread.currentThread().setContextClassLoader(loader); > > Are you sure this it the right place? It might be, but seeing it in a try-catch is surprising. It should be set before the initializer for the main class runs, which might be here but checking. Would the constructor of `MemoryClassLoader` be a better place? Because `context.newClassLoaderFor()` has two exit-points where an instance of `MemoryClassLoader` is created. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20097#discussion_r1678950513 From cstein at openjdk.org Tue Jul 16 08:15:56 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 16 Jul 2024 08:15:56 GMT Subject: RFR: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:08:48 GMT, Christian Stein wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 204: >> >>> 202: ClassLoader loader = context.newClassLoaderFor(parentLoader, firstClassName); >>> 203: firstClass = Class.forName(firstClassName, false, loader); >>> 204: Thread.currentThread().setContextClassLoader(loader); >> >> Are you sure this it the right place? It might be, but seeing it in a try-catch is surprising. It should be set before the initializer for the main class runs, which might be here but checking. > > Would the constructor of `MemoryClassLoader` be a better place? > > Because `context.newClassLoaderFor()` has two exit-points where an instance of `MemoryClassLoader` is created. The try-catch cares for `ClassNotFoundException` instances thrown by `Class.forName()` - which doesn't initialize the main class. But swapping the lines to read: Thread.currentThread().setContextClassLoader(loader); firstClass = Class.forName(firstClassName, false, loader); should better ensure that the TCCL is set before the initializer for the main class runs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20097#discussion_r1678956482 From cstein at openjdk.org Tue Jul 16 08:46:21 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 16 Jul 2024 08:46:21 GMT Subject: RFR: 8335896: Source launcher should set TCCL [v2] In-Reply-To: References: Message-ID: > Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. > > For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Clean up implementation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20097/files - new: https://git.openjdk.org/jdk/pull/20097/files/d549a016..b514deb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20097&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20097&range=00-01 Stats: 6 lines in 2 files changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20097.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20097/head:pull/20097 PR: https://git.openjdk.org/jdk/pull/20097 From cstein at openjdk.org Tue Jul 16 08:46:21 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 16 Jul 2024 08:46:21 GMT Subject: RFR: 8335896: Source launcher should set TCCL [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:13:14 GMT, Christian Stein wrote: >> Would the constructor of `MemoryClassLoader` be a better place? >> >> Because `context.newClassLoaderFor()` has two exit-points where an instance of `MemoryClassLoader` is created. > > The try-catch cares for `ClassNotFoundException` instances thrown by `Class.forName()` - which doesn't initialize the main class. But swapping the lines to read: > > Thread.currentThread().setContextClassLoader(loader); > firstClass = Class.forName(firstClassName, false, loader); > > should better ensure that the TCCL is set before the initializer for the main class runs. I found a better way to move the `TCCL`-related above the try-catch block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20097#discussion_r1678999300 From alanb at openjdk.org Tue Jul 16 08:52:56 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Jul 2024 08:52:56 GMT Subject: RFR: 8335896: Source launcher should set TCCL [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:43:01 GMT, Christian Stein wrote: >> The try-catch cares for `ClassNotFoundException` instances thrown by `Class.forName()` - which doesn't initialize the main class. But swapping the lines to read: >> >> Thread.currentThread().setContextClassLoader(loader); >> firstClass = Class.forName(firstClassName, false, loader); >> >> should better ensure that the TCCL is set before the initializer for the main class runs. > > I found a better way to move the `TCCL`-related above the try-catch block. Good, I was puzzled why newClassLoaderFor was declared to throw CNFE. Related question is do you know why it uses Class.forName without running the class initializer? I guess I expected it would load loader.loadClass(firstClassName) and let the initializer run (it's going to run a bit later anyway). Main thing is that the initializer may do anything and the TCCL needs to be set before that executes (which is what you have now). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20097#discussion_r1679008980 From cstein at openjdk.org Tue Jul 16 09:24:51 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 16 Jul 2024 09:24:51 GMT Subject: RFR: 8335896: Source launcher should set TCCL [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:49:47 GMT, Alan Bateman wrote: >> I found a better way to move the `TCCL`-related above the try-catch block. > > Good, I was puzzled why newClassLoaderFor was declared to throw CNFE. Related question is do you know why it uses Class.forName without running the class initializer? I guess I expected it would load loader.loadClass(firstClassName) and let the initializer run (it's going to run a bit later anyway). Main thing is that the initializer may do anything and the TCCL needs to be set before that executes (which is what you have now). For reference, the single-file launcher `execute()` method had: `Class.forName(mainClassName, true, cl);` IIRC, we decided to call with `false` here in order to delay initialization for when the first class is not the class with the main method - accounting for the new protocal that also tries to match the file name with a later type name within the file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20097#discussion_r1679055521 From cstein at openjdk.org Tue Jul 16 11:50:17 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 16 Jul 2024 11:50:17 GMT Subject: RFR: 8336470: Source launcher should work with service loader SPI in unnamed module Message-ID: Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`. With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form. ------------- Commit messages: - 8336470: Source launcher should work with service loader SPI in unnamed module Changes: https://git.openjdk.org/jdk/pull/20193/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336470 Stats: 39 lines in 3 files changed: 23 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20193/head:pull/20193 PR: https://git.openjdk.org/jdk/pull/20193 From cstein at openjdk.org Tue Jul 16 12:37:13 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 16 Jul 2024 12:37:13 GMT Subject: RFR: 8336470: Source launcher should work with service loader SPI in unnamed module [v2] In-Reply-To: References: Message-ID: > Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`. > > With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Add test as described in https://bugs.openjdk.org/browse/JDK-8336470 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20193/files - new: https://git.openjdk.org/jdk/pull/20193/files/b30fa73b..d35150f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=00-01 Stats: 52 lines in 3 files changed: 51 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20193/head:pull/20193 PR: https://git.openjdk.org/jdk/pull/20193 From liach at openjdk.org Tue Jul 16 23:55:18 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 23:55:18 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API Message-ID: `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) Removal details: - `LocalVariable/LocalVariableType.writeTo` - `WritableElement` - In `BufWriter`: - `writeList(List)` - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` - `writeBytes(BufWriter other)` - `ClassReader.compare`: Avoid reading from `BufWriter` Future implementation cleanup out of scope of this patch: - Annotation writing can be upgraded and move away from `Util.Writable` - The writing of CP indices and attributes can move to their dedicated methods - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition ------------- Commit messages: - 2 test failures - Web review cleanup - Remove WritableElement and reduce Writable usage - Fix up usages of Util.write - Hide writeTo from all class file elements Changes: https://git.openjdk.org/jdk/pull/20205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335939 Stats: 456 lines in 48 files changed: 98 ins; 197 del; 161 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From liach at openjdk.org Wed Jul 17 00:09:51 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 00:09:51 GMT Subject: RFR: 8334714: Class-File API leaves preview In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 13:26:39 GMT, ExE Boss wrote: >> Class-File API is leaving preview. >> This is a removal of all `@PreviewFeature` annotations from Class-File API. >> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. >> >> Please review. >> >> Thanks, >> Adam > > Note?that `Utf8Entry::equalsString` has?inconsistent behaviour when?called with?a?`null`?value, which?I?ve?reported as?[JI?9077307], and?should probably be?fixed before this?API leaves?preview. > > [JI?9077307]: https://bugs.openjdk.org/browse/JI-9077307 "JI?9077307: Inconsistent?NPE?behaviour of?`Utf8Entry::equalsString`" @ExE-Boss Your report has been promoted to https://bugs.openjdk.org/browse/JDK-8336430 and will be addressed in a separate patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2232040064 From asotona at openjdk.org Wed Jul 17 08:35:52 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 17 Jul 2024 08:35:52 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 23:50:17 GMT, Chen Liang wrote: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 287: > 285: public static void writeAnnotation(BufWriterImpl buf, Annotation annotation) { > 286: // handles annotations and type annotations > 287: // TODO annotation cleanup later Do you have any specific annotation cleanup in mind? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20205#discussion_r1680657521 From asotona at openjdk.org Wed Jul 17 08:43:52 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 17 Jul 2024 08:43:52 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 23:50:17 GMT, Chen Liang wrote: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition Great job! ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20205#pullrequestreview-2182288974 From asotona at openjdk.org Wed Jul 17 08:59:07 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 17 Jul 2024 08:59:07 GMT Subject: RFR: 8334714: Class-File API leaves preview [v2] In-Reply-To: References: Message-ID: > Class-File API is leaving preview. > This is a removal of all `@PreviewFeature` annotations from Class-File API. > It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. > > Please review. > > Thanks, > 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 three commits: - Merge branch 'master' into JDK-8334714-final - bumped @since tag - 8334714: Class-File API leaves preview ------------- Changes: https://git.openjdk.org/jdk/pull/19826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=01 Stats: 715 lines in 166 files changed: 0 ins; 477 del; 238 mod Patch: https://git.openjdk.org/jdk/pull/19826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826 PR: https://git.openjdk.org/jdk/pull/19826 From arthur.mcgibbon at gmail.com Wed Jul 17 10:50:00 2024 From: arthur.mcgibbon at gmail.com (Arthur McGibbon) Date: Wed, 17 Jul 2024 11:50:00 +0100 Subject: Diagnostics enhancement request Message-ID: Currently compiler diagnostics are sent back with some positional information. See https://docs.oracle.com/en/java/javase/21/docs/api/java.compiler/javax/tools/Diagnostic.html The Diagnostic class contains range info... getStartPosition - file offset (no line or column number) getEndPosition - file offset (no line or column number) And it contains more specific position info... getLineNumber - line number in file. getColumnNumber - column number in file. getPosition - file offset. For LSP (Language Server Protocol) the requirements for a diagnostic location are startLine, startColumn, endLine, endColumn. Because of this, taking a javac diagnostic and transforming it into LSP diagnostic requires parsing the source file and transforming `getStartPosition`, `getEndPosition` and sometimes `getPosition` into line/column numbers. `getColumnNumber` can't be used (without source file parsing) because it returns a position based on the assumption that a tab is 8 spaces which isn't true in most code from what I've seen and tabs are treated as a single character in LSP. So ideally I'd like methods `getStartLine`, `getEndLine`, `getStartColNumber`, `getEndColNumber` added to the Diagnostic class. Where the `colNumber` methods treat a tab as a single character. Is this possible? I imagine the data is already available at the time the diagnostics are created. regards Arthur -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur.mcgibbon at gmail.com Wed Jul 17 11:15:00 2024 From: arthur.mcgibbon at gmail.com (Arthur McGibbon) Date: Wed, 17 Jul 2024 12:15:00 +0100 Subject: Semantic information output request Message-ID: IDEs use semantic information to navigate and highlight/colour code. By semantic info I mean something like... ``` String foo; // line 2 ... println(foo); // line 15 ``` On line 2 columns 3->9 there is a reference to `java.lang.String` On line 2 columns 10->13 there is a variable called `foo` of type `java.lang.String`. On line 15 columns 11->14 there is a reference to a local variable `foo` of type `java.lang.String` So in an IDE I could run `Go to definition` on line 15 column 11 and be taken to line 2 column 10. Or I run `Go to definition` on line 2 column 5 and be taken to some position in `java/lang/String.java`. Currently IDEs have to parse the source file to discover this semantic information. Or they can use a compiler plugin like https://github.com/sourcegraph/scip-java. In the compiler plugin's case, semanticdb files are output alongside class files. The semantic db files can then be read by the IDE instead of it having to parse the source. The advantage of the plugin is that the parsing is driven by the compiler so the semantic info should always be correct. Also - the IDE doesn't have to contain a java parser that must be up to date. I think the plugin idea originally came from work on a plugin for Scala. Since then, Scala has integrated the plugin code into its compiler so a user can just specify a compiler option to get Scalac to output the semanticdb files instead of having to download and configure a plugin. I'd like to see the same happen with Java and have javac output semantic files when supplied with the relevant javac option. I'd also like to see these files outputted into `-sources.jar` files with the original source. Or maybe in their own `-semantic.jar`. It would mean that IDEs no longer have to parse library files to be able to navigate them, instead they'd just load directly from the distributed semantic files. The benefits of this are reducing load on the many LSPs/IDEs out there, speeding up the generation of this information (it's already in the compiler) and ensuring correctness as the compiler should be the font of all compilery knowledge. regards Arthur -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Wed Jul 17 11:36:51 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 11:36:51 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 08:33:27 GMT, Adam Sotona wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 287: > >> 285: public static void writeAnnotation(BufWriterImpl buf, Annotation annotation) { >> 286: // handles annotations and type annotations >> 287: // TODO annotation cleanup later > > Do you have any specific annotation cleanup in mind? I am thinking of removing the Writable Hierarchy from annotations, and these static methods will handle writing with like a switch (on char, can't use pattern match in bootstrap) instead ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20205#discussion_r1680896744 From mcimadamore at openjdk.org Wed Jul 17 12:07:52 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 17 Jul 2024 12:07:52 GMT Subject: [jdk23] RFR: 8335817: javac AssertionError addLocalVar checkNull In-Reply-To: <-wflmrIYabuDdOv8Z8sVxYSZTUWqtadkgu2IuD_-csc=.47be1901-4282-4fbc-89fa-d845a26d8eca@github.com> References: <-wflmrIYabuDdOv8Z8sVxYSZTUWqtadkgu2IuD_-csc=.47be1901-4282-4fbc-89fa-d845a26d8eca@github.com> Message-ID: On Mon, 15 Jul 2024 15:02:45 GMT, Jan Lahoda wrote: > Hi all, > > This pull request contains a backport of commit [2b0adfc2](https://github.com/openjdk/jdk/commit/2b0adfc2decf47f6f49f072549c96f301f275285) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jan Lahoda on 15 Jul 2024 and was reviewed by Vicente Romero and Maurizio Cimadamore. > > Thanks! > > Original description: > Consider pattern matching with deconstruction patter, like: > > boolean b = o instanceof R(String s); > > > This will get desugared into code similar to `o instanceof R r && r.component() instanceof String s`, except that the call to `component()` is guarded with a try-catch, wrapping any exception with a `MatchException`. The internal javac implementation is to create a synthetic catch clause, and attach it to the relevant enclosing block. > > Now, consider an expression lambda with a deconstruction pattern matching, like `o -> o instanceof R(String s)`. There is no block in the lambda to which the catch could be attached. So, `TransPatterns` will expand the expression lambda to a block lambda, and inject the synthetic catches. But, `TransPatterns` will always do `return ;`, even if the type of `` is void. This then leads to a crash during Gen, as a variable of type `void` is created. > > The patch proposed here avoid creating `return ;` for void-type expression. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20183#pullrequestreview-2182729552 From cushon at openjdk.org Wed Jul 17 19:15:55 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 17 Jul 2024 19:15:55 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas Message-ID: Please consider this possible fix for [JDK-8336491](https://bugs.openjdk.org/browse/JDK-8336491), which avoids generating an unnecessary boxing conversion for the result of void-returning expression lambdas. ------------- Commit messages: - 8336491: Unnecessary boxing conversions in void-returning lambdas Changes: https://git.openjdk.org/jdk/pull/20222/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20222&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336491 Stats: 65 lines in 2 files changed: 64 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20222.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20222/head:pull/20222 PR: https://git.openjdk.org/jdk/pull/20222 From cushon at openjdk.org Wed Jul 17 23:44:50 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 17 Jul 2024 23:44:50 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas [v2] In-Reply-To: References: Message-ID: > Please consider this possible fix for [JDK-8336491](https://bugs.openjdk.org/browse/JDK-8336491), which avoids generating an unnecessary boxing conversion for the result of void-returning expression lambdas. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Push fix into boxIfNeeded, other callers pass a VOID type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20222/files - new: https://git.openjdk.org/jdk/pull/20222/files/7f4337e5..3f319f11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20222&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20222&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20222.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20222/head:pull/20222 PR: https://git.openjdk.org/jdk/pull/20222 From jlahoda at openjdk.org Thu Jul 18 04:55:37 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 18 Jul 2024 04:55:37 GMT Subject: [jdk23] Integrated: 8335817: javac AssertionError addLocalVar checkNull In-Reply-To: <-wflmrIYabuDdOv8Z8sVxYSZTUWqtadkgu2IuD_-csc=.47be1901-4282-4fbc-89fa-d845a26d8eca@github.com> References: <-wflmrIYabuDdOv8Z8sVxYSZTUWqtadkgu2IuD_-csc=.47be1901-4282-4fbc-89fa-d845a26d8eca@github.com> Message-ID: <0FwFf-SEJgpVEcUyDd_Shh1IeOSzsM-WQBjiLGtHPrk=.b8248a00-4371-4806-bad1-184d2f0aca7b@github.com> On Mon, 15 Jul 2024 15:02:45 GMT, Jan Lahoda wrote: > Hi all, > > This pull request contains a backport of commit [2b0adfc2](https://github.com/openjdk/jdk/commit/2b0adfc2decf47f6f49f072549c96f301f275285) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jan Lahoda on 15 Jul 2024 and was reviewed by Vicente Romero and Maurizio Cimadamore. > > Thanks! > > Original description: > Consider pattern matching with deconstruction patter, like: > > boolean b = o instanceof R(String s); > > > This will get desugared into code similar to `o instanceof R r && r.component() instanceof String s`, except that the call to `component()` is guarded with a try-catch, wrapping any exception with a `MatchException`. The internal javac implementation is to create a synthetic catch clause, and attach it to the relevant enclosing block. > > Now, consider an expression lambda with a deconstruction pattern matching, like `o -> o instanceof R(String s)`. There is no block in the lambda to which the catch could be attached. So, `TransPatterns` will expand the expression lambda to a block lambda, and inject the synthetic catches. But, `TransPatterns` will always do `return ;`, even if the type of `` is void. This then leads to a crash during Gen, as a variable of type `void` is created. > > The patch proposed here avoid creating `return ;` for void-type expression. This pull request has now been integrated. Changeset: e83e2b30 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/e83e2b305e46d10a82ad30d58adabf676572576b Stats: 157 lines in 2 files changed: 155 ins; 0 del; 2 mod 8335817: javac AssertionError addLocalVar checkNull Reviewed-by: mcimadamore Backport-of: 2b0adfc2decf47f6f49f072549c96f301f275285 ------------- PR: https://git.openjdk.org/jdk/pull/20183 From mcimadamore at openjdk.org Thu Jul 18 09:30:32 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 18 Jul 2024 09:30:32 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 23:44:50 GMT, Liam Miller-Cushon wrote: >> Please consider this possible fix for [JDK-8336491](https://bugs.openjdk.org/browse/JDK-8336491), which avoids generating an unnecessary boxing conversion for the result of void-returning expression lambdas. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Push fix into boxIfNeeded, other callers pass a VOID type Would we obtain the same result by setting a different expected return type in `Lower::visitLambda` ? E.g. right now we set the expected return type like this: currentRestype = types.erasure(tree.getDescriptorType(types)).getReturnType(); Perhaps, if that type is `void` we should just use `Type.noType` ? I'm a bit worried about the proposed fix having a potentially bigger impact than just the problem it's trying to address. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20222#issuecomment-2236047511 From mcimadamore at openjdk.org Thu Jul 18 09:37:33 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 18 Jul 2024 09:37:33 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 09:27:49 GMT, Maurizio Cimadamore wrote: > I'm a bit worried about the proposed fix having a potentially bigger impact than just the problem it's trying to address. What do you think? I see what I suggested was your original fix - what is the reason you went the other way? I suppose the reason is that `void` can't really be a target type for regular expressions - as `void` is only used in lambdas and methods, and, for methods, the shape of the `return` statement tells you whether you are void-returning or not. So I suppose you concluded that it would have been safe to generalize what `boxIfNeeded` is doing by skipping `void`, which can only really occur when lowering a lambda expression body. Correct? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20222#issuecomment-2236061100 From jlahoda at openjdk.org Thu Jul 18 14:14:32 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 18 Jul 2024 14:14:32 GMT Subject: RFR: 8332600: javac uses record components source position during compilation [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 20:24:23 GMT, Vicente Romero wrote: >> javac uses the source position of record components to find and later probably remove a given record component during compilation. This could be necessary if annotation processors are present. This is done in part to provide better error messages for silly record definitions like: >> >> record R(int i, float i) {} // two record components with the same name >> >> but this is brittle and can backfire if the record is read from a class file as the source positions are not stored there. See [JDK-8332297](https://bugs.openjdk.org/browse/JDK-8332297) for some context >> >> The idea of this fix is not to use the source position but only the name to find a given record component. This could imply that if the user defines an erroneous record like the one above, then the record could end up with less record components than expected but records like this wouldn't compile anyway >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > review comments Seems OK to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20148#pullrequestreview-2185954109 From vromero at openjdk.org Thu Jul 18 15:57:37 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 18 Jul 2024 15:57:37 GMT Subject: RFR: 8332600: javac uses record components source position during compilation [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 20:24:23 GMT, Vicente Romero wrote: >> javac uses the source position of record components to find and later probably remove a given record component during compilation. This could be necessary if annotation processors are present. This is done in part to provide better error messages for silly record definitions like: >> >> record R(int i, float i) {} // two record components with the same name >> >> but this is brittle and can backfire if the record is read from a class file as the source positions are not stored there. See [JDK-8332297](https://bugs.openjdk.org/browse/JDK-8332297) for some context >> >> The idea of this fix is not to use the source position but only the name to find a given record component. This could imply that if the user defines an erroneous record like the one above, then the record could end up with less record components than expected but records like this wouldn't compile anyway >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > review comments thanks for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/20148#issuecomment-2236914738 From vromero at openjdk.org Thu Jul 18 15:57:38 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 18 Jul 2024 15:57:38 GMT Subject: Integrated: 8332600: javac uses record components source position during compilation In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 21:36:40 GMT, Vicente Romero wrote: > javac uses the source position of record components to find and later probably remove a given record component during compilation. This could be necessary if annotation processors are present. This is done in part to provide better error messages for silly record definitions like: > > record R(int i, float i) {} // two record components with the same name > > but this is brittle and can backfire if the record is read from a class file as the source positions are not stored there. See [JDK-8332297](https://bugs.openjdk.org/browse/JDK-8332297) for some context > > The idea of this fix is not to use the source position but only the name to find a given record component. This could imply that if the user defines an erroneous record like the one above, then the record could end up with less record components than expected but records like this wouldn't compile anyway > > TIA This pull request has now been integrated. Changeset: 245c0866 Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/245c08664896d63ac050ebc23259b23908dafed5 Stats: 47 lines in 3 files changed: 23 ins; 16 del; 8 mod 8332600: javac uses record components source position during compilation Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/20148 From cushon at openjdk.org Thu Jul 18 17:30:31 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 18 Jul 2024 17:30:31 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 09:34:48 GMT, Maurizio Cimadamore wrote: > So I suppose you concluded that it would have been safe to generalize what `boxIfNeeded` is doing by skipping `void`, which can only really occur when lowering a lambda expression body. Correct? Yes, that's where I ended up. The initial approach was to handle this in `visitLambda` for expression lambdas, and I added an assertion to `boxIfNeeded` to verify that it wasn't called with `VOID`, but then the tests pointed out a case where I think an expression lambda is first desugared to a block lambdas to handle boxing `void` to `Void`. Your alternative of setting `currentRestype` to `Type.noType` should handle that case as well, I'm happy to make that switch if you'd prefer it over handling `VOID` in `boxIfNeeded`. --- Distilled from `test/langtools/tools/javac/patterns/MatchExceptionLambdaExpression.java`: class MatchExceptionLambdaExpression { public static void main(String[] args) { doRunPrimitiveVoid(o -> checkVoidBox(o instanceof A(String s))); } static void doRunPrimitiveVoid(PrimitiveVoidFI toRun) {} static Void checkVoidBox(boolean a) { return null; } interface PrimitiveVoidFI { public void run(Object o); } record A(String s) {} } ... 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.comp.Lower.boxIfNeeded(Lower.java:3333) at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2150) at jdk.compiler/com.sun.tools.javac.comp.Lower.visitReturn(Lower.java:3842) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1769) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2139) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:172) at jdk.compiler/com.sun.tools.javac.comp.Lower.visitBlock(Lower.java:3812) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1133) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2139) at jdk.compiler/com.sun.tools.javac.comp.Lower.visitLambda(Lower.java:3854) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:2035) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20222#issuecomment-2237129242 From vromero at openjdk.org Thu Jul 18 18:43:34 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 18 Jul 2024 18:43:34 GMT Subject: RFR: 8334714: Class-File API leaves preview [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 08:59:07 GMT, Adam Sotona wrote: >> Class-File API is leaving preview. >> This is a removal of all `@PreviewFeature` annotations from Class-File API. >> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. >> >> Please review. >> >> Thanks, >> 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 three commits: > > - Merge branch 'master' into JDK-8334714-final > - bumped @since tag > - 8334714: Class-File API leaves preview lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19826#pullrequestreview-2186608609 From abimpoudis at openjdk.org Thu Jul 18 20:31:04 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 18 Jul 2024 20:31:04 GMT Subject: RFR: 8336781: Erroneous exhaustivity check with boolean switch Message-ID: <_gF4OY0i4mRpDkRjiR1irSPeEKD1Gq5EGPlSZH_jDUc=.7ea9ff80-ca8a-4b16-b412-fc96d4d4e8c5@github.com> In the case of a `Boolean` switch with 3 values true, false and `null` there was a miscalculation on what consists an exhaustive switch. This PR addresses this bug by removing the values true and false (instead of adding and comparing with 2 expected values). ------------- Commit messages: - 8336781: Erroneous exhaustivity check with boolean switch Changes: https://git.openjdk.org/jdk/pull/20243/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20243&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336781 Stats: 42 lines in 2 files changed: 39 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20243.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20243/head:pull/20243 PR: https://git.openjdk.org/jdk/pull/20243 From liach at openjdk.org Thu Jul 18 22:56:10 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 22:56:10 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v2] In-Reply-To: References: Message-ID: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge BoundAttributeTest - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - 2 test failures - Web review cleanup - Remove WritableElement and reduce Writable usage The rest of Writable in annotations can be removed in later cleanup - Fix up usages of Util.write - Hide writeTo from all class file elements To consider the fate of WritableElement later! ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20205/files - new: https://git.openjdk.org/jdk/pull/20205/files/78830195..bbd6c73c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=00-01 Stats: 2383 lines in 117 files changed: 1586 ins; 335 del; 462 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From liach at openjdk.org Fri Jul 19 02:01:52 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 02:01:52 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation Message-ID: `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. Depends on #20205. ------------- Depends on: https://git.openjdk.org/jdk/pull/20205 Commit messages: - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation Changes: https://git.openjdk.org/jdk/pull/20247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336754 Stats: 218 lines in 18 files changed: 60 ins; 116 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From dholmes at openjdk.org Fri Jul 19 05:53:01 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Jul 2024 05:53:01 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC Message-ID: Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. This also picks up the unpublished changes to java.1 from: - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC And a typo crept in to java.1 from: - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal This also picks up the unpublished change to keytool.1 from: - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints This also picks up the unpublished change to javadoc.1 from: - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). Thanks. ------------- Commit messages: - 8325280: Update troff manpages in JDK 23 before RC Changes: https://git.openjdk.org/jdk/pull/20248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325280 Stats: 142 lines in 28 files changed: 51 ins; 52 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/20248.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20248/head:pull/20248 PR: https://git.openjdk.org/jdk/pull/20248 From dholmes at openjdk.org Fri Jul 19 05:53:02 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Jul 2024 05:53:02 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. Note this is simply a re-generation of the troff files from their sources. If there are any problems that need fixing then a new JBS issue has to be filed to update the source file and regenerate the troff file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2238248354 From cstein at openjdk.org Fri Jul 19 06:27:06 2024 From: cstein at openjdk.org (Christian Stein) Date: Fri, 19 Jul 2024 06:27:06 GMT Subject: RFR: 8336470: Source launcher should work with service loader SPI in unnamed module [v3] In-Reply-To: References: Message-ID: > Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`. > > With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update Tool.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20193/files - new: https://git.openjdk.org/jdk/pull/20193/files/d35150f2..c5f43784 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20193/head:pull/20193 PR: https://git.openjdk.org/jdk/pull/20193 From cstein at openjdk.org Fri Jul 19 06:36:03 2024 From: cstein at openjdk.org (Christian Stein) Date: Fri, 19 Jul 2024 06:36:03 GMT Subject: RFR: 8336470: Source launcher should work with service loader SPI in unnamed module [v4] In-Reply-To: References: Message-ID: > Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`. > > With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Fixup line endings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20193/files - new: https://git.openjdk.org/jdk/pull/20193/files/c5f43784..58bdfb92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=02-03 Stats: 44 lines in 2 files changed: 0 ins; 0 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/20193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20193/head:pull/20193 PR: https://git.openjdk.org/jdk/pull/20193 From asotona at openjdk.org Fri Jul 19 07:12:35 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 07:12:35 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 22:56:10 GMT, Chen Liang wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge BoundAttributeTest > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - 2 test failures > - Web review cleanup > - Remove WritableElement and reduce Writable usage > > The rest of Writable in annotations can be removed in later cleanup > - Fix up usages of Util.write > - Hide writeTo from all class file elements > > To consider the fate of WritableElement later! Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20205#pullrequestreview-2187499298 From alanb at openjdk.org Fri Jul 19 08:29:36 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 19 Jul 2024 08:29:36 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. Marked as reviewed by alanb (Reviewer). Thanks for the tireless effort to update the man pages at the end of each release. ------------- PR Review: https://git.openjdk.org/jdk/pull/20248#pullrequestreview-2187669729 PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2238647463 From asotona at openjdk.org Fri Jul 19 13:33:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 13:33:33 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:55:57 GMT, Chen Liang wrote: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 302: > 300: } > 301: > 302: public static void writeTypeAnnotation(BufWriterImpl buf, TypeAnnotation ta) { Is there any reason to move writeTypeAnnotation from UnboundAttribute? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20247#discussion_r1684390757 From liach at openjdk.org Fri Jul 19 13:48:33 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 13:48:33 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation In-Reply-To: References: Message-ID: <_NIaBMC4ojyen8rfaQC1XrPs4SHefLQRjnq9Ujb75gs=.ffe05c46-d2ba-435a-bb51-fca12b407a8e@github.com> On Fri, 19 Jul 2024 13:30:44 GMT, Adam Sotona wrote: >> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. >> >> Depends on #20205. > > src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 302: > >> 300: } >> 301: >> 302: public static void writeTypeAnnotation(BufWriterImpl buf, TypeAnnotation ta) { > > Is there any reason to move writeTypeAnnotation from UnboundAttribute? This is for consistency with reading annotations: they are now defined in the same file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20247#discussion_r1684409764 From asotona at openjdk.org Fri Jul 19 13:54:02 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 13:54:02 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:55:57 GMT, Chen Liang wrote: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Looks good to me. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2188296784 From vromero at openjdk.org Fri Jul 19 14:43:30 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 19 Jul 2024 14:43:30 GMT Subject: RFR: 8336781: Erroneous exhaustivity check with boolean switch In-Reply-To: <_gF4OY0i4mRpDkRjiR1irSPeEKD1Gq5EGPlSZH_jDUc=.7ea9ff80-ca8a-4b16-b412-fc96d4d4e8c5@github.com> References: <_gF4OY0i4mRpDkRjiR1irSPeEKD1Gq5EGPlSZH_jDUc=.7ea9ff80-ca8a-4b16-b412-fc96d4d4e8c5@github.com> Message-ID: On Thu, 18 Jul 2024 20:25:57 GMT, Aggelos Biboudis wrote: > In the case of a `Boolean` switch with 3 values true, false and `null` there was a miscalculation on what consists an exhaustive switch. This PR addresses this bug by removing the values true and false (instead of adding and comparing with 2 expected values). lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20243#pullrequestreview-2188409334 From jpai at openjdk.org Fri Jul 19 15:14:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 15:14:31 GMT Subject: RFR: 8336470: Source launcher should work with service loader SPI in unnamed module [v4] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 06:36:03 GMT, Christian Stein wrote: >> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`. >> >> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Fixup line endings src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Hello Christian, this should be `2023, 2024, ` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r1684526930 From jpai at openjdk.org Fri Jul 19 15:22:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 15:22:31 GMT Subject: RFR: 8336470: Source launcher should work with service loader SPI in unnamed module [v4] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 06:36:03 GMT, Christian Stein wrote: >> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`. >> >> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Fixup line endings test/langtools/tools/javac/launcher/src/Tool.java line 8: > 6: * under the terms of the GNU General Public License version 2 only, as > 7: * published by the Free Software Foundation. Oracle designates this > 8: * particular file as subject to the "Classpath" exception as provided A test file isn't expected to use this "Classpath" exception copyright text. The copyright text from some other existing test file can be borrowed here to fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r1684536583 From jpai at openjdk.org Fri Jul 19 15:35:36 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 15:35:36 GMT Subject: RFR: 8336470: Source launcher should work with service loader SPI in unnamed module [v4] In-Reply-To: References: Message-ID: <0TdywDEAW84v-TirCfiDm05qmhPzJmGBmLSjpoIMWso=.6ddfefb1-b0be-4153-8096-9ed7ea28fd27@github.com> On Fri, 19 Jul 2024 06:36:03 GMT, Christian Stein wrote: >> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`. >> >> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Fixup line endings src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 277: > 275: * @return the URL of the resource, or null > 276: */ > 277: private URL toResourceInRootPath(String name) { Is this method expected to return `URL` to a `.class` file too? The reason I ask this is, I notice that for classes that belong within the source java file we use a different protocol scheme for the URIs. Is that `sourcelauncher-` protocol meant only for classes that are part of the source file that is launched? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r1684549504 From cushon at openjdk.org Fri Jul 19 16:18:46 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 16:18:46 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references Message-ID: Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. ------------- Commit messages: - 8336786: VerifyError with lambda capture and enclosing instance references Changes: https://git.openjdk.org/jdk/pull/20259/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20259&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336786 Stats: 55 lines in 3 files changed: 52 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20259.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20259/head:pull/20259 PR: https://git.openjdk.org/jdk/pull/20259 From mcimadamore at openjdk.org Fri Jul 19 16:50:36 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 19 Jul 2024 16:50:36 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 16:13:46 GMT, Liam Miller-Cushon wrote: > Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. Marked as reviewed by mcimadamore (Reviewer). The fix looks reasonable. I came up with something slightly different: https://github.com/openjdk/jdk/compare/master...mcimadamore:jdk:lambda_encl_capture?expand=1 (perhaps some of the changes in LambdaToMethod from that fix would still be appreciated, such as the extra assert, and the removal of the subclass test, as I don't think that ever does anything). Where I'm more unsure is in noting that Lower has two modes of capturing an enclosing `this`: a "precise" one, which calls `isMemberOf` and a more fuzzy one, which calls `isSubclass` on the owner. Inner class creation is the only case where we seem to use the fuzzy match. But the lambda code _always_ uses membership. Effectively, the old `LambdaToMethod` code in `visitNewClass`, attempted to scan all the enclosing scopes, looking a proper owner of the to-be captured `this`. Failing that, we would just go ahead and add the captured enclosing `this` anyway. I'm sure these little discrepancies are all accidents waiting to happen, in the sense that probably there are examples where Lower and LambdaToMethod would pick different enclosing `this`. This is kind of an unavoidable consequence of having the capture logic being defined in two unrelated places. So, not sure we've seen the end of this, but your fix seems a good step forward. ------------- PR Review: https://git.openjdk.org/jdk/pull/20259#pullrequestreview-2188680615 PR Comment: https://git.openjdk.org/jdk/pull/20259#issuecomment-2239623408 From cushon at openjdk.org Fri Jul 19 17:02:08 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 17:02:08 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references [v2] In-Reply-To: References: Message-ID: > Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Add assertion in capturedDecl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20259/files - new: https://git.openjdk.org/jdk/pull/20259/files/5dba4fcd..430301ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20259&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20259&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20259.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20259/head:pull/20259 PR: https://git.openjdk.org/jdk/pull/20259 From vromero at openjdk.org Fri Jul 19 17:07:43 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 19 Jul 2024 17:07:43 GMT Subject: RFR: 8332850: javac crashes if container for repeatable annotation is not found Message-ID: javac is crashing if it can't find the container for repeatable annotations in the classpath, this is due to a `CompletionFailure` exception that is not being caught. The current fix is catching the exception and producing an error message which is what we do for similar cases, TIA ------------- Commit messages: - 8332850: javac crashes if container for repeatable annotation is not found Changes: https://git.openjdk.org/jdk/pull/20260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20260&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332850 Stats: 102 lines in 2 files changed: 101 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20260/head:pull/20260 PR: https://git.openjdk.org/jdk/pull/20260 From cushon at openjdk.org Fri Jul 19 17:08:51 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 17:08:51 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references [v3] In-Reply-To: References: Message-ID: <8tbqWMPt3Kor9sb7GMURYyqrSjgBnIl-6liFb6eTtVw=.7b5b96eb-2c95-4ece-8604-1bf8a20bf1d8@github.com> > Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Remove unused subclass test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20259/files - new: https://git.openjdk.org/jdk/pull/20259/files/430301ed..63006204 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20259&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20259&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20259.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20259/head:pull/20259 PR: https://git.openjdk.org/jdk/pull/20259 From mcimadamore at openjdk.org Fri Jul 19 17:14:31 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 19 Jul 2024 17:14:31 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references In-Reply-To: References: Message-ID: <4_XcMqRklkAqcGLMNz17J1WVbTo_VYSe-qKZTjJd32s=.96107045-0cc4-4058-ac54-403261270b00@github.com> On Fri, 19 Jul 2024 16:46:53 GMT, Maurizio Cimadamore wrote: > I came up with something slightly different: > https://github.com/openjdk/jdk/compare/master...mcimadamore:jdk:lambda_encl_capture?expand=1 Looking closer, IMHO dropping the `isMemberOf` from `LambdaToMethod` and replacing it with a simpler subclassing test on the captured symbol owner seems like it should work: after all, `Lower` has already decided whether to resolve via an enclosing `this` or not. If it did, it already has replaced the access to use some `this$0`. At which point, what check `LambdaToMethod` shouldn't matter much, as the synthetic `this$0` will always be accessed and preferred over just `this`. If it didn't, well, then just `this` is fine. As your patch fixes the type of `this` to be the current class (which is correct). But then, no matter whether `Lower` used `isMemberOf` or `isSubclass`, the innermost enclosing type should always act as a capturing frame for `LambdaToMethod` (since we really want the current `this`). So again, using a simpler subclassing check would be fine. In other words, I'm wondering whether the `isMemberOf` check in `LambdaToMethod` is also a relic of a time where `LambdaToMethod` used to run _before_ `Lower`, so it needed to make a choice of how to resolve the enclosing this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20259#issuecomment-2239699673 From iris at openjdk.org Fri Jul 19 17:21:32 2024 From: iris at openjdk.org (Iris Clark) Date: Fri, 19 Jul 2024 17:21:32 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20248#pullrequestreview-2188754909 From mcimadamore at openjdk.org Fri Jul 19 17:32:51 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 19 Jul 2024 17:32:51 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references [v3] In-Reply-To: <8tbqWMPt3Kor9sb7GMURYyqrSjgBnIl-6liFb6eTtVw=.7b5b96eb-2c95-4ece-8604-1bf8a20bf1d8@github.com> References: <8tbqWMPt3Kor9sb7GMURYyqrSjgBnIl-6liFb6eTtVw=.7b5b96eb-2c95-4ece-8604-1bf8a20bf1d8@github.com> Message-ID: On Fri, 19 Jul 2024 17:08:51 GMT, Liam Miller-Cushon wrote: >> Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused subclass test Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20259#pullrequestreview-2188763800 From cushon at openjdk.org Fri Jul 19 17:32:51 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 17:32:51 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references [v4] In-Reply-To: References: Message-ID: > Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Switch to a subclass test in capturedDecl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20259/files - new: https://git.openjdk.org/jdk/pull/20259/files/63006204..2561a7bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20259&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20259&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20259.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20259/head:pull/20259 PR: https://git.openjdk.org/jdk/pull/20259 From cushon at openjdk.org Fri Jul 19 17:32:51 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 17:32:51 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references [v3] In-Reply-To: <8tbqWMPt3Kor9sb7GMURYyqrSjgBnIl-6liFb6eTtVw=.7b5b96eb-2c95-4ece-8604-1bf8a20bf1d8@github.com> References: <8tbqWMPt3Kor9sb7GMURYyqrSjgBnIl-6liFb6eTtVw=.7b5b96eb-2c95-4ece-8604-1bf8a20bf1d8@github.com> Message-ID: On Fri, 19 Jul 2024 17:08:51 GMT, Liam Miller-Cushon wrote: >> Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused subclass test Thanks, switching to `clazz.isSubClass(sym.enclClass(), types)` in LambdaToMethod sounds good, it makes sense that the previous subclass check was a no-op and the more precise membership test shouldn't be necessary after Lower. To double-check, it sounds like you're leaning towards also keeping the change to `makeOwnerThis`, even though it isn't required with the change to the subclass check in LambdaToMethod? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20259#issuecomment-2239725362 From alex.buckley at oracle.com Fri Jul 19 17:59:00 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 19 Jul 2024 10:59:00 -0700 Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation In-Reply-To: References: Message-ID: <6db075b7-29c5-4f03-88ea-ef122f6e9ae5@oracle.com> Logically, an annotation is either a declaration annotation or a type annotation. A declaration annotation _is_ an annotation. A type annotation _is_ an annotation. These terms come from JLS 9.7.4. In the Class File API, `Annotation` is specified as "Models an annotation on a declaration." That's fair: you're using the "good" name `Annotation` for declaration annotations because they are more common than type annotations. (It's not what the Core Reflection API does -- `java.lang.reflect.Annotation` denotes annotations at a very high level of abstraction, independent of appearance in declaration contexts or type contexts -- but that's a different API, so OK.) However, I think it's wrong in Class File for `TypeAnnotation` to have/contain an `Annotation`. Logically, a type annotation does not have/contain a declaration annotation. I don't know much the Class File API supports writing a `TypeAnnotation` into a class file (especially since WritableElement is on the way out), but the problem would be reifying a type annotation on (say) the type used in an `extends` clause, but with the annotation itself only being permitted on (say) a field declaration. Alex On 7/18/2024 7:01 PM, Chen Liang wrote: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. > > ------------- > > Depends on: https://git.openjdk.org/jdk/pull/20205 > > Commit messages: > - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation > > Changes: https://git.openjdk.org/jdk/pull/20247/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8336754 > Stats: 218 lines in 18 files changed: 60 ins; 116 del; 42 mod > Patch: https://git.openjdk.org/jdk/pull/20247.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 > > PR: https://git.openjdk.org/jdk/pull/20247 From mcimadamore at openjdk.org Fri Jul 19 18:08:32 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 19 Jul 2024 18:08:32 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references [v4] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 17:32:51 GMT, Liam Miller-Cushon wrote: >> Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Switch to a subclass test in capturedDecl Another possible avenue of things that can change as a result of this PR. In principle, changing the type of `this` from A to B would cause a difference in the bytecode binary qualifier. E.g. if you have `this.m()` you could see a reference to `B::m` where it used to be `A::m`. But, after inspecting the code paths, it seems that `makeOwnerThis` can only return a plain `this` when you need an enclosing this for: * an inner class creation expression * a static accessor generated by Lower (to access some private/protected instance member) So, in both cases, this PR is only changing the type of a "naked" `this` - therefore no adverse effect on binary qualifiers should occur. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20259#issuecomment-2239825272 From mcimadamore at openjdk.org Fri Jul 19 18:08:32 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 19 Jul 2024 18:08:32 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references [v3] In-Reply-To: References: <8tbqWMPt3Kor9sb7GMURYyqrSjgBnIl-6liFb6eTtVw=.7b5b96eb-2c95-4ece-8604-1bf8a20bf1d8@github.com> Message-ID: On Fri, 19 Jul 2024 17:28:14 GMT, Liam Miller-Cushon wrote: > To double-check, it sounds like you're leaning towards also keeping the change to `makeOwnerThis`, even though it isn't required with the change to the subclass check in LambdaToMethod? Yes. It seems the right thing to do. We want the code to really return the "current" `this`, not just some `this` that might be related with the "current" one. This PR changes `Lower` so that the `this` it produces are the same as those generated by `Attr` itself. And that is a good thing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20259#issuecomment-2239829723 From mcimadamore at openjdk.org Fri Jul 19 21:45:37 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 19 Jul 2024 21:45:37 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references [v4] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 17:32:51 GMT, Liam Miller-Cushon wrote: >> Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Switch to a subclass test in capturedDecl Looks good - thanks for fixing! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20259#pullrequestreview-2189378102 From mcimadamore at openjdk.org Fri Jul 19 21:50:48 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 19 Jul 2024 21:50:48 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 17:28:10 GMT, Liam Miller-Cushon wrote: > Your alternative of setting `currentRestype` to `Type.noType` should handle that case as well, I'm happy to make that switch if you'd prefer it over handling `VOID` in `boxIfNeeded`. I have a very very slight preference for adding an assert in boxIfNeeded to check against VOID (since the method doesn't really seem to be thought for that), and dealing with void in `visitLambda`, by setting `Type.noType`. But, as said, the preference is only slight, given that, in either case some special casing would be required. I suppose the reason for my preference is that I like to put the special casing close to where it belong (so that we can comment it clearly too). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20222#issuecomment-2240257146 From cushon at openjdk.org Fri Jul 19 21:55:37 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 21:55:37 GMT Subject: RFR: 8336786: VerifyError with lambda capture and enclosing instance references [v4] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 17:32:51 GMT, Liam Miller-Cushon wrote: >> Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Switch to a subclass test in capturedDecl Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20259#issuecomment-2240267678 From cushon at openjdk.org Fri Jul 19 21:55:38 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 21:55:38 GMT Subject: Integrated: 8336786: VerifyError with lambda capture and enclosing instance references In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 16:13:46 GMT, Liam Miller-Cushon wrote: > Hi, please consider this fix for [JDK-8336786](https://bugs.openjdk.org/browse/JDK-8336786). After [JDK-8334037](https://bugs.openjdk.org/browse/JDK-8334037) the handling of capturing `this` in lambdas does not handle synthetic `this` variables declared in supertypes in different packages. This change adjusts the lowering of `this` references to be owned by the enclosing class, instead of the superclass, so they are handle correctly be the capture logic in `capturedDecl` in `LambdaToMethod`. This pull request has now been integrated. Changeset: 939fe000 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/939fe000a96bc7c92c7b8814eb6ee66856718e4e Stats: 57 lines in 4 files changed: 53 ins; 1 del; 3 mod 8336786: VerifyError with lambda capture and enclosing instance references Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/20259 From cushon at openjdk.org Fri Jul 19 22:18:05 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 22:18:05 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas [v3] In-Reply-To: References: Message-ID: > Please consider this possible fix for [JDK-8336491](https://bugs.openjdk.org/browse/JDK-8336491), which avoids generating an unnecessary boxing conversion for the result of void-returning expression lambdas. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Represent void lambda results as Type.noType ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20222/files - new: https://git.openjdk.org/jdk/pull/20222/files/3f319f11..2113c06e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20222&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20222&range=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20222.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20222/head:pull/20222 PR: https://git.openjdk.org/jdk/pull/20222 From cushon at openjdk.org Fri Jul 19 22:18:05 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 22:18:05 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 21:47:45 GMT, Maurizio Cimadamore wrote: > I have a very very slight preference for adding an assert in boxIfNeeded to check against VOID (since the method doesn't really seem to be thought for that), and dealing with void in `visitLambda`, by setting `Type.noType`. But, as said, the preference is only slight, given that, in either case some special casing would be required. I suppose the reason for my preference is that I like to put the special casing close to where it belong (so that we can comment it clearly too). Sounds good, I'm happy to make that change. I went ahead and did that, although it turns out that the current logic in `boxIfNeeded` emits a boxing conversion if the target is `Type.noType`, so it still requires a new case there to avoid that. Let me know if I missed anything, or if that changes your preference at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20222#issuecomment-2240354392 From cstein at openjdk.org Sat Jul 20 19:16:32 2024 From: cstein at openjdk.org (Christian Stein) Date: Sat, 20 Jul 2024 19:16:32 GMT Subject: RFR: 8336470: Source launcher should work with service loader SPI in unnamed module [v4] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 15:12:20 GMT, Jaikiran Pai wrote: >> Christian Stein has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixup line endings > > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 2: > >> 1: /* >> 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. > > Hello Christian, this should be `2023, 2024, ` Good catch, will fix it. > test/langtools/tools/javac/launcher/src/Tool.java line 8: > >> 6: * under the terms of the GNU General Public License version 2 only, as >> 7: * published by the Free Software Foundation. Oracle designates this >> 8: * particular file as subject to the "Classpath" exception as provided > > A test file isn't expected to use this "Classpath" exception copyright text. The copyright text from some other existing test file can be borrowed here to fix it. Will fix this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r1685521001 PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r1685521048 From cstein at openjdk.org Sat Jul 20 19:26:31 2024 From: cstein at openjdk.org (Christian Stein) Date: Sat, 20 Jul 2024 19:26:31 GMT Subject: RFR: 8336470: Source launcher should work with service loader SPI in unnamed module [v4] In-Reply-To: <0TdywDEAW84v-TirCfiDm05qmhPzJmGBmLSjpoIMWso=.6ddfefb1-b0be-4153-8096-9ed7ea28fd27@github.com> References: <0TdywDEAW84v-TirCfiDm05qmhPzJmGBmLSjpoIMWso=.6ddfefb1-b0be-4153-8096-9ed7ea28fd27@github.com> Message-ID: On Fri, 19 Jul 2024 15:31:14 GMT, Jaikiran Pai wrote: >> Christian Stein has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixup line endings > > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 277: > >> 275: * @return the URL of the resource, or null >> 276: */ >> 277: private URL toResourceInRootPath(String name) { > > Is this method expected to return `URL` to a `.class` file too? The reason I ask this is, I notice that for classes that belong within the source java file we use a different protocol scheme for the URIs. Is that `sourcelauncher-` protocol meant only for classes that are part of the source file that is launched? Every file that is resolvable under the computed source root path is expected to be returned by this method. This includes `.class` files. But you maybe right that such files should be excluded; or at least be handled the application class loader. Have to write a few more tests to give a better answer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r1685522415 From liach at openjdk.org Sat Jul 20 23:12:59 2024 From: liach at openjdk.org (Chen Liang) Date: Sat, 20 Jul 2024 23:12:59 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v3] In-Reply-To: References: Message-ID: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge BoundAttributeTest - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - 2 test failures - Web review cleanup - Remove WritableElement and reduce Writable usage The rest of Writable in annotations can be removed in later cleanup - Fix up usages of Util.write - Hide writeTo from all class file elements To consider the fate of WritableElement later! ------------- Changes: https://git.openjdk.org/jdk/pull/20205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=02 Stats: 458 lines in 49 files changed: 99 ins; 198 del; 161 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From alanb at openjdk.org Sun Jul 21 05:58:43 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 21 Jul 2024 05:58:43 GMT Subject: RFR: 8335896: Source launcher should set TCCL [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:46:21 GMT, Christian Stein wrote: >> Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. >> >> For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Clean up implementation Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20097#pullrequestreview-2190245034 From cstein at openjdk.org Sun Jul 21 08:51:40 2024 From: cstein at openjdk.org (Christian Stein) Date: Sun, 21 Jul 2024 08:51:40 GMT Subject: Integrated: 8335896: Source launcher should set TCCL In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 10:52:46 GMT, Christian Stein wrote: > Please review this change to set the context class loader of the current thread to the in-memory class loader when the `java` launcher is invoked in source mode. Having the source launcher set the TCCL to the in-memory classloader is benefical for scenarious depending on the TCCL being set to the application-loading loader. > > For example, the single-argument taking [`ServiceLoader.load(Class)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)) method creates "a new service loader for the given service type, using the current thread's [context class loader](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#getContextClassLoader())." This pull request has now been integrated. Changeset: ad498f57 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/ad498f57fcead174306c6e6e3b2d1f9916821b84 Stats: 27 lines in 3 files changed: 23 ins; 2 del; 2 mod 8335896: Source launcher should set TCCL Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/20097 From dholmes at openjdk.org Sun Jul 21 23:09:34 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 21 Jul 2024 23:09:34 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 08:26:51 GMT, Alan Bateman wrote: >> Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. >> >> This also picks up the unpublished changes to java.1 from: >> >> - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags >> - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC >> >> And a typo crept in to java.1 from: >> - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal >> >> This also picks up the unpublished change to keytool.1 from: >> >> - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints >> >> This also picks up the unpublished change to javadoc.1 from: >> >> - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class >> >> and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: >> >> - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments >> - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments >> >> The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). >> >> Thanks. > > Thanks for the tireless effort to update the man pages at the end of each release. Thanks for the reviews @AlanBateman and @irisclark ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2241805932 From dholmes at openjdk.org Sun Jul 21 23:09:35 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 21 Jul 2024 23:09:35 GMT Subject: [jdk23] Integrated: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. This pull request has now been integrated. Changeset: 5473e9e4 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/5473e9e488c8fc7d99ea9d97fd0e7dd212636546 Stats: 142 lines in 28 files changed: 51 ins; 52 del; 39 mod 8325280: Update troff manpages in JDK 23 before RC Reviewed-by: alanb, iris ------------- PR: https://git.openjdk.org/jdk/pull/20248 From mcimadamore at openjdk.org Mon Jul 22 09:28:34 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 22 Jul 2024 09:28:34 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 22:18:05 GMT, Liam Miller-Cushon wrote: >> Please consider this possible fix for [JDK-8336491](https://bugs.openjdk.org/browse/JDK-8336491), which avoids generating an unnecessary boxing conversion for the result of void-returning expression lambdas. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Represent void lambda results as Type.noType The extra check is unfortunate, but I think the code looks good. Conceptually, I still think that returning the tree unmodified when the target is `noType` makes more sense in the general case. Another (optional) possibility would be to handle this in `visitReturn` - e.g. if the target is `void`, then call `translate(expr)` instead of `translate(expr, type)`. I'll leave that decision to what you think it's cleanest. ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20222#pullrequestreview-2191085502 From abimpoudis at openjdk.org Mon Jul 22 10:32:38 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 22 Jul 2024 10:32:38 GMT Subject: Integrated: 8336781: Erroneous exhaustivity check with boolean switch In-Reply-To: <_gF4OY0i4mRpDkRjiR1irSPeEKD1Gq5EGPlSZH_jDUc=.7ea9ff80-ca8a-4b16-b412-fc96d4d4e8c5@github.com> References: <_gF4OY0i4mRpDkRjiR1irSPeEKD1Gq5EGPlSZH_jDUc=.7ea9ff80-ca8a-4b16-b412-fc96d4d4e8c5@github.com> Message-ID: On Thu, 18 Jul 2024 20:25:57 GMT, Aggelos Biboudis wrote: > In the case of a `Boolean` switch with 3 values true, false and `null` there was a miscalculation on what consists an exhaustive switch. This PR addresses this bug by removing the values true and false (instead of adding and comparing with 2 expected values). This pull request has now been integrated. Changeset: c1fdc04a Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/c1fdc04ad78e6e4712f2173370012106f9cc45ee Stats: 42 lines in 2 files changed: 39 ins; 0 del; 3 mod 8336781: Erroneous exhaustivity check with boolean switch Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/20243 From liach at openjdk.org Mon Jul 22 16:42:06 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Jul 2024 16:42:06 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v2] In-Reply-To: References: Message-ID: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Chen Liang 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 to the specification per Alex feedback - Merge branch 'fix/cf-apis' of https://github.com/liachmodded/jdk into fix/typeanno-model - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20247/files - new: https://git.openjdk.org/jdk/pull/20247/files/752451a7..877b9384 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=00-01 Stats: 605 lines in 40 files changed: 515 ins; 31 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From cushon at openjdk.org Mon Jul 22 17:28:40 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 22 Jul 2024 17:28:40 GMT Subject: Integrated: 8336491: Unnecessary boxing conversions in void-returning lambdas In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 19:09:49 GMT, Liam Miller-Cushon wrote: > Please consider this possible fix for [JDK-8336491](https://bugs.openjdk.org/browse/JDK-8336491), which avoids generating an unnecessary boxing conversion for the result of void-returning expression lambdas. This pull request has now been integrated. Changeset: 31a85f17 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/31a85f17440ca0d791f694d670119ba8adc1ba7f Stats: 69 lines in 2 files changed: 69 ins; 0 del; 0 mod 8336491: Unnecessary boxing conversions in void-returning lambdas Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/20222 From cushon at openjdk.org Mon Jul 22 17:28:39 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 22 Jul 2024 17:28:39 GMT Subject: RFR: 8336491: Unnecessary boxing conversions in void-returning lambdas [v3] In-Reply-To: References: Message-ID: <2hD_M_WB33oJtXDOqRMsPAwyl5rU9nsXgHyQb0RbNDY=.708778ce-30d0-4c01-b73b-11e35a2c84de@github.com> On Fri, 19 Jul 2024 22:18:05 GMT, Liam Miller-Cushon wrote: >> Please consider this possible fix for [JDK-8336491](https://bugs.openjdk.org/browse/JDK-8336491), which avoids generating an unnecessary boxing conversion for the result of void-returning expression lambdas. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Represent void lambda results as Type.noType I'm happy with proceeding with the current approach. Thanks again for the help! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20222#issuecomment-2243455712 From cushon at openjdk.org Mon Jul 22 23:09:56 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 22 Jul 2024 23:09:56 GMT Subject: RFR: 8336942: Improve test coverage for class loading elements with annotations of different retentions Message-ID: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com> This changes adds some additional test coverage for the handling of type use annotations read from class files added in [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377). If both a `RUNTIME` and `CLASS` retention type annotation appear on the same element loaded from a class file, the annotations are attached by separate `TypeAnnotationCompleter's`s, and the logic in `ClassReader` needs to merge the annotations from the second attribute with annotations added by the first one. The implementation already handles this correctly, but there isn't explicit test coverage for it. This change adds test coverage for that case. ------------- Commit messages: - Sort entries in nameToAnnotation - 8336942: Improve test coverage for class loading elements with annotations of different retentions Changes: https://git.openjdk.org/jdk/pull/20287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336942 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20287/head:pull/20287 PR: https://git.openjdk.org/jdk/pull/20287 From darcy at openjdk.org Tue Jul 23 02:18:43 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 23 Jul 2024 02:18:43 GMT Subject: RFR: 8332850: javac crashes if container for repeatable annotation is not found In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 17:02:32 GMT, Vicente Romero wrote: > javac is crashing if it can't find the container for repeatable annotations in the classpath, this is due to a `CompletionFailure` exception that is not being caught. The current fix is catching the exception and producing an error message which is what we do for similar cases, > > TIA Looks okay; is there any additional testing or code changes that should be done for repeated type annotations? ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20260#pullrequestreview-2192838855 From liach at openjdk.org Tue Jul 23 05:07:44 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 05:07:44 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v4] In-Reply-To: References: Message-ID: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge BoundAttributeTest - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - 2 test failures - Web review cleanup - Remove WritableElement and reduce Writable usage The rest of Writable in annotations can be removed in later cleanup - Fix up usages of Util.write - ... and 1 more: https://git.openjdk.org/jdk/compare/22914e07...5ce1943a ------------- Changes: https://git.openjdk.org/jdk/pull/20205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=03 Stats: 457 lines in 49 files changed: 99 ins; 198 del; 160 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From liach at openjdk.org Tue Jul 23 05:07:44 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 05:07:44 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v3] In-Reply-To: References: Message-ID: On Sat, 20 Jul 2024 23:12:59 GMT, Chen Liang wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge BoundAttributeTest > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - 2 test failures > - Web review cleanup > - Remove WritableElement and reduce Writable usage > > The rest of Writable in annotations can be removed in later cleanup > - Fix up usages of Util.write > - Hide writeTo from all class file elements > > To consider the fate of WritableElement later! Re-requesting a review: there was a conflict with #20244 in implements list of `DirectMethodBuilder`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20205#issuecomment-2244260340 From liach at openjdk.org Tue Jul 23 05:40:05 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 05:40:05 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v5] In-Reply-To: References: Message-ID: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Fix test compile errors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20205/files - new: https://git.openjdk.org/jdk/pull/20205/files/5ce1943a..09a6f60a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=03-04 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From darcy at openjdk.org Tue Jul 23 05:44:45 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 23 Jul 2024 05:44:45 GMT Subject: RFR: 8335823: Update --release 23 symbol information for JDK 23 build 33 Message-ID: There were a few changes to the class file API in build 32 (JDK-8335935); symbol files regenerated to be current with build 33. ------------- Commit messages: - JDK-8335823: Update --release 23 symbol information for JDK 23 build 33 Changes: https://git.openjdk.org/jdk/pull/20293/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20293&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335823 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20293/head:pull/20293 PR: https://git.openjdk.org/jdk/pull/20293 From iris at openjdk.org Tue Jul 23 06:58:33 2024 From: iris at openjdk.org (Iris Clark) Date: Tue, 23 Jul 2024 06:58:33 GMT Subject: RFR: 8335823: Update --release 23 symbol information for JDK 23 build 33 In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 05:38:48 GMT, Joe Darcy wrote: > There were a few changes to the class file API in build 32 (JDK-8335935); symbol files regenerated to be current with build 33. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20293#pullrequestreview-2193125691 From asotona at openjdk.org Tue Jul 23 07:06:34 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 23 Jul 2024 07:06:34 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 05:40:05 GMT, Chen Liang wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix test compile errors Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20205#pullrequestreview-2193140947 From liach at openjdk.org Tue Jul 23 12:14:34 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 12:14:34 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 05:40:05 GMT, Chen Liang wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix test compile errors Thanks for the reviews! Tier 1 to 3 passes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20205#issuecomment-2245075547 From liach at openjdk.org Tue Jul 23 12:14:36 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 12:14:36 GMT Subject: Integrated: 8335939: Hide element writing across the ClassFile API In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 23:50:17 GMT, Chen Liang wrote: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition This pull request has now been integrated. Changeset: a2a236f9 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/a2a236f9041083e4b8f11e068da0031dd5f52c2b Stats: 461 lines in 50 files changed: 101 ins; 198 del; 162 mod 8335939: Hide element writing across the ClassFile API Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20205 From liach at openjdk.org Tue Jul 23 12:39:32 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 12:39:32 GMT Subject: RFR: 8335823: Update --release 23 symbol information for JDK 23 build 33 In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 05:38:48 GMT, Joe Darcy wrote: > There were a few changes to the class file API in build 32 (JDK-8335935); symbol files regenerated to be current with build 33. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20293#pullrequestreview-2193864184 From vromero at openjdk.org Tue Jul 23 14:20:01 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 23 Jul 2024 14:20:01 GMT Subject: RFR: 8334466: Ambiguous method call with generics may cause FunctionDescriptorLookupError Message-ID: javac is crashing while compiling code like: import java.util.List; class Test { void m() { List list = List.of(new X()); test(list.get(0)); } void test(A a) { } void test(B b) { } interface A> { T a(); } interface B> { T b(); } class X implements A, B { public X a() { return null; } public X b() { return null; } } } this is because method Types::findDescriptorType, which is invoked in this particular case, throws `FunctionDescriptorLookupError` which is an internal exception that is supposed to be captured by the client. The client then should interpret the exception depending on the context. This was not happening in the code path stressed by this test case. This PR is fixing this issue TIA ------------- Commit messages: - adding comment - 8334466: Ambiguous method call with generics may cause FunctionDescriptorLookupError Changes: https://git.openjdk.org/jdk/pull/20300/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20300&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334466 Stats: 38 lines in 3 files changed: 35 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20300.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20300/head:pull/20300 PR: https://git.openjdk.org/jdk/pull/20300 From liach at openjdk.org Tue Jul 23 15:43:58 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 15:43:58 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v3] In-Reply-To: References: Message-ID: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - SealedGraph now redundant - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation ------------- Changes: https://git.openjdk.org/jdk/pull/20247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=02 Stats: 245 lines in 20 files changed: 81 ins; 115 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From liach at openjdk.org Tue Jul 23 15:43:58 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 15:43:58 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v2] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 16:42:06 GMT, Chen Liang wrote: >> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. >> >> Depends on #20205. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. Unfortunately had to force push: the old commit histories now cause conflicts, so I had squashed them into one and applied onto the latest master. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2245592977 From darcy at openjdk.org Tue Jul 23 16:29:36 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 23 Jul 2024 16:29:36 GMT Subject: Integrated: 8335823: Update --release 23 symbol information for JDK 23 build 33 In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 05:38:48 GMT, Joe Darcy wrote: > There were a few changes to the class file API in build 32 (JDK-8335935); symbol files regenerated to be current with build 33. This pull request has now been integrated. Changeset: 8efcb40c Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/8efcb40c47d8730d84620a9e980ab9eeb5f51441 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod 8335823: Update --release 23 symbol information for JDK 23 build 33 Reviewed-by: iris, liach ------------- PR: https://git.openjdk.org/jdk/pull/20293 From kdriver at openjdk.org Tue Jul 23 16:36:06 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 16:36:06 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) Message-ID: Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). ------------- Commit messages: - refactor to change getInstance parameter type and deriveX methods parameter type - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - code review comment - minor code-review comments - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - ... and 98 more: https://git.openjdk.org/jdk/compare/c740e1e3...12f71f86 Changes: https://git.openjdk.org/jdk/pull/20301/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331008 Stats: 2314 lines in 15 files changed: 2313 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From kdriver at openjdk.org Tue Jul 23 16:53:14 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 16:53:14 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v2] In-Reply-To: References: Message-ID: > Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). > > Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). Kevin Driver 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 102 new commits since the last revision: - add back extra comma - remove from Source.java - refactor to change getInstance parameter type and deriveX methods parameter type - code review comment - minor code-review comments - javadoc formatting - javadoc formatting - remove unused declared exception in impls - throw a ProviderException instead of "eating" an NSAE for Mac - fix edge-case in consolidateKeyMaterial - ... and 92 more: https://git.openjdk.org/jdk/compare/12f71f86...ca63c111 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20301/files - new: https://git.openjdk.org/jdk/pull/20301/files/12f71f86..ca63c111 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From kdriver at openjdk.org Tue Jul 23 17:09:10 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 17:09:10 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v3] In-Reply-To: References: Message-ID: > Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). > > Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). Kevin Driver 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 two new commits since the last revision: - refactor to change getInstance parameter type and deriveX methods parameter type - Provide a KDF API and accompanying implementation of RFC 5869. Squashing previous commits that were approved/reviewed in the JDK 23 timeframe. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20301/files - new: https://git.openjdk.org/jdk/pull/20301/files/ca63c111..26cffbf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From kdriver at openjdk.org Tue Jul 23 19:04:34 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 19:04:34 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v4] In-Reply-To: References: Message-ID: > Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). > > Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: getter for KDFParameters ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20301/files - new: https://git.openjdk.org/jdk/pull/20301/files/26cffbf8..4fb26325 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=02-03 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From liach at openjdk.org Tue Jul 23 19:10:12 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 19:10:12 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v4] In-Reply-To: References: Message-ID: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Refine the spec of TypeAnnotation per Alex feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20247/files - new: https://git.openjdk.org/jdk/pull/20247/files/6e31c489..416890a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=02-03 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From liach at openjdk.org Tue Jul 23 19:14:46 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 19:14:46 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v5] In-Reply-To: References: Message-ID: <6A5fADogvrAFf0SOxFNlD0OEOWwjJObCBqh0X2NXIYM=.41ca7fa2-c6a6-487a-8b1f-e2a996526e05@github.com> > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Further refine wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20247/files - new: https://git.openjdk.org/jdk/pull/20247/files/416890a7..beb92159 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From kdriver at openjdk.org Tue Jul 23 20:52:22 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 20:52:22 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v5] In-Reply-To: References: Message-ID: > Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). > > Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: refactor out common code for provider selection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20301/files - new: https://git.openjdk.org/jdk/pull/20301/files/4fb26325..7bedda25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=03-04 Stats: 110 lines in 2 files changed: 19 ins; 82 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From liach at openjdk.org Wed Jul 24 13:00:47 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 13:00:47 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v6] In-Reply-To: References: Message-ID: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Chen Liang has updated the pull request incrementally with three additional commits since the last revision: - More refinements from alex - Artifact -> construct - More about Annotation, add equals note ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20247/files - new: https://git.openjdk.org/jdk/pull/20247/files/beb92159..cf16e7ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=04-05 Stats: 73 lines in 4 files changed: 52 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From asotona at openjdk.org Wed Jul 24 13:39:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 24 Jul 2024 13:39:32 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v6] In-Reply-To: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> References: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> Message-ID: On Wed, 24 Jul 2024 13:00:47 GMT, Chen Liang wrote: >> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. >> >> Depends on #20205. > > Chen Liang has updated the pull request incrementally with three additional commits since the last revision: > > - More refinements from alex > - Artifact -> construct > - More about Annotation, add equals note Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2196775087 From vromero at openjdk.org Wed Jul 24 17:38:57 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 24 Jul 2024 17:38:57 GMT Subject: RFR: 8337037: compiler internal options are not printing the stacktrace after a compiler crash Message-ID: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed, TIA ------------- Commit messages: - 8337037: compiler internal options are not printing the stacktrace after a compiler crash Changes: https://git.openjdk.org/jdk/pull/20314/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337037 Stats: 75 lines in 8 files changed: 45 ins; 4 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/20314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314 PR: https://git.openjdk.org/jdk/pull/20314 From vromero at openjdk.org Wed Jul 24 17:46:44 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 24 Jul 2024 17:46:44 GMT Subject: RFR: 8337037: compiler internal options are not printing the stacktrace after a compiler crash [v2] In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> Message-ID: > There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed, > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20314/files - new: https://git.openjdk.org/jdk/pull/20314/files/e59796c5..2bc5cc32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=00-01 Stats: 27 lines in 3 files changed: 7 ins; 20 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314 PR: https://git.openjdk.org/jdk/pull/20314 From aturbanov at openjdk.org Wed Jul 24 19:13:36 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 24 Jul 2024 19:13:36 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v6] In-Reply-To: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> References: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> Message-ID: On Wed, 24 Jul 2024 13:00:47 GMT, Chen Liang wrote: >> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. >> >> Depends on #20205. > > Chen Liang has updated the pull request incrementally with three additional commits since the last revision: > > - More refinements from alex > - Artifact -> construct > - More about Annotation, add equals note test/langtools/lib/annotations/annotations/classfile/ClassfileInspector.java line 1200: > 1198: case RuntimeVisibleTypeAnnotationsAttribute rvattr -> { > 1199: if (expected.matchVisibility(true)) { > 1200: for(var anno : rvattr.annotations()) { Suggestion: for (var anno : rvattr.annotations()) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20247#discussion_r1690305951 From liach at openjdk.org Wed Jul 24 19:28:33 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 19:28:33 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v6] In-Reply-To: References: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> Message-ID: On Wed, 24 Jul 2024 19:11:18 GMT, Andrey Turbanov wrote: >> Chen Liang has updated the pull request incrementally with three additional commits since the last revision: >> >> - More refinements from alex >> - Artifact -> construct >> - More about Annotation, add equals note > > test/langtools/lib/annotations/annotations/classfile/ClassfileInspector.java line 1200: > >> 1198: case RuntimeVisibleTypeAnnotationsAttribute rvattr -> { >> 1199: if (expected.matchVisibility(true)) { >> 1200: for(var anno : rvattr.annotations()) { > > Suggestion: > > for (var anno : rvattr.annotations()) { There are 43 `for(` and 2 `for (` in this file, so fixing a single occurrence isn't too helpful; for consistency I think you can create a dedicated RFE for running IDE formatters over all jdk/classfile tests. I will review it if you submit such a patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20247#discussion_r1690320937 From jjg at openjdk.org Wed Jul 24 21:26:50 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 24 Jul 2024 21:26:50 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v3] In-Reply-To: References: Message-ID: > Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. > > Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. > > There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. > > A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. > > There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Fix merge issues - Merge with upstream master - fix whitespace - reorder imports - Cleanup pass - Merge doclint into html: part 2: TagName/HtmlTag - Merge doclint support classes into html: part 1: attributes - Move basic classes from internal.doclets.formats.html.markup to internal.html ------------- Changes: https://git.openjdk.org/jdk/pull/19916/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=02 Stats: 2982 lines in 106 files changed: 1099 ins; 1218 del; 665 mod Patch: https://git.openjdk.org/jdk/pull/19916.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19916/head:pull/19916 PR: https://git.openjdk.org/jdk/pull/19916 From vromero at openjdk.org Wed Jul 24 21:30:11 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 24 Jul 2024 21:30:11 GMT Subject: RFR: 8332850: javac crashes if container for repeatable annotation is not found [v2] In-Reply-To: References: Message-ID: > javac is crashing if it can't find the container for repeatable annotations in the classpath, this is due to a `CompletionFailure` exception that is not being caught. The current fix is catching the exception and producing an error message which is what we do for similar cases, > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding a test for type annos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20260/files - new: https://git.openjdk.org/jdk/pull/20260/files/4557494c..5531ab17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20260&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20260&range=00-01 Stats: 50 lines in 1 file changed: 37 ins; 8 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20260/head:pull/20260 PR: https://git.openjdk.org/jdk/pull/20260 From vromero at openjdk.org Wed Jul 24 21:30:11 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 24 Jul 2024 21:30:11 GMT Subject: RFR: 8332850: javac crashes if container for repeatable annotation is not found [v2] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 02:16:11 GMT, Joe Darcy wrote: > Looks okay; is there any additional testing or code changes that should be done for repeated type annotations? @jddarcy thanks for the comments, I have added a test for type annotations ------------- PR Comment: https://git.openjdk.org/jdk/pull/20260#issuecomment-2248930102 From jjg at openjdk.org Wed Jul 24 22:09:46 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 24 Jul 2024 22:09:46 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v4] In-Reply-To: References: Message-ID: > Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. > > Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. > > There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. > > A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. > > There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Cleanup use of HtmlStyle and HtmlStyles ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19916/files - new: https://git.openjdk.org/jdk/pull/19916/files/32cc264d..4d210ce9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=02-03 Stats: 49 lines in 13 files changed: 13 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/19916.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19916/head:pull/19916 PR: https://git.openjdk.org/jdk/pull/19916 From cushon at google.com Wed Jul 24 23:30:04 2024 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 24 Jul 2024 16:30:04 -0700 Subject: Redo of backport of JDK-8225377 (type annotations are not visible to javac plugins across compilation boundaries) Message-ID: Hi, I would like to raise the possibility of re-doing the backport of JDK-8225377 to JDK 21. To briefly recap the issue, JDK-8225377 was a fix made in JDK 22 which causes javac to attach type annotations read from bytecode with their corresponding type mirror. Prior to that change javac read the annotations from the class file, but did not attach them to the corresponding type, so annotation processors were unable to retrieve them from the type mirror API. There is more detail in the bug [1] and PR [2]. There was an attempt to backport the fix to earlier release trains, but there was some compatibility impact to micronaut [3][4], and the change was backed out [5]. (The issue affecting micronaut has since been fixed [6].) The compatibility impact from the change comes from the fact that `AnnotatedConstruct#getAnnotationMirrors` correctly reports annotations that were previously being ignored, and `TypeMirror#toString` correctly includes the annotations in the string representation that were previously omitted. This change affects existing code, for example if an annotation processor doesn't handle type annotations and was relying on the bug causing them to be skipped, or code that expects `TypeMirror#toString` to omit type annotations and relies on stable `toString` input to use as a key. There is also some ongoing impact from the presence of the bug. Annotation processors that want to process type-use annotations are unable to retrieve annotations from classes on JDK versions prior to 22, and have no workaround to access those annotations without delving into javac internals. A specific example is the JSpecify annotations [7], which I would like to make possible for annotation processors to access when they appear on libraries read from the classpath. I understand that redoing the backport would require filing a 'REDO BACKPORT' issue and creating a new CSR associated with that bug. Before I do that, I'm curious if anyone on the list has input on the idea of redoing the backport, and of how to evaluate that tradeoff between the risk of the compatibility impact and the benefit of fixing the bug in earlier release trains? Thanks, Liam [1] https://bugs.openjdk.org/browse/JDK-8225377 [2] https://github.com/openjdk/jdk/pull/16407 [3] https://bugs.openjdk.org/browse/JDK-8323093 [4] https://github.com/micronaut-projects/micronaut-core/pull/10293 [5] https://bugs.openjdk.org/browse/JDK-8322883 [6] https://github.com/micronaut-projects/micronaut-core/releases/tag/v4.2.3 [7] https://jspecify.dev/blog/release-1.0.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Wed Jul 24 23:35:32 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 24 Jul 2024 23:35:32 GMT Subject: RFR: 8332850: javac crashes if container for repeatable annotation is not found [v2] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 21:30:11 GMT, Vicente Romero wrote: >> javac is crashing if it can't find the container for repeatable annotations in the classpath, this is due to a `CompletionFailure` exception that is not being caught. The current fix is catching the exception and producing an error message which is what we do for similar cases, >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > adding a test for type annos Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20260#pullrequestreview-2197965918 From mcimadamore at openjdk.org Thu Jul 25 09:57:34 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 25 Jul 2024 09:57:34 GMT Subject: RFR: 8337037: compiler internal options are not printing the stacktrace after a compiler crash [v2] In-Reply-To: References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> Message-ID: On Wed, 24 Jul 2024 17:46:44 GMT, Vicente Romero wrote: >> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed, >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments Looks good. Two observation (no need to do anything, mostly for your consideration): * Given that the new exception type is used across different types (e.g. Types and Resolve), it would perhaps make sense to put it in the `util` package? * I noticed that the changes to Type.SignatureGenerator have caused a cascade effect on all the subclasses. I wonder: perhaps SignatureGenerator should be an member inner class, so that it can read its "doe" bit from `Types` directly? After all, clients all have a `types` instance available when creating a subclass of the signature generator, so that would work for them too, but would avoid a bit of repetition. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20314#pullrequestreview-2198849601 PR Review: https://git.openjdk.org/jdk/pull/20314#pullrequestreview-2198849889 From hannesw at openjdk.org Thu Jul 25 11:09:32 2024 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 25 Jul 2024 11:09:32 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v4] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 22:09:46 GMT, Jonathan Gibbons wrote: >> Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. >> >> Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. >> >> There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. >> >> A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. >> >> There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup use of HtmlStyle and HtmlStyles Changes requested by hannesw (Reviewer). src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlAttr.java line 25: > 23: * questions. > 24: */ > 25: Copyright header and doc comments were removed here (I guess by accident). src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlStyle.java line 5: > 3: public interface HtmlStyle { > 4: String cssName(); > 5: } Copyright header and doc comments are missing in this file. ------------- PR Review: https://git.openjdk.org/jdk/pull/19916#pullrequestreview-2198994299 PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1691263216 PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1691261610 From hannesw at openjdk.org Thu Jul 25 11:12:32 2024 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 25 Jul 2024 11:12:32 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v4] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 22:09:46 GMT, Jonathan Gibbons wrote: >> Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. >> >> Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. >> >> There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. >> >> A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. >> >> There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup use of HtmlStyle and HtmlStyles Two files in the new `html` package are missing copyright header and doc comments: `HtmlAttr.java` and `HtmlStyle.java`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19916#issuecomment-2250071458 From vromero at openjdk.org Thu Jul 25 13:45:38 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 25 Jul 2024 13:45:38 GMT Subject: Integrated: 8332850: javac crashes if container for repeatable annotation is not found In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 17:02:32 GMT, Vicente Romero wrote: > javac is crashing if it can't find the container for repeatable annotations in the classpath, this is due to a `CompletionFailure` exception that is not being caught. The current fix is catching the exception and producing an error message which is what we do for similar cases, > > TIA This pull request has now been integrated. Changeset: 34ee06f5 Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/34ee06f51122e8afb875cc3b75f513912272fd9b Stats: 131 lines in 2 files changed: 130 ins; 0 del; 1 mod 8332850: javac crashes if container for repeatable annotation is not found Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/20260 From vromero at openjdk.org Thu Jul 25 15:53:11 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 25 Jul 2024 15:53:11 GMT Subject: RFR: 8337037: compiler internal options are not printing the stacktrace after a compiler crash [v3] In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> Message-ID: <67aL-_uglJIWeqILraOM8SMsZElQRbHXf2hE0Twkg3c=.0688a6da-e7aa-4961-9c0d-4aadd713acb6@github.com> > There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed, > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20314/files - new: https://git.openjdk.org/jdk/pull/20314/files/2bc5cc32..c5bb19cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=01-02 Stats: 109 lines in 9 files changed: 58 ins; 36 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/20314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314 PR: https://git.openjdk.org/jdk/pull/20314 From vromero at openjdk.org Thu Jul 25 16:06:01 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 25 Jul 2024 16:06:01 GMT Subject: RFR: 8337037: compiler internal options are not printing the stacktrace after a compiler crash [v4] In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> Message-ID: <2ZT6n0HemLAL6xup6asFZIz-NKa4oO3iyzeriB_IWU8=.5c75eb5b-ba86-48e8-baea-d4eceac40def@github.com> > There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed, > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: clean-up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20314/files - new: https://git.openjdk.org/jdk/pull/20314/files/c5bb19cb..51fada43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=02-03 Stats: 5 lines in 4 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314 PR: https://git.openjdk.org/jdk/pull/20314 From vromero at openjdk.org Thu Jul 25 16:10:49 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 25 Jul 2024 16:10:49 GMT Subject: RFR: 8337037: compiler internal options are not printing the stacktrace after a compiler crash [v5] In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> Message-ID: > There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed, > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20314/files - new: https://git.openjdk.org/jdk/pull/20314/files/51fada43..3407774f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314 PR: https://git.openjdk.org/jdk/pull/20314 From vromero at openjdk.org Thu Jul 25 16:13:45 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 25 Jul 2024 16:13:45 GMT Subject: RFR: 8337037: compiler internal options are not printing the stacktrace after a compiler crash [v2] In-Reply-To: References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> Message-ID: On Thu, 25 Jul 2024 09:54:22 GMT, Maurizio Cimadamore wrote: > Looks good. Two observation (no need to do anything, mostly for your consideration): > > * Given that the new exception type is used across different types (e.g. Types and Resolve), it would perhaps make sense to put it in the `util` package? > > * I noticed that the changes to Type.SignatureGenerator have caused a cascade effect on all the subclasses. I wonder: perhaps SignatureGenerator should be an member inner class, so that it can read its "doe" bit from `Types` directly? After all, clients all have a `types` instance available when creating a subclass of the signature generator, so that would work for them too, but would avoid a bit of repetition. thanks for your comments, I have made the proposed modifications plus a few other minor changes ------------- PR Comment: https://git.openjdk.org/jdk/pull/20314#issuecomment-2250839730 From mcimadamore at openjdk.org Thu Jul 25 16:26:33 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 25 Jul 2024 16:26:33 GMT Subject: RFR: 8337037: compiler internal options are not printing the stacktrace after a compiler crash [v5] In-Reply-To: References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> Message-ID: On Thu, 25 Jul 2024 16:10:49 GMT, Vicente Romero wrote: >> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed, >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > removing unused import Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20314#pullrequestreview-2199807865 From vromero at openjdk.org Thu Jul 25 17:06:38 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 25 Jul 2024 17:06:38 GMT Subject: Integrated: 8337037: compiler internal options are not printing the stacktrace after a compiler crash In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com> Message-ID: <1fVwA9V3jpCPownWfuCNZ7Ybp-NAD4uBwvf3VLmRCR0=.77a9e946-d5e9-40cb-a53e-3b8f872216b5@github.com> On Wed, 24 Jul 2024 17:33:24 GMT, Vicente Romero wrote: > There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed, > > TIA This pull request has now been integrated. Changeset: cf0d9e0e Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/cf0d9e0e521b495a96a3de7775b1b3ae14d20d80 Stats: 138 lines in 9 files changed: 75 ins; 30 del; 33 mod 8337037: compiler internal options are not printing the stacktrace after a compiler crash Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/20314 From liach at openjdk.org Thu Jul 25 23:16:42 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 23:16:42 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments Message-ID: Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. ------------- Commit messages: - 8337219: AccessFlags factories do not require necessary arguments Changes: https://git.openjdk.org/jdk/pull/20341/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20341&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337219 Stats: 212 lines in 21 files changed: 71 ins; 80 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/20341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20341/head:pull/20341 PR: https://git.openjdk.org/jdk/pull/20341 From manu at sridharan.net Fri Jul 26 02:12:42 2024 From: manu at sridharan.net (Manu Sridharan) Date: Thu, 25 Jul 2024 22:12:42 -0400 Subject: Redo of backport of JDK-8225377 (type annotations are not visible to javac plugins across compilation boundaries) In-Reply-To: References: Message-ID: Hi all, I wanted to chime in to support the idea of re-doing the backport of this fix. I?m a primary maintainer of NullAway (https://github.com/uber/NullAway) and we are working to better support checking of generic types and arrays according to the JSpecify spec. Due to JDK-8225377 we need to implement workarounds based on internal APIs to read type annotations from bytecode for JDK versions prior to 22. We have implemented a few already, but fully supporting all possible type annotation positions (on nested generic types, arrays, etc.) will be significant additional work. A backport of the fix for JDK-8225377 would save us a lot of time and make it much easier for tools like NullAway to properly analyze and support these language features. Best, Manu On Jul 24, 2024 at 16:30:04, Liam Miller-Cushon wrote: > Hi, > > I would like to raise the possibility of re-doing the backport of > JDK-8225377 to JDK 21. > > To briefly recap the issue, JDK-8225377 was a fix made in JDK 22 which > causes javac to attach type annotations read from bytecode with their > corresponding type mirror. Prior to that change javac read the annotations > from the class file, but did not attach them to the corresponding type, so > annotation processors were unable to retrieve them from the type mirror > API. There is more detail in the bug [1] and PR [2]. > > There was an attempt to backport the fix to earlier release trains, but > there was some compatibility impact to micronaut [3][4], and the change was > backed out [5]. (The issue affecting micronaut has since been fixed [6].) > The compatibility impact from the change comes from the fact that > `AnnotatedConstruct#getAnnotationMirrors` correctly reports annotations > that were previously being ignored, and `TypeMirror#toString` correctly > includes the annotations in the string representation that were previously > omitted. This change affects existing code, for example if an annotation > processor doesn't handle type annotations and was relying on the bug > causing them to be skipped, or code that expects `TypeMirror#toString` to > omit type annotations and relies on stable `toString` input to use as a key. > > There is also some ongoing impact from the presence of the bug. Annotation > processors that want to process type-use annotations are unable to retrieve > annotations from classes on JDK versions prior to 22, and have no > workaround to access those annotations without delving into javac > internals. A specific example is the JSpecify annotations [7], which I > would like to make possible for annotation processors to access when they > appear on libraries read from the classpath. > > I understand that redoing the backport would require filing a 'REDO > BACKPORT' issue and creating a new CSR associated with that bug. > > Before I do that, I'm curious if anyone on the list has input on the idea > of redoing the backport, and of how to evaluate that tradeoff between the > risk of the compatibility impact and the benefit of fixing the bug in > earlier release trains? > > Thanks, > Liam > > [1] https://bugs.openjdk.org/browse/JDK-8225377 > [2] https://github.com/openjdk/jdk/pull/16407 > [3] https://bugs.openjdk.org/browse/JDK-8323093 > [4] https://github.com/micronaut-projects/micronaut-core/pull/10293 > [5] https://bugs.openjdk.org/browse/JDK-8322883 > [6] > https://github.com/micronaut-projects/micronaut-core/releases/tag/v4.2.3 > [7] https://jspecify.dev/blog/release-1.0.0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Fri Jul 26 08:22:31 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 26 Jul 2024 08:22:31 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote: > Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. > > `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. > > However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. > > As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. > > This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. It is a reasonable cleanup of risky factory methods, given the fact we have more safe `withFlags` builders methods. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20341#pullrequestreview-2201219552 From hannesw at openjdk.org Fri Jul 26 10:54:38 2024 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 26 Jul 2024 10:54:38 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v4] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 22:09:46 GMT, Jonathan Gibbons wrote: >> Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. >> >> Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. >> >> There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. >> >> A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. >> >> There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup use of HtmlStyle and HtmlStyles src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlTag.java line 87: > 85: attrs(AttrKind.HTML4, CLEAR)), > 86: > 87: BUTTON(BlockType.OTHER, EndKind.REQUIRED, Several tag constants that use `BlockType.OTHER` in this enum are defined as [Phrasing Content](https://html.spec.whatwg.org/#phrasing-content) in the HTML5 spec. Since HTML5 phrasing content roughly corresponds to pre-HTML5 inline content these tags should use `BlockType.INLINE` here. This includes the following tags: - BUTTON - INPUT - LABEL - LINK - SCRIPT These tags were also flagged as `phrasingContent` in the old doclet `TagName` enum. I'm not sure whether marking it as `INLINE` content will break DocLint tests. It would seem like a good idea to suggest using [HTML5 content categories](https://developer.mozilla.org/en-US/docs/Web/HTML/Content_categories) in the new merged code, but the new categories are more complex and overlapping, and don't include list and table content, so there is not a lot to gain besides maybe more up-to-date terminology. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1692888920 From mcimadamore at openjdk.org Fri Jul 26 13:31:46 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 26 Jul 2024 13:31:46 GMT Subject: RFR: 8336492: Regression in lambda serialization In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 10:31:24 GMT, Maurizio Cimadamore wrote: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2246: > 2244: return true; > 2245: } > 2246: if (sym.owner.kind != MTH && rs.isSerializable(sym.type)) { Note, this change serialized form for local/anon classes, by omitting capture of enclosing `this` where possible. (see discussion on serialization compatibility in the PR). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1692870181 From mcimadamore at openjdk.org Fri Jul 26 13:31:45 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 26 Jul 2024 13:31:45 GMT Subject: RFR: 8336492: Regression in lambda serialization Message-ID: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. #### Compatibility This PR changes the set of fields that are added to local/anonymous classes. Consider the following case: class Outer { void m(int x) { class Local extends Serializable { void print() { System.out.println(x); } } } } This used to generate the following bytecode for `Local`: class Outer$1Local { final int val$x; descriptor: I final Outer this$0; descriptor: LOuter; Outer$1Local(); descriptor: (LOuter;I)V void print(); descriptor: ()V } With this patch, we only generate this: class Outer$1Local implements java.io.Serializable { final int val$x; descriptor: I Outer$1Local(); descriptor: (LOuter;I)V void print(); descriptor: ()V } That is, the field for `this$0` is omitted (as that's not used). This affects the serialized form of this local class, as there's now one less field in the serialized form. While this change is desirable (it brings behavior in sync with lambda expressions, and avoiding capture of enclosing instance might be beneficial for GC reachability), we need to make sure this is ok. Also, it is possible that the _order_ in which local capture fields appear in classes/constructor parameters of local/anon classes changes slightly, due the fact we're using a different visitor. Another, minor issue in this rewrite is that now generated lambda methods can have different names from before. In the old code, a shared counter for _all_ lambdas in a class was used. As the new code shares the same logic for checking name clashing as the one used in serializable lambdas, we now increment the suffix after `lambda$foo$` if needed. So if two lambdas are defined in two methods `foo` and `bar`, we now get `lambda$foo$0` and `lambda$foo$bar$0` (before, one of them would have had the index set to `1`). While this affects some tests, which name we generate for synthetic lambda methods is a private contract, so I didn't think that preserving 100% compatibility was relevant here. @cushon perhaps you could help assessing the compatibility impact of this change (as you seem to have a codebase which rely on serialization of local classes/lambdas) ? ------------- Commit messages: - Fix Scoped test - Initial push Changes: https://git.openjdk.org/jdk/pull/20349/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336492 Stats: 1462 lines in 10 files changed: 395 ins; 716 del; 351 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From acobbs at openjdk.org Fri Jul 26 16:04:32 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 26 Jul 2024 16:04:32 GMT Subject: RFR: 8336492: Regression in lambda serialization In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 10:31:24 GMT, Maurizio Cimadamore wrote: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Refactoring Awesomeness Ratio (not counting unit tests) = 1.58. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2253057996 From mcimadamore at openjdk.org Fri Jul 26 16:23:09 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 26 Jul 2024 16:23:09 GMT Subject: RFR: 8336492: Regression in lambda serialization [v2] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Reduce incompatibilities by making sure that the name of a lambda captured parameter matches the name of the captured local (skipping any intermediate synthetic local capture in local classes) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/4fcc7814..76a972b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=00-01 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Fri Jul 26 16:43:31 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 26 Jul 2024 16:43:31 GMT Subject: RFR: 8336492: Regression in lambda serialization [v2] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 10:34:27 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduce incompatibilities by making sure that the name of a lambda captured parameter matches the name of the captured local (skipping any intermediate synthetic local capture in local classes) > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2246: > >> 2244: return true; >> 2245: } >> 2246: if (sym.owner.kind != MTH && rs.isSerializable(sym.type)) { > > Note, this change serialized form for local/anon classes, by omitting capture of enclosing `this` where possible. (see discussion on serialization compatibility in the PR). Note: consistency with the lambda case is kind of nice, but if this turns out to be problematic, we can omit this change from this PR, and always capture `this$0` in case of a serializable local/anon class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693336149 From josiahnoel at gmail.com Fri Jul 26 16:46:21 2024 From: josiahnoel at gmail.com (Josiah Noel) Date: Fri, 26 Jul 2024 12:46:21 -0400 Subject: Redo of backport of JDK-8225377 (type annotations are not visible to javac plugins across compilation boundaries) In-Reply-To: References: Message-ID: I also maintain multiple annotation processors (Avaje Inject and Validation ) that (futilely) try to scan type-use annotations from external dependencies for some features. A backport would be nice to have so the import features could work in earlier versions. On Thu, Jul 25, 2024 at 10:12?PM Manu Sridharan wrote: > Hi all, > > I wanted to chime in to support the idea of re-doing the backport of this > fix. I?m a primary maintainer of NullAway ( > https://github.com/uber/NullAway) and we are working to better support > checking of generic types and arrays according to the JSpecify spec. Due > to JDK-8225377 we need to implement workarounds based on internal APIs to > read type annotations from bytecode for JDK versions prior to 22. We have > implemented a few already, but fully supporting all possible type > annotation positions (on nested generic types, arrays, etc.) will be > significant additional work. A backport of the fix for JDK-8225377 would > save us a lot of time and make it much easier for tools like NullAway to > properly analyze and support these language features. > > Best, > Manu > > > On Jul 24, 2024 at 16:30:04, Liam Miller-Cushon wrote: > >> Hi, >> >> I would like to raise the possibility of re-doing the backport of >> JDK-8225377 to JDK 21. >> >> To briefly recap the issue, JDK-8225377 was a fix made in JDK 22 which >> causes javac to attach type annotations read from bytecode with their >> corresponding type mirror. Prior to that change javac read the annotations >> from the class file, but did not attach them to the corresponding type, so >> annotation processors were unable to retrieve them from the type mirror >> API. There is more detail in the bug [1] and PR [2]. >> >> There was an attempt to backport the fix to earlier release trains, but >> there was some compatibility impact to micronaut [3][4], and the change was >> backed out [5]. (The issue affecting micronaut has since been fixed [6].) >> The compatibility impact from the change comes from the fact that >> `AnnotatedConstruct#getAnnotationMirrors` correctly reports annotations >> that were previously being ignored, and `TypeMirror#toString` correctly >> includes the annotations in the string representation that were previously >> omitted. This change affects existing code, for example if an annotation >> processor doesn't handle type annotations and was relying on the bug >> causing them to be skipped, or code that expects `TypeMirror#toString` to >> omit type annotations and relies on stable `toString` input to use as a key. >> >> There is also some ongoing impact from the presence of the bug. >> Annotation processors that want to process type-use annotations are unable >> to retrieve annotations from classes on JDK versions prior to 22, and have >> no workaround to access those annotations without delving into javac >> internals. A specific example is the JSpecify annotations [7], which I >> would like to make possible for annotation processors to access when they >> appear on libraries read from the classpath. >> >> I understand that redoing the backport would require filing a 'REDO >> BACKPORT' issue and creating a new CSR associated with that bug. >> >> Before I do that, I'm curious if anyone on the list has input on the idea >> of redoing the backport, and of how to evaluate that tradeoff between the >> risk of the compatibility impact and the benefit of fixing the bug in >> earlier release trains? >> >> Thanks, >> Liam >> >> [1] https://bugs.openjdk.org/browse/JDK-8225377 >> [2] https://github.com/openjdk/jdk/pull/16407 >> [3] https://bugs.openjdk.org/browse/JDK-8323093 >> [4] https://github.com/micronaut-projects/micronaut-core/pull/10293 >> [5] https://bugs.openjdk.org/browse/JDK-8322883 >> [6] >> https://github.com/micronaut-projects/micronaut-core/releases/tag/v4.2.3 >> [7] https://jspecify.dev/blog/release-1.0.0 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Fri Jul 26 16:49:11 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 26 Jul 2024 16:49:11 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add more docs to CaptureScanner, and make fields private/final ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/76a972b7..17bee2c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=01-02 Stats: 21 lines in 1 file changed: 8 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From cushon at openjdk.org Fri Jul 26 17:44:31 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 26 Jul 2024 17:44:31 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 16:49:11 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add more docs to CaptureScanner, and make fields private/final This looks exciting! > @cushon perhaps you could help assessing the compatibility impact of this change (as you seem to have a codebase which rely on serialization of local classes/lambdas) ? I'd be happy to. I have started a round of testing at https://github.com/openjdk/jdk/pull/20349/commits/76a972b775504f06b1db183a1b3fd047c2507f85, it'll take about a day to have results. One caveat is that Google's use of serialization generally doesn't rely on persisting the serialized form, and we had disabled the check for serialization in `shouldEmitOuterThis` so the enclosing instance could be skipped even for serializable classes. That has been fine for us, but I don't know how well that generalizes. There's some previous discussion about the compatibility impact of omitting `this` references in [JDK-8277965](https://bugs.openjdk.org/browse/JDK-8277965) and linked issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2253206115 From vromero at openjdk.org Fri Jul 26 19:03:36 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 26 Jul 2024 19:03:36 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 16:49:11 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add more docs to CaptureScanner, and make fields private/final great simplification, some comments for your consideration src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 208: > 206: * on _where_ the lambda capture occurs). > 207: */ > 208: record CaptureSiteInfo(Symbol owner, boolean inStaticInit, VarSymbol pendingVar) { minor suggestion, add another constructor with only the first two arguments as there are two constructor invocations where the last argument is `null` src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 229: > 227: > 228: /** > 229: * @return Name of the enclosing method to be folded into synthetic probably the comment needs to also mention that it can return `new` or `static` no only the method name src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 277: > 275: this.context = null; > 276: this.contextMap = new HashMap<>(); > 277: cdef = analyzer.analyzeAndPreprocessClass((JCClassDecl) cdef); nice src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 405: > 403: > 404: apportionTypeAnnotations(tree, > 405: owner::getInitTypeAttributes, not sure that this is semantically the same as before src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1117: > 1115: // Inherit ACC_STRICT from the enclosing method, or, for clinit, > 1116: // from the class. > 1117: long flags = SYNTHETIC | LAMBDA_METHOD | side: I wonder if we could use the same bits for flags: `LAMBDA_METHOD` and `RECORD` and safe a bit position for other flags src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1327: > 1325: * Simple subclass modelling the translation context of a method reference. > 1326: */ > 1327: final class ReferenceTranslationContext extends TranslationContext { minor, we can probably remove this class it is not adding any behavior src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1344: > 1342: CAPTURED_VAR; // variables in enclosing scope to translated synthetic parameters > 1343: > 1344: boolean propagateAnnotations() { suggestion: there is only one use of this method and the method can be rewritten with a ternary operator and probably inlined in its only client ------------- PR Review: https://git.openjdk.org/jdk/pull/20349#pullrequestreview-2202071213 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693214548 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693281104 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693283247 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693294216 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693449685 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693477205 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693454240 From vromero at openjdk.org Fri Jul 26 20:53:34 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 26 Jul 2024 20:53:34 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 16:49:11 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add more docs to CaptureScanner, and make fields private/final src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1239: > 1237: ret.pos = sym.pos; > 1238: // Set ret.data. Same as case LOCAL_VAR above. > 1239: if (sym.isExceptionParameter()) { do we really need to set this exception parameter thing for a method param? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693595215 From vromero at openjdk.org Fri Jul 26 22:02:38 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 26 Jul 2024 22:02:38 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 16:49:11 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add more docs to CaptureScanner, and make fields private/final src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 338: > 336: @Override > 337: public void visitClassDef(JCClassDecl tree) { > 338: KlassInfo prevKlassInfo = kInfo; future improvement? we have class info, lambda context, capture site info, should we probably gather them all in an environment like structure? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1693639081 From cushon at openjdk.org Sat Jul 27 18:44:32 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sat, 27 Jul 2024 18:44:32 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 16:49:11 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add more docs to CaptureScanner, and make fields private/final Some initial testing shows a regression in type annotation handling with this change. Given an example like the following, the type annotation in the lambda is now being incorrectly propagated to the constructor. A `RuntimeInvisibleTypeAnnotations` attribute for the annotation is emitted on both the synthetic lambda method and the constructor. I noticed this because the `length` for the `RuntimeInvisibleTypeAnnotations` is longer than the constructor, and both ASM and javap report an error for the class file. import java.lang.annotation.ElementType; import java.lang.annotation.Target; import java.util.ArrayList; import java.util.List; class T { @Target(ElementType.TYPE_USE) @interface A {} Runnable r = () -> { List<@A Object> xs = new ArrayList<>(); xs.add(1); xs.add(2); xs.add(3); xs.add(5); xs.add(6); xs.add(7); xs.add(8); }; T() {} } javap reports an error because the type annotation's length is longer than the constructor: $ javap -c T Compiled from "T.java" class T { java.lang.Runnable r; T(); Code: Error: error at or after byte 0 Error: Fatal error: Bytecode offset out of range; bci=89, codeLength=14 Using the JDK 11 javap shows T(); descriptor: ()V flags: (0x0000) Code: stack=2, locals=1, args_size=1 0: aload_0 1: invokespecial #1 // Method java/lang/Object."":()V 4: aload_0 5: invokedynamic #7, 0 // InvokeDynamic #0:run:()Ljava/lang/Runnable; 10: putfield #11 // Field r:Ljava/lang/Runnable; 13: return LineNumberTable: line 22: 0 line 10: 4 line 22: 13 RuntimeInvisibleTypeAnnotations: 0: #35(): LOCAL_VARIABLE, {start_pc=8, length=81, index=0}, location=[TYPE_ARGUMENT(0)] T$A ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2254224629 From syan at openjdk.org Mon Jul 29 08:06:39 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Jul 2024 08:06:39 GMT Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with fastdebug binary Message-ID: Hi all, Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value when the tested binary is fastdebug or slowdebug. The change has been verified, no risk. ------------- Commit messages: - 8337334: Test tools/javac/7142086/T7142086.java timeout with fastdebug binary Changes: https://git.openjdk.org/jdk/pull/20370/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20370&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337334 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20370/head:pull/20370 PR: https://git.openjdk.org/jdk/pull/20370 From syan at openjdk.org Mon Jul 29 08:12:05 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Jul 2024 08:12:05 GMT Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with fastdebug binary [v2] In-Reply-To: References: Message-ID: > Hi all, > Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value when the tested binary is fastdebug or slowdebug. > > The change has been verified, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: add vm.debug for requires.properties in test/langtools/TEST.ROOT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20370/files - new: https://git.openjdk.org/jdk/pull/20370/files/d139096c..98b26e29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20370&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20370&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20370/head:pull/20370 PR: https://git.openjdk.org/jdk/pull/20370 From syan at openjdk.org Mon Jul 29 08:12:05 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Jul 2024 08:12:05 GMT Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with fastdebug binary In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 08:02:17 GMT, SendaoYan wrote: > Hi all, > Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value when the tested binary is fastdebug or slowdebug. > > The change has been verified, no risk. ![image](https://github.com/user-attachments/assets/3b289e9b-1a0d-4262-b93a-190f24bfdec0) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20370#issuecomment-2255280062 From mcimadamore at openjdk.org Mon Jul 29 09:42:36 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 09:42:36 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Sat, 27 Jul 2024 18:42:13 GMT, Liam Miller-Cushon wrote: > Some initial testing shows a regression in type annotation handling with this change. Thanks, I'll take a look ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2255466861 From mcimadamore at openjdk.org Mon Jul 29 09:46:33 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 09:46:33 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: <_w42tJFIEMhIb6CG8kh038VdU-bQYRjcOemqM31B7hk=.1b78089c-6c9b-4bbe-82b7-501c5bf95784@github.com> On Fri, 26 Jul 2024 15:59:15 GMT, Vicente Romero wrote: > not sure that this is semantically the same as before Yeah, this is a bit tricky. Basically, the issue with type annotations is that they are encoded in different places depending on the case. E.g. a local variable inside a static/instance initializer has the type annotation recorded in the _class symbol_ (!!). There's also different methods to fetch type annotations, depending on whether it was a normal type annotation, or one in a static/instance initializer. The general idea is that we try to figure out the symbol that "owns" the type annotation while visiting, and then move all lambda annotations from that owner onto the new lambda method symbol. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1694924545 From mcimadamore at openjdk.org Mon Jul 29 10:01:32 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 10:01:32 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Mon, 29 Jul 2024 09:40:09 GMT, Maurizio Cimadamore wrote: > > Some initial testing shows a regression in type annotation handling with this change. > > Thanks, I'll take a look Ugh. This is quite ugly. The type annotation is seen, and correctly moved by `LambdaToMethod`. Unfortunately, the annotation seems to be added in _two_ places: in the local variable, and then in the synthetic constructor of `T`. We move the former, but not the latter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2255505164 From mcimadamore at openjdk.org Mon Jul 29 12:35:55 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 12:35:55 GMT Subject: RFR: 8336492: Regression in lambda serialization [v4] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Simplify and consolidate code to keep track of lambda owners ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/17bee2c7..4f789ae5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=02-03 Stats: 116 lines in 6 files changed: 30 ins; 53 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Mon Jul 29 12:40:36 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 12:40:36 GMT Subject: RFR: 8336492: Regression in lambda serialization [v4] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Mon, 29 Jul 2024 12:35:55 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and consolidate code to keep track of lambda owners After trying different approaches, I realized that the cleanest (by far) solution is to simply capture the lambda owner symbol during `Attr`, instead of trying to reconstruct this owner using various (wrong) heuristics. When doing this, I realized that there were several issues which predated my refactoring - that is, the logic in `TypeAnnotations` relies on the `BLOCK` flag to be set on static/instance initializer owner method symbols - but sometimes this flag was missing (this is now fixed). Also, the `EnclosingMethodAttribute` sometimes reported `` being the method owner of a local class. This is deliberately against the JVMS, which state: > In particular, method_index must be zero if the current class was immediately enclosed in source code by an instance initializer, static initializer, instance variable initializer, or class variable initializer. (The first two concern both local classes and anonymous classes, while the last two concern anonymous classes declared on the right hand side of a field assignment.) We even had a test which enforced the *wrong* behavior (!!). Last, the static/instance initializer symbol used to have a `null` type. This is now fixed, as we can always rely on the `BLOCK` flag instead (which is, again, cleaner). As a result, `CaptureSiteInfo` is now gone. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2255821369 From mcimadamore at openjdk.org Mon Jul 29 13:21:35 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 13:21:35 GMT Subject: RFR: 8336492: Regression in lambda serialization [v4] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: <48tAP685fNLA3ZxUi5Sf48jra7SBNEupo6ZKHr0JemA=.39f30679-d321-43b5-8aac-ecd82e69af2f@github.com> On Mon, 29 Jul 2024 12:35:55 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and consolidate code to keep track of lambda owners src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1425: > 1423: Symbol fakeOwner = > 1424: new MethodSymbol(tree.flags | BLOCK | > 1425: env.info.scope.owner.flags() & STRICTFP, names.empty, fakeOwnerType, the type was left null here, which caused some crashes in `LambdaToMethod`. There was really no reason for this to be null, except that `ClassWriter` looks at type being null as a test to see if owner is a static/instance init block. But we can use `BLOCK` for that (as `TypeAnnotations` does) src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 3576: > 3574: Type clinitType = new MethodType(List.nil(), > 3575: syms.voidType, List.nil(), syms.methodClass); > 3576: clinit = new MethodSymbol(BLOCK | STATIC | SYNTHETIC | PRIVATE, Added missing `BLOCK`, so that we're now consistent with what the rest of the code (not only `LambdaToMethod`) expects. src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 332: > 330: ClassSymbol enclClass = c.owner.enclClass(); > 331: MethodSymbol enclMethod = > 332: ((c.owner.flags() & BLOCK) != 0 // local to init block new test, which looks at the `BLOCK` flag ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695218946 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695220032 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695221145 From cpovirk at google.com Mon Jul 29 14:08:29 2024 From: cpovirk at google.com (Chris Povirk) Date: Mon, 29 Jul 2024 10:08:29 -0400 Subject: Redo of backport of JDK-8225377 (type annotations are not visible to javac plugins across compilation boundaries) In-Reply-To: References: Message-ID: Manu spoke about the ability to annotate different positions (e.g., type-parameter bounds) for improved nullness checking. I'd also call out that this affects even users who use nullness annotations on "basic" locations like fields, parameters, and return types: Unless tools use internal javac APIs, type-use annotations in even these basic locations in class files are invisible until JDK 22. (And as Josiah points out, this affects more tools than just "nullness checkers." We've also seen it with AutoValue .) This means that type-use annotations are worse than declaration annotations in some ways, even as they're better in others. As a result, users can't confidently pick even a set of nullness annotations without evaluating the tradeoffs. It would be great to be able to tell users "Use type-use annotations" without waiting for them all to update to JDK 22. Plus: Even if the fix is backported today, experience shows that users will also have to wait for some annotation processors to be enhanced to start looking for type-use annotations _at all_. I'd be happy to see us continue to drive that positive feedback loop: As type-use annotations become more visible to annotation processors, tools increasingly get modified to recognize them, leading to more adoption of type-use annotations and more opportunity to identify and iron out remaining wrinkles. Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Mon Jul 29 14:31:18 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 14:31:18 GMT Subject: RFR: 8336492: Regression in lambda serialization [v5] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Remove commented code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/4f789ae5..f98f6225 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=03-04 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Mon Jul 29 14:31:18 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 14:31:18 GMT Subject: RFR: 8336492: Regression in lambda serialization [v5] In-Reply-To: <_w42tJFIEMhIb6CG8kh038VdU-bQYRjcOemqM31B7hk=.1b78089c-6c9b-4bbe-82b7-501c5bf95784@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> <_w42tJFIEMhIb6CG8kh038VdU-bQYRjcOemqM31B7hk=.1b78089c-6c9b-4bbe-82b7-501c5bf95784@github.com> Message-ID: On Mon, 29 Jul 2024 09:43:49 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 405: >> >>> 403: >>> 404: apportionTypeAnnotations(tree, >>> 405: owner::getInitTypeAttributes, >> >> not sure that this is semantically the same as before > >> not sure that this is semantically the same as before > > Yeah, this is a bit tricky. Basically, the issue with type annotations is that they are encoded in different places depending on the case. E.g. a local variable inside a static/instance initializer has the type annotation recorded in the _class symbol_ (!!). There's also different methods to fetch type annotations, depending on whether it was a normal type annotation, or one in a static/instance initializer. > > The general idea is that we try to figure out the symbol that "owns" the type annotation while visiting, and then move all lambda annotations from that owner onto the new lambda method symbol. Should be better after [this push](https://github.com/openjdk/jdk/pull/20349/commits/29910e6c0bae0b75e386169e114a4849ed931436) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695337011 From mcimadamore at openjdk.org Mon Jul 29 14:41:34 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 14:41:34 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 18:31:52 GMT, Vicente Romero wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more docs to CaptureScanner, and make fields private/final > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1344: > >> 1342: CAPTURED_VAR; // variables in enclosing scope to translated synthetic parameters >> 1343: >> 1344: boolean propagateAnnotations() { > > suggestion: there is only one use of this method and the method can be rewritten with a ternary operator and probably inlined in its only client Addressed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695357466 From mcimadamore at openjdk.org Mon Jul 29 15:01:16 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 15:01:16 GMT Subject: RFR: 8336492: Regression in lambda serialization [v6] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Simplify translation contexts - Address review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/f98f6225..fcbbfeb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=04-05 Stats: 46 lines in 1 file changed: 3 ins; 22 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Mon Jul 29 15:01:17 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 15:01:17 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 18:59:29 GMT, Vicente Romero wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more docs to CaptureScanner, and make fields private/final > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1327: > >> 1325: * Simple subclass modelling the translation context of a method reference. >> 1326: */ >> 1327: final class ReferenceTranslationContext extends TranslationContext { > > minor, we can probably remove this class it is not adding any behavior Addressed [here](https://github.com/openjdk/jdk/pull/20349/commits/fcbbfeb111f0894f706af6c82187f3192ba3b327) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695388323 From vromero at openjdk.org Mon Jul 29 15:21:34 2024 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 29 Jul 2024 15:21:34 GMT Subject: RFR: 8336492: Regression in lambda serialization [v5] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Mon, 29 Jul 2024 14:31:18 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Remove commented code src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1422: > 1420: // let the owner of the environment be a freshly > 1421: // created BLOCK-method. > 1422: Type fakeOwnerType = new MethodType(List.nil(), syms.voidType, List.nil(), syms.methodClass); could this type be shared across all fake owner symbols? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CaptureScanner.java line 60: > 58: * without any duplicates. > 59: */ > 60: private final ListBuffer fvs = new ListBuffer<>(); should this be a set? LinkedHashSet? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695370350 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695371824 From vromero at openjdk.org Mon Jul 29 16:12:34 2024 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 29 Jul 2024 16:12:34 GMT Subject: RFR: 8336492: Regression in lambda serialization [v6] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Mon, 29 Jul 2024 15:01:16 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Simplify translation contexts > - Address review comment src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 347: > 345: public void visitLambda(JCLambda tree) { > 346: LambdaTranslationContext localContext = new LambdaTranslationContext(tree); > 347: if (dumpLambdaToMethodStats) { probably in a follow-up fix, but I don't see too much value on keeping / growing this stats code. This seems to belong in a regression test that probably uses a plugin or similar to get some stats while compiling lambdas / mrefs ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695500553 From vromero at openjdk.org Mon Jul 29 16:19:34 2024 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 29 Jul 2024 16:19:34 GMT Subject: RFR: 8336492: Regression in lambda serialization [v6] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Mon, 29 Jul 2024 15:01:16 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Simplify translation contexts > - Address review comment src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1188: > 1186: break; > 1187: case LOCAL_VAR: > 1188: ret = new VarSymbol(sym.flags() & FINAL, sym.name, sym.type, translatedSym); shouldn't this symbol be synthetic too? same for the param below ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695509264 From mcimadamore at openjdk.org Mon Jul 29 16:56:14 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 16:56:14 GMT Subject: RFR: 8336492: Regression in lambda serialization [v7] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Make lambda symbol kind enum completely private to lambda translation context class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/fcbbfeb1..6aacccde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=05-06 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Mon Jul 29 16:56:14 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 16:56:14 GMT Subject: RFR: 8336492: Regression in lambda serialization [v6] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Mon, 29 Jul 2024 16:09:53 GMT, Vicente Romero wrote: >> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: >> >> - Simplify translation contexts >> - Address review comment > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 347: > >> 345: public void visitLambda(JCLambda tree) { >> 346: LambdaTranslationContext localContext = new LambdaTranslationContext(tree); >> 347: if (dumpLambdaToMethodStats) { > > probably in a follow-up fix, but I don't see too much value on keeping / growing this stats code. This seems to belong in a regression test that probably uses a plugin or similar to get some stats while compiling lambdas / mrefs Actually... in an attempt to remove the translation context classes (and just keep the lambda translation context class - after all method references don't need much there), I stumbled upon a bad test failure in the lambda deduplication test. This test depends on the compiler generating the stat diagnostics for every encountered lambda... maybe we can drop that dependency and the stats, but probably better to do it elsewhere. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1188: > >> 1186: break; >> 1187: case LOCAL_VAR: >> 1188: ret = new VarSymbol(sym.flags() & FINAL, sym.name, sym.type, translatedSym); > > shouldn't this symbol be synthetic too? same for the param below I suppose local variables and parameters come from "real" symbols in the source code. We could probably do either way, but for now I preferred not to touch this stuff ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695554139 PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695551862 From mcimadamore at openjdk.org Mon Jul 29 17:03:33 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 17:03:33 GMT Subject: RFR: 8336492: Regression in lambda serialization [v5] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Mon, 29 Jul 2024 14:47:59 GMT, Vicente Romero wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove commented code > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CaptureScanner.java line 60: > >> 58: * without any duplicates. >> 59: */ >> 60: private final ListBuffer fvs = new ListBuffer<>(); > > should this be a set? LinkedHashSet? note that we use `prepend` to add symbols (which is what the old code used). So, we *could* change to something else, but w/o prepending, we'd create even more ordering issues. Maybe investigate separately? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695565688 From mcimadamore at openjdk.org Mon Jul 29 17:06:33 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 17:06:33 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Fri, 26 Jul 2024 21:59:26 GMT, Vicente Romero wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more docs to CaptureScanner, and make fields private/final > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 338: > >> 336: @Override >> 337: public void visitClassDef(JCClassDecl tree) { >> 338: KlassInfo prevKlassInfo = kInfo; > > future improvement? we have class info, lambda context, capture site info, should we probably gather them all in an environment like structure? yes and no. First, note that capture site info is gone. As for lambda context and klass info, we use them in different ways: the lambda context is set when we're in a lambda. The klass info is set when we are inside a klass. We create many lambda contexts for each klass info. We could of course move the lambda context field from the visitor to klass info, but I'm not sure how much that buys. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695570111 From martin.desruisseaux at geomatys.com Mon Jul 29 17:06:10 2024 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Mon, 29 Jul 2024 19:06:10 +0200 Subject: StandardLocation.PATCH_MODULE_PATH unsupported by javax.tools.JavaCompiler? Message-ID: Hello I'm rewriting the Maven compiler plugin for better support of Java Module System with Maven 4 [1]. This work removes completely the Plexus compiler API and uses directly the `javax.tools.JavaCompiler` interface instead. It works well, but I'm having an issue with the `--patch-module` option (for compiling the tests of modular projects). My understanding is that the modules to patch should be specified by a code like below: JavaCompiler compiler = ...; try (StandardJavaFileManager fm = getStandardFileManager(...)) { String module = ...; List testSources = List.of(...); // A single directory fm.setLocationForModule(StandardLocation.PATCH_MODULE_PATH, module, testSources); } However, it results in an UnsupportedOperationException thrown by `com.sun.tools.javac.file.Locations.PatchModulesLocationHandler`. The source code is as below: @Override // defined by LocationHandler void setPathsForModule(String moduleName, Iterable files) throws IOException { throw new UnsupportedOperationException(); // not yet } The "not yet" comment gives the impression that this method is intended to be implemented, is that right? A workaround is to put `--patch-module` in the options passed as the `options` argument in the call to `JavaCompiler.getTask(...)`. But a call to `compiler.isSupportedOption("--patch-module")` returns -1, meaning that it should not be allowed. I noticed that if I ignore this information and put a `--patch-module` option anyway, it works. But isn't it a violation of JavaCompiler API contract? The Javadoc said that it should throw IllegalArgumentException if any option is invalid. Thanks, ??? Martin [1]https://github.com/Geomatys/maven-compiler-plugin/wiki -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Mon Jul 29 17:10:38 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 17:10:38 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: <5iMirOzZRUnkUuk6XYo0orFNAnAVc9A1VICZQjmiHUY=.501ae945-6e2f-48bc-a3a1-764daf301195@github.com> On Fri, 26 Jul 2024 20:50:53 GMT, Vicente Romero wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more docs to CaptureScanner, and make fields private/final > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1239: > >> 1237: ret.pos = sym.pos; >> 1238: // Set ret.data. Same as case LOCAL_VAR above. >> 1239: if (sym.isExceptionParameter()) { > > not a change from your patch but, do we really need to set this exception parameter thing for a method param? Also this could be a TypeMetadata. Also, there is no test affected if this `if` with its block is removed so either unnecessary, me thinks, or we need more tests I'm not 100% sure, but eyeballing the code, I see that `sym.isExceptionParameter` is used in the backend (e.g. `Code`) so I'd suspect that a failure in doing this would lead to issues when generating bytecode, which I suspect is why this code was added in the first place. But, while that seems useful for a local variable declared inside a lambda, I don't see how a lambda parameter can itself be an exception parameter... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695575651 From mcimadamore at openjdk.org Mon Jul 29 17:31:50 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 17:31:50 GMT Subject: RFR: 8336492: Regression in lambda serialization [v8] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address more review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/6aacccde..c1c33eb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=06-07 Stats: 8 lines in 2 files changed: 2 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Mon Jul 29 17:49:11 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 17:49:11 GMT Subject: RFR: 8336492: Regression in lambda serialization [v9] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Drop caching of clinit fake symbols in Attr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/c1c33eb1..5d9449ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=07-08 Stats: 26 lines in 1 file changed: 0 ins; 18 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Mon Jul 29 18:22:12 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 18:22:12 GMT Subject: RFR: 8336492: Regression in lambda serialization [v10] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix more cases where EnclosingMethodAttribute is wrong for lambdas declared in instance field inits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/5d9449ed..0fef88e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=08-09 Stats: 33 lines in 2 files changed: 2 ins; 23 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Mon Jul 29 18:26:37 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 29 Jul 2024 18:26:37 GMT Subject: RFR: 8336492: Regression in lambda serialization [v10] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: <0zvb4IX8t1MqbO4Gv3lpytgOqKgLI2t1NePV7sOCS8o=.dec9fc76-cc33-4f4a-889e-7e2eb6a3291a@github.com> On Mon, 29 Jul 2024 18:22:12 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix more cases where EnclosingMethodAttribute is wrong for lambdas declared in instance field inits > After trying different approaches, I realized that the cleanest (by far) solution is to simply capture the lambda owner symbol during `Attr`, instead of trying to reconstruct this owner using various (wrong) heuristics. When doing this, I realized that there were several issues which predated my refactoring - that is, the logic in `TypeAnnotations` relies on the `BLOCK` flag to be set on static/instance initializer owner method symbols - but sometimes this flag was missing (this is now fixed). Also, the `EnclosingMethodAttribute` sometimes reported `` being the method owner of a local class. This is deliberately against the JVMS, which state: > > > In particular, method_index must be zero if the current class was immediately enclosed in source code by an instance initializer, static initializer, instance variable initializer, or class variable initializer. (The first two concern both local classes and anonymous classes, while the last two concern anonymous classes declared on the right hand side of a field assignment.) > > We even had a test which enforced the _wrong_ behavior (!!). > > Last, the static/instance initializer symbol used to have a `null` type. This is now fixed, as we can always rely on the `BLOCK` flag instead (which is, again, cleaner). > > As a result, `CaptureSiteInfo` is now gone. I've ended up rewriting a biggie chunk in `Attr::lambdaEnv` as that seemed out of sync with what the rest of the compiler did (and also found other instances where `EnclosingMethod` contained a method index for lambdas **not** declared inside constructors) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2256619954 From vromero at openjdk.org Mon Jul 29 20:50:33 2024 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 29 Jul 2024 20:50:33 GMT Subject: RFR: 8336492: Regression in lambda serialization [v10] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Mon, 29 Jul 2024 18:22:12 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix more cases where EnclosingMethodAttribute is wrong for lambdas declared in instance field inits src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 831: > 829: > 830: private MethodType typeToMethodType(Type mt) { > 831: Type type = types.erasure(mt); nit: not part of your patch but I think that `mt` should already be erased at this point, now that Lower is running before L2M ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1695887367 From vromero at openjdk.org Mon Jul 29 21:18:39 2024 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 29 Jul 2024 21:18:39 GMT Subject: RFR: 8336492: Regression in lambda serialization [v10] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: <23U1MrhH9QHi1YHlVyBU8Cnw4O1zG1ocM5XdPnjpt6s=.6a2932c4-be8b-4d0e-a18a-b00074c3f9c4@github.com> On Mon, 29 Jul 2024 18:22:12 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix more cases where EnclosingMethodAttribute is wrong for lambdas declared in instance field inits looks good, great fix! ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20349#pullrequestreview-2206109496 From liach at openjdk.org Mon Jul 29 23:30:48 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 23:30:48 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments [v2] In-Reply-To: References: Message-ID: <54Vm9cESCel67_6T83MfcPkoQVYP-_evYbeBQAL9YDI=.2eb7457e-2dfd-4900-a15c-f3d6ca3e4775@github.com> > Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. > > `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. > > However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. > > As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. > > This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Reapply import changes after merge - Merge branch 'master' of https://github.com/openjdk/jdk into fix/accessflags-factory - 8337219: AccessFlags factories do not require necessary arguments ------------- Changes: https://git.openjdk.org/jdk/pull/20341/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20341&range=01 Stats: 211 lines in 21 files changed: 71 ins; 80 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/20341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20341/head:pull/20341 PR: https://git.openjdk.org/jdk/pull/20341 From liach at openjdk.org Mon Jul 29 23:30:48 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 23:30:48 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments In-Reply-To: References: Message-ID: <93I9hQSJh0LGonXvDVhgohzf2ydmej2gWzDuixkHoKw=.4363b0f1-1c17-4188-97eb-6e95fe5c7af0@github.com> On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote: > Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. > > `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. > > However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. > > As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. > > This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. Fixed the merge conflict in BuilderBlockTest due to import reordering. Please re-review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20341#issuecomment-2257177179 From mcimadamore at openjdk.org Tue Jul 30 08:27:39 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 30 Jul 2024 08:27:39 GMT Subject: RFR: 8336492: Regression in lambda serialization [v10] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Mon, 29 Jul 2024 20:47:38 GMT, Vicente Romero wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix more cases where EnclosingMethodAttribute is wrong for lambdas declared in instance field inits > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 831: > >> 829: >> 830: private MethodType typeToMethodType(Type mt) { >> 831: Type type = types.erasure(mt); > > nit: not part of your patch but I think that `mt` should already be erased at this point, now that Lower is running before L2M I don't think so - I see it used here: MethodSymbol samSym = (MethodSymbol) types.findDescriptorSymbol(tree.target.tsym); List staticArgs = List.of( typeToMethodType(samSym.type), refSym.asHandle(), typeToMethodType(tree.getDescriptorType(types))); I think neither `samSym.type` nor the result of `tree::getDescriptorType` (which is based on `tree.target`) are erased. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1696544601 From asotona at openjdk.org Tue Jul 30 08:37:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 30 Jul 2024 08:37:32 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments [v2] In-Reply-To: <54Vm9cESCel67_6T83MfcPkoQVYP-_evYbeBQAL9YDI=.2eb7457e-2dfd-4900-a15c-f3d6ca3e4775@github.com> References: <54Vm9cESCel67_6T83MfcPkoQVYP-_evYbeBQAL9YDI=.2eb7457e-2dfd-4900-a15c-f3d6ca3e4775@github.com> Message-ID: On Mon, 29 Jul 2024 23:30:48 GMT, Chen Liang wrote: >> Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. >> >> `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. >> >> However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. >> >> As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. >> >> This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Reapply import changes after merge > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/accessflags-factory > - 8337219: AccessFlags factories do not require necessary arguments Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20341#pullrequestreview-2207034646 From vromero at openjdk.org Tue Jul 30 12:10:39 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 30 Jul 2024 12:10:39 GMT Subject: RFR: 8336492: Regression in lambda serialization [v10] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: <52_3Q7L2kLZT1AesT_FD6Y7pu8E4EJF_pvUleKzVW78=.2e6314ba-4997-44b4-bb68-605e2acda24c@github.com> On Tue, 30 Jul 2024 08:24:56 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 831: >> >>> 829: >>> 830: private MethodType typeToMethodType(Type mt) { >>> 831: Type type = types.erasure(mt); >> >> nit: not part of your patch but I think that `mt` should already be erased at this point, now that Lower is running before L2M > > I don't think so - I see it used here: > > > MethodSymbol samSym = (MethodSymbol) types.findDescriptorSymbol(tree.target.tsym); > List staticArgs = List.of( > typeToMethodType(samSym.type), > refSym.asHandle(), > typeToMethodType(tree.getDescriptorType(types))); > > > I think neither `samSym.type` nor the result of `tree::getDescriptorType` (which is based on `tree.target`) are erased. ok sounds good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1696851526 From mcimadamore at openjdk.org Tue Jul 30 13:25:03 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 30 Jul 2024 13:25:03 GMT Subject: RFR: 8336492: Regression in lambda serialization [v11] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: <_FtbRg24JIwwxqDmm43ZYLIo1ChswlQ3MEinVYJ3yTs=.0627b4b4-9945-4c77-965a-ac82ffc971a6@github.com> > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Drop TranslationContext ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/0fef88e5..6a5501fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=09-10 Stats: 88 lines in 1 file changed: 16 ins; 32 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Tue Jul 30 13:25:03 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 30 Jul 2024 13:25:03 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Sat, 27 Jul 2024 18:42:13 GMT, Liam Miller-Cushon wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more docs to CaptureScanner, and make fields private/final > > Some initial testing shows a regression in type annotation handling with this change. > > Given an example like the following, the type annotation in the lambda is now being incorrectly propagated to the constructor. A `RuntimeInvisibleTypeAnnotations` attribute for the annotation is emitted on both the synthetic lambda method and the constructor. I noticed this because the `length` for the `RuntimeInvisibleTypeAnnotations` is longer than the constructor, and both ASM and javap report an error for the class file. > > > import java.lang.annotation.ElementType; > import java.lang.annotation.Target; > import java.util.ArrayList; > import java.util.List; > > class T { > @Target(ElementType.TYPE_USE) > @interface A {} > > Runnable r = > () -> { > List<@A Object> xs = new ArrayList<>(); > xs.add(1); > xs.add(2); > xs.add(3); > xs.add(5); > xs.add(6); > xs.add(7); > xs.add(8); > }; > > T() {} > } > > > javap reports an error because the type annotation's length is longer than the constructor: > > > $ javap -c T > Compiled from "T.java" > class T { > java.lang.Runnable r; > > T(); > Code: > Error: error at or after byte 0 > Error: Fatal error: Bytecode offset out of range; bci=89, codeLength=14 > > > Using the JDK 11 javap shows > > > T(); > descriptor: ()V > flags: (0x0000) > Code: > stack=2, locals=1, args_size=1 > 0: aload_0 > 1: invokespecial #1 // Method java/lang/Object."":()V > 4: aload_0 > 5: invokedynamic #7, 0 // InvokeDynamic #0:run:()Ljava/lang/Runnable; > 10: putfield #11 // Field r:Ljava/lang/Runnable; > 13: return > LineNumberTable: > line 22: 0 > line 10: 4 > line 22: 13 > RuntimeInvisibleTypeAnnotations: > 0: #35(): LOCAL_VARIABLE, {start_pc=8, length=81, index=0}, location=[TYPE_ARGUMENT(0)] > T$A Found a way to simplify the code some more by dropping the `TranslationContext` superclass and keep the `DeduplicationTest` happy. This should be the last cleanup. @cushon things look stable on our end, maybe you want to give this PR another try? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2258338993 From mcimadamore at openjdk.org Tue Jul 30 14:55:55 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 30 Jul 2024 14:55:55 GMT Subject: RFR: 8336492: Regression in lambda serialization [v12] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Minory style cleanup to get rid of IDE warnings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/6a5501fa..da70a4a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=10-11 Stats: 57 lines in 1 file changed: 2 ins; 24 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From cushon at openjdk.org Tue Jul 30 16:20:33 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 30 Jul 2024 16:20:33 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Sat, 27 Jul 2024 18:42:13 GMT, Liam Miller-Cushon wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more docs to CaptureScanner, and make fields private/final > > Some initial testing shows a regression in type annotation handling with this change. > > Given an example like the following, the type annotation in the lambda is now being incorrectly propagated to the constructor. A `RuntimeInvisibleTypeAnnotations` attribute for the annotation is emitted on both the synthetic lambda method and the constructor. I noticed this because the `length` for the `RuntimeInvisibleTypeAnnotations` is longer than the constructor, and both ASM and javap report an error for the class file. > > > import java.lang.annotation.ElementType; > import java.lang.annotation.Target; > import java.util.ArrayList; > import java.util.List; > > class T { > @Target(ElementType.TYPE_USE) > @interface A {} > > Runnable r = > () -> { > List<@A Object> xs = new ArrayList<>(); > xs.add(1); > xs.add(2); > xs.add(3); > xs.add(5); > xs.add(6); > xs.add(7); > xs.add(8); > }; > > T() {} > } > > > javap reports an error because the type annotation's length is longer than the constructor: > > > $ javap -c T > Compiled from "T.java" > class T { > java.lang.Runnable r; > > T(); > Code: > Error: error at or after byte 0 > Error: Fatal error: Bytecode offset out of range; bci=89, codeLength=14 > > > Using the JDK 11 javap shows > > > T(); > descriptor: ()V > flags: (0x0000) > Code: > stack=2, locals=1, args_size=1 > 0: aload_0 > 1: invokespecial #1 // Method java/lang/Object."":()V > 4: aload_0 > 5: invokedynamic #7, 0 // InvokeDynamic #0:run:()Ljava/lang/Runnable; > 10: putfield #11 // Field r:Ljava/lang/Runnable; > 13: return > LineNumberTable: > line 22: 0 > line 10: 4 > line 22: 13 > RuntimeInvisibleTypeAnnotations: > 0: #35(): LOCAL_VARIABLE, {start_pc=8, length=81, index=0}, location=[TYPE_ARGUMENT(0)] > T$A > @cushon things look stable on our end, maybe you want to give this PR another try? I will verify with the latest changes, but I have preliminary results from testing before https://github.com/openjdk/jdk/pull/20349/commits/6a5501fa83aef2ee455e7c965a1ebc74d36b97ec. There were no unexpected regressions, and some minor expected compatibility impact: * A number of tests are asserting on names of synthetic lambda methods that have changed (e.g. `assertThat(Throwables.getStackTraceAsString(...)).contains("foo$0");`) * I found a single test that was reading in persisted serialized data which no longer deserialized, and had to be updated to match the new output I also removed the workarounds I'd added for JDK-8336492 and confirmed that they are unnecessary after these changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2258727944 From mcimadamore at openjdk.org Tue Jul 30 16:27:33 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 30 Jul 2024 16:27:33 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Tue, 30 Jul 2024 16:17:43 GMT, Liam Miller-Cushon wrote: > * A number of tests are asserting on names of synthetic lambda methods that have changed (e.g. `assertThat(Throwables.getStackTraceAsString(...)).contains("foo$0");`) > > * I found a single test that was reading in persisted serialized data which no longer deserialized, and had to be updated to match the new output Thanks. I suppose we have a good starting point then. If this proves to be too much incompatibility we could also try to fixup the logic later so that the generated names are more similar to the ones we had. It would be interesting if you could share some details about the deserialization failure: a redundant `this$0` in the serialized stream should be handles (serialization allows to ignore and reorder fields). Was there a name incompatibility in the captures? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2258741662 From cushon at openjdk.org Tue Jul 30 17:21:33 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 30 Jul 2024 17:21:33 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Tue, 30 Jul 2024 16:25:17 GMT, Maurizio Cimadamore wrote: > It would be interesting if you could share some details about the deserialization failure: a redundant `this$0` in the serialized stream should be handles (serialization allows to ignore and reorder fields). Was there a name incompatibility in the captures? I investigated, it looks like the order of a captured local and parameter is now reversed in the signature: import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; import java.nio.file.Files; import java.nio.file.Path; public class X { public static void main(String[] args) throws Exception { final Path path = Path.of(args[1]); switch (args[0]) { case "write" -> write(path, "hello"); case "read" -> read(path); } } static void write(Path path, String s) throws Exception { int x = 42; Runnable r = (Runnable & Serializable) () -> { System.err.println(s + x); }; try (ObjectOutputStream oos = new ObjectOutputStream(Files.newOutputStream(path))) { oos.writeObject(r); } } static void read(Path path) throws Exception { Runnable r; try (ObjectInputStream ois = new ObjectInputStream(Files.newInputStream(path))) { r = (Runnable) ois.readObject(); } r.run(); } } $BASELINE/bin/javac --release 22 X.java && $BASELINE/bin/java X write o && $EXPERIMENT/bin/javac --release 22 X.java && $EXPERIMENT/bin/java X read o ... Exception in thread "main" java.io.InvalidObjectException: ReflectiveOperationException during deserialization at java.base/java.lang.invoke.SerializedLambda.readResolve(SerializedLambda.java:280) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at java.base/java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1198) at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2278) at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1747) at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:525) at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:483) at X.read(X.java:31) at X.main(X.java:12) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at java.base/java.lang.invoke.SerializedLambda.readResolve(SerializedLambda.java:278) ... 9 more Caused by: java.lang.IllegalArgumentException: Invalid lambda deserialization at X.$deserializeLambda$(X.java:7) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ... 11 more Comparing the output shows: 494,495c494,495 < private static void lambda$write$e26d8c1c$1(java.lang.String, int); < descriptor: (Ljava/lang/String;I)V --- > private static void lambda$write$b96aa0a6$1(int, java.lang.String); > descriptor: (ILjava/lang/String;)V ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2258840088 From vromero at openjdk.org Tue Jul 30 17:37:33 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 30 Jul 2024 17:37:33 GMT Subject: RFR: 8336492: Regression in lambda serialization [v12] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Tue, 30 Jul 2024 14:55:55 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Minory style cleanup to get rid of IDE warnings latest changes looks good too ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20349#pullrequestreview-2208295487 From liach at openjdk.org Tue Jul 30 17:44:34 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 30 Jul 2024 17:44:34 GMT Subject: Integrated: 8337219: AccessFlags factories do not require necessary arguments In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote: > Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. > > `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. > > However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. > > As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. > > This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. This pull request has now been integrated. Changeset: 93c19ac7 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/93c19ac73c2feb8d6191bc5da98b4a9c8e2b5590 Stats: 211 lines in 21 files changed: 71 ins; 80 del; 60 mod 8337219: AccessFlags factories do not require necessary arguments Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20341 From jjg at openjdk.org Tue Jul 30 17:53:33 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 30 Jul 2024 17:53:33 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v4] In-Reply-To: References: Message-ID: <374QOKpMLd_bULmqz6Cx6D_aqD90uE_eSIV5jD7XDhs=.f78d4745-2291-4102-a01b-cddb4c61f901@github.com> On Fri, 26 Jul 2024 10:52:22 GMT, Hannes Walln?fer wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup use of HtmlStyle and HtmlStyles > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlTag.java line 87: > >> 85: attrs(AttrKind.HTML4, CLEAR)), >> 86: >> 87: BUTTON(BlockType.OTHER, EndKind.REQUIRED, > > Several tag constants that use `BlockType.OTHER` in this enum are defined as [Phrasing Content](https://html.spec.whatwg.org/#phrasing-content) in the HTML5 spec. Since HTML5 phrasing content roughly corresponds to pre-HTML5 inline content these tags should use `BlockType.INLINE` here. This includes the following tags: > > - BUTTON > - INPUT > - LABEL > - LINK > - SCRIPT > > These tags were also flagged as `phrasingContent` in the old doclet `TagName` enum. I'm not sure whether marking it as `INLINE` content will break DocLint tests. > > It would seem like a good idea to suggest using [HTML5 content categories](https://developer.mozilla.org/en-US/docs/Web/HTML/Content_categories) in the new merged code, but the new categories are more complex and overlapping, and don't include list and table content, so there is not a lot to gain besides maybe more up-to-date terminology. I'll look to upgrade these. In the original impl of DocLint, it was something of a conscious decision to avoid supporting input elements. I'm surprised LINK is phrasing content: I thought it could only appear in HEAD elements. I will check. Generally, moving towards HTML 5 names is a good goal, but some of that could/should be part of a DocLint cleanup. This is primarily just a merge, not an upgrade. And, while DocLint is intended to be helpful, it is specifically for doc comments and their likely content, and not a full conformance checker. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1697355146 From mcimadamore at openjdk.org Tue Jul 30 17:58:33 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 30 Jul 2024 17:58:33 GMT Subject: RFR: 8336492: Regression in lambda serialization [v3] In-Reply-To: References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: On Tue, 30 Jul 2024 17:19:06 GMT, Liam Miller-Cushon wrote: > I investigated, it looks like the order of a captured local and parameter is now reversed in the signature: I see - since the serialized form of a lambda also includes a signature string, we fail to deserialize if the signature string cannot be parsed to a `MethodType` that is consistent with the type of the generated lambda method. Also, since the order of captures is different, the serialized lambda name is also different. The order of captures has changed because `CaptureScanner`. Now, if I compile this program using Java 22: class Test { void m(String s, int i) { new Object() { void g() { System.out.println(s + i); } }; } Runnable r(String s, int i) { return () -> System.out.println(s + i); } } I see that the order of capture is the same in both the anon class constructor and the lambda: private static void lambda$r$0(java.lang.String, int); ... Test$1(Test, java.lang.String, int); But with this patch they are not: private static void lambda$r$0(int, java.lang.String); ... Test$1(Test, java.lang.String, int); The peculiarity (which I missed) is that `Lower` gets the set of freevars, and then always _prepend_ their definition to the class/constructor. `LambdaToMethod`, OTOH, _appends_ them. This is what's causing the mismatched order. I'll fix this, as I think the old order looked better than the new one (as each captured variable appear in "order of capture"). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2258900256 From jjg at openjdk.org Tue Jul 30 18:02:06 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 30 Jul 2024 18:02:06 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v5] In-Reply-To: References: Message-ID: > Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. > > Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. > > There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. > > A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. > > There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Fix missing legal headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19916/files - new: https://git.openjdk.org/jdk/pull/19916/files/4d210ce9..c3c26d62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=03-04 Stats: 50 lines in 2 files changed: 50 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19916.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19916/head:pull/19916 PR: https://git.openjdk.org/jdk/pull/19916 From jjg at openjdk.org Tue Jul 30 18:05:35 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 30 Jul 2024 18:05:35 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v4] In-Reply-To: <374QOKpMLd_bULmqz6Cx6D_aqD90uE_eSIV5jD7XDhs=.f78d4745-2291-4102-a01b-cddb4c61f901@github.com> References: <374QOKpMLd_bULmqz6Cx6D_aqD90uE_eSIV5jD7XDhs=.f78d4745-2291-4102-a01b-cddb4c61f901@github.com> Message-ID: <_QbxjpoM8zV1N9dYo4Acg2Zj35lFnnErCCpm8a3vogw=.576d8114-5cc6-48ec-9dba-50ee0da3d708@github.com> On Tue, 30 Jul 2024 17:50:43 GMT, Jonathan Gibbons wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlTag.java line 87: >> >>> 85: attrs(AttrKind.HTML4, CLEAR)), >>> 86: >>> 87: BUTTON(BlockType.OTHER, EndKind.REQUIRED, >> >> Several tag constants that use `BlockType.OTHER` in this enum are defined as [Phrasing Content](https://html.spec.whatwg.org/#phrasing-content) in the HTML5 spec. Since HTML5 phrasing content roughly corresponds to pre-HTML5 inline content these tags should use `BlockType.INLINE` here. This includes the following tags: >> >> - BUTTON >> - INPUT >> - LABEL >> - LINK >> - SCRIPT >> >> These tags were also flagged as `phrasingContent` in the old doclet `TagName` enum. I'm not sure whether marking it as `INLINE` content will break DocLint tests. >> >> It would seem like a good idea to suggest using [HTML5 content categories](https://developer.mozilla.org/en-US/docs/Web/HTML/Content_categories) in the new merged code, but the new categories are more complex and overlapping, and don't include list and table content, so there is not a lot to gain besides maybe more up-to-date terminology. > > I'll look to upgrade these. In the original impl of DocLint, it was something of a conscious decision to avoid supporting input elements. > > I'm surprised LINK is phrasing content: I thought it could only appear in HEAD elements. I will check. > > Generally, moving towards HTML 5 names is a good goal, but some of that could/should be part of a DocLint cleanup. This is primarily just a merge, not an upgrade. And, while DocLint is intended to be helpful, it is specifically for doc comments and their likely content, and not a full conformance checker. I see LINK can be phrasing content under certain conditions. I'll adjust the enum accordingly, but I do not think it worth updating DocLint at this time to do any additional checking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1697369859 From jjg at openjdk.org Tue Jul 30 18:16:46 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 30 Jul 2024 18:16:46 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v4] In-Reply-To: <_QbxjpoM8zV1N9dYo4Acg2Zj35lFnnErCCpm8a3vogw=.576d8114-5cc6-48ec-9dba-50ee0da3d708@github.com> References: <374QOKpMLd_bULmqz6Cx6D_aqD90uE_eSIV5jD7XDhs=.f78d4745-2291-4102-a01b-cddb4c61f901@github.com> <_QbxjpoM8zV1N9dYo4Acg2Zj35lFnnErCCpm8a3vogw=.576d8114-5cc6-48ec-9dba-50ee0da3d708@github.com> Message-ID: On Tue, 30 Jul 2024 18:02:32 GMT, Jonathan Gibbons wrote: >> I'll look to upgrade these. In the original impl of DocLint, it was something of a conscious decision to avoid supporting input elements. >> >> I'm surprised LINK is phrasing content: I thought it could only appear in HEAD elements. I will check. >> >> Generally, moving towards HTML 5 names is a good goal, but some of that could/should be part of a DocLint cleanup. This is primarily just a merge, not an upgrade. And, while DocLint is intended to be helpful, it is specifically for doc comments and their likely content, and not a full conformance checker. > > I see LINK can be phrasing content under certain conditions. > I'll adjust the enum accordingly, but I do not think it worth updating DocLint at this time to do any additional checking. > I'm not sure whether marking it as INLINE content will break DocLint tests. tools/doclint/html/OtherTagsTest.java needs to be updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1697383203 From jjg at openjdk.org Tue Jul 30 18:49:05 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 30 Jul 2024 18:49:05 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v6] In-Reply-To: References: Message-ID: > Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. > > Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. > > There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. > > A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. > > There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Update/improve merge of HtmlTag and TagName ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19916/files - new: https://git.openjdk.org/jdk/pull/19916/files/c3c26d62..7996a9e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=04-05 Stats: 12 lines in 3 files changed: 1 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19916.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19916/head:pull/19916 PR: https://git.openjdk.org/jdk/pull/19916 From dnguyen at openjdk.org Tue Jul 30 20:22:00 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 30 Jul 2024 20:22:00 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update Message-ID: Localization update for JDK23 RDP2 Please view for enhanced diffs on affected files: https://cr.openjdk.org/~dnguyen/output/ ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/20394/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20394&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337054 Stats: 28 lines in 7 files changed: 6 ins; 3 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/20394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20394/head:pull/20394 PR: https://git.openjdk.org/jdk/pull/20394 From jlu at openjdk.org Tue Jul 30 20:57:33 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 30 Jul 2024 20:57:33 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 20:17:28 GMT, Damon Nguyen wrote: > Localization update for JDK23 RDP2 > > Please view for enhanced diffs on affected files: > https://cr.openjdk.org/~dnguyen/output/ LGTM src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 96: > 94: > 95: # 0: kind name, 1: symbol > 96: compiler.err.already.annotated={0} {1} ????? Noticeably, _zh_CN_ has updates to a few values that were not updated in the original, but are a result of updated translations by the translation tool. For this particular case it appears that only a space is added, but the contents do appear to be changing as well. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties line 123: > 121: > 122: # 0: string > 123: launcher.err.invalid.value.for.source=--source ???????{0} Looks correct. Removal of `\n` is done by white space tool, and standardizes this value with the original and other localized values that do not end with `\n`. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/20394#pullrequestreview-2208619181 PR Review Comment: https://git.openjdk.org/jdk/pull/20394#discussion_r1697548560 PR Review Comment: https://git.openjdk.org/jdk/pull/20394#discussion_r1697541280 From naoto at openjdk.org Tue Jul 30 22:47:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 30 Jul 2024 22:47:32 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 20:17:28 GMT, Damon Nguyen wrote: > Localization update for JDK23 RDP2 > > Please view for enhanced diffs on affected files: > https://cr.openjdk.org/~dnguyen/output/ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties line 283: > 281: doclet.record_equals_doc.fullbody.tail.both=??????????{@link java.util.Objects#equals(Object,Object) Objects::equals(Object,Object)}??????????????????????????????????compare???????????? > 282: > 283: doclet.record_equals_doc.fullbody.tail.primitive=????????????????????????????????????compare???????????? These translation are somewhat questionable. IIUC the original English meaning is to compare components to each other *using* the `compare` methods in the wrappers, but these Japanese translations imply compare components *to* the `compare` methods in the wrappers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20394#discussion_r1697682420 From jlu at openjdk.org Tue Jul 30 22:54:31 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 30 Jul 2024 22:54:31 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 22:45:03 GMT, Naoto Sato wrote: >> Localization update for JDK23 RDP2 >> >> Please view for enhanced diffs on affected files: >> https://cr.openjdk.org/~dnguyen/output/ > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties line 283: > >> 281: doclet.record_equals_doc.fullbody.tail.both=??????????{@link java.util.Objects#equals(Object,Object) Objects::equals(Object,Object)}??????????????????????????????????compare???????????? >> 282: >> 283: doclet.record_equals_doc.fullbody.tail.primitive=????????????????????????????????????compare???????????? > > These translation are somewhat questionable. IIUC the original English meaning is to compare components to each other *using* the `compare` methods in the wrappers, but these Japanese translations imply compare components *to* the `compare` methods in the wrappers. If you are able to provide a better translation, that would be ideal. We can replace this translation with that one, as well as filing a bug against the translation tool asking them to use yours. Otherwise, we should probably not revert this change, as while it is questionable, it is still updated to match the new English definition, and the previous localized definition would not match since it is outdated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20394#discussion_r1697686854 From naoto at openjdk.org Tue Jul 30 23:06:31 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 30 Jul 2024 23:06:31 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 20:17:28 GMT, Damon Nguyen wrote: > Localization update for JDK23 RDP2 > > Please view for enhanced diffs on affected files: > https://cr.openjdk.org/~dnguyen/output/ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties line 281: > 279: doclet.record_equals_doc.fullbody.head=????????????"???"?????????????????????????????????????????????????????????????????? > 280: > 281: doclet.record_equals_doc.fullbody.tail.both=??????????{@link java.util.Objects#equals(Object,Object) Objects::equals(Object,Object)}??????????????????????????????????compare???????????? Suggestion: doclet.record_equals_doc.fullbody.tail.both=??????????{@link java.util.Objects#equals(Object,Object) Objects::equals(Object,Object)}??????????????????????????????????compare???????????? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20394#discussion_r1697694518 From naoto at openjdk.org Tue Jul 30 23:06:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 30 Jul 2024 23:06:32 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 22:52:24 GMT, Justin Lu wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties line 283: >> >>> 281: doclet.record_equals_doc.fullbody.tail.both=??????????{@link java.util.Objects#equals(Object,Object) Objects::equals(Object,Object)}??????????????????????????????????compare???????????? >>> 282: >>> 283: doclet.record_equals_doc.fullbody.tail.primitive=????????????????????????????????????compare???????????? >> >> These translation are somewhat questionable. IIUC the original English meaning is to compare components to each other *using* the `compare` methods in the wrappers, but these Japanese translations imply compare components *to* the `compare` methods in the wrappers. > > If you are able to provide a better translation, that would be ideal. We can replace this translation with that one, as well as filing a bug against the translation tool asking them to use yours. > > Otherwise, we should probably not revert this change, as while it is questionable, it is still updated to match the new English definition, and the previous localized definition would not match since it is outdated. Cannot suggest the translation for the second line on GitHub (complaining "Applying suggestions on deleted lines is not supported."), but the same diff can be applied here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20394#discussion_r1697697593 From dnguyen at openjdk.org Wed Jul 31 10:52:06 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 31 Jul 2024 10:52:06 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v2] In-Reply-To: References: Message-ID: > Localization update for JDK23 RDP2 > > Please view for enhanced diffs on affected files: > https://cr.openjdk.org/~dnguyen/output/ Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update translation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20394/files - new: https://git.openjdk.org/jdk/pull/20394/files/45e10bf2..0aa0d1f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20394&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20394&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20394/head:pull/20394 PR: https://git.openjdk.org/jdk/pull/20394 From dnguyen at openjdk.org Wed Jul 31 10:56:36 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 31 Jul 2024 10:56:36 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v2] In-Reply-To: References: Message-ID: <8HCY51d0zjVZMXgtPZJ5DHa_KBT3O14QyAV0_nhPQI8=.85306dd0-d069-454b-b307-47f7dadc1733@github.com> On Tue, 30 Jul 2024 23:00:13 GMT, Naoto Sato wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update translation > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties line 281: > >> 279: doclet.record_equals_doc.fullbody.head=????????????"???"?????????????????????????????????????????????????????????????????? >> 280: >> 281: doclet.record_equals_doc.fullbody.tail.both=??????????{@link java.util.Objects#equals(Object,Object) Objects::equals(Object,Object)}??????????????????????????????????compare???????????? > > Suggestion: > > doclet.record_equals_doc.fullbody.tail.both=??????????{@link java.util.Objects#equals(Object,Object) Objects::equals(Object,Object)}??????????????????????????????????compare???????????? Replaced the translation as suggested. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20394#discussion_r1698310817 From mcimadamore at openjdk.org Wed Jul 31 10:56:06 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 31 Jul 2024 10:56:06 GMT Subject: RFR: 8336492: Regression in lambda serialization [v13] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: <8romtHTXG5L5i8wTTjp6Rrs8x5EpT_1nHDpd8BTxdDw=.9b9e66fa-3205-4728-bfed-7e01763b56ab@github.com> > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Make sure order of captured vars is the same as before. Do not remove `this$0` from serializable local classes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/da70a4a8..2deabf85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=11-12 Stats: 93 lines in 4 files changed: 71 ins; 17 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Wed Jul 31 11:00:56 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 31 Jul 2024 11:00:56 GMT Subject: RFR: 8336492: Regression in lambda serialization [v14] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Remove whitespaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/2deabf85..c8a1d746 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From mcimadamore at openjdk.org Wed Jul 31 11:00:56 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 31 Jul 2024 11:00:56 GMT Subject: RFR: 8336492: Regression in lambda serialization [v13] In-Reply-To: <8romtHTXG5L5i8wTTjp6Rrs8x5EpT_1nHDpd8BTxdDw=.9b9e66fa-3205-4728-bfed-7e01763b56ab@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> <8romtHTXG5L5i8wTTjp6Rrs8x5EpT_1nHDpd8BTxdDw=.9b9e66fa-3205-4728-bfed-7e01763b56ab@github.com> Message-ID: On Wed, 31 Jul 2024 10:56:06 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make sure order of captured vars is the same as before. > Do not remove `this$0` from serializable local classes. I've added a couple of changes: * first, I made sure that the order of captured local is the same as before (and, importantly, that the order is consistent across local classes and lambdas) * second, I reverted the changes to drop `this$0` in serializable local classes. Thinking more about this, this seemed to me mostly an orthogonal improvement, unrelated to the bulk of this fix. If we want to pursue this we should probably (a) do that in a separate issue and (b) do that for both local and member classes (after checking the JLS, there's nothing there saying that member classes should have a _field_, or that the name of such field is specified in any way). This means that this PR leaves us with two minor incompatibilities: * the name of non-serializable lambdas might change (for now, I'd like to keep it this way, as I think new names are better, and relying on unspecified generated names is discouraged anyways - we can revisit if absolutely necessary) * due to the fixes in this PR, javac now correctly omits the method index in some of the generated `EnclosingMethod` attributes, when the lambda is defined inside a static or instance initializer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2260242091 From dnguyen at openjdk.org Wed Jul 31 11:02:06 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 31 Jul 2024 11:02:06 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v3] In-Reply-To: References: Message-ID: > Localization update for JDK23 RDP2 > > Please view for enhanced diffs on affected files: > https://cr.openjdk.org/~dnguyen/output/ Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update another translation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20394/files - new: https://git.openjdk.org/jdk/pull/20394/files/0aa0d1f0..18e523d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20394&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20394&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20394/head:pull/20394 PR: https://git.openjdk.org/jdk/pull/20394 From dnguyen at openjdk.org Wed Jul 31 11:02:06 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 31 Jul 2024 11:02:06 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 23:03:40 GMT, Naoto Sato wrote: > Cannot suggest the translation for the second line on GitHub (complaining "Applying suggestions on deleted lines is not supported."), but the same diff can be applied here I think I handled the issue you mentioned here. I replaced line 283 with the same suggested change you commented on for line 281. Let me know if there are any issues, but if this is correct, the current state of the PR should have fixed both of your concerns. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20394#discussion_r1698316910 From mcimadamore at openjdk.org Wed Jul 31 11:03:56 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 31 Jul 2024 11:03:56 GMT Subject: RFR: 8336492: Regression in lambda serialization [v15] In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> Message-ID: <2znFXIlPbisb08rk4C0f_pkEExxp0z4msksgthsLkZE=.89d61019-e553-48fd-80aa-97a4c19b0707@github.com> > This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. > > The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). > > The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. > > This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. > > The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. > > Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. > > #### Compatibility > > This PR chan... Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Beef up serializable lambda test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20349/files - new: https://git.openjdk.org/jdk/pull/20349/files/c8a1d746..df490071 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=13-14 Stats: 18 lines in 1 file changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349 PR: https://git.openjdk.org/jdk/pull/20349 From prappo at openjdk.org Wed Jul 31 11:19:31 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 31 Jul 2024 11:19:31 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 11:02:06 GMT, Damon Nguyen wrote: >> Localization update for JDK23 RDP2 >> >> Please view for enhanced diffs on affected files: >> https://cr.openjdk.org/~dnguyen/output/ > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update another translation Is it an incremental update since https://github.com/openjdk/jdk/pull/19609? I cannot verify correctness of translation, but I can review this PR generally for `jdk.javadoc`. >From what I can see, the changes are only to the property files, which is expected from the PR title. The keys from English files 1-1 match the keys from non-English files: there are no missing or extra keys. >From that point of view, the changes to `jdk.javadoc` look good. ------------- Marked as reviewed by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20394#pullrequestreview-2209878371 From naoto at openjdk.org Wed Jul 31 16:44:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 31 Jul 2024 16:44:32 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 11:02:06 GMT, Damon Nguyen wrote: >> Localization update for JDK23 RDP2 >> >> Please view for enhanced diffs on affected files: >> https://cr.openjdk.org/~dnguyen/output/ > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update another translation Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20394#pullrequestreview-2210664500 From naoto at openjdk.org Wed Jul 31 16:44:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 31 Jul 2024 16:44:32 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 10:58:46 GMT, Damon Nguyen wrote: >> Cannot suggest the translation for the second line on GitHub (complaining "Applying suggestions on deleted lines is not supported."), but the same diff can be applied here > >> Cannot suggest the translation for the second line on GitHub (complaining "Applying suggestions on deleted lines is not supported."), but the same diff can be applied here > > I think I handled the issue you mentioned here. I replaced line 283 with the same suggested change you commented on for line 281. Let me know if there are any issues, but if this is correct, the current state of the PR should have fixed both of your concerns. Thanks! Thanks, Damon. Now the latest revision has the correct translation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20394#discussion_r1698811821 From jlu at openjdk.org Wed Jul 31 17:23:32 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 31 Jul 2024 17:23:32 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 11:02:06 GMT, Damon Nguyen wrote: >> Localization update for JDK23 RDP2 >> >> Please view for enhanced diffs on affected files: >> https://cr.openjdk.org/~dnguyen/output/ > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update another translation Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20394#pullrequestreview-2210736642 From jjg at openjdk.org Wed Jul 31 18:00:11 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 31 Jul 2024 18:00:11 GMT Subject: RFR: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc [v7] In-Reply-To: References: Message-ID: <43YQdIChggAClgqX0386nbz1tnJYekHNVl34a5TPV7I=.6ba0c8dc-bbc1-4f45-89aa-c17a2d73ca5a@github.com> > Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module. > > Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet. > > There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name. > > A few minor bugs were found and fixed. Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package. The naming follows `HtmlId` and `HtmlIds`. > > There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge with upstream master; add reference in HtmlTag to a related RFE - Update/improve merge of HtmlTag and TagName - Fix missing legal headers - Cleanup use of HtmlStyle and HtmlStyles - Fix merge issues - Merge with upstream master - fix whitespace - reorder imports - Cleanup pass - Merge doclint into html: part 2: TagName/HtmlTag - ... and 2 more: https://git.openjdk.org/jdk/compare/e4c7850c...2b6363ee ------------- Changes: https://git.openjdk.org/jdk/pull/19916/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=06 Stats: 3024 lines in 108 files changed: 1164 ins; 1221 del; 639 mod Patch: https://git.openjdk.org/jdk/pull/19916.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19916/head:pull/19916 PR: https://git.openjdk.org/jdk/pull/19916 From dnguyen at openjdk.org Wed Jul 31 20:10:32 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 31 Jul 2024 20:10:32 GMT Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 11:02:06 GMT, Damon Nguyen wrote: >> Localization update for JDK23 RDP2 >> >> Please view for enhanced diffs on affected files: >> https://cr.openjdk.org/~dnguyen/output/ > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update another translation > Is it an incremental update since #19609? > > I cannot verify correctness of translation, but I can review this PR generally for `jdk.javadoc`. > > From what I can see, the changes are only to the property files, which is expected from the PR title. The keys from English files 1-1 match the keys from non-English files: there are no missing or extra keys. > > From that point of view, the changes to `jdk.javadoc` look good. Thanks for your review! Yes, we have localization drops twice (RDP1 & RDP2). RDP1 will have a majority of the translations typically and the RDP2 drop is usually a minor update in comparison. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20394#issuecomment-2261356696 From vromero at openjdk.org Wed Jul 31 20:59:36 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 31 Jul 2024 20:59:36 GMT Subject: RFR: 8336492: Regression in lambda serialization [v15] In-Reply-To: <2znFXIlPbisb08rk4C0f_pkEExxp0z4msksgthsLkZE=.89d61019-e553-48fd-80aa-97a4c19b0707@github.com> References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com> <2znFXIlPbisb08rk4C0f_pkEExxp0z4msksgthsLkZE=.89d61019-e553-48fd-80aa-97a4c19b0707@github.com> Message-ID: On Wed, 31 Jul 2024 11:03:56 GMT, Maurizio Cimadamore wrote: >> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`. >> >> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed). >> >> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`. >> >> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols. >> >> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is. >> >> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`. >> >> #### C... > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Beef up serializable lambda test src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CaptureScanner.java line 57: > 55: > 56: /** > 57: * The list of owner's variables accessed from within the local class, I think that now that the field is a set we probably should update this comment, it is not a list anymore and it can't have duplicates ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1699098034