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