From jlahoda at openjdk.org Mon Jun 3 07:34:18 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 3 Jun 2024 07:34:18 GMT Subject: RFR: 8325168: JShell should support Markdown comments [v6] In-Reply-To: References: Message-ID: > This is an attempt to add Markdown support in documentation comments to JShell. > > It works by converting the Markdown text to HTML during the process of resolving `{@inheritDoc}` tags. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17686/files - new: https://git.openjdk.org/jdk/pull/17686/files/d85a2b8a..64c984d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17686&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17686&range=04-05 Stats: 128 lines in 3 files changed: 21 ins; 4 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/17686.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17686/head:pull/17686 PR: https://git.openjdk.org/jdk/pull/17686 From duke at openjdk.org Mon Jun 3 11:46:23 2024 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Mon, 3 Jun 2024 11:46:23 GMT Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is failing on Japanese Windows Message-ID: 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. ------------- Commit messages: - 8333427: langtools/tools/javac/newlines/NewLineTest.java is failing on Japanese Windows Changes: https://git.openjdk.org/jdk/pull/19519/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19519&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333427 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19519.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19519/head:pull/19519 PR: https://git.openjdk.org/jdk/pull/19519 From jlahoda at openjdk.org Mon Jun 3 12:51:09 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 3 Jun 2024 12:51:09 GMT Subject: RFR: 8327368: javac crash when computing exhaustiveness checks. Message-ID: Consider code like: package test; public class Test { sealed interface A permits T, U {} sealed interface B permits V, W {} static final class T implements A {} static final class U implements A {} static final class V implements B {} static final class W implements B {} final static record R(A a, B b) {} static int r(R r) { return switch (r) { case R(A a, V b) -> 1; case R(T a, B b) -> 2; case R(U a, W b) -> 3; }; } } To properly evaluate exhaustiveness, we need to consider `R(T a, B b)` to act as `R(T a, W b)`, so that we can reduce `R(T a, W b)` and `R(U a, W b)` to `R(A a, W b)`. Which is then reduced together with `R(A a, V b)` to `R(A a, B b)` and consequently to just `R`. This was done under JDK-8325215, by expanding `B` into all possible subtypes, from which we can pick patterns for reduction. Eventually, that patch may need a more complete revamp, but the idea herein is just to prevent a `ClassCastException` when the type of the binding pattern is not a class-based type - typically, when it is a type variable. As type variables don't have subtypes, we cannot expand then to all possible subtypes anyway, and can simply skip them. ------------- Commit messages: - 8327368: javac crash when computing exhaustiveness checks. Changes: https://git.openjdk.org/jdk/pull/19523/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19523&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327368 Stats: 37 lines in 2 files changed: 33 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19523/head:pull/19523 PR: https://git.openjdk.org/jdk/pull/19523 From vromero at openjdk.org Mon Jun 3 20:39:34 2024 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 3 Jun 2024 20:39:34 GMT Subject: RFR: 8043226: Better diagnostics for non-applicable type annotations [v5] In-Reply-To: <972CxtISa9G1XeC7uAtoYB3Tgzfm9Rr33lU06ikerY4=.3025f009-2f72-4e91-ab94-78c1b0370322@github.com> References: <972CxtISa9G1XeC7uAtoYB3Tgzfm9Rr33lU06ikerY4=.3025f009-2f72-4e91-ab94-78c1b0370322@github.com> Message-ID: <5rh-hM8UHJyP-J5ez1aHEugbA62miOeSqoBjhXM3ifU=.c26d4528-0977-4c6b-8702-189d0c0fda8d@github.com> On Fri, 3 May 2024 17:00:15 GMT, Liam Miller-Cushon wrote: >> Hi, >> >> Please consider this improvement to diagnostics on inadmissable type annotations. >> >> [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug. >> >> I have some notes on details of the proposed changes below. >> >> --- >> >> Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. >> >> As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2. >> >> This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names. >> >> Before: >> >> >> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA >> @TA Outer.SInner osi; >> ^ >> >> >> After: >> >> >> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA >> @TA Outer.SInner osi; >> ^ >> (to annotate a qualified type, write Outer. at TA SInner) >> >> >> --- >> >> Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`. >> >> This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location. >> >> This also improves the ordering of the diagnostic in the output, since... > > 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 six additional commits since the last revision: > > - Adjust diagnostic message based on review feedback > - Merge branch 'master' into JDK-8043226 > - Merge branch 'master' into JDK-8043226 > - Merge branch 'master' into JDK-8043226 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > > Co-authored-by: Werner Dietl > - 8043226: Better diagnostics for non-applicable type annotations lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16592#pullrequestreview-2094806961 From cushon at openjdk.org Mon Jun 3 22:43:51 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 3 Jun 2024 22:43:51 GMT Subject: RFR: 8043226: Better diagnostics for non-applicable type annotations [v6] In-Reply-To: References: Message-ID: > Hi, > > Please consider this improvement to diagnostics on inadmissable type annotations. > > [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug. > > I have some notes on details of the proposed changes below. > > --- > > Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. > > As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2. > > This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names. > > Before: > > > test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA > @TA Outer.SInner osi; > ^ > > > After: > > > test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA > @TA Outer.SInner osi; > ^ > (to annotate a qualified type, write Outer. at TA SInner) > > > --- > > Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`. > > This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location. > > This also improves the ordering of the diagnostic in the output, since attribution errors are report before type annotation validation errors in the l... 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 seven additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8043226 - Adjust diagnostic message based on review feedback - Merge branch 'master' into JDK-8043226 - Merge branch 'master' into JDK-8043226 - Merge branch 'master' into JDK-8043226 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Co-authored-by: Werner Dietl - 8043226: Better diagnostics for non-applicable type annotations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16592/files - new: https://git.openjdk.org/jdk/pull/16592/files/c01922e2..840daee9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16592&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16592&range=04-05 Stats: 100181 lines in 1913 files changed: 69381 ins; 20336 del; 10464 mod Patch: https://git.openjdk.org/jdk/pull/16592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16592/head:pull/16592 PR: https://git.openjdk.org/jdk/pull/16592 From jlahoda at openjdk.org Tue Jun 4 11:57:13 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 4 Jun 2024 11:57:13 GMT Subject: Integrated: 8325168: JShell should support Markdown comments In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 14:02:28 GMT, Jan Lahoda wrote: > This is an attempt to add Markdown support in documentation comments to JShell. > > It works by converting the Markdown text to HTML during the process of resolving `{@inheritDoc}` tags. This pull request has now been integrated. Changeset: 8d3de45f Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/8d3de45f4dfd60dc4e2f210cb0c085fcf6efb8e2 Stats: 2056 lines in 9 files changed: 1209 ins; 842 del; 5 mod 8325168: JShell should support Markdown comments Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk/pull/17686 From jlahoda at openjdk.org Tue Jun 4 12:24:59 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 4 Jun 2024 12:24:59 GMT Subject: RFR: 8327368: javac crash when computing exhaustiveness checks. [v2] In-Reply-To: References: Message-ID: > Consider code like: > > package test; > > public class Test { > > sealed interface A permits T, U {} > > sealed interface B permits V, W {} > > static final class T implements A {} > > static final class U implements A {} > > static final class V implements B {} > > static final class W implements B {} > > final static record R(A a, B b) {} > > static int r(R r) { > return switch (r) { > case R(A a, V b) -> 1; > case R(T a, B b) -> 2; > case R(U a, W b) -> 3; > }; > } > } > > > To properly evaluate exhaustiveness, we need to consider `R(T a, B b)` to act as `R(T a, W b)`, so that we can reduce `R(T a, W b)` and `R(U a, W b)` to `R(A a, W b)`. Which is then reduced together with `R(A a, V b)` to `R(A a, B b)` and consequently to just `R`. > > This was done under JDK-8325215, by expanding `B` into all possible subtypes, from which we can pick patterns for reduction. Eventually, that patch may need a more complete revamp, but the idea herein is just to prevent a `ClassCastException` when the type of the binding pattern is not a class-based type - typically, when it is a type variable. This patch uses the type variable's bounds as the based from which the permitted subtypes are computed. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Must handle type variables using their bounds. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19523/files - new: https://git.openjdk.org/jdk/pull/19523/files/e779ee2d..086f2520 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19523&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19523&range=00-01 Stats: 87 lines in 2 files changed: 63 ins; 5 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/19523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19523/head:pull/19523 PR: https://git.openjdk.org/jdk/pull/19523 From vromero at openjdk.org Tue Jun 4 13:19:17 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 4 Jun 2024 13:19:17 GMT Subject: RFR: 8327368: javac crash when computing exhaustiveness checks. [v2] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 12:24:59 GMT, Jan Lahoda wrote: >> Consider code like: >> >> package test; >> >> public class Test { >> >> sealed interface A permits T, U {} >> >> sealed interface B permits V, W {} >> >> static final class T implements A {} >> >> static final class U implements A {} >> >> static final class V implements B {} >> >> static final class W implements B {} >> >> final static record R(A a, B b) {} >> >> static int r(R r) { >> return switch (r) { >> case R(A a, V b) -> 1; >> case R(T a, B b) -> 2; >> case R(U a, W b) -> 3; >> }; >> } >> } >> >> >> To properly evaluate exhaustiveness, we need to consider `R(T a, B b)` to act as `R(T a, W b)`, so that we can reduce `R(T a, W b)` and `R(U a, W b)` to `R(A a, W b)`. Which is then reduced together with `R(A a, V b)` to `R(A a, B b)` and consequently to just `R`. >> >> This was done under JDK-8325215, by expanding `B` into all possible subtypes, from which we can pick patterns for reduction. Eventually, that patch may need a more complete revamp, but the idea herein is just to prevent a `ClassCastException` when the type of the binding pattern is not a class-based type - typically, when it is a type variable. This patch uses the type variable's bounds as the based from which the permitted subtypes are computed. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Must handle type variables using their bounds. looks good ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19523#pullrequestreview-2096366390 From cushon at openjdk.org Tue Jun 4 17:22:05 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 4 Jun 2024 17:22:05 GMT Subject: Integrated: 8043226: Better diagnostics for non-applicable type annotations In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 01:21:28 GMT, Liam Miller-Cushon wrote: > Hi, > > Please consider this improvement to diagnostics on inadmissable type annotations. > > [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug. > > I have some notes on details of the proposed changes below. > > --- > > Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. > > As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2. > > This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names. > > Before: > > > test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA > @TA Outer.SInner osi; > ^ > > > After: > > > test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA > @TA Outer.SInner osi; > ^ > (to annotate a qualified type, write Outer. at TA SInner) > > > --- > > Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`. > > This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location. > > This also improves the ordering of the diagnostic in the output, since attribution errors are report before type annotation validation errors in the l... This pull request has now been integrated. Changeset: 612b6896 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/612b6896d28cebf61ef024709ff3afb5e3ee0dde Stats: 290 lines in 17 files changed: 35 ins; 49 del; 206 mod 8043226: Better diagnostics for non-applicable type annotations Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/16592 From cushon at openjdk.org Tue Jun 4 17:43:08 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 4 Jun 2024 17:43:08 GMT Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version Message-ID: 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. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into JDK-8332744 - Use jdk.internal.misc.Unsafe instead of sun.misc.Unsafe in microbenchmarks to avoid a sunapi warning - [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version Changes: https://git.openjdk.org/jdk/pull/19397/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332744 Stats: 159 lines in 20 files changed: 132 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/19397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19397/head:pull/19397 PR: https://git.openjdk.org/jdk/pull/19397 From cushon at openjdk.org Tue Jun 4 18:03:44 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 4 Jun 2024 18:03:44 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics [v3] In-Reply-To: References: Message-ID: > Hi, > > Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. > > For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. > > An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. > > The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. 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 seven additional commits since the last revision: - Update after merge of JDK-8043226 - Merge remote-tracking branch 'origin/master' into JDK-8291643 - Merge branch 'master' into JDK-8291643 - Use Type stripping logic added for JDK-8042981 - Merge branch 'master' into JDK-8291643 - Updates based on review thread * Support optionally printing types with type annotations * Move handling of types in AbstractDiagnosticFormatter * Make annotation removal more robust, don't rely on stripMetadata - 8291643: Consider omitting type annotations from type error diagnostics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16578/files - new: https://git.openjdk.org/jdk/pull/16578/files/7331c7cb..eced87f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16578&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16578&range=01-02 Stats: 672872 lines in 8096 files changed: 158730 ins; 162063 del; 352079 mod Patch: https://git.openjdk.org/jdk/pull/16578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16578/head:pull/16578 PR: https://git.openjdk.org/jdk/pull/16578 From cushon at openjdk.org Tue Jun 4 18:03:50 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 4 Jun 2024 18:03:50 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics [v2] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 20:35:20 GMT, Liam Miller-Cushon wrote: >> Hi, >> >> Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. >> >> For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. >> >> An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. >> >> The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. > > 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 four additional commits since the last revision: > > - Use Type stripping logic added for JDK-8042981 > - Merge branch 'master' into JDK-8291643 > - Updates based on review thread > > * Support optionally printing types with type annotations > * Move handling of types in AbstractDiagnosticFormatter > * Make annotation removal more robust, don't rely on stripMetadata > - 8291643: Consider omitting type annotations from type error diagnostics > `AbstractDiagnosticFormatter` now removes type annotations from printed types by default, and there's a `JCDiagnostic.AnnotatedType` wrapper for diagnostics that want to opt-in to printing types with annotations. This isn't currently used in the PR, but #16592 is an example of a diagnostic that wants to include type annotations. I updated this after the merge of [JDK-8043226: Better diagnostics for non-applicable type annotations](https://bugs.openjdk.org/browse/JDK-8043226), which introduces some diagnostics that include types where the annotations should be preserved, to use the `JCDiagnostic.AnnotatedType` to preserve those annotations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16578#issuecomment-2148101935 From vromero at openjdk.org Tue Jun 4 21:54:02 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 4 Jun 2024 21:54:02 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics [v3] In-Reply-To: References: Message-ID: <-hwQPoAqcN6MvRihetBKArz6qW-FptZKX-u4oXhFltQ=.42477734-9ecd-4eb5-a70b-2d1af9b0a4d2@github.com> On Tue, 4 Jun 2024 18:03:44 GMT, Liam Miller-Cushon wrote: >> Hi, >> >> Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. >> >> For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. >> >> An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. >> >> The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. > > 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 seven additional commits since the last revision: > > - Update after merge of JDK-8043226 > - Merge remote-tracking branch 'origin/master' into JDK-8291643 > - Merge branch 'master' into JDK-8291643 > - Use Type stripping logic added for JDK-8042981 > - Merge branch 'master' into JDK-8291643 > - Updates based on review thread > > * Support optionally printing types with type annotations > * Move handling of types in AbstractDiagnosticFormatter > * Make annotation removal more robust, don't rely on stripMetadata > - 8291643: Consider omitting type annotations from type error diagnostics lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16578#pullrequestreview-2097447990 From darcy at openjdk.org Tue Jun 4 22:53:03 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 4 Jun 2024 22:53:03 GMT Subject: RFR: 8333586: Improve syntax of @see tags in javax.lang.model Message-ID: Avoid using `` when alternative syntax will do. ------------- Commit messages: - Update copyright years. - JDK-8333586: Improve syntax of @see tags in javax.lang.mode Changes: https://git.openjdk.org/jdk/pull/19552/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19552&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333586 Stats: 104 lines in 36 files changed: 0 ins; 0 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/19552.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19552/head:pull/19552 PR: https://git.openjdk.org/jdk/pull/19552 From iris at openjdk.org Tue Jun 4 23:31:55 2024 From: iris at openjdk.org (Iris Clark) Date: Tue, 4 Jun 2024 23:31:55 GMT Subject: RFR: 8333586: Improve syntax of @see tags in javax.lang.model In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 22:48:54 GMT, Joe Darcy wrote: > Avoid using `` when alternative syntax will do. Nice tidy of @see references. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19552#pullrequestreview-2097573645 From jjg at openjdk.org Wed Jun 5 00:45:00 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 5 Jun 2024 00:45:00 GMT Subject: RFR: 8333586: Improve syntax of @see tags in javax.lang.model In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 22:48:54 GMT, Joe Darcy wrote: > Avoid using `` when alternative syntax will do. Marked as reviewed by jjg (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19552#pullrequestreview-2097631888 From darcy at openjdk.org Wed Jun 5 00:59:05 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 5 Jun 2024 00:59:05 GMT Subject: Integrated: 8333586: Improve syntax of @see tags in javax.lang.model In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 22:48:54 GMT, Joe Darcy wrote: > Avoid using `` when alternative syntax will do. This pull request has now been integrated. Changeset: 67b9a081 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/67b9a081391d6ef775581d65da4b3cc302aa8dd8 Stats: 104 lines in 36 files changed: 0 ins; 0 del; 104 mod 8333586: Improve syntax of @see tags in javax.lang.model Reviewed-by: iris, jjg ------------- PR: https://git.openjdk.org/jdk/pull/19552 From jlahoda at openjdk.org Wed Jun 5 05:49:00 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 5 Jun 2024 05:49:00 GMT Subject: Integrated: 8327368: javac crash when computing exhaustiveness checks In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 12:47:15 GMT, Jan Lahoda wrote: > Consider code like: > > package test; > > public class Test { > > sealed interface A permits T, U {} > > sealed interface B permits V, W {} > > static final class T implements A {} > > static final class U implements A {} > > static final class V implements B {} > > static final class W implements B {} > > final static record R(A a, B b) {} > > static int r(R r) { > return switch (r) { > case R(A a, V b) -> 1; > case R(T a, B b) -> 2; > case R(U a, W b) -> 3; > }; > } > } > > > To properly evaluate exhaustiveness, we need to consider `R(T a, B b)` to act as `R(T a, W b)`, so that we can reduce `R(T a, W b)` and `R(U a, W b)` to `R(A a, W b)`. Which is then reduced together with `R(A a, V b)` to `R(A a, B b)` and consequently to just `R`. > > This was done under JDK-8325215, by expanding `B` into all possible subtypes, from which we can pick patterns for reduction. Eventually, that patch may need a more complete revamp, but the idea herein is just to prevent a `ClassCastException` when the type of the binding pattern is not a class-based type - typically, when it is a type variable. This patch uses the type variable's bounds as the based from which the permitted subtypes are computed. This pull request has now been integrated. Changeset: 1f094672 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/1f09467230971d6458918ec19ffeb259b8c028a3 Stats: 98 lines in 2 files changed: 91 ins; 0 del; 7 mod 8327368: javac crash when computing exhaustiveness checks Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/19523 From jvernee at openjdk.org Wed Jun 5 09:11:30 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Jun 2024 09:11:30 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release Message-ID: Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. Testing: tier 1-3 (ongoing) ------------- Commit messages: - fix -Xlint:restricted when using --release Changes: https://git.openjdk.org/jdk/pull/19548/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19548&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333560 Stats: 9 lines in 3 files changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/19548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19548/head:pull/19548 PR: https://git.openjdk.org/jdk/pull/19548 From jvernee at openjdk.org Wed Jun 5 11:25:22 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Jun 2024 11:25:22 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v2] In-Reply-To: References: Message-ID: > Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. > > Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. > > There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. > > Testing: tier 1-3 (ongoing) Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: add Jan's patch that adds internal fake annotation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19548/files - new: https://git.openjdk.org/jdk/pull/19548/files/54f062c3..9dfaf070 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19548&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19548&range=00-01 Stats: 11 lines in 3 files changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19548/head:pull/19548 PR: https://git.openjdk.org/jdk/pull/19548 From jvernee at openjdk.org Wed Jun 5 11:28:59 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Jun 2024 11:28:59 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 11:25:22 GMT, Jorn Vernee wrote: >> Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. >> >> Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. >> >> There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. >> >> Testing: tier 1-3 (ongoing) > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > add Jan's patch that adds internal fake annotation Spoke to @lahodaj offline, and he pointed out that we need to add a fake annotation for `@Restricted` as well. Javac will use the fake annotation to set the internal `RESTRICTED` flag, but it is not otherwise exposed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19548#issuecomment-2149592778 From vromero at openjdk.org Wed Jun 5 15:33:59 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 5 Jun 2024 15:33:59 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 11:25:22 GMT, Jorn Vernee wrote: >> Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. >> >> Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. >> >> There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. >> >> Testing: tier 1-3 (ongoing) > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > add Jan's patch that adds internal fake annotation lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19548#pullrequestreview-2099560072 From darcy at openjdk.org Wed Jun 5 15:35:18 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 5 Jun 2024 15:35:18 GMT Subject: RFR: 8330182: Start of release updates for JDK 24 [v12] In-Reply-To: References: Message-ID: > Get JDK 24 underway. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Update copyright. - Updated problem list after bug fix. - Merge branch 'master' into JDK-8330188 - Merge branch 'master' into JDK-8330188 - Temporarily problem list java.lang.instrument tests until jar generation is fixed. - Merge branch 'master' into JDK-8330188 - Update symbol files for JDK 23 build 25. - Correct release year. - Merge branch 'master' into JDK-8330188 - Add symbol files current with JDK 23 build 24. - ... and 13 more: https://git.openjdk.org/jdk/compare/4369856c...f4a5026b ------------- Changes: https://git.openjdk.org/jdk/pull/18787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=11 Stats: 2083 lines in 50 files changed: 2019 ins; 7 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/18787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787 PR: https://git.openjdk.org/jdk/pull/18787 From iris at openjdk.org Wed Jun 5 15:45:05 2024 From: iris at openjdk.org (Iris Clark) Date: Wed, 5 Jun 2024 15:45:05 GMT Subject: RFR: 8330182: Start of release updates for JDK 24 [v12] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 15:35:18 GMT, Joe Darcy wrote: >> Get JDK 24 underway. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Update copyright. > - Updated problem list after bug fix. > - Merge branch 'master' into JDK-8330188 > - Merge branch 'master' into JDK-8330188 > - Temporarily problem list java.lang.instrument tests until jar generation is fixed. > - Merge branch 'master' into JDK-8330188 > - Update symbol files for JDK 23 build 25. > - Correct release year. > - Merge branch 'master' into JDK-8330188 > - Add symbol files current with JDK 23 build 24. > - ... and 13 more: https://git.openjdk.org/jdk/compare/4369856c...f4a5026b Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2099585754 From jvernee at openjdk.org Wed Jun 5 17:47:57 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Jun 2024 17:47:57 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 11:25:22 GMT, Jorn Vernee wrote: >> Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. >> >> Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. >> >> There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. >> >> Testing: tier 1-3 (ongoing) > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > add Jan's patch that adds internal fake annotation I'm taking a look at the failed test. Will re-run tier 1-3 as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19548#issuecomment-2150618982 From vromero at openjdk.org Wed Jun 5 18:15:59 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 5 Jun 2024 18:15:59 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 17:45:30 GMT, Jorn Vernee wrote: > I'm taking a look at the failed test. Will re-run tier 1-3 as well. what test failed? just curious ------------- PR Comment: https://git.openjdk.org/jdk/pull/19548#issuecomment-2150664039 From jvernee at openjdk.org Wed Jun 5 18:15:59 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Jun 2024 18:15:59 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 18:11:18 GMT, Vicente Romero wrote: > > I'm taking a look at the failed test. Will re-run tier 1-3 as well. > > what test failed? just curious `tools/javac/processing/model/TestSymtabItems.java` failed. We need to use `enterSyntheticAnnotation` in `Symtab` instead of `enterClass` I think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19548#issuecomment-2150668440 From jlahoda at openjdk.org Wed Jun 5 18:26:56 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 5 Jun 2024 18:26:56 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 18:13:20 GMT, Jorn Vernee wrote: > > > I'm taking a look at the failed test. Will re-run tier 1-3 as well. > > > > > > what test failed? just curious > > `tools/javac/processing/model/TestSymtabItems.java` failed. We need to use `enterSyntheticAnnotation` in `Symtab` instead of `enterClass` I think. Oops, yes, sorry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19548#issuecomment-2150689369 From jvernee at openjdk.org Wed Jun 5 18:42:08 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Jun 2024 18:42:08 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v3] In-Reply-To: References: Message-ID: > Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. > > Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. > > There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. > > Testing: tier 1-3 (ongoing) Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: use enterSyntheticAnnotation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19548/files - new: https://git.openjdk.org/jdk/pull/19548/files/9dfaf070..cadc668b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19548&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19548&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19548/head:pull/19548 PR: https://git.openjdk.org/jdk/pull/19548 From cushon at openjdk.org Wed Jun 5 19:13:04 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 5 Jun 2024 19:13:04 GMT Subject: Integrated: 8291643: Consider omitting type annotations from type error diagnostics In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 00:47:10 GMT, Liam Miller-Cushon wrote: > Hi, > > Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. > > For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. > > An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. > > The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. This pull request has now been integrated. Changeset: 7564949a Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/7564949a56b533b9d955ff5feee75afd18e51f74 Stats: 35 lines in 10 files changed: 29 ins; 0 del; 6 mod 8291643: Consider omitting type annotations from type error diagnostics Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/16578 From duke at openjdk.org Wed Jun 5 20:16:07 2024 From: duke at openjdk.org (Chris Povirk) Date: Wed, 5 Jun 2024 20:16:07 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics [v2] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 20:35:20 GMT, Liam Miller-Cushon wrote: >> Hi, >> >> Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. >> >> For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. >> >> An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. >> >> The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. > > 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 four additional commits since the last revision: > > - Use Type stripping logic added for JDK-8042981 > - Merge branch 'master' into JDK-8291643 > - Updates based on review thread > > * Support optionally printing types with type annotations > * Move handling of types in AbstractDiagnosticFormatter > * Make annotation removal more robust, don't rely on stripMetadata > - 8291643: Consider omitting type annotations from type error diagnostics As an interested party, one thing that I'd highlight is that the tests and examples shown here are by nature simpler than what we see in real-world errors, such as this one: com/google/common/collect/MutableClassToInstanceMap.java:169: error: incompatible types: Map,B> cannot be converted to Map,? extends B> where @org.checkerframework.checker.nullness.qual.NonNull B is a type-variable: @org.checkerframework.checker.nullness.qual.NonNull B extends @org.checkerframework.checker.nullness.qual.Nullable Object declared in class MutableClassToInstanceMap That could be reduced to merely: com/google/common/collect/MutableClassToInstanceMap.java:169: error: incompatible types: Map,B> cannot be converted to Map,? extends B> where B is a type-variable: B extends Object declared in class MutableClassToInstanceMap Note also that the first line of the current message, by including `@org.checkerframework.checker.nullness.qual.NonNull` in the one type but not the other, may suggest to some readers that the nullness annotations are part of the reason for the error, when in fact the error has nothing to do with nullness. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16578#issuecomment-2088992273 From mcimadamore at openjdk.org Thu Jun 6 13:47:44 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 6 Jun 2024 13:47:44 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v3] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 18:42:08 GMT, Jorn Vernee wrote: >> Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. >> >> Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. >> >> There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. >> >> Testing: tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > use enterSyntheticAnnotation make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 343: > 341: private static final String RESTRICTED_ANNOTATION = > 342: "Ljdk/internal/javac/Restricted;"; > 343: private static final String RESTRICTED_ANNOTATION_INTERNAL = These should be moved around, now we're intermixing preview-related decls with restricted ones ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19548#discussion_r1629581595 From mcimadamore at openjdk.org Thu Jun 6 13:56:47 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 6 Jun 2024 13:56:47 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v3] In-Reply-To: References: Message-ID: <4DL9GXbE8UDmc3R_-IJWqE3ckblRcEh0DhOv-KbRAz4=.52a40eb8-bc1b-4ffd-bbdc-1b0f8ea00408@github.com> On Wed, 5 Jun 2024 18:42:08 GMT, Jorn Vernee wrote: >> Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. >> >> Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. >> >> There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. >> >> Testing: tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > use enterSyntheticAnnotation Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19548#pullrequestreview-2102057035 From jvernee at openjdk.org Thu Jun 6 14:14:16 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 6 Jun 2024 14:14:16 GMT Subject: RFR: 8333560: -Xlint:restricted does not work with --release [v4] In-Reply-To: References: Message-ID: > Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. > > Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. > > There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. > > Testing: tier 1-3 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: order annotation name decls ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19548/files - new: https://git.openjdk.org/jdk/pull/19548/files/cadc668b..128ca055 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19548&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19548&range=02-03 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19548/head:pull/19548 PR: https://git.openjdk.org/jdk/pull/19548 From jvernee at openjdk.org Thu Jun 6 15:21:50 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 6 Jun 2024 15:21:50 GMT Subject: Integrated: 8333560: -Xlint:restricted does not work with --release In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 18:43:10 GMT, Jorn Vernee wrote: > Currently, `-Xlint:restricted` can be used to print out lint warnings when restricted methods are used in source code compiled by javac. However, this option doesn't work as intended when used in combination with `--release`, and instead no warnings are printed at all. > > Javac relies on the internal `jdk.internal.javac.Restricted` annotation being present on a method in order to determine if a method is restricted. This annotation is however currently being stripped out when generating shim class files that are used by javac to get release-specific symbol information. > > There are already some annotations that are exempt from being stripped away, such as `jdk.internal.javac.PreviewFeature`. The proposed fix is to add `jdk.internal.javac.Restricted` to the list of exempted annotations as well. > > Testing: tier 1-3 This pull request has now been integrated. Changeset: 02f24041 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/02f240415cbda5f67a91af50d5974fb001104170 Stats: 20 lines in 5 files changed: 14 ins; 0 del; 6 mod 8333560: -Xlint:restricted does not work with --release Co-authored-by: Jan Lahoda Reviewed-by: vromero, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/19548 From darcy at openjdk.org Thu Jun 6 16:04:56 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 6 Jun 2024 16:04:56 GMT Subject: Integrated: 8330182: Start of release updates for JDK 24 In-Reply-To: References: Message-ID: On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy wrote: > Get JDK 24 underway. This pull request has now been integrated. Changeset: 75dc2f85 Author: Joe Darcy Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/75dc2f8518d0adea30f7065d6732b807c0220756 Stats: 2083 lines in 50 files changed: 2019 ins; 7 del; 57 mod 8330182: Start of release updates for JDK 24 8330183: Add SourceVersion.RELEASE_24 8330184: Add source 24 and target 24 to javac Reviewed-by: iris, vromero, asotona, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/18787 From hgreule at openjdk.org Thu Jun 6 16:56:53 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Thu, 6 Jun 2024 16:56:53 GMT Subject: RFR: 8328536: javac - crash on unknown type referenced in yield statement [v4] In-Reply-To: References: Message-ID: > Pasting e.g. > > I m(I i, int x) { > return switch (x) { > default -> i; > }; > } > > in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch. > > Javac will not crash but swallow the exception, and create a file containing the command line options. > > I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally. Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into fix/switch-yield-unknown-type-crash # Conflicts: # test/langtools/tools/javac/recovery/AttrRecovery.java - add testcase - Don't bail out early on erroneous type, adjust tests - Merge branch 'master' into fix/switch-yield-unknown-type-crash - Merge branch 'master' into fix/switch-yield-unknown-type-crash - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash - add bug id - Fix jshell crash on unknown type in switch yield ------------- Changes: https://git.openjdk.org/jdk/pull/18383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18383&range=03 Stats: 54 lines in 6 files changed: 47 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18383/head:pull/18383 PR: https://git.openjdk.org/jdk/pull/18383 From darcy at openjdk.org Fri Jun 7 18:03:24 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 7 Jun 2024 18:03:24 GMT Subject: RFR: 8333823: Update --release 23 symbol information for JDK 23 build 26 Message-ID: Usual symbol file update for a new JDK build. ------------- Commit messages: - JDK-8333823: Update --release 23 symbol information for JDK 23 build 26 Changes: https://git.openjdk.org/jdk/pull/19603/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19603&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333823 Stats: 163 lines in 3 files changed: 160 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19603/head:pull/19603 PR: https://git.openjdk.org/jdk/pull/19603 From iris at openjdk.org Fri Jun 7 18:49:12 2024 From: iris at openjdk.org (Iris Clark) Date: Fri, 7 Jun 2024 18:49:12 GMT Subject: RFR: 8333823: Update --release 23 symbol information for JDK 23 build 26 In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 17:59:24 GMT, Joe Darcy wrote: > Usual symbol file update for a new JDK build. Confirmed, change applies to JDK 24 so PR correctly against master branch. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19603#pullrequestreview-2105181057 From jjg at openjdk.org Fri Jun 7 20:36:11 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 7 Jun 2024 20:36:11 GMT Subject: RFR: 8333823: Update --release 23 symbol information for JDK 23 build 26 In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 17:59:24 GMT, Joe Darcy wrote: > Usual symbol file update for a new JDK build. Looks OK to me. ------------- Marked as reviewed by jjg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19603#pullrequestreview-2105319249 From darcy at openjdk.org Fri Jun 7 20:41:16 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 7 Jun 2024 20:41:16 GMT Subject: Integrated: 8333823: Update --release 23 symbol information for JDK 23 build 26 In-Reply-To: References: Message-ID: <2zj1s5HQ7m1O-sArniWZEIaVFSuYmh3P1QjeAIateDQ=.5ca344fb-1503-4f36-915a-81949768ba90@github.com> On Fri, 7 Jun 2024 17:59:24 GMT, Joe Darcy wrote: > Usual symbol file update for a new JDK build. This pull request has now been integrated. Changeset: cf677c90 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/cf677c901e70d98404ec9cc3d75a93926e02fcd2 Stats: 163 lines in 3 files changed: 160 ins; 1 del; 2 mod 8333823: Update --release 23 symbol information for JDK 23 build 26 Reviewed-by: iris, jjg ------------- PR: https://git.openjdk.org/jdk/pull/19603 From mcimadamore at openjdk.org Fri Jun 7 20:51:29 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 7 Jun 2024 20:51:29 GMT Subject: RFR: 8333766: Stack overflow with anonymous class in super() parameter Message-ID: This patch fixes an issue in `LambdaToMethod` where the wrong code is generated to access a symbol in the enclosing scope. `LambdaTranslationContext::addSymbol` has some logic to avoid referring to `T.this` when `T` is a type under construction. This fix works well when a lambda is directly enclosed in a `super` or `this` call, but does not scale to more complex cases, such as the one in this issue. A more complete fix needs to check whether the target `T.this` is really available via a chain of enclosing `this$n` fields. If that's not the case, then `T.this` must be captured by the lambda more directly, as there's no *path* to it from the innermost enclosing this. To detect that, I've added a method (`outerThisReachable`) which more or less mimic the lookup logic in `Lower::makeOwnerThisN`. ------------- Commit messages: - Fix whitespaces - Initial push Changes: https://git.openjdk.org/jdk/pull/19604/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19604&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333766 Stats: 283 lines in 5 files changed: 279 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19604/head:pull/19604 PR: https://git.openjdk.org/jdk/pull/19604 From mcimadamore at openjdk.org Fri Jun 7 20:51:29 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 7 Jun 2024 20:51:29 GMT Subject: RFR: 8333766: Stack overflow with anonymous class in super() parameter In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 18:00:50 GMT, Maurizio Cimadamore wrote: > This patch fixes an issue in `LambdaToMethod` where the wrong code is generated to access a symbol in the enclosing scope. > > `LambdaTranslationContext::addSymbol` has some logic to avoid referring to `T.this` when `T` is a type under construction. This fix works well when a lambda is directly enclosed in a `super` or `this` call, but does not scale to more complex cases, such as the one in this issue. > > A more complete fix needs to check whether the target `T.this` is really available via a chain of enclosing `this$n` fields. If that's not the case, then `T.this` must be captured by the lambda more directly, as there's no *path* to it from the innermost enclosing this. > > To detect that, I've added a method (`outerThisReachable`) which more or less mimic the lookup logic in `Lower::makeOwnerThisN`. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 2121: > 2119: if (skind == CAPTURED_THIS && sym != null && sym.kind == TYP) { > 2120: ClassSymbol currentClass = currentClass(); > 2121: if (currentClass != null && currentClass != sym && !outerThisReachable(currentClass.type, sym)) { There is a subtle change here - note that now if `currentClass == sym` we just skip this part (in this case just using `this` is enough). src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 2134: > 2132: } > 2133: > 2134: private boolean outerThisReachable(Type current, Symbol target) { The idea here is: if we can reach the target symbol from the current one w/o traversing any type under construction, or any type for which `NOOUTERTHIS` is set, then we can consider the target `T.this` reachable. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 2140: > 2138: return true; > 2139: } else { > 2140: return current.tsym.hasOuterInstance() && note that `hasOuterInstance` takes into account the `NOOUTERTHIS` flag, that is, whether the inner class can have an enclosing instance at all. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19604#discussion_r1631536921 PR Review Comment: https://git.openjdk.org/jdk/pull/19604#discussion_r1631539474 PR Review Comment: https://git.openjdk.org/jdk/pull/19604#discussion_r1631538135 From emilia.lopezf.1999 at gmail.com Sat Jun 8 23:16:58 2024 From: emilia.lopezf.1999 at gmail.com (=?UTF-8?Q?Emilia_L=C3=B3pez?=) Date: Sat, 8 Jun 2024 20:16:58 -0300 Subject: javac misalignment with the JLS Message-ID: Hi, Upon reading the JLS, chapter ?7.7.1 Module Declaration - Dependences [1], the spec does not mention anything regarding multiple appearances of the requires modifiers (transitive and static), however javac errs if static is declared multiple times, and if transitive is declared twice or more consecutively, the second time the token is consumed as a module name, despite the BNF indicating any amount of {RequiresModifier} instances; the English description is lacking. Is the Java language specification wrong, lacking or missing in describing this aspect of compilation of modular compilation units? Or does javac not abide by it? [1] https://docs.oracle.com/javase/specs/jls/se22/html/jls-7.html#jls-7.7.1 Regards, Emilia L?pez -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Mon Jun 10 02:38:25 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 10 Jun 2024 02:38:25 GMT Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 Message-ID: Sets the version to 24/24-ea and the copyright year to 2025. Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. This initial generation also picks up the unpublished changes from: - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC - JDK-8284500: Typo in Supported Named Extensions - BasicContraints - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class Thanks ------------- Commit messages: - 8330205: Initial troff manpage generation for JDK 24 Changes: https://git.openjdk.org/jdk/pull/19617/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330205 Stats: 66 lines in 28 files changed: 12 ins; 13 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/19617.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617 PR: https://git.openjdk.org/jdk/pull/19617 From alanb at openjdk.org Mon Jun 10 07:18:11 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 10 Jun 2024 07:18:11 GMT Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 In-Reply-To: References: Message-ID: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com> On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote: > Sets the version to 24/24-ea and the copyright year to 2025. > > Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. > > This initial generation also picks up the unpublished changes from: > > - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC > - JDK-8284500: Typo in Supported Named Extensions - BasicContraints > - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class > > Thanks Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118 From dholmes at openjdk.org Mon Jun 10 08:04:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 10 Jun 2024 08:04:12 GMT Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 In-Reply-To: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com> References: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com> Message-ID: On Mon, 10 Jun 2024 07:15:51 GMT, Alan Bateman wrote: >> Sets the version to 24/24-ea and the copyright year to 2025. >> >> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. >> >> This initial generation also picks up the unpublished changes from: >> >> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC >> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints >> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class >> >> Thanks > > Marked as reviewed by alanb (Reviewer). Thanks for the review @AlanBateman ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2157606095 From gavin.bierman at oracle.com Mon Jun 10 08:43:19 2024 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Mon, 10 Jun 2024 08:43:19 +0000 Subject: javac misalignment with the JLS In-Reply-To: References: Message-ID: <75214109-347B-4293-82EC-9C775A6D2DFA@oracle.com> Hi Emilia, Thanks. Could you file this as a bug and I?ll attend to it? Cheers, Gavin On 9 Jun 2024, at 00:16, Emilia L?pez wrote: Hi, Upon reading the JLS, chapter ?7.7.1 Module Declaration - Dependences [1], the spec does not mention anything regarding multiple appearances of the requires modifiers (transitive and static), however javac errs if static is declared multiple times, and if transitive is declared twice or more consecutively, the second time the token is consumed as a module name, despite the BNF indicating any amount of {RequiresModifier} instances; the English description is lacking. Is the Java language specification wrong, lacking or missing in describing this aspect of compilation of modular compilation units? Or does javac not abide by it? [1] https://docs.oracle.com/javase/specs/jls/se22/html/jls-7.html#jls-7.7.1 Regards, Emilia L?pez -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Mon Jun 10 11:14:27 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 10 Jun 2024 11:14:27 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory [v7] 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 17 commits: - 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 - Adjust test for new error messages - ... and 7 more: https://git.openjdk.org/jdk/compare/7b43a8cd...2bd13ece ------------- Changes: https://git.openjdk.org/jdk/pull/2752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=06 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 pminborg at openjdk.org Mon Jun 10 11:55:29 2024 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 10 Jun 2024 11:55:29 GMT Subject: RFR: 8330465: Stable Values and Collections (Internal) [v20] In-Reply-To: References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com> Message-ID: On Fri, 17 May 2024 09:31:33 GMT, Per Minborg wrote: >> # Stable Values & Collections (Internal) >> >> ## Summary >> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization. >> >> ## Goals >> * Provide an easy and intuitive API to describe value holders that can change at most once. >> * Decouple declaration from initialization without significant footprint or performance penalties. >> * Reduce the amount of static initializer and/or field initialization code. >> * Uphold integrity and consistency, even in a multi-threaded environment. >> >> For more details, see the draft JEP: https://openjdk.org/jeps/8312611 >> >> ## Performance >> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads: >> >> >> Benchmark Mode Cnt Score Error Units >> StableBenchmark.atomic thrpt 10 259.478 ? 36.809 ops/us >> StableBenchmark.dcl thrpt 10 225.710 ? 26.638 ops/us >> StableBenchmark.stable thrpt 10 4382.478 ? 1151.472 ops/us <- StableValue significantly faster >> >> >> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads): >> >> >> Benchmark Mode Cnt Score Error Units >> StableStaticBenchmark.atomic thrpt 10 6487.835 ? 385.639 ops/us >> StableStaticBenchmark.dcl thrpt 10 6605.239 ? 210.610 ops/us >> StableStaticBenchmark.stable thrpt 10 14338.239 ? 1426.874 ops/us >> StableStaticBenchmark.staticCHI thrpt 10 13780.341 ? 1839.651 ops/us >> >> >> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads): >> >> >> Benchmark Mode Cnt Score Error Units >> StableListElementBenchmark.instanceArrayList thrpt 10 5812.992 ? 1169.730 ops/us >> StableListElementBenchmark.instanceList thrpt 10 4818.643 ? 704.893 ops/us >> StableListElementBenchmark... > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Add benchmarks for memoized IntFunction and Function > - Add benchmark for memoized supplier A new PR will be made available shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2158140833 From pminborg at openjdk.org Mon Jun 10 11:55:30 2024 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 10 Jun 2024 11:55:30 GMT Subject: Withdrawn: 8330465: Stable Values and Collections (Internal) In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com> References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com> Message-ID: On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote: > # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization. > > ## Goals > * Provide an easy and intuitive API to describe value holders that can change at most once. > * Decouple declaration from initialization without significant footprint or performance penalties. > * Reduce the amount of static initializer and/or field initialization code. > * Uphold integrity and consistency, even in a multi-threaded environment. > > For more details, see the draft JEP: https://openjdk.org/jeps/8312611 > > ## Performance > Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads: > > > Benchmark Mode Cnt Score Error Units > StableBenchmark.atomic thrpt 10 259.478 ? 36.809 ops/us > StableBenchmark.dcl thrpt 10 225.710 ? 26.638 ops/us > StableBenchmark.stable thrpt 10 4382.478 ? 1151.472 ops/us <- StableValue significantly faster > > > Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads): > > > Benchmark Mode Cnt Score Error Units > StableStaticBenchmark.atomic thrpt 10 6487.835 ? 385.639 ops/us > StableStaticBenchmark.dcl thrpt 10 6605.239 ? 210.610 ops/us > StableStaticBenchmark.stable thrpt 10 14338.239 ? 1426.874 ops/us > StableStaticBenchmark.staticCHI thrpt 10 13780.341 ? 1839.651 ops/us > > > Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads): > > > Benchmark Mode Cnt Score Error Units > StableListElementBenchmark.instanceArrayList thrpt 10 5812.992 ? 1169.730 ops/us > StableListElementBenchmark.instanceList thrpt 10 4818.643 ? 704.893 ops/us > StableListElementBenchmark.staticArrayList thrpt 10 7614.741 ? 564.777 ops/us > StableListElementBe... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18794 From emilia.lopezf.1999 at gmail.com Mon Jun 10 15:29:02 2024 From: emilia.lopezf.1999 at gmail.com (=?UTF-8?Q?Emilia_L=C3=B3pez?=) Date: Mon, 10 Jun 2024 12:29:02 -0300 Subject: javac misalignment with the JLS In-Reply-To: <75214109-347B-4293-82EC-9C775A6D2DFA@oracle.com> References: <75214109-347B-4293-82EC-9C775A6D2DFA@oracle.com> Message-ID: Hi Gavin, I submitted a bug report through the bug database submission form and it is awaiting triage, thanks. Regards, Emilia L?pez On Mon, 10 Jun 2024 at 05:43, Gavin Bierman wrote: > > Hi Emilia, > > Thanks. Could you file this as a bug and I?ll attend to it? > > Cheers, > Gavin > > On 9 Jun 2024, at 00:16, Emilia L?pez wrote: > > Hi, > > Upon reading the JLS, chapter ?7.7.1 Module Declaration - Dependences [1], the spec does not mention anything regarding multiple appearances of the requires modifiers (transitive and static), however javac errs if static is declared multiple times, and if transitive is declared twice or more consecutively, the second time the token is consumed as a module name, despite the BNF indicating any amount of {RequiresModifier} instances; the English description is lacking. Is the Java language specification wrong, lacking or missing in describing this aspect of compilation of modular compilation units? Or does javac not abide by it? > > [1] https://docs.oracle.com/javase/specs/jls/se22/html/jls-7.html#jls-7.7.1 > > Regards, > Emilia L?pez > > From iris at openjdk.org Mon Jun 10 17:30:15 2024 From: iris at openjdk.org (Iris Clark) Date: Mon, 10 Jun 2024 17:30:15 GMT Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 In-Reply-To: References: Message-ID: On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote: > Sets the version to 24/24-ea and the copyright year to 2025. > > Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. > > This initial generation also picks up the unpublished changes from: > > - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC > - JDK-8284500: Typo in Supported Named Extensions - BasicContraints > - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class > > Thanks Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2108383696 From dnguyen at openjdk.org Mon Jun 10 20:05:33 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 10 Jun 2024 20:05:33 GMT Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update Message-ID: This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n: https://cr.openjdk.org/~dnguyen/output2/ ------------- Commit messages: - Review comment edits - Initial localization changes Changes: https://git.openjdk.org/jdk/pull/19609/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333827 Stats: 239 lines in 39 files changed: 133 ins; 57 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/19609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609 PR: https://git.openjdk.org/jdk/pull/19609 From achung at openjdk.org Mon Jun 10 20:05:33 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 10 Jun 2024 20:05:33 GMT Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. > > The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. > > Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n: > https://cr.openjdk.org/~dnguyen/output2/ Just a question about the reverted translations, otherwise LGTM > The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. Any particular reason you know that the tool had the definitions adjusted? I see some of the changes look like like command line options not being translated, but it's a bit hard to tell. Do you know if the reverted words should be translated (and possibly will be re-translated in future drops?) or should they be left untranslated? ------------- PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2105526180 PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2155723513 From jlu at openjdk.org Mon Jun 10 20:05:33 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 10 Jun 2024 20:05:33 GMT Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com> On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. > > The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. > > Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n: > https://cr.openjdk.org/~dnguyen/output2/ Cannot speak to the translations themselves, but in general the changes LGTM pending the comments. src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 1: > 1: # It looks like these .properties files need to have their copyright years bumped. I believe since the original was not bumped, the translation tool did not reflect the correct year in the localized versions. src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 66: > 64: label.size=??(&Z): > 65: label.source=??(&C): > 66: label.outputbins=????(&P)? Looks like the translation tool changed this from a colon (U+003A) to a full width colon (U+FF1A). There are l10n rules when it comes to punctuation, I am not sure if this is a result of that. It looks like the surrounding key/values are simply using (U+003A) colons. If we decide to revert this colon change, we need to also probably file a bug against the translation tool. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278: > 276: UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}". > 277: UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden. > 278: ENTITYFailedInitializeGrammar = ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool. src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 285: > 283: VIRTUAL_MACHINE=Virtuelle Maschine > 284: VM_ARGUMENTS=VM-Argumente > 285: VMINTERNAL_FRAME_ACCESSIBLE_DESCRIPTION=Innerer Frame f?r das Monitoring einer Java Virtual Machine This one-off change is consistent with the change in _src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java_. src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183: > 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts > 182: > 183: help.usage = Verwendung: jshell