From darcy at openjdk.java.net Mon Jan 3 18:33:35 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 3 Jan 2022 18:33:35 GMT Subject: RFR: JDK-8277515: Update --release 18 symbol information for JDK 18 build 29 Message-ID: Usual update to the JDK 19 symbol files for changes in JDK 18; this time JDK-8276660 in JDK 18 build 28. ------------- Commit messages: - JDK-8277515: Update --release 18 symbol information for JDK 18 build 29 Changes: https://git.openjdk.java.net/jdk/pull/6948/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6948&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277515 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6948/head:pull/6948 PR: https://git.openjdk.java.net/jdk/pull/6948 From iris at openjdk.java.net Mon Jan 3 19:16:20 2022 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 3 Jan 2022 19:16:20 GMT Subject: RFR: JDK-8277515: Update --release 18 symbol information for JDK 18 build 29 In-Reply-To: References: Message-ID: On Mon, 3 Jan 2022 18:26:24 GMT, Joe Darcy wrote: > Usual update to the JDK 19 symbol files for changes in JDK 18; this time JDK-8276660 in JDK 18 build 28. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6948 From jjg at openjdk.java.net Mon Jan 3 21:50:18 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 3 Jan 2022 21:50:18 GMT Subject: [jdk18] RFR: JDK-8273452: DocTrees.getDocCommentTree should be specified as idempotent In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 11:05:01 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to add implementation notes to the `DocTrees.getDocCommentTree` methods, some of which return the same `DocCommentTree` instance on repeated invocation and some don't. I decided to use `@implNote` instead of `@implSpec` as usually I wouldn't expect object identity to be part of a Java API specification. > > I verified the described behavior using code analysis and enhancing existing tests. The latter are not included in the commit as this is a `noreg-doc` issue. I guess it's a gray area whether it should be an `implSpec` or an `implNote`. It is a relatively important aspect of the API, because the operations are expensive, and even cause some downstream caching. For now, it's enough that it is noted in some fashion. As a general style note, I would suggest a blank line before each `implNote`, and change "The implementation of this method" to either "The default implementation of this method" or just "This implementation". ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/36 From jlahoda at openjdk.java.net Tue Jan 4 17:27:28 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 4 Jan 2022 17:27:28 GMT Subject: [jdk18] RFR: 8278373: JavacTypes.searchMethod finds incorrect match Message-ID: Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method. In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases. This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here: http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff ------------- Commit messages: - 8278373: JavacTypes.searchMethod finds incorrect match Changes: https://git.openjdk.java.net/jdk18/pull/79/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=79&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278373 Stats: 70 lines in 2 files changed: 52 ins; 2 del; 16 mod Patch: https://git.openjdk.java.net/jdk18/pull/79.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/79/head:pull/79 PR: https://git.openjdk.java.net/jdk18/pull/79 From vromero at openjdk.java.net Tue Jan 4 19:50:15 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 4 Jan 2022 19:50:15 GMT Subject: [jdk18] RFR: 8278373: JavacTypes.searchMethod finds incorrect match In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda wrote: > Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method. > > In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases. > > This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here: > http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff looks sensible will we need a release note for this bug? it could be that some user's APIs could be affected by this change ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/79 From jjg at openjdk.java.net Tue Jan 4 19:54:15 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 4 Jan 2022 19:54:15 GMT Subject: [jdk18] RFR: 8278373: JavacTypes.searchMethod finds incorrect match In-Reply-To: References: Message-ID: <3nXgEPemHZli72G96ehNbbHt5-Hc1WMc4UqP1wrP7z8=.84935fb2-c8d3-4906-8da6-72aab0dc9828@github.com> On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda wrote: > Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method. > > In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases. > > This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here: > http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff Generally good; I think this is the right fix in the current situation and for potential back porting. It provides improved but compatible behavior. The API diffs were an unexpected "bonus", if that is the right word. It's better to know about and fix issues than to not know about them. I've spot checked a few of them and all seem reasonable. The fix is especially obvious when the link and the clear-text are different and meant to be the same. The one thing I would suggest is that because a lot of the api diffs are related to "subtyping" between primitive types, we might want to add some test cases for that into the test as well. Here is a random example of the kind of diff I'm talking about: ``` - as if by calling Math.max. + as if by calling Math.max. Further out (JDK 19?) I think we should investigate the need for the `strict == false` case and/or give warnings (in javadoc) when the lookup is not exact. We should fix any cases in the JDK docs where that is the case, and/or consider removing support for `strict == false` or else make it an opt-in behavior somehow. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/79 From jjg at openjdk.java.net Tue Jan 4 20:03:18 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 4 Jan 2022 20:03:18 GMT Subject: [jdk18] RFR: 8278373: JavacTypes.searchMethod finds incorrect match In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda wrote: > Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method. > > In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases. > > This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here: > http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff > [snip] > > Further out (JDK 19?) I think we should investigate the need for the `strict == false` case and/or give warnings (in javadoc) when the lookup is not exact. We should fix any cases in the JDK docs where that is the case, and/or consider removing support for `strict == false` or else make it an opt-in behavior somehow. Filed JDK-8279474 ------------- PR: https://git.openjdk.java.net/jdk18/pull/79 From vromero at openjdk.java.net Tue Jan 4 21:12:17 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 4 Jan 2022 21:12:17 GMT Subject: RFR: 8211004: javac is complaining about non-denotable types and refusing to generate the class file In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 21:35:24 GMT, Vicente Romero wrote: > Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code, > > TIA ping ------------- PR: https://git.openjdk.java.net/jdk/pull/6886 From jlahoda at openjdk.java.net Wed Jan 5 14:37:02 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 5 Jan 2022 14:37:02 GMT Subject: [jdk18] RFR: 8278373: JavacTrees.searchMethod finds incorrect match [v2] In-Reply-To: References: Message-ID: > Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method. > > In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases. > > This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here: > http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8278373 - Adding new test cases as suggested on the code review. - 8278373: JavacTypes.searchMethod finds incorrect match ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/79/files - new: https://git.openjdk.java.net/jdk18/pull/79/files/8c0ad7f0..0c88aa60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=79&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=79&range=00-01 Stats: 137 lines in 5 files changed: 116 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/jdk18/pull/79.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/79/head:pull/79 PR: https://git.openjdk.java.net/jdk18/pull/79 From jlahoda at openjdk.java.net Wed Jan 5 14:37:03 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 5 Jan 2022 14:37:03 GMT Subject: [jdk18] RFR: 8278373: JavacTrees.searchMethod finds incorrect match In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda wrote: > Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method. > > In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases. > > This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here: > http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff I've filled a release note here: https://bugs.openjdk.java.net/browse/JDK-8279503 And updated the patch to include primitive types and methods with multiple parameters: https://github.com/openjdk/jdk18/pull/79/commits/34e421b96fa7f4e7e20aec16bb758056191b8773 Feedback is welcome! ------------- PR: https://git.openjdk.java.net/jdk18/pull/79 From vromero at openjdk.java.net Wed Jan 5 16:48:23 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 5 Jan 2022 16:48:23 GMT Subject: [jdk18] RFR: 8278373: JavacTrees.searchMethod finds incorrect match [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 14:37:02 GMT, Jan Lahoda wrote: >> Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method. >> >> In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases. >> >> This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here: >> http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8278373 > - Adding new test cases as suggested on the code review. > - 8278373: JavacTypes.searchMethod finds incorrect match latest change looks good to me ------------- PR: https://git.openjdk.java.net/jdk18/pull/79 From shade at openjdk.java.net Wed Jan 5 17:06:38 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 5 Jan 2022 17:06:38 GMT Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187 Message-ID: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it. ------------- Commit messages: - 8279528: Unused TypeEnter.diag after JDK-8205187 Changes: https://git.openjdk.java.net/jdk/pull/6971/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6971&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279528 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6971/head:pull/6971 PR: https://git.openjdk.java.net/jdk/pull/6971 From vromero at openjdk.java.net Wed Jan 5 18:55:15 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 5 Jan 2022 18:55:15 GMT Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187 In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> Message-ID: On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev wrote: > SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6971 From darcy at openjdk.java.net Wed Jan 5 18:59:16 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 Jan 2022 18:59:16 GMT Subject: Integrated: JDK-8277515: Update --release 18 symbol information for JDK 18 build 29 In-Reply-To: References: Message-ID: On Mon, 3 Jan 2022 18:26:24 GMT, Joe Darcy wrote: > Usual update to the JDK 19 symbol files for changes in JDK 18; this time JDK-8276660 in JDK 18 build 28. This pull request has now been integrated. Changeset: 9a0e8900 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/9a0e890056fb8ae4e28e656118e73fae33ba5e2a Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8277515: Update --release 18 symbol information for JDK 18 build 29 Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/6948 From jlahoda at openjdk.java.net Wed Jan 5 20:29:10 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 5 Jan 2022 20:29:10 GMT Subject: RFR: 8211004: javac is complaining about non-denotable types and refusing to generate the class file In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 21:35:24 GMT, Vicente Romero wrote: > Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code, > > TIA Looks reasonable. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6886 From vromero at openjdk.java.net Wed Jan 5 20:57:16 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 5 Jan 2022 20:57:16 GMT Subject: RFR: 8211004: javac is complaining about non-denotable types and refusing to generate the class file In-Reply-To: References: Message-ID: <3k3decu-1toNuG1Q0uN-3euSdjIQtzsSKWb2UrRyYjQ=.dc6f8e55-12cf-4a19-99cc-73d2766bb334@github.com> On Fri, 17 Dec 2021 21:35:24 GMT, Vicente Romero wrote: > Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code, > > TIA thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/6886 From vromero at openjdk.java.net Wed Jan 5 21:02:50 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 5 Jan 2022 21:02:50 GMT Subject: RFR: 8211004: javac is complaining about non-denotable types and refusing to generate the class file [v2] In-Reply-To: References: Message-ID: <_WdYX7Q-jQ-oy8yPI9oMPc6NtEx5X3Alj1HGnmXCXO4=.85e3d29f-7ce4-446a-bde8-8dbef9650239@github.com> > Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code, > > TIA Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8211004 - 8211004: javac is complaining about non-denotable types and refusing to generate the class file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6886/files - new: https://git.openjdk.java.net/jdk/pull/6886/files/ed719136..a50d57b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6886&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6886&range=00-01 Stats: 13046 lines in 494 files changed: 7907 ins; 3309 del; 1830 mod Patch: https://git.openjdk.java.net/jdk/pull/6886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6886/head:pull/6886 PR: https://git.openjdk.java.net/jdk/pull/6886 From vromero at openjdk.java.net Thu Jan 6 05:57:41 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 6 Jan 2022 05:57:41 GMT Subject: RFR: 8279290: symbol not found error, implicit lambdas and diamond constructor invocations Message-ID: Please review this PR which is fixing a bug caused by scope sharing. In particular for code like: class Test { static class B{} static class A1 { A1(Consumer cons) {} } void foo() { new A1(findMe -> new B<>() {{ System.out.println(findMe); // javac is failing here with symbol not found for findMe }}); } } the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch. TIA ------------- Commit messages: - 8279290: symbol not found error, implicit lambdas and diamond constructor invocations Changes: https://git.openjdk.java.net/jdk/pull/6977/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6977&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279290 Stats: 56 lines in 2 files changed: 55 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6977.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6977/head:pull/6977 PR: https://git.openjdk.java.net/jdk/pull/6977 From vromero at openjdk.java.net Thu Jan 6 06:02:13 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 6 Jan 2022 06:02:13 GMT Subject: Integrated: 8211004: javac is complaining about non-denotable types and refusing to generate the class file In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 21:35:24 GMT, Vicente Romero wrote: > Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code, > > TIA This pull request has now been integrated. Changeset: 456bd1ed Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/456bd1ed1cbfedc225194e9afb917b913e5bc9d5 Stats: 21 lines in 8 files changed: 15 ins; 1 del; 5 mod 8211004: javac is complaining about non-denotable types and refusing to generate the class file Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/6886 From jlahoda at openjdk.java.net Thu Jan 6 13:57:54 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 6 Jan 2022 13:57:54 GMT Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements Message-ID: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class. An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.) The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing. ------------- Commit messages: - 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements Changes: https://git.openjdk.java.net/jdk18/pull/85/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=85&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278930 Stats: 176 lines in 2 files changed: 174 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk18/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/85/head:pull/85 PR: https://git.openjdk.java.net/jdk18/pull/85 From vromero at openjdk.java.net Thu Jan 6 18:05:15 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 6 Jan 2022 18:05:15 GMT Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> Message-ID: On Thu, 6 Jan 2022 13:48:40 GMT, Jan Lahoda wrote: > When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class. > > An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.) > > The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/85 From jjg at openjdk.java.net Fri Jan 7 00:04:30 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 7 Jan 2022 00:04:30 GMT Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> Message-ID: <41Z2LFC6BkhV7HGN69D8LrcU4iYdlUlHY3hZy_jiuSk=.d9e5b807-4ccf-474f-b755-04fe70c4bcf6@github.com> On Thu, 6 Jan 2022 13:48:40 GMT, Jan Lahoda wrote: > When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class. > > An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.) > > The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing. The change to the code looks plausible, but I'm not expert enough to approve it. Check copyright years on modified files. test/langtools/tools/javac/processing/model/element/TestListPackageFromAPI.java line 2: > 1: /* > 2: * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved. Copyright year? test/langtools/tools/javac/processing/model/element/TestListPackageFromAPI.java line 70: > 68: Files.newOutputStream(classes.resolve("Test.class")).close(); > 69: > 70: Thread.sleep(2000); Mild ugh ------------- PR: https://git.openjdk.java.net/jdk18/pull/85 From shade at openjdk.java.net Fri Jan 7 07:07:16 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 7 Jan 2022 07:07:16 GMT Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187 In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> Message-ID: <79Ue7vVCiMqu6aprAVwkJpBF2C7ZV89MzBByd8HKZIg=.6da5dca7-5767-4a1f-81ff-ac8775258963@github.com> On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev wrote: > SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it. Thanks, more reviewers needed, or is this change simple enough? ------------- PR: https://git.openjdk.java.net/jdk/pull/6971 From cushon at openjdk.java.net Fri Jan 7 11:32:16 2022 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Fri, 7 Jan 2022 11:32:16 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v3] In-Reply-To: References: Message-ID: <72IPi3oS8KX5xaCsQWGxR09xzHMNpFK3PySyQv8g8TA=.c273cd54-1473-40e0-95fe-311d595c02e7@github.com> On Tue, 12 Oct 2021 07:23:32 GMT, Jan Lahoda wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Document the rationale for the jasm changes > > How about code like: > > StringBuilder builder2 = new StringBuilder("foo"); > Object oo = builder2; > oo += "" + builder2.append("bar"); > > > Should that be covered as well? From looking at the patch (not really trying it), it does not seem to be covered? @lahodaj would you be willing to review for the compiler group? ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From jlahoda at openjdk.java.net Fri Jan 7 12:41:07 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 7 Jan 2022 12:41:07 GMT Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements [v2] In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> Message-ID: > When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class. > > An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.) > > The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Test cleanup. ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/85/files - new: https://git.openjdk.java.net/jdk18/pull/85/files/c3473de4..6bef38f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=85&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=85&range=00-01 Stats: 41 lines in 1 file changed: 7 ins; 26 del; 8 mod Patch: https://git.openjdk.java.net/jdk18/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/85/head:pull/85 PR: https://git.openjdk.java.net/jdk18/pull/85 From jlahoda at openjdk.java.net Fri Jan 7 12:47:05 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 7 Jan 2022 12:47:05 GMT Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements [v3] In-Reply-To: <41Z2LFC6BkhV7HGN69D8LrcU4iYdlUlHY3hZy_jiuSk=.d9e5b807-4ccf-474f-b755-04fe70c4bcf6@github.com> References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> <41Z2LFC6BkhV7HGN69D8LrcU4iYdlUlHY3hZy_jiuSk=.d9e5b807-4ccf-474f-b755-04fe70c4bcf6@github.com> Message-ID: On Thu, 6 Jan 2022 23:58:29 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating year. > > test/langtools/tools/javac/processing/model/element/TestListPackageFromAPI.java line 70: > >> 68: Files.newOutputStream(classes.resolve("Test.class")).close(); >> 69: >> 70: Thread.sleep(2000); > > Mild ugh. What condition are you waiting for? Are you waiting for file timestamps to be newer, or something like that? Can you "poll" looking for the desired change instead? Thanks for the comment! It was waiting to reliably make the timestamps different, but I've cleaned up the test here to avoid that: https://github.com/openjdk/jdk18/pull/85/commits/6bef38f54e791092eb88843c766d8f5d064ac9c5 ------------- PR: https://git.openjdk.java.net/jdk18/pull/85 From jlahoda at openjdk.java.net Fri Jan 7 12:47:04 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 7 Jan 2022 12:47:04 GMT Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements [v3] In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> Message-ID: > When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class. > > An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.) > > The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Updating year. ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/85/files - new: https://git.openjdk.java.net/jdk18/pull/85/files/6bef38f5..b051fdc4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=85&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=85&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk18/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/85/head:pull/85 PR: https://git.openjdk.java.net/jdk18/pull/85 From vromero at openjdk.java.net Fri Jan 7 14:26:16 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 7 Jan 2022 14:26:16 GMT Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187 In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> Message-ID: On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev wrote: > SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it. usually one reviewer is enough, unless it is a big change ------------- PR: https://git.openjdk.java.net/jdk/pull/6971 From vromero at openjdk.java.net Fri Jan 7 17:22:30 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 7 Jan 2022 17:22:30 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v5] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 17:14:42 GMT, Liam Miller-Cushon wrote: >> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Rename WellKnownTypes to WellKnownTypeSignatures > > and add more functional test coverage for string concat of well-known > types, covering all strategies. the compiler changes look good to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5844 From jlahoda at openjdk.java.net Fri Jan 7 18:18:29 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 7 Jan 2022 18:18:29 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v5] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 17:14:42 GMT, Liam Miller-Cushon wrote: >> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Rename WellKnownTypes to WellKnownTypeSignatures > > and add more functional test coverage for string concat of well-known > types, covering all strategies. Looks reasonable. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5844 From shade at openjdk.java.net Mon Jan 10 08:34:32 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 10 Jan 2022 08:34:32 GMT Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187 In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> Message-ID: On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev wrote: > SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it. All right then, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/6971 From shade at openjdk.java.net Mon Jan 10 08:34:33 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 10 Jan 2022 08:34:33 GMT Subject: Integrated: 8279528: Unused TypeEnter.diag after JDK-8205187 In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com> Message-ID: On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev wrote: > SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it. This pull request has now been integrated. Changeset: 4aefd8b8 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/4aefd8b8b6cd76137e3bc51a84d1182fde22ba02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8279528: Unused TypeEnter.diag after JDK-8205187 Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/6971 From jlahoda at openjdk.java.net Mon Jan 10 08:38:39 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 10 Jan 2022 08:38:39 GMT Subject: [jdk18] Integrated: 8278373: JavacTrees.searchMethod finds incorrect match In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda wrote: > Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method. > > In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases. > > This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here: > http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff This pull request has now been integrated. Changeset: 642ab34a Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk18/commit/642ab34a60172f4b629f953e146b54b9c7269033 Stats: 89 lines in 2 files changed: 71 ins; 2 del; 16 mod 8278373: JavacTrees.searchMethod finds incorrect match Reviewed-by: vromero, jjg ------------- PR: https://git.openjdk.java.net/jdk18/pull/79 From jlahoda at openjdk.java.net Mon Jan 10 09:34:43 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 10 Jan 2022 09:34:43 GMT Subject: [jdk18] Integrated: 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com> Message-ID: On Thu, 6 Jan 2022 13:48:40 GMT, Jan Lahoda wrote: > When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class. > > An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.) > > The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing. This pull request has now been integrated. Changeset: 8f969a13 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk18/commit/8f969a1362343df8592046a838436f41894ee471 Stats: 158 lines in 2 files changed: 155 ins; 0 del; 3 mod 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk18/pull/85 From duke at openjdk.java.net Mon Jan 10 11:08:52 2022 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 10 Jan 2022 11:08:52 GMT Subject: RFR: 8274425: Remove unused Modules.extraLimitMods [v2] In-Reply-To: <3XU4OpaQ6kW3DXLru4uScWtbIQBiYgHyoUPBdkkoo-g=.bd1ac042-fb54-4b37-9433-d4c0c5990e6f@github.com> References: <3XU4OpaQ6kW3DXLru4uScWtbIQBiYgHyoUPBdkkoo-g=.bd1ac042-fb54-4b37-9433-d4c0c5990e6f@github.com> Message-ID: <_VSeie5GC-sPX0apREmPYJCW__5cwX-EdClVUMJMlls=.84b4e3eb-7f53-438a-b180-588e67d9f3df@github.com> > HashSet `com.sun.tools.javac.comp.Modules.extraLimitMods` is always empty. Code only check its content, but no content added. > There was a method `addExtraLimitModules`, but it was removed under [JDK-8175191](https://bugs.openjdk.java.net/browse/JDK-8175191) 253fdcd0b26 > Method `addExtraLimitModules` itself was added in ec9ca2997f4, but was never actually used . Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8274425: Remove unused Modules.extraLimitMods update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5628/files - new: https://git.openjdk.java.net/jdk/pull/5628/files/72bf4ca3..54113676 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5628&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5628&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5628.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5628/head:pull/5628 PR: https://git.openjdk.java.net/jdk/pull/5628 From hannesw at openjdk.java.net Mon Jan 10 11:46:06 2022 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 Jan 2022 11:46:06 GMT Subject: [jdk18] RFR: JDK-8273452: DocTrees.getDocCommentTree should be specified as idempotent [v2] In-Reply-To: References: Message-ID: > Please review a doc-only change to add implementation notes to the `DocTrees.getDocCommentTree` methods, some of which return the same `DocCommentTree` instance on repeated invocation and some don't. I decided to use `@implNote` instead of `@implSpec` as usually I wouldn't expect object identity to be part of a Java API specification. > > I verified the described behavior using code analysis and enhancing existing tests. The latter are not included in the commit as this is a `noreg-doc` issue. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8273452: review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/36/files - new: https://git.openjdk.java.net/jdk18/pull/36/files/f69a1052..66cbd42b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=36&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=36&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk18/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/36/head:pull/36 PR: https://git.openjdk.java.net/jdk18/pull/36 From hannesw at openjdk.java.net Mon Jan 10 12:07:29 2022 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 Jan 2022 12:07:29 GMT Subject: [jdk18] Integrated: JDK-8273452: DocTrees.getDocCommentTree should be specified as idempotent In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 11:05:01 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to add implementation notes to the `DocTrees.getDocCommentTree` methods, some of which return the same `DocCommentTree` instance on repeated invocation and some don't. I decided to use `@implNote` instead of `@implSpec` as usually I wouldn't expect object identity to be part of a Java API specification. > > I verified the described behavior using code analysis and enhancing existing tests. The latter are not included in the commit as this is a `noreg-doc` issue. This pull request has now been integrated. Changeset: 354c9047 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk18/commit/354c9047987c0837d95440780993a0aa84551ea1 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod 8273452: DocTrees.getDocCommentTree should be specified as idempotent Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk18/pull/36 From jwilhelm at openjdk.java.net Mon Jan 10 17:10:40 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 10 Jan 2022 17:10:40 GMT Subject: Integrated: Merge jdk18 Message-ID: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com> Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8274679: Remove unnecessary conversion to String in security code in java.base - 8142362: Lots of code duplication in Copy class - 8218857: Confusing overloads for os::open - 8183227: read/write APIs in class os shall return ssize_t - 8279300: [arm32] SIGILL when running GetObjectSizeIntrinsicsTest - 8278329: some TraceDeoptimization code not included in PRODUCT build - 8279523: Parallel: Remove unnecessary PSScavenge::_to_space_top_before_gc - 8279522: Serial: Remove unused Generation::clear_remembered_set - 8279528: Unused TypeEnter.diag after JDK-8205187 - ... and 163 more: https://git.openjdk.java.net/jdk/compare/40df5df9...6ff1c607 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/7017/files Stats: 27994 lines in 750 files changed: 20678 ins; 5315 del; 2001 mod Patch: https://git.openjdk.java.net/jdk/pull/7017.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7017/head:pull/7017 PR: https://git.openjdk.java.net/jdk/pull/7017 From jwilhelm at openjdk.java.net Mon Jan 10 17:10:41 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 10 Jan 2022 17:10:41 GMT Subject: Integrated: Merge jdk18 In-Reply-To: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com> References: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com> Message-ID: On Mon, 10 Jan 2022 17:00:05 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: d9b1bb58 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/d9b1bb58600c03cee43387864d1530d4dd5f1422 Stats: 615 lines in 24 files changed: 478 ins; 77 del; 60 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7017 From cushon at openjdk.java.net Tue Jan 11 15:48:34 2022 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Tue, 11 Jan 2022 15:48:34 GMT Subject: Integrated: JDK-8273914: Indy string concat changes order of operations In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 21:00:04 GMT, Liam Miller-Cushon wrote: > This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. This pull request has now been integrated. Changeset: cfee4512 Author: Liam Miller-Cushon URL: https://git.openjdk.java.net/jdk/commit/cfee4512f7048e9cf440078e9eb87d37c7ebcdd9 Stats: 532 lines in 8 files changed: 473 ins; 20 del; 39 mod 8273914: Indy string concat changes order of operations Reviewed-by: vromero, jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From vromero at openjdk.java.net Wed Jan 12 16:51:28 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 12 Jan 2022 16:51:28 GMT Subject: RFR: 8279290: symbol not found error, implicit lambdas and diamond constructor invocations In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 05:42:49 GMT, Vicente Romero wrote: > Please review this PR which is fixing a bug caused by scope sharing. In particular for code like: > > class Test { > static class B{} > > static class A1 { > A1(Consumer cons) {} > } > > void foo() { > new A1(findMe -> > new B<>() {{ > System.out.println(findMe); // javac is failing here with symbol not found for findMe > }}); > } > } > > the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch. > > TIA ping ------------- PR: https://git.openjdk.java.net/jdk/pull/6977 From prappo at openjdk.java.net Thu Jan 13 10:35:39 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 10:35:39 GMT Subject: RFR: 8279918: Fix various doc typos Message-ID: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> - Most of the typos are of a trivial kind: missing whitespace. - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. - ' is an apostrophe, which does not require to be encoded. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/7063/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279918 Stats: 85 lines in 34 files changed: 0 ins; 0 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/7063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7063/head:pull/7063 PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 10:49:28 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 10:49:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - ' is an apostrophe, which does not require to be encoded. src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73: > 71: * will be transparent to the BreakIterator.  A sequence of characters will break the > 72: * same way it would if any ignore characters it contains are taken out.  Break > 73: * positions never occur before ignore characters.

"before ignored characters" ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 11:04:28 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 11:04:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com> On Thu, 13 Jan 2022 10:46:11 GMT, Kevin Walls wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - ' is an apostrophe, which does not require to be encoded. > > src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73: > >> 71: * will be transparent to the BreakIterator.  A sequence of characters will break the >> 72: * same way it would if any ignore characters it contains are taken out.  Break >> 73: * positions never occur before ignore characters.

> > "before ignored characters" I believe it's the name of a concept, so I will leave it as is: > There is one special substitution. If the description defines a substitution called "", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 11:04:28 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 11:04:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - ' is an apostrophe, which does not require to be encoded. src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58: > 56: * A JDBC driver implementation should use > 57: * the constructor {@code BatchUpdateException(String reason, String SQLState, > 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type. Similarly at line 81, 118, 151, 247, 277, 318, 354. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 11:07:28 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 11:07:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> Message-ID: On Thu, 13 Jan 2022 11:00:55 GMT, Kevin Walls wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - ' is an apostrophe, which does not require to be encoded. > > src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58: > >> 56: * A JDBC driver implementation should use >> 57: * the constructor {@code BatchUpdateException(String reason, String SQLState, >> 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of > > While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type. > Similarly at line 81, 118, 151, 247, 277, 318, 354. I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 11:21:27 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 11:21:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. src/java.sql/share/classes/java/sql/Statement.java line 784: > 782: * statement returns a {@code ResultSet} object, the second argument > 783: * supplied to this method is not an > 784: * {@code int} array whose elements are valid column indexes, the method is called on a Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives. It probably does not mean that all these have to be true to throw the exception, but it doesn't say that. We are nitpicking of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 11:33:27 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 11:33:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 11:33:27 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 11:33:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> Message-ID: On Thu, 13 Jan 2022 11:04:43 GMT, Pavel Rappo wrote: >> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58: >> >>> 56: * A JDBC driver implementation should use >>> 57: * the constructor {@code BatchUpdateException(String reason, String SQLState, >>> 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of >> >> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type. >> Similarly at line 81, 118, 151, 247, 277, 318, 354. > > I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code. OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating the [] completely looks quite rare. I'll leave it up to you. 8-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 11:33:28 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 11:33:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> On Thu, 13 Jan 2022 11:18:42 GMT, Kevin Walls wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > src/java.sql/share/classes/java/sql/Statement.java line 784: > >> 782: * statement returns a {@code ResultSet} object, the second argument >> 783: * supplied to this method is not an >> 784: * {@code int} array whose elements are valid column indexes, the method is called on a > > Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives. It probably does not mean that all these have to be true to throw the exception, but it doesn't say that. We are nitpicking of course. You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 11:46:27 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 11:46:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. Overall this looks good, thanks for the clean up :-) A few comments below src/java.base/share/classes/java/io/DataInput.java line 496: > 494: * ceases. If the character {@code '\r'} > 495: * is encountered, it is discarded and, if > 496: * the following byte converts to the The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 11:46:27 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 11:46:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> Message-ID: On Thu, 13 Jan 2022 11:28:34 GMT, Kevin Walls wrote: >> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code. > > OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating the [] completely looks quite rare. > I'll leave it up to you. 8-) I think that can be a follow on clean up. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 11:46:28 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 11:46:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> Message-ID: On Thu, 13 Jan 2022 11:29:35 GMT, Pavel Rappo wrote: >> src/java.sql/share/classes/java/sql/Statement.java line 784: >> >>> 782: * statement returns a {@code ResultSet} object, the second argument >>> 783: * supplied to this method is not an >>> 784: * {@code int} array whose elements are valid column indexes, the method is called on a >> >> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives. It probably does not mean that all these have to be true to throw the exception, but it doesn't say that. We are nitpicking of course. > > You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory. Yes an "or" is probably worthwhile to add. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 12:40:45 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 12:40:45 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 11:42:48 GMT, Lance Andersen wrote: > The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later. Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From mullan at openjdk.java.net Thu Jan 13 13:45:30 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 13 Jan 2022 13:45:30 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. The change in the one security class (KeyStoreLoginModule) looks fine. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 13:51:34 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 13:51:34 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> Message-ID: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com> On Thu, 13 Jan 2022 11:38:13 GMT, Lance Andersen wrote: > Yes an "or" is probably worthwhile to add. I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql: * java/sql/Statement.java:59 * java/sql/Statement.java:85 * java/sql/Statement.java:346 * java/sql/Statement.java:524 * java/sql/Statement.java:745 * java/sql/Statement.java:814 * java/sql/Statement.java:860 * java/sql/Statement.java:913 * java/sql/Statement.java:962 * java/sql/Statement.java:1225 * java/sql/Statement.java:1269 * java/sql/Statement.java:1314 ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 14:01:04 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 14:01:04 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Additional typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7063/files - new: https://git.openjdk.java.net/jdk/pull/7063/files/fe81eeca..b256a13f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7063/head:pull/7063 PR: https://git.openjdk.java.net/jdk/pull/7063 From sspitsyn at openjdk.java.net Thu Jan 13 16:53:27 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 13 Jan 2022 16:53:27 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Hi Pavel, Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 17:18:23 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 17:18:23 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 12:37:46 GMT, Pavel Rappo wrote: > > The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later. > > Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up. Yes I am. It just does not flow as well as it could IMHO ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From naoto at openjdk.java.net Thu Jan 13 17:25:30 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 13 Jan 2022 17:25:30 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From naoto at openjdk.java.net Thu Jan 13 17:25:31 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 13 Jan 2022 17:25:31 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com> Message-ID: <4-d5YVHaRmPcyMlFYm2fxtIaRq6Z5PVooC8yd0OIbag=.cbd015b1-b2bd-43ba-b12f-8727087364b5@github.com> On Thu, 13 Jan 2022 10:59:13 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73: >> >>> 71: * will be transparent to the BreakIterator.  A sequence of characters will break the >>> 72: * same way it would if any ignore characters it contains are taken out.  Break >>> 73: * positions never occur before ignore characters.

>> >> "before ignored characters" > > I believe it's the name of a concept, so I will leave it as is: > >> There is one special substitution. If the description defines a substitution called "", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator. Yes, that is correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 17:25:31 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 17:25:31 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com> Message-ID: <-4rLp_8_PwigKKpD1gGONCS8QMfDkNNNP4uZU1k9u9M=.9119e3bf-b879-42eb-a3a7-af6442a0551e@github.com> On Thu, 13 Jan 2022 13:48:02 GMT, Pavel Rappo wrote: > > Yes an "or" is probably worthwhile to add. > > I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql: > > * java/sql/Statement.java:59 > * java/sql/Statement.java:85 > * java/sql/Statement.java:346 > * java/sql/Statement.java:524 > * java/sql/Statement.java:745 > * java/sql/Statement.java:814 > * java/sql/Statement.java:860 > * java/sql/Statement.java:913 > * java/sql/Statement.java:962 > * java/sql/Statement.java:1225 > * java/sql/Statement.java:1269 > * java/sql/Statement.java:1314 I am fine with that. I guess a semi-colon could also be used vs. a comma to divide the Exception scenarios listed ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 17:35:25 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 17:35:25 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From jjg at openjdk.java.net Thu Jan 13 23:01:28 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 13 Jan 2022 23:01:28 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> Message-ID: On Thu, 13 Jan 2022 11:40:20 GMT, Lance Andersen wrote: >> OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating the [] completely looks quite rare. >> I'll leave it up to you. 8-) > > I think that can be a follow on clean up. The strange formatting of `long []updateCounts` looks very unusual and well worth a followup cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From duke at openjdk.java.net Fri Jan 14 02:31:56 2022 From: duke at openjdk.java.net (Aggelos Biboudis) Date: Fri, 14 Jan 2022 02:31:56 GMT Subject: RFR: 8036019: Insufficient alternatives listed in some errors produced by the parser Message-ID: Adjusts the corresponding "expected-" errors for `argumentOpt`, `typeArgumentsOpt` and `annotationValue`. ------------- Commit messages: - 8036019: Improve alternatives listed in some errors Changes: https://git.openjdk.java.net/jdk/pull/7019/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7019&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8036019 Stats: 94 lines in 9 files changed: 87 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7019/head:pull/7019 PR: https://git.openjdk.java.net/jdk/pull/7019 From jlahoda at openjdk.java.net Fri Jan 14 11:22:36 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 14 Jan 2022 11:22:36 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos javac changes look good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From azvegint at openjdk.java.net Fri Jan 14 12:19:28 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 14 Jan 2022 12:19:28 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <2NHrJp-0YZuLsk1to7auM4-WbJ0BxxfUImHMBAYHxs8=.012a0e0c-a9e7-4bb9-b822-21334744d4ed@github.com> On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Client changes looks good to me. ------------- Marked as reviewed by azvegint (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From egahlin at openjdk.java.net Fri Jan 14 12:42:32 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 14 Jan 2022 12:42:32 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Marked as reviewed by egahlin (Reviewer). The JFR related changes looks OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From jjg at openjdk.java.net Fri Jan 14 16:08:31 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 14 Jan 2022 16:08:31 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <96bxwtnI-_Z67Udh4acEGwA2xzIy6dAV6CxOe9HLkRo=.dd8643aa-f3be-42e2-ad72-4a00d90363d9@github.com> On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos jdk.compiler and jdk.javadoc look good ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Fri Jan 14 16:13:34 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 14 Jan 2022 16:13:34 GMT Subject: Integrated: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. This pull request has now been integrated. Changeset: f1805309 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/f1805309352a22119ae2edf8bfbb596f00936224 Stats: 88 lines in 35 files changed: 0 ins; 0 del; 88 mod 8279918: Fix various doc typos Reviewed-by: kevinw, lancea, mullan, sspitsyn, naoto, jlahoda, azvegint, egahlin, jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From jlahoda at openjdk.java.net Fri Jan 14 18:29:26 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 14 Jan 2022 18:29:26 GMT Subject: RFR: 8279290: symbol not found error, implicit lambdas and diamond constructor invocations In-Reply-To: References: Message-ID: <0bY9C4NCWVpte54wjajAtM1eZACxPXUr3sgnijSCPJk=.72d7d436-99be-415c-91bc-3dbc3d0f3288@github.com> On Thu, 6 Jan 2022 05:42:49 GMT, Vicente Romero wrote: > Please review this PR which is fixing a bug caused by scope sharing. In particular for code like: > > class Test { > static class B{} > > static class A1 { > A1(Consumer cons) {} > } > > void foo() { > new A1(findMe -> > new B<>() {{ > System.out.println(findMe); // javac is failing here with symbol not found for findMe > }}); > } > } > > the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch. > > TIA Looks good to me. Please note that `jdk/javadoc/doclet/testLinkPlatform/TestLinkPlatform.java` failed in the GitHub checks under `Linux x86 (langtools/tier1)`. Quite possibly an unrelated random failure, but please be sure to run tests before integrating to double-check. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6977 From vromero at openjdk.java.net Fri Jan 14 21:41:07 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 14 Jan 2022 21:41:07 GMT Subject: RFR: 8279290: symbol not found error, implicit lambdas and diamond constructor invocations In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 05:42:49 GMT, Vicente Romero wrote: > Please review this PR which is fixing a bug caused by scope sharing. In particular for code like: > > class Test { > static class B{} > > static class A1 { > A1(Consumer cons) {} > } > > void foo() { > new A1(findMe -> > new B<>() {{ > System.out.println(findMe); // javac is failing here with symbol not found for findMe > }}); > } > } > > the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch. > > TIA thanks for the review ------------- PR: https://git.openjdk.java.net/jdk/pull/6977 From vromero at openjdk.java.net Tue Jan 18 15:54:00 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 18 Jan 2022 15:54:00 GMT Subject: Integrated: 8279290: symbol not found error, implicit lambdas and diamond constructor invocations In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 05:42:49 GMT, Vicente Romero wrote: > Please review this PR which is fixing a bug caused by scope sharing. In particular for code like: > > class Test { > static class B{} > > static class A1 { > A1(Consumer cons) {} > } > > void foo() { > new A1(findMe -> > new B<>() {{ > System.out.println(findMe); // javac is failing here with symbol not found for findMe > }}); > } > } > > the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch. > > TIA This pull request has now been integrated. Changeset: 9e3f68d8 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/9e3f68d8f41ff632ebf28a6f488f6a06754a088f Stats: 56 lines in 2 files changed: 55 ins; 0 del; 1 mod 8279290: symbol not found error, implicit lambdas and diamond constructor invocations Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/6977 From vromero at openjdk.java.net Tue Jan 18 17:31:30 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 18 Jan 2022 17:31:30 GMT Subject: RFR: 8036019: Insufficient alternatives listed in some errors produced by the parser In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 18:53:35 GMT, Aggelos Biboudis wrote: > Adjusts the corresponding "expected-" errors for `argumentOpt`, `typeArgumentsOpt` and `annotationValue`. Changes requested by vromero (Reviewer). src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3382: > 3380: } > 3381: } > 3382: accept(RBRACE, tk -> Errors.AnnotationMissingElementValue); I think that this method needs some more massage, annotations like this one are being accepted: @SuppressWarnings({,}) even previous to your patch, if my reading of the spec is correct, there should be at least one `ElementValue` ------------- PR: https://git.openjdk.java.net/jdk/pull/7019 From jlahoda at openjdk.java.net Wed Jan 19 13:40:00 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 19 Jan 2022 13:40:00 GMT Subject: [jdk18] RFR: 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling Message-ID: For code like: public class TestInstanceOf { public static void main(String[] args) { Number abc = 1; new Object() { { if (abc instanceof Integer integer) { System.out.println(integer.intValue()); } } }; } } `javac` crashes with: An exception has occurred in the compiler (17-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[3]" is null at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:577) at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:902) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1961) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1852) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1742) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1584) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:631) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:682) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1097) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1091) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:930) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:921) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2414) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:737) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1617) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1585) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64) at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50) The cause is in `TransPatterns` - it tracks the current class and method, so that it can define correct owners for temporary variables. But if there's a class nested in a method, the current method field is not cleared, and consequently the temporary variables get a wrong owner (the method enclosing the class, not a method inside the current class), which then crashes subsequent phases, like Gen. The proposed fix is to clear `currentMethod` when entering a class AST node. ------------- Commit messages: - 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling Changes: https://git.openjdk.java.net/jdk18/pull/110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=110&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278834 Stats: 167 lines in 2 files changed: 167 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk18/pull/110.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/110/head:pull/110 PR: https://git.openjdk.java.net/jdk18/pull/110 From vromero at openjdk.java.net Wed Jan 19 16:52:39 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 Jan 2022 16:52:39 GMT Subject: [jdk18] RFR: 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling In-Reply-To: References: Message-ID: <3EPPI3r9GgEwc_7xtIGXHYOAfjrlhmeVjOLjJw9i-io=.5a73b5bb-64b1-4693-a5a0-81839daba2e8@github.com> On Wed, 19 Jan 2022 13:29:44 GMT, Jan Lahoda wrote: > For code like: > > public class TestInstanceOf { > > public static void main(String[] args) { > Number abc = 1; > new Object() { > { > if (abc instanceof Integer integer) { > System.out.println(integer.intValue()); > } > } > }; > } > > } > > > `javac` crashes with: > > An exception has occurred in the compiler (17-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[3]" is null > at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:577) > at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:902) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1961) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1852) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1742) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1584) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:631) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:682) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1097) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1091) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:930) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:921) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2414) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:737) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1617) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1585) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50) > > > The cause is in `TransPatterns` - it tracks the current class and method, so that it can define correct owners for temporary variables. But if there's a class nested in a method, the current method field is not cleared, and consequently the temporary variables get a wrong owner (the method enclosing the class, not a method inside the current class), which then crashes subsequent phases, like Gen. > > The proposed fix is to clear `currentMethod` when entering a class AST node. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/110 From duke at openjdk.java.net Wed Jan 19 17:11:27 2022 From: duke at openjdk.java.net (Aggelos Biboudis) Date: Wed, 19 Jan 2022 17:11:27 GMT Subject: RFR: 8036019: Insufficient alternatives listed in some errors produced by the parser In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 17:27:29 GMT, Vicente Romero wrote: >> Adjusts the corresponding "expected-" errors for `argumentOpt`, `typeArgumentsOpt` and `annotationValue`. > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3382: > >> 3380: } >> 3381: } >> 3382: accept(RBRACE, tk -> Errors.AnnotationMissingElementValue); > > I think that this method needs some more massage, annotations like this one are being accepted: > > > @SuppressWarnings({,}) > > even previous to your patch, if my reading of the spec is correct, there should be at least one `ElementValue` Indeed, that was my observation as well but then I noticed this: https://bugs.openjdk.java.net/browse/JDK-8012722 This is among the positive tests of that contribution: public class SingleCommaAnnotationValue { @Foo({}) void a() { } @Foo({,}) void b() { } @Foo({0}) void c() { } @Foo({0,}) void d() { } @Foo({0,0}) void e() { } @Foo({0,0,}) void f() { } } @interface Foo { int[] value(); } What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/7019 From duke at openjdk.java.net Wed Jan 19 17:31:31 2022 From: duke at openjdk.java.net (Aggelos Biboudis) Date: Wed, 19 Jan 2022 17:31:31 GMT Subject: RFR: 8036019: Insufficient alternatives listed in some errors produced by the parser In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:08:07 GMT, Aggelos Biboudis wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3382: >> >>> 3380: } >>> 3381: } >>> 3382: accept(RBRACE, tk -> Errors.AnnotationMissingElementValue); >> >> I think that this method needs some more massage, annotations like this one are being accepted: >> >> >> @SuppressWarnings({,}) >> >> even previous to your patch, if my reading of the spec is correct, there should be at least one `ElementValue` > > Indeed, that was my observation as well but then I noticed this: > > https://bugs.openjdk.java.net/browse/JDK-8012722 > > This is among the positive tests of that contribution, which exists on master: > > > public class SingleCommaAnnotationValue { > @Foo({}) void a() { } > @Foo({,}) void b() { } > @Foo({0}) void c() { } > @Foo({0,}) void d() { } > @Foo({0,0}) void e() { } > @Foo({0,0,}) void f() { } > } > @interface Foo { int[] value(); } > > > What do you think? To my understanding the following rule permits `{,}`: ElementValueArrayInitializer: { [ElementValueList] [,] } ElementValueList: ElementValue {, ElementValue} ------------- PR: https://git.openjdk.java.net/jdk/pull/7019 From vromero at openjdk.java.net Wed Jan 19 18:02:56 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 Jan 2022 18:02:56 GMT Subject: RFR: 8036019: Insufficient alternatives listed in some errors produced by the parser In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 18:53:35 GMT, Aggelos Biboudis wrote: > Adjusts the corresponding "expected-" errors for `argumentOpt`, `typeArgumentsOpt` and `annotationValue`. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7019 From vromero at openjdk.java.net Wed Jan 19 18:02:57 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 Jan 2022 18:02:57 GMT Subject: RFR: 8036019: Insufficient alternatives listed in some errors produced by the parser In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:28:29 GMT, Aggelos Biboudis wrote: >> Indeed, that was my observation as well but then I noticed this: >> >> https://bugs.openjdk.java.net/browse/JDK-8012722 >> >> This is among the positive tests of that contribution, which exists on master: >> >> >> public class SingleCommaAnnotationValue { >> @Foo({}) void a() { } >> @Foo({,}) void b() { } >> @Foo({0}) void c() { } >> @Foo({0,}) void d() { } >> @Foo({0,0}) void e() { } >> @Foo({0,0,}) void f() { } >> } >> @interface Foo { int[] value(); } >> >> >> What do you think? > > To my understanding the following rule permits `{,}`: > > > ElementValueArrayInitializer: > { [ElementValueList] [,] } > ElementValueList: > ElementValue {, ElementValue} I see, thanks for the clarification ------------- PR: https://git.openjdk.java.net/jdk/pull/7019 From jlahoda at openjdk.java.net Wed Jan 19 19:06:29 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 19 Jan 2022 19:06:29 GMT Subject: [jdk18] Integrated: 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling In-Reply-To: References: Message-ID: <2VNlFS3HtUObZzn8C-6USYDO4TVlUK4Z2j5VVC7Nxys=.4895316b-cc18-4b6f-8a56-514051e721f5@github.com> On Wed, 19 Jan 2022 13:29:44 GMT, Jan Lahoda wrote: > For code like: > > public class TestInstanceOf { > > public static void main(String[] args) { > Number abc = 1; > new Object() { > { > if (abc instanceof Integer integer) { > System.out.println(integer.intValue()); > } > } > }; > } > > } > > > `javac` crashes with: > > An exception has occurred in the compiler (17-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[3]" is null > at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:577) > at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:902) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1961) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1852) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1742) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1584) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:631) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:682) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1097) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1091) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:930) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:921) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2414) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:737) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1617) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1585) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50) > > > The cause is in `TransPatterns` - it tracks the current class and method, so that it can define correct owners for temporary variables. But if there's a class nested in a method, the current method field is not cleared, and consequently the temporary variables get a wrong owner (the method enclosing the class, not a method inside the current class), which then crashes subsequent phases, like Gen. > > The proposed fix is to clear `currentMethod` when entering a class AST node. This pull request has now been integrated. Changeset: be0538d7 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk18/commit/be0538d7c8e2cbfa599dbcb4c5c69533678a8421 Stats: 167 lines in 2 files changed: 167 ins; 0 del; 0 mod 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk18/pull/110 From joe.darcy at oracle.com Wed Jan 19 23:35:36 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 19 Jan 2022 15:35:36 -0800 Subject: JSR 269 MR for Java SE 18 changes Message-ID: <11c8e416-70b9-96b1-9494-9e54d22020dd@oracle.com> FYI, https://jcp.org/aboutJava/communityprocess/maintenance/jsr269/index12.html -Joe From jwilhelm at openjdk.java.net Thu Jan 20 00:40:42 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 20 Jan 2022 00:40:42 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl - 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling - 8272058: 25 Null pointer dereference defect groups in 4 files - 8280234: AArch64 "core" variant does not build after JDK-8270947 - 8280155: [PPC64, s390] frame size checks are not yet correct - 8273383: vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes verifying length of DCQS - 8279654: jdk/incubator/vector/Vector256ConversionTests.java crashes randomly with SVE - 8278417: Closed test fails after JDK-8276108 on aarch64 - 8274096: Improve decoding of image files - ... and 30 more: https://git.openjdk.java.net/jdk/compare/98d96a77...e0d83a07 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7151/files Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/7151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7151/head:pull/7151 PR: https://git.openjdk.java.net/jdk/pull/7151 From jwilhelm at openjdk.java.net Thu Jan 20 01:21:56 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 20 Jan 2022 01:21:56 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 00:28:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 4616c13c Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/4616c13c2f1ced8a8bdeed81f0469523932e91b5 Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7151 From jlahoda at openjdk.java.net Thu Jan 20 12:42:14 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 20 Jan 2022 12:42:14 GMT Subject: RFR: 8280067: Incorrect code generated for unary - on char operand Message-ID: Consider the following snippet of code: Character var = (char) -(false ? (char) param : (char) 2); The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator: -`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`. -when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached -then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned -`Gen.visitUnary` will push the constant the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result -so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`. This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`. The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`. ------------- Commit messages: - 8280067: Incorrect code generated for unary - on char operand Changes: https://git.openjdk.java.net/jdk/pull/7156/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7156&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280067 Stats: 187 lines in 2 files changed: 185 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7156/head:pull/7156 PR: https://git.openjdk.java.net/jdk/pull/7156 From jlaskey at openjdk.java.net Thu Jan 20 12:53:49 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 20 Jan 2022 12:53:49 GMT Subject: RFR: 8280067: Incorrect code generated for unary - on char operand In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 12:31:57 GMT, Jan Lahoda wrote: > Consider the following snippet of code: > > Character var = (char) -(false ? (char) param : (char) 2); > > > The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator: > -`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`. > -when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached > -then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned > -`Gen.visitUnary` will push the constant the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result > -so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`. > > This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`. > > The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`. LGTM test/langtools/tools/javac/code/CharImmediateValue.java line 78: > 76: void runSourceTest() throws Exception { > 77: int param = 0; > 78: Character var = (char) -(false ? (char) param : (char) 2); "var"? - syntax highlighting misreads. ------------- Marked as reviewed by jlaskey (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7156 From vromero at openjdk.java.net Thu Jan 20 17:12:48 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 20 Jan 2022 17:12:48 GMT Subject: RFR: 8280067: Incorrect code generated for unary - on char operand In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 12:31:57 GMT, Jan Lahoda wrote: > Consider the following snippet of code: > > Character var = (char) -(false ? (char) param : (char) 2); > > > The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator: > -`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`. > -when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached > -then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned > -`Gen.visitUnary` will push the constant the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result > -so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`. > > This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`. > > The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`. I'm seeing that Lower is reducing the conditional to `(char)(char)2` at `Lower::visitConditional` could it be that the type is wrongly set to `int` somewhere before reaching to `Gen`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7156 From jlahoda at openjdk.java.net Thu Jan 20 18:57:50 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 20 Jan 2022 18:57:50 GMT Subject: RFR: 8280067: Incorrect code generated for unary - on char operand In-Reply-To: References: Message-ID: <0plXWWkjfjYcoezypBLRbru9MUv-keJjcCHeYyFa8Fo=.dd56ee52-0eda-43d2-8fa7-388ccde3e960@github.com> On Thu, 20 Jan 2022 17:09:26 GMT, Vicente Romero wrote: > I'm seeing that Lower is reducing the conditional to `(char)(char)2` at `Lower::visitConditional` could it be that the type is wrongly set to `int` somewhere before reaching to `Gen`? I believe the types of `(char)(char) 2` is correctly `char`, and the type of `-(char)(char)2` is correctly `int` in the AST. But then, when generating the code, the actual value on the stack for `-(char)(char)2` is `-2`, but then for the outermost cast, the codegen thinks the type of the value on the stack is `char`, so does it does not need the cast (`i2c`), which is wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/7156 From darcy at openjdk.java.net Thu Jan 20 19:09:06 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 20 Jan 2022 19:09:06 GMT Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK 18 build 32 Message-ID: Update of JDK 18 symbol information for build 32. @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered. ------------- Commit messages: - JDK-8279397: Update --release 18 symbol information for JDK 18 build 32 Changes: https://git.openjdk.java.net/jdk/pull/7165/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7165&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279397 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7165.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7165/head:pull/7165 PR: https://git.openjdk.java.net/jdk/pull/7165 From iris at openjdk.java.net Thu Jan 20 19:26:49 2022 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 20 Jan 2022 19:26:49 GMT Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK 18 build 32 In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy wrote: > Update of JDK 18 symbol information for build 32. > > @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7165 From vromero at openjdk.java.net Thu Jan 20 20:49:49 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 20 Jan 2022 20:49:49 GMT Subject: RFR: 8280067: Incorrect code generated for unary - on char operand In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 12:31:57 GMT, Jan Lahoda wrote: > Consider the following snippet of code: > > Character var = (char) -(false ? (char) param : (char) 2); > > > The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator: > -`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`. > -when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached > -then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned > -`Gen.visitUnary` will push the constant the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result > -so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`. > > This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`. > > The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7156 From simone.bordet at gmail.com Fri Jan 21 10:46:04 2022 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 21 Jan 2022 11:46:04 +0100 Subject: Compilation issue with requires static Message-ID: Hi, the issue is described in detail here: https://issues.apache.org/jira/browse/MCOMPILER-481. To summarize, we have module A with: requires static X. Then we have module B with: requires A. Module B has test classes (that are patched into module B), and to compile the test classes X is added to the class-path, and --add-reads B=ALL-UNNAMED is also added. My understanding is that a test class in module B should be able to read classes from module X, due to the --add-reads directive. However, the compiler (triggered by Maven, but you can see the full command line in the issue linked above) reports: [ERROR] /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38] cannot access org.eclipse.jetty.util.ajax.JSON [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found where MainTest is a test class in module B, and JSON is a class in module X. The workaround is to put the jar of module X in the module-path, but that seems unnecessary given the --add-reads directive. Is the error expected behavior, or a javac bug? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From jan.lahoda at oracle.com Fri Jan 21 18:25:33 2022 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 21 Jan 2022 19:25:33 +0100 Subject: Compilation issue with requires static In-Reply-To: References: Message-ID: <81cf11e6-638f-5084-778e-94c9e62b1570@oracle.com> Hi Simone, The full error is: .../MainTest.java:12: error: cannot access JSON ??????? JSON json = new JSONService().json; ???????????????????????????????????? ^ ? class file for org.eclipse.jetty.util.ajax.JSON not found 1 error The JSON class is available to the 'compiler.bug.app' module, and can be used there (there is no error for the variable's type, for example). But JSONService is from module 'compiler.bug.service', and its return type is JSON, and JSON is not available in the context of the 'compiler.bug.service' module, leading to the error. So I don't currently see a bug in javac for this. In principle, one could specify '--add-reads compiler.bug.service=ALL-UNNAMED' (then the JSON class from the unnamed module would be available to 'compiler.bug.service'), but it is not clear to me why the dependent module is not simply put on the module path. Jan On 21. 01. 22 11:46, Simone Bordet wrote: > Hi, > > the issue is described in detail here: > https://issues.apache.org/jira/browse/MCOMPILER-481. > > To summarize, we have module A with: requires static X. > Then we have module B with: requires A. > Module B has test classes (that are patched into module B), and to > compile the test classes X is added to the class-path, and --add-reads > B=ALL-UNNAMED is also added. > > My understanding is that a test class in module B should be able to > read classes from module X, due to the --add-reads directive. > > However, the compiler (triggered by Maven, but you can see the full > command line in the issue linked above) reports: > > [ERROR] /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38] > cannot access org.eclipse.jetty.util.ajax.JSON > [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found > > where MainTest is a test class in module B, and JSON is a class in module X. > > The workaround is to put the jar of module X in the module-path, but > that seems unnecessary given the --add-reads directive. > > Is the error expected behavior, or a javac bug? > > Thanks! > From jlahoda at openjdk.java.net Fri Jan 21 18:42:51 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 21 Jan 2022 18:42:51 GMT Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK 18 build 32 In-Reply-To: References: Message-ID: <0vhdXH6xMp15rkFrpxZ3YrfPpke3Ox7YEbUO2wFuccQ=.0460eb20-1bd2-437e-9276-a1d56fc604bb@github.com> On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy wrote: > Update of JDK 18 symbol information for build 32. > > @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered. I believe this is an artifact of limited optimization of the InnerClasses attribute: if the InnerClasses attribute refers to a class that is not part of `ct.sym`, then it is stripped, but if the class is part of ct.sym, the code does not check if it is used from the headers. So some InnerClass entries may sadly be produced for classes that were only used inside method bodies. Possibly an improvement for the future to do more aggressive cleaning. (In general, recording more/unnecessary classes in the InnerClasses shouldn't be harmful besides wasting space, I believe.) ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7165 From jjg at openjdk.java.net Fri Jan 21 18:45:58 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 21 Jan 2022 18:45:58 GMT Subject: [jdk18] RFR: JDK-8279179: Update nroff pages in JDK 18 before RC Message-ID: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> Please review this semi-automated update to the nroff man pages from the upstream repo. ------------- Commit messages: - JDK-8279179: Update nroff pages in JDK 18 before RC Changes: https://git.openjdk.java.net/jdk18/pull/112/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=112&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279179 Stats: 34 lines in 3 files changed: 32 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk18/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/112/head:pull/112 PR: https://git.openjdk.java.net/jdk18/pull/112 From darcy at openjdk.java.net Fri Jan 21 18:58:45 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 21 Jan 2022 18:58:45 GMT Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK 18 build 32 In-Reply-To: <0vhdXH6xMp15rkFrpxZ3YrfPpke3Ox7YEbUO2wFuccQ=.0460eb20-1bd2-437e-9276-a1d56fc604bb@github.com> References: <0vhdXH6xMp15rkFrpxZ3YrfPpke3Ox7YEbUO2wFuccQ=.0460eb20-1bd2-437e-9276-a1d56fc604bb@github.com> Message-ID: On Fri, 21 Jan 2022 18:39:02 GMT, Jan Lahoda wrote: > I believe this is an artifact of limited optimization of the InnerClasses attribute: if the InnerClasses attribute refers to a class that is not part of `ct.sym`, then it is stripped, but if the class is part of ct.sym, the code does not check if it is used from the headers. So some InnerClass entries may sadly be produced for classes that were only used inside method bodies. Possibly an improvement for the future to do more aggressive cleaning. (In general, recording more/unnecessary classes in the InnerClasses shouldn't be harmful besides wasting space, I believe.) Good to know; thanks Jan. ------------- PR: https://git.openjdk.java.net/jdk/pull/7165 From darcy at openjdk.java.net Fri Jan 21 18:58:45 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 21 Jan 2022 18:58:45 GMT Subject: Integrated: JDK-8279397: Update --release 18 symbol information for JDK 18 build 32 In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy wrote: > Update of JDK 18 symbol information for build 32. > > @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered. This pull request has now been integrated. Changeset: c1e4f3dd Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/c1e4f3dd1b42474c9abc22c7b981a98f9c36e0d5 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8279397: Update --release 18 symbol information for JDK 18 build 32 Reviewed-by: iris, jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/7165 From alex.buckley at oracle.com Fri Jan 21 19:12:23 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 21 Jan 2022 11:12:23 -0800 Subject: Compilation issue with requires static In-Reply-To: References: Message-ID: <5a73d3be-303c-3e45-4e73-042d05cd6310@oracle.com> On 1/21/2022 2:46 AM, Simone Bordet wrote: > the issue is described in detail here: > https://issues.apache.org/jira/browse/MCOMPILER-481. > > To summarize, we have module A with: requires static X. > Then we have module B with: requires A. > Module B has test classes (that are patched into module B), and to > compile the test classes X is added to the class-path, and --add-reads > B=ALL-UNNAMED is also added. > > My understanding is that a test class in module B should be able to > read classes from module X, due to the --add-reads directive. > > However, the compiler (triggered by Maven, but you can see the full > command line in the issue linked above) reports: > > [ERROR] /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38] > cannot access org.eclipse.jetty.util.ajax.JSON > [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found > > where MainTest is a test class in module B, and JSON is a class in module X. > > The workaround is to put the jar of module X in the module-path, but > that seems unnecessary given the --add-reads directive. > > Is the error expected behavior, or a javac bug? I agree with Jan that javac is unlikely to be at fault here. The intent of module A is that module X be on the modulepath at compile-time. I realize you are not compiling module A, but rather module B (or at least the test classes patched into B), but it would still be simpler to put X on the modulepath instead of messing around with the classpath. Then, you should do `--add-modules X --add-reads B=X` to ensure that X is, first, resolved (A's `requires static X;` is moot as you're not compiling/resolving A), and second, readable by B. Alex From iris at openjdk.java.net Fri Jan 21 21:09:09 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 21 Jan 2022 21:09:09 GMT Subject: [jdk18] RFR: JDK-8279179: Update nroff pages in JDK 18 before RC In-Reply-To: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> References: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> Message-ID: On Fri, 21 Jan 2022 18:37:50 GMT, Jonathan Gibbons wrote: > Please review this semi-automated update to the nroff man pages from the upstream repo. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/112 From mchung at openjdk.java.net Fri Jan 21 21:30:14 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 21 Jan 2022 21:30:14 GMT Subject: [jdk18] RFR: JDK-8279179: Update nroff pages in JDK 18 before RC In-Reply-To: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> References: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> Message-ID: On Fri, 21 Jan 2022 18:37:50 GMT, Jonathan Gibbons wrote: > Please review this semi-automated update to the nroff man pages from the upstream repo. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/112 From jjg at openjdk.java.net Fri Jan 21 23:22:13 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 21 Jan 2022 23:22:13 GMT Subject: [jdk18] Integrated: JDK-8279179: Update nroff pages in JDK 18 before RC In-Reply-To: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> References: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> Message-ID: On Fri, 21 Jan 2022 18:37:50 GMT, Jonathan Gibbons wrote: > Please review this semi-automated update to the nroff man pages from the upstream repo. This pull request has now been integrated. Changeset: 7d2ef9d9 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk18/commit/7d2ef9d984f96cd260dc233c4acf58669615227f Stats: 34 lines in 3 files changed: 32 ins; 0 del; 2 mod 8279179: Update nroff pages in JDK 18 before RC Reviewed-by: iris, mchung ------------- PR: https://git.openjdk.java.net/jdk18/pull/112 From simone.bordet at gmail.com Mon Jan 24 09:50:32 2022 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 24 Jan 2022 10:50:32 +0100 Subject: Compilation issue with requires static In-Reply-To: <5a73d3be-303c-3e45-4e73-042d05cd6310@oracle.com> References: <5a73d3be-303c-3e45-4e73-042d05cd6310@oracle.com> Message-ID: Jan, Alex, On Fri, Jan 21, 2022 at 8:12 PM Alex Buckley wrote: > I agree with Jan that javac is unlikely to be at fault here. Thanks for the help! We understand the problem better now, and we'll continue on the Maven Compiler Plugin side to support the use-case I reported here, which was supported in previous versions of the Maven Compiler Plugin but there was a regression. The insights you provided about javac were key to understanding the issue. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From jlahoda at openjdk.java.net Mon Jan 24 13:56:12 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 24 Jan 2022 13:56:12 GMT Subject: Integrated: 8280067: Incorrect code generated for unary - on char operand In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 12:31:57 GMT, Jan Lahoda wrote: > Consider the following snippet of code: > > Character var = (char) -(false ? (char) param : (char) 2); > > > The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator: > -`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`. > -when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached > -then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned > -`Gen.visitUnary` will push the constant the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result > -so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`. > > This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`. > > The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`. This pull request has now been integrated. Changeset: 18c9cb07 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/18c9cb07891cdd68c06385a28af16e3931b84317 Stats: 187 lines in 2 files changed: 185 ins; 0 del; 2 mod 8280067: Incorrect code generated for unary - on char operand Reviewed-by: jlaskey, vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/7156 From duke at openjdk.java.net Mon Jan 24 15:13:12 2022 From: duke at openjdk.java.net (Aggelos Biboudis) Date: Mon, 24 Jan 2022 15:13:12 GMT Subject: Integrated: 8036019: Insufficient alternatives listed in some errors produced by the parser In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 18:53:35 GMT, Aggelos Biboudis wrote: > Adjusts the corresponding "expected-" errors for `argumentOpt`, `typeArgumentsOpt` and `annotationValue`. This pull request has now been integrated. Changeset: 2b133415 Author: Angelos Bimpoudis Committer: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/2b13341500cb9474f5fd6375b97d102ffb635b13 Stats: 94 lines in 9 files changed: 87 ins; 0 del; 7 mod 8036019: Insufficient alternatives listed in some errors produced by the parser Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/7019 From jwilhelm at openjdk.java.net Mon Jan 24 20:00:50 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 24 Jan 2022 20:00:50 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18 - 8280441: Missing "classpath exception" in several files from jdk.httpserver - 8279179: Update nroff pages in JDK 18 before RC The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7203&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7203&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7203/files Stats: 62 lines in 10 files changed: 46 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/7203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7203/head:pull/7203 PR: https://git.openjdk.java.net/jdk/pull/7203 From jwilhelm at openjdk.java.net Mon Jan 24 21:57:13 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 24 Jan 2022 21:57:13 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 19:51:08 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 52ddbe2d Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/52ddbe2dcdb2fa52d85c987443ffa14522ace729 Stats: 62 lines in 10 files changed: 46 ins; 0 del; 16 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7203 From duke at openjdk.java.net Wed Jan 26 22:13:38 2022 From: duke at openjdk.java.net (duke) Date: Wed, 26 Jan 2022 22:13:38 GMT Subject: Withdrawn: 8276836: Error in javac caused by switch expression without result expressions: Internal error: stack sim error In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 13:47:17 GMT, Guoxiong Li wrote: > Hi all, > > The method `Gen#visitSwitchExpression` will switch code generation off by using the method `Code#markDead` when it meets the code like `throw new RuntimeException()`. Then the method `Gen#completeBinop` won't generate the expected code and wiil let the left operand stay in the stack without handling it. > > This patch pops the left operand from the stack to solve this issue. And the corresponding test is added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6350 From joe.darcy at oracle.com Fri Jan 28 02:32:50 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 27 Jan 2022 18:32:50 -0800 Subject: FYI, in Java SE 19 SuppressedWarnings annotations will be applicable in all declaration contexts Message-ID: FYI, with the fix to ??? JDK-8280744: Allow SuppressWarnings to be used in all declaration contexts in 19, SuppressedWarnings annotations will be applicable in all declaration contexts, which include several where they are not currently allowed, such as package-info files. -Joe From jlahoda at openjdk.java.net Fri Jan 28 11:04:36 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 Jan 2022 11:04:36 GMT Subject: RFR: 8280866: SuppressWarnings does not work properly in package-info and module-info Message-ID: `@SuppressWarnings` is not handled properly in `module-info` and, after https://bugs.openjdk.java.net/browse/JDK-8280744, also not in `package-info`. This patch attempts to fix that, by correctly deferring the warnings, and the printing them at an appropriate point. ------------- Commit messages: - Cleanup. - 8280866: SuppressWarnings does not work properly in package-info and module-info Changes: https://git.openjdk.java.net/jdk/pull/7266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7266&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280866 Stats: 247 lines in 4 files changed: 234 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7266/head:pull/7266 PR: https://git.openjdk.java.net/jdk/pull/7266 From darcy at openjdk.java.net Fri Jan 28 17:50:09 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 28 Jan 2022 17:50:09 GMT Subject: RFR: 8280866: SuppressWarnings does not work properly in package-info and module-info In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 10:57:50 GMT, Jan Lahoda wrote: > `@SuppressWarnings` is not handled properly in `module-info` and, after https://bugs.openjdk.java.net/browse/JDK-8280744, also not in `package-info`. This patch attempts to fix that, by correctly deferring the warnings, and the printing them at an appropriate point. Test case looks good; thanks for fixing this. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7266 From duke at openjdk.java.net Sun Jan 30 04:01:16 2022 From: duke at openjdk.java.net (duke) Date: Sun, 30 Jan 2022 04:01:16 GMT Subject: Withdrawn: 8274881: Update jdk.compiler classes to use try-with-resources In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 07:52:40 GMT, Andrey Turbanov wrote: > 8274881: Update jdk.compiler classes to use try-with-resources This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5816