From jonathan.gibbons at oracle.com  Mon May  2 16:15:30 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 2 May 2022 09:15:30 -0700
Subject: RFR: 8282149: Some -Xlint keys are missing in javac man page
In-Reply-To: <JbwMW1O_eV_laudIhXkWcc_RcKDCf9bpzC83EqYZn6g=.1901afa6-ae53-452a-9a2b-cb95234c277e@github.com>
References: <O5B_IK-miHHwcFl6T8Td-ait-36v5QRZA1cw_bOldjM=.a26b960c-0f0d-4542-8098-860b96dee038@github.com>
 <JbwMW1O_eV_laudIhXkWcc_RcKDCf9bpzC83EqYZn6g=.1901afa6-ae53-452a-9a2b-cb95234c277e@github.com>
Message-ID: <66258559-618e-95be-5a01-7650f59ca8b4@oracle.com>

Ethan,

I'll try and get to it this week.

-- Jon


On 4/27/22 6:12 PM, Ethan McCue wrote:
> On Sat, 26 Mar 2022 14:33:57 GMT, Ethan McCue <duke at openjdk.java.net> wrote:
>
>> Adds all the XLint options that were noted as missing in the man page by the issue.
> .
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/7971

From jjg at openjdk.java.net  Mon May  2 19:20:53 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 May 2022 19:20:53 GMT
Subject: RFR: 8286028: Some -Xlint keys are missing in javac man page
Message-ID: <CVbV8oHRXpmN3n8-59P9N7k52ZZopDiOD_tykW4arsc=.8e450fee-1554-4bc0-916f-952fb3300dd0@github.com>

Please review an update to the javac man page, derived from the upstream sources, and triggered by PR #7971 by Ethan McCue.

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

Commit messages:
 - JDK-8282149: Some -Xlint keys are missing in javac man page

Changes: https://git.openjdk.java.net/jdk/pull/8507/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8507&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286028
  Stats: 20 lines in 1 file changed: 14 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8507/head:pull/8507

PR: https://git.openjdk.java.net/jdk/pull/8507

From darcy at openjdk.java.net  Mon May  2 19:20:53 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 2 May 2022 19:20:53 GMT
Subject: RFR: 8286028: Some -Xlint keys are missing in javac man page
In-Reply-To: <CVbV8oHRXpmN3n8-59P9N7k52ZZopDiOD_tykW4arsc=.8e450fee-1554-4bc0-916f-952fb3300dd0@github.com>
References: <CVbV8oHRXpmN3n8-59P9N7k52ZZopDiOD_tykW4arsc=.8e450fee-1554-4bc0-916f-952fb3300dd0@github.com>
Message-ID: <n7q2WxQCroj5TVKjCvaoWG-w7d_G3dMnFCOPjV8ZTDU=.a78eab33-ec5c-4c2c-9375-70cd1b541120@github.com>

On Mon, 2 May 2022 19:05:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to the javac man page, derived from the upstream sources, and triggered by PR #7971 by Ethan McCue.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8507

From jjg at openjdk.java.net  Mon May  2 21:14:31 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 May 2022 21:14:31 GMT
Subject: Integrated: 8286028: Some -Xlint keys are missing in javac man page
In-Reply-To: <CVbV8oHRXpmN3n8-59P9N7k52ZZopDiOD_tykW4arsc=.8e450fee-1554-4bc0-916f-952fb3300dd0@github.com>
References: <CVbV8oHRXpmN3n8-59P9N7k52ZZopDiOD_tykW4arsc=.8e450fee-1554-4bc0-916f-952fb3300dd0@github.com>
Message-ID: <J9pufqk76p6GNO6fjdjGPrO8HGj1ZYwzPNPUWt6qV9o=.787f1b70-cb90-4d22-865e-6a2ad1673eb5@github.com>

On Mon, 2 May 2022 19:05:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to the javac man page, derived from the upstream sources, and triggered by PR #7971 by Ethan McCue.

This pull request has now been integrated.

Changeset: f973b783
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f973b78383dd9b47557b5ab06dd4978122bcee63
Stats:     20 lines in 1 file changed: 14 ins; 0 del; 6 mod

8286028: Some -Xlint keys are missing in javac man page

Co-authored-by: Ethan McCue <emccue at live.com>
Reviewed-by: darcy

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

PR: https://git.openjdk.java.net/jdk/pull/8507

From jjg at openjdk.java.net  Mon May  2 21:17:42 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 May 2022 21:17:42 GMT
Subject: RFR: 8282149: Some -Xlint keys are missing in javac man page
In-Reply-To: <JbwMW1O_eV_laudIhXkWcc_RcKDCf9bpzC83EqYZn6g=.1901afa6-ae53-452a-9a2b-cb95234c277e@github.com>
References: <O5B_IK-miHHwcFl6T8Td-ait-36v5QRZA1cw_bOldjM=.a26b960c-0f0d-4542-8098-860b96dee038@github.com>
 <JbwMW1O_eV_laudIhXkWcc_RcKDCf9bpzC83EqYZn6g=.1901afa6-ae53-452a-9a2b-cb95234c277e@github.com>
Message-ID: <9DYWH8jr753vSU1DkKwOuQeSNVI9BYyUgfEJ8MuUQfo=.e1f9e22a-c74a-4f45-9fb6-28a5523e36bc@github.com>

On Thu, 28 Apr 2022 01:09:44 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

>> Adds all the XLint options that were noted as missing in the man page by the issue.
>
> .

@bowbahdoe  As a result of this thread, the issue has been fixed in PR #8507.  I have credited you as a co-contributor on that other version.

Thank you for your help and persistence in fixing this issue.

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

PR: https://git.openjdk.java.net/jdk/pull/7971

From duke at openjdk.java.net  Mon May  2 22:17:27 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Mon, 2 May 2022 22:17:27 GMT
Subject: Withdrawn: 8282149: Some -Xlint keys are missing in javac man page
In-Reply-To: <O5B_IK-miHHwcFl6T8Td-ait-36v5QRZA1cw_bOldjM=.a26b960c-0f0d-4542-8098-860b96dee038@github.com>
References: <O5B_IK-miHHwcFl6T8Td-ait-36v5QRZA1cw_bOldjM=.a26b960c-0f0d-4542-8098-860b96dee038@github.com>
Message-ID: <NA8JX73qt4MG6vRV_XFp-84XMKIhX9c65Zl8NnfY6D0=.46fa4a64-d474-41c1-a2e2-1c3b5fb43653@github.com>

On Sat, 26 Mar 2022 14:33:57 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

> Adds all the XLint options that were noted as missing in the man page by the issue.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/7971

From iris at openjdk.java.net  Tue May  3 00:13:22 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 3 May 2022 00:13:22 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class
In-Reply-To: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
Message-ID: <4kcClU0UAH2EX7p27W6t70Qpobw95vRF5a2eHg2WrN4=.1c7da657-a552-40c7-b7d7-14dd6e77d0ec@github.com>

On Fri, 29 Apr 2022 00:29:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
> 
> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From darcy at openjdk.java.net  Tue May  3 04:01:21 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 May 2022 04:01:21 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces [v2]
In-Reply-To: <NANBTC8SHjxN4oFJ5rPMIQgBOYeU37FqMPuWEDJx3q8=.2b9936ad-bdf2-4bcc-bb3f-3f1321595594@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <NANBTC8SHjxN4oFJ5rPMIQgBOYeU37FqMPuWEDJx3q8=.2b9936ad-bdf2-4bcc-bb3f-3f1321595594@github.com>
Message-ID: <7J2Tc_TQu1cHRkqRxBdfCC7QqwEjNhhEH9Aa0y2jqWE=.33ff7ce4-d27e-46c9-98b1-41f17637c968@github.com>

On Thu, 28 Apr 2022 18:36:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
>> 
>> interface I {}
>> 
>> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
>> 
>> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
>> 
>> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoiding a use of a new flag to determine Object methods copied to interfaces.

Please file a CSR for the behavioral compatibility impact.

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From jlahoda at openjdk.java.net  Tue May  3 07:12:21 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 3 May 2022 07:12:21 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces [v2]
In-Reply-To: <zRvzXaRa4PhOokdDj5Vf8brpa7zvrxq3trkhSYmBQOQ=.d4199c2a-ed53-4a4a-9b7c-57a8501b2c4e@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <NANBTC8SHjxN4oFJ5rPMIQgBOYeU37FqMPuWEDJx3q8=.2b9936ad-bdf2-4bcc-bb3f-3f1321595594@github.com>
 <zRvzXaRa4PhOokdDj5Vf8brpa7zvrxq3trkhSYmBQOQ=.d4199c2a-ed53-4a4a-9b7c-57a8501b2c4e@github.com>
Message-ID: <vbJcty37igTpRbzZw483H--51IoUZPdn8uDw-zeJ7OU=.b8622a68-d069-4875-81be-51df77a21cd2@github.com>

On Sat, 30 Apr 2022 19:36:25 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Re: the impact of JDK-8272564, for what it's worth, it ended up being a noticeable breaking change for us:
> 
>     * Some static analysis that was looking for interfaces noticed the 'sharper' static type information on these calls. This is an improvement, but still a breaking one.
> 
>     * A non-OpenJDK runtime's verifier didn't handle the new calls (which is their bug, but confirms this is a slightly surprising edge case), and we ended up doing some bytecode munging to rewrite back to invokevirtuals for code affected by that.
> 
> 
> At this point we've absorbed the breaking change and I personally don't have any concerns with the new behaviour, I'm just sharing that in case you're still weighing the risk of whack-a-mole from keeping JDK-8272564.

JDK-8272564 has three parts:
1. the model was modelling mistake, where the AST was referring to a suboptimal element. In particular:

interface I {
     public String toString();
}
interface J extends I {}

I i = null;
i.toString(); //AST and classfile contain call to I.toString()
J j = null;
j.toString(); //AST and classfile contain call to j.l.Object.toString()


the attribution of `j.toString()` is obviously weird, and has then effects on various other parts of the model.

2. in the case above, the classfile was also referring to `j.l.Object.toString()` for `j.toString()`, which is also a bit weird.
3. for cases like:

interface K {}
K k = null;
k.toString();

the classfile was referring to `j.l.Object.toString()`, which strictly speaking does not adhere to JLS 9.2. (Interface Members), which says interfaces have the `public abstract` methods of `j.l.Object` (unless they declare them explicitly).

I believe this problem, and other problems were likely caused by fixing 3. I believe we did that mostly for consistency, and if needed we could revert this part.

I would really prefer to not revert 1., as that makes the model much less useful.

For 2., it is a bit related to 1., but we could revert that, although it is a bit more complex, and is unlikely to be causing problems.

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From jlahoda at openjdk.java.net  Tue May  3 09:34:45 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 3 May 2022 09:34:45 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v9]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <m_ymLdpAFIEkQR1cjVs3V0JS8IHKpD80IGlN23qJXzI=.099f6b86-7db5-4294-b631-6a229b5b42f6@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

 - Merge branch 'master' into type-patterns-third
 - Reducing MatchException constructors.
 - Merge branch 'master' into type-patterns-third
 - Reference-type pattern is not applicable at a selector of a primitive type - fixing.
 - Merge branch 'master' into type-patterns-third
 - Cleanup, fixing tests.
 - Cleanup - more total -> unconditional pattern renaming.
 - Adjusting to review feedback.
 - Cleanup.
 - Fixing tests.
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...cb5c1d20

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

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=08
  Stats: 860 lines in 52 files changed: 424 ins; 244 del; 192 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From mcimadamore at openjdk.java.net  Tue May  3 10:36:21 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 3 May 2022 10:36:21 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces [v2]
In-Reply-To: <NANBTC8SHjxN4oFJ5rPMIQgBOYeU37FqMPuWEDJx3q8=.2b9936ad-bdf2-4bcc-bb3f-3f1321595594@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <NANBTC8SHjxN4oFJ5rPMIQgBOYeU37FqMPuWEDJx3q8=.2b9936ad-bdf2-4bcc-bb3f-3f1321595594@github.com>
Message-ID: <0AQ8w6zDjMQbf8FZxmg3FSs9rmTyog3Qsoter6YEVV8=.4c5824bc-e628-4b32-9f43-8900fa8fae73@github.com>

On Thu, 28 Apr 2022 18:36:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
>> 
>> interface I {}
>> 
>> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
>> 
>> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
>> 
>> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoiding a use of a new flag to determine Object methods copied to interfaces.

Looks good. I think I'm now convinced that this change does not make things worse, and that the changes in 8272564, while potentially breaking, do make the compiler more explicitly in sync with the JLS, so let's try to keep them in place. I agree with @lahodaj analysis that, if needs be, we can just rollback the codegen part of 8272564.

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8054

From jlahoda at openjdk.java.net  Tue May  3 12:16:27 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 3 May 2022 12:16:27 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
Message-ID: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>

8262889: Compiler implementation for Record Patterns

A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html

There are two notable tricky parts:
-in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
-in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview

`MatchException` has been extended to cover additional cases related to record patterns.

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

Depends on: https://git.openjdk.java.net/jdk/pull/8182

Commit messages:
 - 8262889: Compiler implementation for Record Patterns

Changes: https://git.openjdk.java.net/jdk/pull/8516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262889
  Stats: 2008 lines in 45 files changed: 1943 ins; 15 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From prappo at openjdk.java.net  Tue May  3 12:19:33 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 3 May 2022 12:19:33 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class
In-Reply-To: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
Message-ID: <H5ozOyGfkfb457i56tKTVnm7cl2fyYmUuZ2LUXTt4BU=.af1849f2-3482-4c56-a064-d4e1b65942a2@github.com>

On Fri, 29 Apr 2022 00:29:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
> 
> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.

It's nice to see many `break` go.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 737:

> 735:     private Element getEnclosingPackageOrClass(Element e) {
> 736:         while (e != null) {
> 737:             if (e.getKind().isDeclaredType() || e.getKind() == ElementKind.PACKAGE) {

This change does not seem to be equivalent: `isDeclaredType()` accepts more kinds than the `switch` did. Does it matter here?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 866:

> 864:         if (paramElement == null) {
> 865:             switch (env.currElement.getKind()) {
> 866:                 case CLASS, ENUM, INTERFACE, ANNOTATION_TYPE -> {

Neither an enum nor annotation can be generic.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 1127:

> 1125:             return false;
> 1126: 
> 1127:         return switch (e.getKind()) {

While uniformity of constructs is good, to me, the previous variant read better. Does this have to be a switch expression?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 1171:

> 1169: 
> 1170:     private boolean isDefaultConstructor() {
> 1171:         return switch (env.currElement.getKind()) {

Similar to the above.

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From prappo at openjdk.java.net  Tue May  3 13:56:14 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 3 May 2022 13:56:14 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec)
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>

On Thu, 28 Apr 2022 02:05:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

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

This is nice work. I haven't seen it in detail, but I'm plannig to do so later.

What's the logistics here? There are two interrelated bugs: 6251738 and 8226279. Are you going to add an 8226279 as an issue to this PR (`/issue add 8226279`)? What about @bug tags in tests? Are they going to mention both issues?

src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 290:

> 288:     R visitSince(SinceTree node, P p);
> 289: 
> 290:     /**

This file uses a consistent style for doc comments for `visit` methods. Consider adhering to that style for the time being. If you think that the style could be improved, it should be improved in a separate PR.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 340:

> 338:     SnippetTree newSnippetTree(List<? extends DocTree> attributes, TextTree text);
> 339: 
> 340:     /**

Similar comment to that of DocTreeVisitor: consider adhering to the file style.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 512:

> 510:     }
> 511: 
> 512:     /**

Similar comment on the file style.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 532:

> 530: 
> 531:     /**
> 532:      * {@inheritDoc} This implementation scans the children in left to right order.

Same as above: surprising.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 544:

> 542: 
> 543:     /**
> 544:      * {@inheritDoc} This implementation scans the children in left to right order.

This change is surprising; firstly, it's unrelated to this PR, secondly... why?

src/jdk.compiler/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java line 466:

> 464:     }
> 465: 
> 466:     /**

Again: the file style.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 1217:

> 1215:         @Override
> 1216:         public boolean isBlank() {
> 1217:             return text.isBlank();

Can text be null?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 419:

> 417: 
> 418:     @Override @DefinedBy(Api.COMPILER_TREE)
> 419:     public DCSpec newSpecTree(TextTree url, List<? extends DocTree> title) {

In DocTreeFactory the first parameter is called uri.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ExternalSpecsWriter.java line 68:

> 66:  * Generates the file with the summary of all the references to external specifications.
> 67:  *
> 68:  *  <p><b>This is NOT part of any supported API.

We abolished such notes in JDK-8284362.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java line 33:

> 31: import java.nio.file.InvalidPathException;
> 32: import java.nio.file.Path;
> 33: import java.util.ArrayList;

This does not seem necessary for this PR and looks like an artifact of editing in an IDE.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 44:

> 42:  * A taglet that represents the {@code @spec} tag.
> 43:  *
> 44:  *  <p><b>This is NOT part of any supported API.

See my comment on such notes above.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 49:

> 47:  *  deletion without notice.</b>
> 48:  */
> 49: public class SpecTaglet extends BaseTaglet implements InheritableTaglet {

Ooh! This taglet is inheritable. Is it the right thing to do? If the inheritance is not needed down the hierarchy, how can the author avoid it?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java line 192:

> 190:      *
> 191:      * @param element  the element that owns the doc comment
> 192:      * @param specTags the array of @spec tags.

Naked tags that aren't meant to be interpreted by javadoc make me uncomfortable.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFinder.java line 277:

> 275: 
> 276:     private static boolean isNonEmpty(List<? extends DocTree> list) {
> 277:         return list != null && !list.isEmpty();

`output.inlineTags` should never be null. Separately, can this readability change be done in a separate PR? I do have one suitable PR in the works, which can include it.

test/langtools/jdk/javadoc/doclet/testConditionalPages/TestConditionalPages.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved.

Consider adding 6251738 to `@bug`.

test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2022, Oracle and/or its affiliates. All rights reserved.

Same as above.

test/langtools/tools/javac/diags/examples/NoTitle.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.

It's surprising to see 2012 here.

test/langtools/tools/javac/diags/examples/NoURI.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.

Same as above.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From rriggs at openjdk.java.net  Tue May  3 17:53:18 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 3 May 2022 17:53:18 GMT
Subject: RFR: 8283606: Tests may fail with zh locale on MacOS [v2]
In-Reply-To: <w4nJAxEkbFQ-LD20D7cm-KWV6L6pv0alU-IW7p8VfUs=.2085986b-901e-4173-9c89-2b5d7c6ac74e@github.com>
References: <ptah2PBYatKtfv5rLFzaPP3rWqqPIz0cShcZHDjv3hg=.bd8d63bd-681e-4787-b3b4-d542233be781@github.com>
 <w4nJAxEkbFQ-LD20D7cm-KWV6L6pv0alU-IW7p8VfUs=.2085986b-901e-4173-9c89-2b5d7c6ac74e@github.com>
Message-ID: <pFaDlp6PloJOccStTo8dEZ_pDHRZPMEh7kGO2etXw-4=.0dc79c59-96f7-48ee-b045-99f9274a24ea@github.com>

On Thu, 24 Mar 2022 17:30:22 GMT, Vikey Chen <duke at openjdk.java.net> wrote:

>> From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html
>>> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases.
>> 
>> However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced.
>> 
>> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java
>> test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java
>> test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java
>> test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java
>> test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java
>> test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java
>> test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java
>> test/langtools/tools/javac/platform/PlatformProviderTest.java
>> test/langtools/tools/jdeps/MultiReleaseJar.java
>
> Vikey Chen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   polish

Looks fine.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7924

From jjg at openjdk.java.net  Tue May  3 21:29:19 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 21:29:19 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class
In-Reply-To: <H5ozOyGfkfb457i56tKTVnm7cl2fyYmUuZ2LUXTt4BU=.af1849f2-3482-4c56-a064-d4e1b65942a2@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
 <H5ozOyGfkfb457i56tKTVnm7cl2fyYmUuZ2LUXTt4BU=.af1849f2-3482-4c56-a064-d4e1b65942a2@github.com>
Message-ID: <Ml6KK8GJ930Oz-Tdu_z9rSJ-bWQ5sgVzC3SGXwt3tv4=.d59adf52-c542-4e6e-89ac-ae26578d3338@github.com>

On Tue, 3 May 2022 11:31:09 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
>> 
>> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 866:
> 
>> 864:         if (paramElement == null) {
>> 865:             switch (env.currElement.getKind()) {
>> 866:                 case CLASS, ENUM, INTERFACE, ANNOTATION_TYPE -> {
> 
> Neither an enum nor annotation can be generic.

good point

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 1127:
> 
>> 1125:             return false;
>> 1126: 
>> 1127:         return switch (e.getKind()) {
> 
> While uniformity of constructs is good, to me, the previous variant read better. Does this have to be a switch expression?

no. it may work better as a simple (non-switch) expression; i'll try it

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 1171:
> 
>> 1169: 
>> 1170:     private boolean isDefaultConstructor() {
>> 1171:         return switch (env.currElement.getKind()) {
> 
> Similar to the above.

similar answer

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From jjg at openjdk.java.net  Tue May  3 21:34:17 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 21:34:17 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class
In-Reply-To: <H5ozOyGfkfb457i56tKTVnm7cl2fyYmUuZ2LUXTt4BU=.af1849f2-3482-4c56-a064-d4e1b65942a2@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
 <H5ozOyGfkfb457i56tKTVnm7cl2fyYmUuZ2LUXTt4BU=.af1849f2-3482-4c56-a064-d4e1b65942a2@github.com>
Message-ID: <RWYySh7gCIdP4A6gKO3X15-RpM3_Abfhw_N7WOlMXrU=.d442bdad-854d-4429-8a8e-282eddce0dd7@github.com>

On Tue, 3 May 2022 11:03:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
>> 
>> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 737:
> 
>> 735:     private Element getEnclosingPackageOrClass(Element e) {
>> 736:         while (e != null) {
>> 737:             if (e.getKind().isDeclaredType() || e.getKind() == ElementKind.PACKAGE) {
> 
> This change does not seem to be equivalent: `isDeclaredType()` accepts more kinds than the `switch` did. Does it matter here?

I don't think it matters and/or the code is more correct according to the semantics of the name.

I think this is a case where we get bit-rot from new values being added to enums and not being consistently used throughout the code.

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From jjg at openjdk.java.net  Tue May  3 21:53:21 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 21:53:21 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class [v2]
In-Reply-To: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
Message-ID: <yZ-c4K0npx8EMau8yVHelqUzEe_zRNEZZ6F77MyP_Fg=.79b059a7-7238-4fbc-a592-a2915527de16@github.com>

> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
> 
> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8460/files
  - new: https://git.openjdk.java.net/jdk/pull/8460/files/d18824b8..edbb9247

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8460&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8460&range=00-01

  Stats: 23 lines in 1 file changed: 3 ins; 9 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8460.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8460/head:pull/8460

PR: https://git.openjdk.java.net/jdk/pull/8460

From jjg at openjdk.java.net  Tue May  3 21:58:07 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 21:58:07 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec)
In-Reply-To: <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
Message-ID: <RZJOCnEbBouqZKq80zlmY4ay_8z9ko7xCZe8AidZMX8=.f1269d62-8b42-4821-87ef-0d33b261d1a5@github.com>

On Tue, 3 May 2022 12:38:09 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 290:
> 
>> 288:     R visitSince(SinceTree node, P p);
>> 289: 
>> 290:     /**
> 
> This file uses a consistent style for doc comments for `visit` methods. Consider adhering to that style for the time being. If you think that the style could be improved, it should be improved in a separate PR.

The style is consistent with other recent additions that have default methods.  In other words, there is not one but two styles already in play in this file, for the two different kinds of methods.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Tue May  3 22:02:24 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 22:02:24 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec)
In-Reply-To: <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
Message-ID: <ra5mbVlZsni6K2dj4VwaCCYXWBgAgNpZwBrQXEHQLco=.908d96b1-2eaf-4bbf-a041-927f0298bfec@github.com>

On Tue, 3 May 2022 12:40:42 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 340:
> 
>> 338:     SnippetTree newSnippetTree(List<? extends DocTree> attributes, TextTree text);
>> 339: 
>> 340:     /**
> 
> Similar comment to that of DocTreeVisitor: consider adhering to the file style.

I see there is a missing `@since` tag, which I'll fix.
I'd prefer to leave the extra whitespace for now, and maybe cleanup the style of the other comments later.

> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 512:
> 
>> 510:     }
>> 511: 
>> 512:     /**
> 
> Similar comment on the file style.

I'll adjust the order of the tags.

Aside: we should have a guideline somewhere on the recommended order of block tags in a comment,

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Tue May  3 22:11:42 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 22:11:42 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec)
In-Reply-To: <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
Message-ID: <FGrxbxn9A4WDqaR-cXSVVCL7UVy0Zt1_RLWYeo9_41A=.74149d6f-cd48-48cc-9576-bc5fd7990285@github.com>

On Tue, 3 May 2022 12:42:41 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 544:
> 
>> 542: 
>> 543:     /**
>> 544:      * {@inheritDoc} This implementation scans the children in left to right order.
> 
> This change is surprising; firstly, it's unrelated to this PR, secondly... why?

Bug and/or some variant of cut n paste. I'll ensure to use `@implSpec`.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From prappo at openjdk.java.net  Tue May  3 22:28:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 3 May 2022 22:28:34 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class [v2]
In-Reply-To: <yZ-c4K0npx8EMau8yVHelqUzEe_zRNEZZ6F77MyP_Fg=.79b059a7-7238-4fbc-a592-a2915527de16@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
 <yZ-c4K0npx8EMau8yVHelqUzEe_zRNEZZ6F77MyP_Fg=.79b059a7-7238-4fbc-a592-a2915527de16@github.com>
Message-ID: <k6Gy-VovpJJu-dGAClv0zOpOJ3pdw4CyW29vIP-YtW0=.e17f4622-9dae-4dea-98b6-b1693ef8d276@github.com>

On Tue, 3 May 2022 21:53:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
>> 
>> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

I have a few more comments, Jon.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 217:

> 215:         hasNonWhitespaceText = false;
> 216: 
> 217:         implicitHeadingRank = switch (p.getLeaf().getKind()) {

(observation) Since _rank_ is a rather unusual word to see, I explored this a bit. Numerals in H1, H2, H3, H4, H5, and H6 were somewhat implicitly referred to as _heading levels_ by HTML4, and indeed became referred to as _ranks_ in HTML5.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 866:

> 864:         if (paramElement == null) {
> 865:             switch (env.currElement.getKind()) {
> 866:                 case CLASS, INTERFACE -> {

A record can be generic too.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 1230:

> 1228:         for (DocTree d: list) {
> 1229:             switch (d.getKind()) {
> 1230:                 case TEXT -> {

Using `switch` here seems overkill.

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From jjg at openjdk.java.net  Tue May  3 22:28:36 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 22:28:36 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec)
In-Reply-To: <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
Message-ID: <B4_K5bPOTQ3SRQrjwY_IJ8FUMf0pixar5szzB12VATs=.fe364e32-cdbf-4c7b-9b48-eeaed8000c4a@github.com>

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

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFinder.java line 277:
> 
>> 275: 
>> 276:     private static boolean isNonEmpty(List<? extends DocTree> list) {
>> 277:         return list != null && !list.isEmpty();
> 
> `output.inlineTags` should never be null. Separately, can this readability change be done in a separate PR? I do have one suitable PR in the works, which can include it.

I'll back out these lines as long as the tests still pass.

> test/langtools/jdk/javadoc/doclet/testConditionalPages/TestConditionalPages.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Consider adding 6251738 to `@bug`.

Mmmm, OK

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From prappo at openjdk.java.net  Tue May  3 22:40:56 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 3 May 2022 22:40:56 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class [v2]
In-Reply-To: <yZ-c4K0npx8EMau8yVHelqUzEe_zRNEZZ6F77MyP_Fg=.79b059a7-7238-4fbc-a592-a2915527de16@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
 <yZ-c4K0npx8EMau8yVHelqUzEe_zRNEZZ6F77MyP_Fg=.79b059a7-7238-4fbc-a592-a2915527de16@github.com>
Message-ID: <Z80HoVEE8XldqJoDzPTtTTeFcY6-EWA34iWfi0usrZw=.71bc8a32-ba59-4705-ba52-a7f245bbc14e@github.com>

On Tue, 3 May 2022 21:53:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
>> 
>> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by prappo (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From jjg at openjdk.java.net  Tue May  3 22:41:00 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 22:41:00 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class [v2]
In-Reply-To: <k6Gy-VovpJJu-dGAClv0zOpOJ3pdw4CyW29vIP-YtW0=.e17f4622-9dae-4dea-98b6-b1693ef8d276@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
 <yZ-c4K0npx8EMau8yVHelqUzEe_zRNEZZ6F77MyP_Fg=.79b059a7-7238-4fbc-a592-a2915527de16@github.com>
 <k6Gy-VovpJJu-dGAClv0zOpOJ3pdw4CyW29vIP-YtW0=.e17f4622-9dae-4dea-98b6-b1693ef8d276@github.com>
Message-ID: <hYe0BJ7he2FQTuKmKjVnduXT7785z0YP4lC5xYFxlsg=.f26f8d55-0392-4f6c-a1c4-671783c3e092@github.com>

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

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 866:
> 
>> 864:         if (paramElement == null) {
>> 865:             switch (env.currElement.getKind()) {
>> 866:                 case CLASS, INTERFACE -> {
> 
> A record can be generic too.

Yes, but RECORD is handled in a different case, along with METHOD and CONSTRUCTOR, because it can have "plain" `@param` as well as type-parameter `@param`.  In contrast, a class or interface can only have type-parameter `@param` and never plain `@param`.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 1230:
> 
>> 1228:         for (DocTree d: list) {
>> 1229:             switch (d.getKind()) {
>> 1230:                 case TEXT -> {
> 
> Using `switch` here seems overkill.

I almost fixed that one earlier. OK, I'll do that too. It was over-zealous use of use of unqualified names in an enum-switch

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From prappo at openjdk.java.net  Tue May  3 22:41:01 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 3 May 2022 22:41:01 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class [v2]
In-Reply-To: <hYe0BJ7he2FQTuKmKjVnduXT7785z0YP4lC5xYFxlsg=.f26f8d55-0392-4f6c-a1c4-671783c3e092@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
 <yZ-c4K0npx8EMau8yVHelqUzEe_zRNEZZ6F77MyP_Fg=.79b059a7-7238-4fbc-a592-a2915527de16@github.com>
 <k6Gy-VovpJJu-dGAClv0zOpOJ3pdw4CyW29vIP-YtW0=.e17f4622-9dae-4dea-98b6-b1693ef8d276@github.com>
 <hYe0BJ7he2FQTuKmKjVnduXT7785z0YP4lC5xYFxlsg=.f26f8d55-0392-4f6c-a1c4-671783c3e092@github.com>
Message-ID: <Tvm4EcWgveFw0-7pEEmihf6yhIaEE3gvMhwjDW4ALrY=.82112f5a-8d93-40fd-a154-d154753acaed@github.com>

On Tue, 3 May 2022 22:30:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Yes, but RECORD is handled in a different case, along with METHOD and CONSTRUCTOR, because it can have "plain" `@param` as well as type-parameter `@param`. In contrast, a class or interface can only have type-parameter `@param` and never plain `@param`.

You are correct; I missed that unconditionality in that second arm for`METHOD, CONSTRUCTOR, RECORD`.

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From jjg at openjdk.java.net  Tue May  3 22:47:49 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 22:47:49 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class [v3]
In-Reply-To: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
Message-ID: <8LZE068FcdMqAk4tMZkTlmCbc62rdG533ieO8LqTYoA=.b960f449-31d4-4080-bf40-dd9721598a92@github.com>

> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
> 
> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8460/files
  - new: https://git.openjdk.java.net/jdk/pull/8460/files/edbb9247..7be7ab30

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8460&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8460&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8460.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8460/head:pull/8460

PR: https://git.openjdk.java.net/jdk/pull/8460

From jjg at openjdk.java.net  Tue May  3 22:47:51 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 3 May 2022 22:47:51 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class [v2]
In-Reply-To: <k6Gy-VovpJJu-dGAClv0zOpOJ3pdw4CyW29vIP-YtW0=.e17f4622-9dae-4dea-98b6-b1693ef8d276@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
 <yZ-c4K0npx8EMau8yVHelqUzEe_zRNEZZ6F77MyP_Fg=.79b059a7-7238-4fbc-a592-a2915527de16@github.com>
 <k6Gy-VovpJJu-dGAClv0zOpOJ3pdw4CyW29vIP-YtW0=.e17f4622-9dae-4dea-98b6-b1693ef8d276@github.com>
Message-ID: <tkaRCVajInsfy9mkZ83l--pjVl3m1mYnwChUr2w11YM=.ac5a1902-eb47-4496-90cc-d623810f5e1b@github.com>

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

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 217:
> 
>> 215:         hasNonWhitespaceText = false;
>> 216: 
>> 217:         implicitHeadingRank = switch (p.getLeaf().getKind()) {
> 
> (observation) Since _rank_ is a rather unusual word to see, I explored this a bit. Numerals in H1, H2, H3, H4, H5, and H6 were somewhat implicitly referred to as _heading levels_ by HTML4, and indeed became referred to as _ranks_ in HTML5.

yes, that is where I found the term.

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From joe.darcy at oracle.com  Tue May  3 22:49:10 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 3 May 2022 15:49:10 -0700
Subject: RFR of CSR for start of JDK 20 updates JDK-8286094 and JDK-8286096
Message-ID: <c17b7166-ae13-ebc0-3f23-4a7f5be920e9@oracle.com>

Hello,

Please review several CSRs ahead of the future start-of-JDK-20 updates:

 ??? JDK-8286094: Add source 20 and target 20 to javac
 ??? https://bugs.openjdk.java.net/browse/JDK-8286094

 ??? JDK-8286096: Add SourceVersion.RELEASE_20
 ??? https://bugs.openjdk.java.net/browse/JDK-8286096

The code review of these changes will eventually be done under

 ??? https://github.com/openjdk/jdk/pull/8236

I'm keeping that PR in draft for now to avoid spamming several mailing 
lists as the branch is synced with new changes from mainline.

Thanks,

-Joe


From mcimadamore at openjdk.java.net  Wed May  4 10:58:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 10:58:31 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>

On Tue, 3 May 2022 12:07:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

Changes look generally good. Personally, I found the changes in Flow the harder to follow - but I that part is just hard (even in the spec), as it has to perform a search in both breadth (as records have more than one component) and in depth (as patterns can be nested). I've added some comments to check my understanding.

src/java.base/share/classes/java/lang/MatchException.java line 41:

> 39:  *        constants at runtime than it had at compilation time, or the type hierarchy has changed
> 40:  *        in incompatible ways between compile time and run time.</li>
> 41:  *    <li>Null targets and sealed types. If an interface or abstract class {@code C} is sealed

Should this be `null targets and nested sealed type test patterns` ?

Also, not sure `null` target is the right expression - maybe `null and nested xyz` would work better?

src/jdk.compiler/share/classes/com/sun/source/tree/DeconstructionPatternTree.java line 43:

> 41:      * @return the deconstructed type
> 42:      */
> 43:     Tree getDeconstructor();

Shouldn't this return an ExpressionTree?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4180:

> 4178:             type = attribTree(tree.var.vartype, env, varInfo);
> 4179:         } else {
> 4180:             type = resultInfo.pt;

Looks good - infers the binging var type from the record component being processed. If not in a record, then I suspect resultInfo.pt is just the target expression type (e.g. var in toplevel environment).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 750:

> 748:         private Set<Symbol> coveredSymbols(DiagnosticPosition pos, Type targetType,
> 749:                                            Iterable<? extends JCCaseLabel> labels) {
> 750:             Set<Symbol> constants = new HashSet<>();

Should this be called `constants` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 824:

> 822:                 }
> 823:                 for (Symbol currentType : nestedCovered) {
> 824:                     if (types.isSubtype(types.erasure(currentType.type),

Not 100% what this test does

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 836:

> 834:             for (Entry<Symbol, List<JCDeconstructionPattern>> e : componentType2Patterns.entrySet()) {
> 835:                 if (coversDeconstructionStartingFromComponent(pos, targetType, e.getValue(), component + 1)) {
> 836:                     covered.add(e.getKey());

So... it seems to me that what this code is doing is that, for a component index _i_, we get all its recursively covered symbols - then we add them to the set of covered symbols of component _i_, but only if components _w_, where _w_ > _i_ are also covered? That is, if in `R(P1, P2, ... Pn)`, we see that `P1` is covered, but `P2` is not, we also consider `P1` not covered (which in turn makes `R` not covered).

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 788:

> 786:             }
> 787:             if (token.kind == LPAREN) {
> 788:                 ListBuffer<JCPattern> nested = new ListBuffer<>();

should we add comment saying "deconstruction pattern"

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 808:

> 806:                 pattern = toP(F.at(pos).DeconstructionPattern(e, nested.toList(), var));
> 807:             } else {
> 808:                 JCVariableDecl var = toP(F.at(token.pos).VarDef(mods, ident(), e, null));

and, here, a comment saying "type test pattern" ?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1004:

> 1002:                     JCExpression type = unannotatedType(false);
> 1003:                     if (token.kind == IDENTIFIER) {
> 1004:                         checkSourceLevel(token.pos, Feature.PATTERN_MATCHING_IN_INSTANCEOF);

Two question/comments:
* I believe that `checkSourceLevel` is called here, but not in `analyzePattern` because `analyzePattern` is also called in the `switch` code, in which case we already check for source level which supports pattern in switch, correct?
* For type test pattern, this code recurses to parsePattern, which seems correct, but the same doesn't happen for deconstructor patterns. Apart from the initial "peek" the code seems otherwise the same - would it be possible to consolidate?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3186:

> 3184:                                 : PatternResult.PATTERN;
> 3185:                     }
> 3186:                     parentDepth++; break;

* s/parentDepth/parenDepth
* maybe s/depth/typeDepth

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mcimadamore at openjdk.java.net  Wed May  4 10:58:33 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 10:58:33 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
Message-ID: <aXWInt5Fx8rtPdhD0B4IGHpEeXf8azyT99uPFsmZUpA=.1d0e2315-7c53-4d63-8f07-cb1460513d67@github.com>

On Wed, 4 May 2022 09:59:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4180:
> 
>> 4178:             type = attribTree(tree.var.vartype, env, varInfo);
>> 4179:         } else {
>> 4180:             type = resultInfo.pt;
> 
> Looks good - infers the binging var type from the record component being processed. If not in a record, then I suspect resultInfo.pt is just the target expression type (e.g. var in toplevel environment).

That said, I'm not sure how this connects with `instanceof`. This patch doesn't seem to alter `visitTypeTest`. In the current code I can see this:

if (tree.pattern.getTag() == BINDINGPATTERN ||
           tree.pattern.getTag() == PARENTHESIZEDPATTERN) {
           attribTree(tree.pattern, env, unknownExprInfo);
           ...
           

This seems wrong for two reasons:

* it doesn't take into account the new pattern tag
* it uses an "unknown" result info when attributing, meaning that any toplevel `var` pattern will not be attributed correctly

But we seem to have tests covering record patterns and instanceof. so I'm wondering if I'm missing some code update?

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From amaembo at gmail.com  Wed May  4 14:40:13 2022
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 4 May 2022 16:40:13 +0200
Subject: IllegalAccessError when method reference resolves to method returning
 inaccessible class
Message-ID: <CAE+3fjYHdVJQK2AZMEOQ09phoufOXLvQzfsy9wDBoEgCvLFiLw@mail.gmail.com>

Consider the following code:

// foo/Foo.java
package foo;

public class Foo {
    public static Bar bar() {
        return new Bar();
    }

    static class Bar {}
}

// bar/Baz.java
package bar;

import foo.Foo;
import java.util.function.Supplier;

public class Baz {
    public static  void foo(Supplier<Object> supplier) {
        System.out.println(supplier.get());
    }

    public static void main(String[] args) {
        Baz.foo(Foo::bar);
    }
}

It's perfectly compilable (tried javac 17 and 19-ea) but immediately
fails at runtime with

Exception in thread "main" java.lang.IllegalAccessError: failed to
access class foo.Foo$Bar from class bar.Baz (foo.Foo$Bar and bar.Baz
are in unnamed module of loader 'app')
at bar.Baz.main(Baz.java:14)

It looks like VM doesn't like if bootstrap method refers to a method
that mentions inaccessible type in a signature. However, we can
normally call the same method in lambda:

public static void main(String[] args) {
    Baz.foo(() -> Foo.bar());
}

I'm not sure whether this is a compiler or VM problem but to me, it
looks wrong when the program after successful complete recompilation
fails with IllegalAccessError. Please correct me if this compiler
behavior is specified.

With best regards,
Tagir Valeev

From alex.buckley at oracle.com  Wed May  4 16:30:12 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 4 May 2022 09:30:12 -0700
Subject: IllegalAccessError when method reference resolves to method
 returning inaccessible class
In-Reply-To: <CAE+3fjYHdVJQK2AZMEOQ09phoufOXLvQzfsy9wDBoEgCvLFiLw@mail.gmail.com>
References: <CAE+3fjYHdVJQK2AZMEOQ09phoufOXLvQzfsy9wDBoEgCvLFiLw@mail.gmail.com>
Message-ID: <b859c4ce-5251-a54e-e651-8fc356dac1eb@oracle.com>

I believe this program is accepted by JLS 15.13, and that accepting the 
program is correct. It has always been possible in Java to invoke a 
method whose return type is inaccessible to the caller, provided that 
the caller doesn't use the method's result at the inaccessible type. 
Fundamentally the same rules apply to the indirect invocation denoted by 
a method reference expression. Foo::bar is typed w.r.t. [the function 
type of] Supplier<Object>, for which an access check _is_ performed; 
however, Foo::bar is not typed w.r.t. anything involving the 
inaccessible nested type Foo.Bar, so Foo::bar is as legal as its 
"equivalent" lambda expression ()->Foo.bar().

Alex

On 5/4/2022 7:40 AM, Tagir Valeev wrote:
> Consider the following code:
> 
> // foo/Foo.java
> package foo;
> 
> public class Foo {
>      public static Bar bar() {
>          return new Bar();
>      }
> 
>      static class Bar {}
> }
> 
> // bar/Baz.java
> package bar;
> 
> import foo.Foo;
> import java.util.function.Supplier;
> 
> public class Baz {
>      public static  void foo(Supplier<Object> supplier) {
>          System.out.println(supplier.get());
>      }
> 
>      public static void main(String[] args) {
>          Baz.foo(Foo::bar);
>      }
> }
> 
> It's perfectly compilable (tried javac 17 and 19-ea) but immediately
> fails at runtime with
> 
> Exception in thread "main" java.lang.IllegalAccessError: failed to
> access class foo.Foo$Bar from class bar.Baz (foo.Foo$Bar and bar.Baz
> are in unnamed module of loader 'app')
> at bar.Baz.main(Baz.java:14)
> 
> It looks like VM doesn't like if bootstrap method refers to a method
> that mentions inaccessible type in a signature. However, we can
> normally call the same method in lambda:
> 
> public static void main(String[] args) {
>      Baz.foo(() -> Foo.bar());
> }
> 
> I'm not sure whether this is a compiler or VM problem but to me, it
> looks wrong when the program after successful complete recompilation
> fails with IllegalAccessError. Please correct me if this compiler
> behavior is specified.
> 
> With best regards,
> Tagir Valeev

From cushon at openjdk.java.net  Wed May  4 17:35:08 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 4 May 2022 17:35:08 GMT
Subject: RFR: 8284220: TypeMirror#toString omits enclosing class names
 after JDK-8281238 [v6]
In-Reply-To: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
References: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
Message-ID: <LBRyajLKjW5X5lCrP_vNJJ4yWo_3CCg1orG8oHbBUEQ=.6d66f55c-09fb-49de-90f9-059c4d26eb17@github.com>

> Please consider this fix for https://bugs.openjdk.java.net/browse/JDK-8284220, which updates `ClassType#toString` to include enclosing class names when type annotations are present.
> 
> For example, `java.util. at A Map.Entry<?,?>` is now printed as `java.util. at A Map.Entry<?,?>`, instead of `java.util. at A Entry<?,?>` (note the missing `Map`).

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

 - Merge branch 'master' into JDK-8284220
 - Merge branch 'master' into JDK-8284220
 - Add more documentation to test
 - Merge branch 'openjdk:master' into JDK-8284220
 - Refactor test based on review feedback
 - 8284220: TypeMirror#toString omits enclosing class names after JDK-8281238

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8084/files
  - new: https://git.openjdk.java.net/jdk/pull/8084/files/67103c77..d7b7e0ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8084&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8084&range=04-05

  Stats: 23542 lines in 721 files changed: 16763 ins; 3367 del; 3412 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8084.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8084/head:pull/8084

PR: https://git.openjdk.java.net/jdk/pull/8084

From prappo at openjdk.java.net  Wed May  4 18:34:25 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 4 May 2022 18:34:25 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class [v3]
In-Reply-To: <8LZE068FcdMqAk4tMZkTlmCbc62rdG533ieO8LqTYoA=.b960f449-31d4-4080-bf40-dd9721598a92@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
 <8LZE068FcdMqAk4tMZkTlmCbc62rdG533ieO8LqTYoA=.b960f449-31d4-4080-bf40-dd9721598a92@github.com>
Message-ID: <h2Ykelgyl6InH9QxUKB6j3XX6dbbVFkrJrRp1AfaYCA=.5b3f1cdb-7b5b-41d3-9bd7-0dd54fae5a15@github.com>

On Tue, 3 May 2022 22:47:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
>> 
>> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by prappo (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From darcy at openjdk.java.net  Wed May  4 20:19:44 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 4 May 2022 20:19:44 GMT
Subject: RFR: 8284220: TypeMirror#toString omits enclosing class names
 after JDK-8281238 [v6]
In-Reply-To: <LBRyajLKjW5X5lCrP_vNJJ4yWo_3CCg1orG8oHbBUEQ=.6d66f55c-09fb-49de-90f9-059c4d26eb17@github.com>
References: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
 <LBRyajLKjW5X5lCrP_vNJJ4yWo_3CCg1orG8oHbBUEQ=.6d66f55c-09fb-49de-90f9-059c4d26eb17@github.com>
Message-ID: <SVajXnjdlGqMmzXV5Rbq8I5mKcOhlp1NsO-qHGgEaiw=.c275f518-5958-4107-b67b-75b58ab6d27c@github.com>

On Wed, 4 May 2022 17:35:08 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please consider this fix for https://bugs.openjdk.java.net/browse/JDK-8284220, which updates `ClassType#toString` to include enclosing class names when type annotations are present.
>> 
>> For example, `java.util. at A Map.Entry<?,?>` is now printed as `java.util. at A Map.Entry<?,?>`, instead of `java.util. at A Entry<?,?>` (note the missing `Map`).
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8284220
>  - Merge branch 'master' into JDK-8284220
>  - Add more documentation to test
>  - Merge branch 'openjdk:master' into JDK-8284220
>  - Refactor test based on review feedback
>  - 8284220: TypeMirror#toString omits enclosing class names after JDK-8281238

Looks fine.

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

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8084

From jjg at openjdk.java.net  Wed May  4 20:27:06 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 4 May 2022 20:27:06 GMT
Subject: Integrated: JDK-8285869: Selective cleanup in doclint Checker class
In-Reply-To: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
References: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>
Message-ID: <AfqKtk--BcNUAKiaVZE0gpwSJ4RHyFy2NXVFeSSmmx0=.795e9f5f-8b36-4004-a1a3-450f296a69ab@github.com>

On Fri, 29 Apr 2022 00:29:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"
> 
> The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.

This pull request has now been integrated.

Changeset: 28e6d805
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/28e6d805f4bc9d107ac839aca854bcb96a6637d8
Stats:     154 lines in 2 files changed: 12 ins; 51 del; 91 mod

8285869: Selective cleanup in doclint Checker class

Reviewed-by: iris, prappo

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

PR: https://git.openjdk.java.net/jdk/pull/8460

From cushon at openjdk.java.net  Wed May  4 20:28:31 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 4 May 2022 20:28:31 GMT
Subject: Integrated: 8284220: TypeMirror#toString omits enclosing class names
 after JDK-8281238
In-Reply-To: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
References: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
Message-ID: <FyaZEqkCWpHO8l-1ihpyZyr03EqF8BKH9YUIf0W2WAg=.b7f85144-fe69-4a11-bc87-9b74418c89f2@github.com>

On Sun, 3 Apr 2022 22:22:06 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please consider this fix for https://bugs.openjdk.java.net/browse/JDK-8284220, which updates `ClassType#toString` to include enclosing class names when type annotations are present.
> 
> For example, `java.util. at A Map.Entry<?,?>` is now printed as `java.util. at A Map.Entry<?,?>`, instead of `java.util. at A Entry<?,?>` (note the missing `Map`).

This pull request has now been integrated.

Changeset: 4d30a1e8
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4d30a1e8d1587c63e85950b7a61439b5bf98c689
Stats:     165 lines in 4 files changed: 165 ins; 0 del; 0 mod

8284220: TypeMirror#toString omits enclosing class names after JDK-8281238

Reviewed-by: darcy

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

PR: https://git.openjdk.java.net/jdk/pull/8084

From iklam at openjdk.java.net  Thu May  5 00:09:28 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 5 May 2022 00:09:28 GMT
Subject: RFR: 8283606: Tests may fail with zh locale on MacOS [v4]
In-Reply-To: <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com>
References: <ptah2PBYatKtfv5rLFzaPP3rWqqPIz0cShcZHDjv3hg=.bd8d63bd-681e-4787-b3b4-d542233be781@github.com>
 <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com>
Message-ID: <1WS-PIPcRSnYI2AjzykxCMZhFLpyInWL1JGmMTZjhuY=.88e75659-952a-4313-837b-6770dbe994ca@github.com>

On Mon, 28 Mar 2022 17:00:39 GMT, Vikey Chen <duke at openjdk.java.net> wrote:

>> From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html
>>> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases.
>> 
>> However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced.
>> 
>> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java
>> test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java
>> test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java
>> test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java
>> test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java
>> test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java
>> test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java
>> test/langtools/tools/javac/platform/PlatformProviderTest.java
>> test/langtools/tools/jdeps/MultiReleaseJar.java
>
> Vikey Chen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Locale.ENGLISH to Locale.US

I tested the patch on latest JDK repo and passed tiers 1 and 2.

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

PR: https://git.openjdk.java.net/jdk/pull/7924

From duke at openjdk.java.net  Thu May  5 00:09:30 2022
From: duke at openjdk.java.net (Vikey Chen)
Date: Thu, 5 May 2022 00:09:30 GMT
Subject: Integrated: 8283606: Tests may fail with zh locale on MacOS
In-Reply-To: <ptah2PBYatKtfv5rLFzaPP3rWqqPIz0cShcZHDjv3hg=.bd8d63bd-681e-4787-b3b4-d542233be781@github.com>
References: <ptah2PBYatKtfv5rLFzaPP3rWqqPIz0cShcZHDjv3hg=.bd8d63bd-681e-4787-b3b4-d542233be781@github.com>
Message-ID: <fD0HBqe_Iytld72N4PyZhHB_iqo76XQ9XlcDN6SoAoQ=.68501a95-3b2f-4707-9ab9-404e04d85bc6@github.com>

On Wed, 23 Mar 2022 15:34:43 GMT, Vikey Chen <duke at openjdk.java.net> wrote:

> From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html
>> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases.
> 
> However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced.
> 
> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java
> test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java
> test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java
> test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java
> test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java
> test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java
> test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java
> test/langtools/tools/javac/platform/PlatformProviderTest.java
> test/langtools/tools/jdeps/MultiReleaseJar.java

This pull request has now been integrated.

Changeset: 7d545084
Author:    Vikey Chen <vikeytk at gmail.com>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7d545084f45af44386cb38172fd783f889a8c4e7
Stats:     37 lines in 9 files changed: 14 ins; 0 del; 23 mod

8283606: Tests may fail with zh locale on MacOS

Reviewed-by: iklam, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/7924

From duke at openjdk.java.net  Thu May  5 01:19:22 2022
From: duke at openjdk.java.net (Vikey Chen)
Date: Thu, 5 May 2022 01:19:22 GMT
Subject: RFR: 8283606: Tests may fail with zh locale on MacOS [v4]
In-Reply-To: <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com>
References: <ptah2PBYatKtfv5rLFzaPP3rWqqPIz0cShcZHDjv3hg=.bd8d63bd-681e-4787-b3b4-d542233be781@github.com>
 <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com>
Message-ID: <CPsIhjvoYOqpqSi8SeJn5aDHuihl3A0LbIDxbIlfdWw=.c2a1273b-c84b-49a2-a815-04a5f5d96d67@github.com>

On Mon, 28 Mar 2022 17:00:39 GMT, Vikey Chen <duke at openjdk.java.net> wrote:

>> From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html
>>> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases.
>> 
>> However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced.
>> 
>> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java
>> test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java
>> test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java
>> test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java
>> test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java
>> test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java
>> test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java
>> test/langtools/tools/javac/platform/PlatformProviderTest.java
>> test/langtools/tools/jdeps/MultiReleaseJar.java
>
> Vikey Chen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Locale.ENGLISH to Locale.US

Thanks Ioi and Roger.

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

PR: https://git.openjdk.java.net/jdk/pull/7924

From amaembo at gmail.com  Thu May  5 06:54:15 2022
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 5 May 2022 08:54:15 +0200
Subject: IllegalAccessError when method reference resolves to method
 returning inaccessible class
In-Reply-To: <b859c4ce-5251-a54e-e651-8fc356dac1eb@oracle.com>
References: <CAE+3fjYHdVJQK2AZMEOQ09phoufOXLvQzfsy9wDBoEgCvLFiLw@mail.gmail.com>
 <b859c4ce-5251-a54e-e651-8fc356dac1eb@oracle.com>
Message-ID: <CAE+3fjYbJ97wYuLqfpWcww+sUstJnS8Qz96f1sVk0zK7JViaeQ@mail.gmail.com>

Thank you, Alex.

I also think that accepting the program is correct. However, it looks
like the resulting bytecode is not accepted by JVM. Probably, emitting
a bridge method is necessary here (effectively compiling the method
reference just like lambda).

With best regards,
Tagir Valeev.

On Wed, May 4, 2022 at 6:30 PM Alex Buckley <alex.buckley at oracle.com> wrote:
>
> I believe this program is accepted by JLS 15.13, and that accepting the
> program is correct. It has always been possible in Java to invoke a
> method whose return type is inaccessible to the caller, provided that
> the caller doesn't use the method's result at the inaccessible type.
> Fundamentally the same rules apply to the indirect invocation denoted by
> a method reference expression. Foo::bar is typed w.r.t. [the function
> type of] Supplier<Object>, for which an access check _is_ performed;
> however, Foo::bar is not typed w.r.t. anything involving the
> inaccessible nested type Foo.Bar, so Foo::bar is as legal as its
> "equivalent" lambda expression ()->Foo.bar().
>
> Alex
>
> On 5/4/2022 7:40 AM, Tagir Valeev wrote:
> > Consider the following code:
> >
> > // foo/Foo.java
> > package foo;
> >
> > public class Foo {
> >      public static Bar bar() {
> >          return new Bar();
> >      }
> >
> >      static class Bar {}
> > }
> >
> > // bar/Baz.java
> > package bar;
> >
> > import foo.Foo;
> > import java.util.function.Supplier;
> >
> > public class Baz {
> >      public static  void foo(Supplier<Object> supplier) {
> >          System.out.println(supplier.get());
> >      }
> >
> >      public static void main(String[] args) {
> >          Baz.foo(Foo::bar);
> >      }
> > }
> >
> > It's perfectly compilable (tried javac 17 and 19-ea) but immediately
> > fails at runtime with
> >
> > Exception in thread "main" java.lang.IllegalAccessError: failed to
> > access class foo.Foo$Bar from class bar.Baz (foo.Foo$Bar and bar.Baz
> > are in unnamed module of loader 'app')
> > at bar.Baz.main(Baz.java:14)
> >
> > It looks like VM doesn't like if bootstrap method refers to a method
> > that mentions inaccessible type in a signature. However, we can
> > normally call the same method in lambda:
> >
> > public static void main(String[] args) {
> >      Baz.foo(() -> Foo.bar());
> > }
> >
> > I'm not sure whether this is a compiler or VM problem but to me, it
> > looks wrong when the program after successful complete recompilation
> > fails with IllegalAccessError. Please correct me if this compiler
> > behavior is specified.
> >
> > With best regards,
> > Tagir Valeev

From abimpoudis at openjdk.java.net  Thu May  5 12:09:18 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 5 May 2022 12:09:18 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <ARuPq5vlo0dKLhaeZUYa30wcFd7GDZp-twt8cu4B1Zg=.436547c2-b52f-4c68-89bf-468416a99a2a@github.com>

On Tue, 3 May 2022 12:07:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 783:

> 781:             }
> 782:             for (Entry<Symbol, List<JCDeconstructionPattern>> e : categorizedDeconstructionPatterns.entrySet()) {
> 783:                 if (coversDeconstructionStartingFromComponent(pos, targetType, e.getValue(), 0)) {

Here, the result of `e.getValue` is a reversed list of the observed patterns. 

For the switch below,


switch (r) {
            case R(A a, A b) -> 1;
            case R(A a, B b) -> 2;
            case R(B a, A b) -> 3;
            case R(B a, B b) -> 4;
}


The 0th element of that list is the `R(B a, B b)` pattern, the 1st the `R(B a, A b)`. I am 99% sure that this is not a problem but I am pointing it out regardless, in case there is any underlying danger to that.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From abimpoudis at openjdk.java.net  Thu May  5 12:09:18 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 5 May 2022 12:09:18 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
Message-ID: <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>

On Wed, 4 May 2022 10:51:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 824:
> 
>> 822:                 }
>> 823:                 for (Symbol currentType : nestedCovered) {
>> 824:                     if (types.isSubtype(types.erasure(currentType.type),
> 
> Not 100% what this test does

I think this is i) from the domination relation:

> A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mcimadamore at openjdk.java.net  Thu May  5 12:20:17 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 12:20:17 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
Message-ID: <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>

On Thu, 5 May 2022 12:06:38 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> I think this is i) from the domination relation:
> 
> > A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.

But this subtyping test seems to happen at the level of the component pattern list, not at the R/S level, right?

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From abimpoudis at openjdk.java.net  Thu May  5 12:32:14 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 5 May 2022 12:32:14 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
 <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
Message-ID: <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>

On Thu, 5 May 2022 12:16:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I think this is i) from the domination relation:
>> 
>>> A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.
>
>> I think this is i) from the domination relation:
>> 
>> > A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.
> 
> But this subtyping test seems to happen at the level of the component pattern list, not at the R/S level, right?

You are right. It is the ii) which iteratively checks the component pattern list L.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From rriggs at openjdk.java.net  Thu May  5 15:38:40 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 15:38:40 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
Message-ID: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>

Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

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

Commit messages:
 - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
 - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From mcimadamore at openjdk.java.net  Thu May  5 15:48:37 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 15:48:37 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <UCFbYTr1ZOafb18sLjmi7h1X0vdur721OLDSvrba3Lw=.64954b7b-38f4-4b9e-8750-e90e6847edb3@github.com>

On Tue, 3 May 2022 12:07:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

I've added some renaming suggestions for the code in Flow, after some discussions with @biboudis.
More generally, that code should contain comments, with example of what it's trying to do - e.g. how it's partitioning the set of patterns, etc.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 64:

> 62:     public enum Feature {
> 63:         SWITCH_PATTERN_MATCHING,
> 64:         DECONSTRUCTION_PATTERNS,

The spec and JEP talks about record patterns - I think we should follow the correct name here

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 751:

> 749:                                            Iterable<? extends JCCaseLabel> labels) {
> 750:             Set<Symbol> constants = new HashSet<>();
> 751:             Map<Symbol, List<JCDeconstructionPattern>> categorizedDeconstructionPatterns = new HashMap<>();

maybe rename to `deconstructionPatternsBySymbol` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 790:

> 788:         }
> 789: 
> 790:         private boolean coversDeconstructionStartingFromComponent(DiagnosticPosition pos,

maybe rename as `coverDeconstructionFromComponent`/`coverDeconstructionAt`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 792:

> 790:         private boolean coversDeconstructionStartingFromComponent(DiagnosticPosition pos,
> 791:                                                                   Type targetType,
> 792:                                                                   List<JCDeconstructionPattern> patterns,

patterns -> "deconstructionPatterns"

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 800:

> 798:             }
> 799: 
> 800:             Type parameterizedComponentType = types.memberType(targetType, components.get(component));

maybe `instantiatedComponentType`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 802:

> 800:             Type parameterizedComponentType = types.memberType(targetType, components.get(component));
> 801:             List<JCPattern> nestedComponentPatterns = patterns.map(d -> d.nested.get(component));
> 802:             Set<Symbol> nestedCovered = coveredSymbols(pos, parameterizedComponentType,

maybe `coveredComponents`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 807:

> 805:             Set<Symbol> covered = new HashSet<>();
> 806: 
> 807:             for (JCDeconstructionPattern subTypeCandidate : patterns) {

`subTypeCandidate` -> `deconstructionPattern`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 809:

> 807:             for (JCDeconstructionPattern subTypeCandidate : patterns) {
> 808:                 JCPattern nestedPattern = subTypeCandidate.nested.get(component);
> 809:                 Symbol currentPatternType;

`currentPatternType` -> `componentPatternType`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 823:

> 821:                     }
> 822:                 }
> 823:                 for (Symbol currentType : nestedCovered) {

`currentType` -> `coveredComponent`

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 246:

> 244:         PARENTHESIZEDPATTERN,
> 245: 
> 246:         DECONSTRUCTIONPATTERN,

might want to rename to RECORDPATTERN (but this is impl dependent, so less important to fix)

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 2373:

> 2371:     }
> 2372: 
> 2373:     public static class JCDeconstructionPattern extends JCPattern

JCRecordPattern (although this is impl-only, so less important to fix)

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mcimadamore at openjdk.java.net  Thu May  5 15:48:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 15:48:38 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
 <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
 <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>
Message-ID: <ff8zs0KPz1lnUAXZnOLmgOV29nrMku68gCzcXx22cfk=.e3013590-1330-45f9-9c8e-d39a1784aeda@github.com>

On Thu, 5 May 2022 12:28:42 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>>> I think this is i) from the domination relation:
>>> 
>>> > A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.
>> 
>> But this subtyping test seems to happen at the level of the component pattern list, not at the R/S level, right?
>
> You are right. It is the ii) which iteratively checks the component pattern list L.

I now believe that the check is needed to properly classify patterns based on the type of the i-th component. That said, not sure this should be a subtyping check, or a type equality

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From rriggs at openjdk.java.net  Thu May  5 15:52:08 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 15:52:08 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <e_sR29d_Zl9ExOEc4SGmHIp2i-CBudv0Jz5WoPajR6o=.424b8572-8f96-48ad-a5b5-6bccc90ccf96@github.com>

On Thu, 5 May 2022 15:30:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

The PR is not needed, the issue will be fixed by PR#8556.

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 15:52:08 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 15:52:08 GMT
Subject: Withdrawn: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <-MV5GsnX2_TA6gbscqcAd9hUUDyAHptzeUVbFokmRq0=.fb0a68d1-434f-46a3-8d5d-08e359fa86db@github.com>

On Thu, 5 May 2022 15:30:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From vromero at openjdk.java.net  Thu May  5 17:39:16 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 5 May 2022 17:39:16 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <UCFbYTr1ZOafb18sLjmi7h1X0vdur721OLDSvrba3Lw=.64954b7b-38f4-4b9e-8750-e90e6847edb3@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <UCFbYTr1ZOafb18sLjmi7h1X0vdur721OLDSvrba3Lw=.64954b7b-38f4-4b9e-8750-e90e6847edb3@github.com>
Message-ID: <Xgg7Wh7p5xT8ONeIAFTexGHrailtcndlQBj2IPG1gNI=.938fd89e-bb35-469b-bcae-bc50e21db5ff@github.com>

On Thu, 5 May 2022 15:21:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 64:
> 
>> 62:     public enum Feature {
>> 63:         SWITCH_PATTERN_MATCHING,
>> 64:         DECONSTRUCTION_PATTERNS,
> 
> The spec and JEP talks about record patterns - I think we should follow the correct name here

yup, I agree

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From dcubed at openjdk.java.net  Thu May  5 19:26:32 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 5 May 2022 19:26:32 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <j2slI-tA8Mq-MV6-icXxs5eGeBsJ5ZnqTHDlieJ1_mc=.8cf2fbad-f982-4a15-b5ab-a647e8687c96@github.com>

On Thu, 5 May 2022 15:30:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

Thumbs up (after resync). This is a trivial fix.

test/lib-test/ProblemList.txt line 40:

> 38: #
> 39: #############################################################################
> 40: jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java 8286191 generic-all

This change shouldn't be here. I think you need to update
your repo to sync with your earlier fix.

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 19:56:36 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 19:56:36 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java [v2]
In-Reply-To: <j2slI-tA8Mq-MV6-icXxs5eGeBsJ5ZnqTHDlieJ1_mc=.8cf2fbad-f982-4a15-b5ab-a647e8687c96@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
 <j2slI-tA8Mq-MV6-icXxs5eGeBsJ5ZnqTHDlieJ1_mc=.8cf2fbad-f982-4a15-b5ab-a647e8687c96@github.com>
Message-ID: <A3ndGjxg4YA3-UMR65VC0hJH5lmRhi-sKBdISCPleTA=.30609e3b-3980-4fb0-aa42-ee04e1487f33@github.com>

On Thu, 5 May 2022 19:23:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Roger Riggs 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 8286199-problem-jshell
>>  - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
>>  - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java
>
> test/lib-test/ProblemList.txt line 40:
> 
>> 38: #
>> 39: #############################################################################
>> 40: jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java 8286191 generic-all
> 
> This change shouldn't be here. I think you need to update
> your repo to sync with your earlier fix.

Updated, after the merge only the langtools ProblemList.txt is modified

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 19:56:36 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 19:56:36 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java [v2]
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

Roger Riggs 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 8286199-problem-jshell
 - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
 - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8557/files
  - new: https://git.openjdk.java.net/jdk/pull/8557/files/1962634e..cd0d157c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8557&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8557&range=00-01

  Stats: 656 lines in 10 files changed: 269 ins; 209 del; 178 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8557.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8557/head:pull/8557

PR: https://git.openjdk.java.net/jdk/pull/8557

From dcubed at openjdk.java.net  Thu May  5 20:06:59 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 5 May 2022 20:06:59 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java [v2]
In-Reply-To: <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
 <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>
Message-ID: <X2YJGs4rqJmZxMXdEj68KmiTJKn4PEtXBeDehHhZ0Io=.5c4a2188-1ff6-4232-8b12-0eca8510c35a@github.com>

On Thu, 5 May 2022 19:56:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.
>
> Roger Riggs 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 8286199-problem-jshell
>  - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
>  - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 20:06:59 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 20:06:59 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java [v2]
In-Reply-To: <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
 <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>
Message-ID: <08JP1LQ73JAFDNdsgBjfx3QUdPORyet98rCcHCdCBvs=.f7b00a4a-a979-4c9f-995c-b4163ced7550@github.com>

On Thu, 5 May 2022 19:56:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.
>
> Roger Riggs 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 8286199-problem-jshell
>  - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
>  - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

ProblemListing the test to clean up the CI.
#8556 seems to have been delayed

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 20:07:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 20:07:01 GMT
Subject: Integrated: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <iqXAqtRkfp4Clh15adhHYvpRLiRfqFlZwxqyDjZsmzc=.29a9606b-2afd-4809-8aba-7e038dd4bde0@github.com>

On Thu, 5 May 2022 15:30:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

This pull request has now been integrated.

Changeset: 2f995c8d
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2f995c8d2b8650e45e6a360f3c958bfaf46b2ef3
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8286199: ProblemList jdk/jshell/ExternalEditorTest.java

Reviewed-by: dcubed

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From abimpoudis at openjdk.java.net  Fri May  6 09:29:47 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 6 May 2022 09:29:47 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <ARuPq5vlo0dKLhaeZUYa30wcFd7GDZp-twt8cu4B1Zg=.436547c2-b52f-4c68-89bf-468416a99a2a@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <ARuPq5vlo0dKLhaeZUYa30wcFd7GDZp-twt8cu4B1Zg=.436547c2-b52f-4c68-89bf-468416a99a2a@github.com>
Message-ID: <Iy47suZU3gubfJfa-JTLMTBg8-UW8gBvuCwCf7aD6E0=.05749c17-7dc3-44b4-931e-54de051e93ff@github.com>

On Thu, 5 May 2022 11:57:34 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 783:
> 
>> 781:             }
>> 782:             for (Entry<Symbol, List<JCDeconstructionPattern>> e : categorizedDeconstructionPatterns.entrySet()) {
>> 783:                 if (coversDeconstructionStartingFromComponent(pos, targetType, e.getValue(), 0)) {
> 
> Here, the result of `e.getValue` is a reversed list of the observed patterns. 
> 
> For the switch below,
> 
> 
> switch (r) {
>             case R(A a, A b) -> 1;
>             case R(A a, B b) -> 2;
>             case R(B a, A b) -> 3;
>             case R(B a, B b) -> 4;
> }
> 
> 
> The 0th element of that list is the `R(B a, B b)` pattern, the 1st the `R(B a, A b)`. I am 99% sure that this is not a problem but I am pointing it out regardless, in case there is any underlying danger to that.

Order doesn't matter. I triple checked.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Fri May  6 10:54:44 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 10:54:44 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <ff8zs0KPz1lnUAXZnOLmgOV29nrMku68gCzcXx22cfk=.e3013590-1330-45f9-9c8e-d39a1784aeda@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
 <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
 <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>
 <ff8zs0KPz1lnUAXZnOLmgOV29nrMku68gCzcXx22cfk=.e3013590-1330-45f9-9c8e-d39a1784aeda@github.com>
Message-ID: <EAuN_I-WQ69znIV0H_SNEN9xHHo77oVR-fUhVC32OUU=.0ee69407-f82e-4973-999d-5298acdcea97@github.com>

On Thu, 5 May 2022 15:17:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> You are right. It is the ii) which iteratively checks the component pattern list L.
>
> I now believe that the check is needed to properly classify patterns based on the type of the i-th component. That said, not sure this should be a subtyping check, or a type equality

A good question. Consider code like:

    private void test(R r) {
        switch (r) {
            case R(A a, A v) -> {}
            case R(B b, A v) -> {}
            case R(I i, B v) -> {}
        }
    }
    final class A implements I {}
    sealed interface I permits A, B {}
    final class B implements I {}
    record R(I i1, I i2) {}


The switch is exhaustive - all the possible combinations are covered. When checking the first component, the code will categorize the patterns like:

A -> R(A a, A v), R(I i, B v)
B -> R(B b, A v), R(I i, B v)
I   -> R(I i, B v)

this categorization is done using the subtype check, so that `R(I i, B v)` will appear in the list for `A`. When checking the second component, the possibility for `I` is not exhaustive (does not cover `A` in the second component), but the possibilities for `A` and `B` are exhaustive, and they together cover `I`.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mcimadamore at openjdk.java.net  Fri May  6 11:47:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 11:47:46 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <EAuN_I-WQ69znIV0H_SNEN9xHHo77oVR-fUhVC32OUU=.0ee69407-f82e-4973-999d-5298acdcea97@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
 <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
 <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>
 <ff8zs0KPz1lnUAXZnOLmgOV29nrMku68gCzcXx22cfk=.e3013590-1330-45f9-9c8e-d39a1784aeda@github.com>
 <EAuN_I-WQ69znIV0H_SNEN9xHHo77oVR-fUhVC32OUU=.0ee69407-f82e-4973-999d-5298acdcea97@github.com>
Message-ID: <rfSLRnkD06hQsseSOVLaUAyqYVbdd4XeGJlsgCSucj4=.6bfca844-1270-4740-93fb-9a074f83c46c@github.com>

On Fri, 6 May 2022 10:51:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I now believe that the check is needed to properly classify patterns based on the type of the i-th component. That said, not sure this should be a subtyping check, or a type equality
>
> A good question. Consider code like:
> 
>     private void test(R r) {
>         switch (r) {
>             case R(A a, A v) -> {}
>             case R(B b, A v) -> {}
>             case R(I i, B v) -> {}
>         }
>     }
>     final class A implements I {}
>     sealed interface I permits A, B {}
>     final class B implements I {}
>     record R(I i1, I i2) {}
> 
> 
> The switch is exhaustive - all the possible combinations are covered. When checking the first component, the code will categorize the patterns like:
> 
> A -> R(A a, A v), R(I i, B v)
> B -> R(B b, A v), R(I i, B v)
> I   -> R(I i, B v)
> 
> this categorization is done using the subtype check, so that `R(I i, B v)` will appear in the list for `A`. When checking the second component, the possibility for `I` is not exhaustive (does not cover `A` in the second component), but the possibilities for `A` and `B` are exhaustive, and they together cover `I`.

Ah - makes sense of course - I "just" needed a more convoluted example :-)

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Fri May  6 12:01:00 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 12:01:00 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <aXWInt5Fx8rtPdhD0B4IGHpEeXf8azyT99uPFsmZUpA=.1d0e2315-7c53-4d63-8f07-cb1460513d67@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <aXWInt5Fx8rtPdhD0B4IGHpEeXf8azyT99uPFsmZUpA=.1d0e2315-7c53-4d63-8f07-cb1460513d67@github.com>
Message-ID: <iN1xCC5z772qtp9-mKoveY5nu8HEbM27pF0ErqM8Mf0=.3c8971cf-fa27-4e0b-830f-8c6492484f8c@github.com>

On Wed, 4 May 2022 10:03:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4180:
>> 
>>> 4178:             type = attribTree(tree.var.vartype, env, varInfo);
>>> 4179:         } else {
>>> 4180:             type = resultInfo.pt;
>> 
>> Looks good - infers the binging var type from the record component being processed. If not in a record, then I suspect resultInfo.pt is just the target expression type (e.g. var in toplevel environment).
>
> That said, I'm not sure how this connects with `instanceof`. This patch doesn't seem to alter `visitTypeTest`. In the current code I can see this:
> 
> if (tree.pattern.getTag() == BINDINGPATTERN ||
>            tree.pattern.getTag() == PARENTHESIZEDPATTERN) {
>            attribTree(tree.pattern, env, unknownExprInfo);
>            ...
>            
> 
> This seems wrong for two reasons:
> 
> * it doesn't take into account the new pattern tag
> * it uses an "unknown" result info when attributing, meaning that any toplevel `var` pattern will not be attributed correctly
> 
> But we seem to have tests covering record patterns and instanceof. so I'm wondering if I'm missing some code update?

Some of the handling inside this ifs is only needed for type test and parenthesized patterns (as record patterns are never unconditional (total)). I have an upcoming patch that should improve the tests here, however.

For `var` - the specification does not allow `var` at the top level (14.30.1, "The LocalVariableType in a top-level type pattern denotes a reference type (and furthermore is not var)."). In my upcoming patch, I am adding a test to ensure meaningful behavior for top-level type test patterns with `var`.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From simeon.danailov.andreev at gmail.com  Fri May  6 13:47:39 2022
From: simeon.danailov.andreev at gmail.com (S A)
Date: Fri, 6 May 2022 16:47:39 +0300
Subject: Non-javac compiler support for '--release N'
Message-ID: <CACcnpz1vmDMuQWosVhDH2XaSzy7vB44VqeNBb5dgdbhm51yirA@mail.gmail.com>

 Hi all,

to summarize my question, how is a non-javac compiler expected to support
the '--release N' option?

E.g. the Eclipse Java compiler utilizes the archive 'lib/ct.sym' that is
available in the JDK distributions. As far as I'm aware, the structure of
this archive has no official specification and  there is no guarantee that
the current structure will remain stable (including backporting changes).
So are other compilers meant to use this archive, or was it added
exclusively for javac?

>From the jdt-dev Eclipse mailing list, I was pointed to:
https://bugs.openjdk.java.net/browse/JDK-8199521 (on which there has been
no activity)

Best regards and thanks,
Simeon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220506/21d3ec6c/attachment.htm>

From ethan at mccue.dev  Fri May  6 14:08:13 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 6 May 2022 15:08:13 +0100
Subject: Non-javac compiler support for '--release N'
In-Reply-To: <CACcnpz1vmDMuQWosVhDH2XaSzy7vB44VqeNBb5dgdbhm51yirA@mail.gmail.com>
References: <CACcnpz1vmDMuQWosVhDH2XaSzy7vB44VqeNBb5dgdbhm51yirA@mail.gmail.com>
Message-ID: <CA+NR86i5TxAB=dKq9fao8PnZ6WEQd_QQOYvaDVaQxoeqKk_vDw@mail.gmail.com>

Totally non authoritative answer, but at first read ct.sym
is generated by this script here

https://github.com/openjdk/jdk/blob/master/make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java

Conceptually, an alternative compiler can just run the same script and get
the same output, but with the conceit that deciding on the file format for
the dump and keeping the script updated with respect to the rest of the JDK
would be the responsibility of that compiler.

The output of the script could also be written out manually into whatever
format. "Which apis we're introduced in which release" is a stable set of
things. You could do it by hand, the script is just an optimization for
carpal tunnel.

On Fri, May 6, 2022, 2:48 PM S A <simeon.danailov.andreev at gmail.com> wrote:

> Hi all,
>
> to summarize my question, how is a non-javac compiler expected to support
> the '--release N' option?
>
> E.g. the Eclipse Java compiler utilizes the archive 'lib/ct.sym' that is
> available in the JDK distributions. As far as I'm aware, the structure of
> this archive has no official specification and  there is no guarantee that
> the current structure will remain stable (including backporting changes).
> So are other compilers meant to use this archive, or was it added
> exclusively for javac?
>
> From the jdt-dev Eclipse mailing list, I was pointed to:
> https://bugs.openjdk.java.net/browse/JDK-8199521 (on which there has been
> no activity)
>
> Best regards and thanks,
> Simeon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220506/a3e961f3/attachment.htm>

From jlahoda at openjdk.java.net  Fri May  6 14:09:24 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 14:09:24 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

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

  Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8516/files
  - new: https://git.openjdk.java.net/jdk/pull/8516/files/56020b0b..90b37c3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=00-01

  Stats: 193 lines in 18 files changed: 67 ins; 19 del; 107 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From abimpoudis at openjdk.java.net  Fri May  6 14:32:54 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 6 May 2022 14:32:54 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
Message-ID: <2fBRfV4OxKk_OYkO8lKU7bEyHi8lrnen1ZOsnI80BFY=.80a15060-7bcf-434a-9e3a-c2e008a110f9@github.com>

On Fri, 6 May 2022 14:09:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

>From the JLS specdiff

> If the type R names a generic record class then it is a compile-time error if R is not a parameterized type.

The following snippet raises a `MatchException`. Shouldn't it be a compile-time error?


        Box<String> r = new Box<>(null);

        switch (r) {
            case Box(String s):
                System.out.println("match");
        }

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mcimadamore at openjdk.java.net  Fri May  6 14:46:58 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 14:46:58 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
Message-ID: <BRVCNwq7xvWl2AwuqeynSn5BfSc3G7LTaXoee3r3neQ=.90f9863d-7651-405a-b2b4-10cfd75429dd@github.com>

On Fri, 6 May 2022 14:09:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 752:

> 750:                                            Iterable<? extends JCCaseLabel> labels) {
> 751:             Set<Symbol> coveredSymbols = new HashSet<>();
> 752:             Map<Symbol, List<JCRecordPattern>> deconstructionPatternsBySymbol = new HashMap<>();

since you seem to have settled on "recordPattern" for implementation names - you can probably revisit some of these names to say "record" instead of "deconstruction".

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 801:

> 799:             //i.e. represent all possible combinations.
> 800:             //This is done by categorizing the patterns based on the type covered by the given
> 801:             //starting component.

Example needed here. For instance (I discussed this with @biboudis):


record Outer(R r) { };
sealed interface I { };
class A implements I { };
class B implements I { };
sealed interface R { };
record Foo(I i) implements R { }
record Bar(I i) implements R { }

switch (o) {
   case Outer(Foo(A), Foo(A)):
   case Outer(Foo(B), Foo(B)):
   case Outer(Foo(A), Foo(B)):
   case Outer(Foo(B), Foo(A)):
   case Outer(Bar(A), Bar(A)):
   case Outer(Bar(B), Bar(B)):
   case Outer(Bar(A), Bar(B)):
   case Outer(Bar(B), Bar(A)):
}


Which generates two sets:


   case Outer(Foo(A), Foo(A)):
   case Outer(Foo(B), Foo(B)):
   case Outer(Foo(A), Foo(B)):
   case Outer(Foo(B), Foo(A)):


And


   case Outer(Bar(A), Bar(A)):
   case Outer(Bar(B), Bar(B)):
   case Outer(Bar(A), Bar(B)):
   case Outer(Bar(B), Bar(A)):


Sorry for being pedantic - this code is tricky and I'm worried we'll all forget exactly how it works in 2 months :-)

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1014:

> 1012:                         pattern = parsePattern(patternPos, mods, type, false);
> 1013:                     } else if (token.kind == LPAREN) {
> 1014:                         pattern = parsePattern(patternPos, mods, type, false);

Nice!

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8516

From gbierman at openjdk.java.net  Fri May  6 15:47:51 2022
From: gbierman at openjdk.java.net (Gavin Bierman)
Date: Fri, 6 May 2022 15:47:51 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
Message-ID: <yfzxxHdWskcWrJOxDBMMeSXV-24cL3E-kdvQ71FwArA=.b1c9b7f7-5fcd-4462-ab4d-137364a9bafd@github.com>

On Fri, 6 May 2022 14:09:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

> From the JLS specdiff
> 
> > If the type R names a generic record class then it is a compile-time error if R is not a parameterized type.
> 
> The following snippet raises a `MatchException`. Shouldn't it be a compile-time error?
> 
> ```
>         Box<String> r = new Box<>(null);
> 
>         switch (r) {
>             case Box(String s):
>                 System.out.println("match");
>         }
> ```
> 
> If this is Ok and my understanding is wrong, then why that raises an exception at all? I can make it work (as an unconditional) if I define the Box as `record Box<T extends String>` and now I am confused...
> 
> ping @GavinBierman @lahodaj

A couple of issues here. (1) This should be a compile-time error. (2) upon investigation I think there is a bug with the pattern matching code, because the compiler is currently saying that the pattern match here: `Box<String> bs = new Box<>(null); if (bs instanceof Box<String>(String s)) { System.out.println("match!"); }` does not succeed. (It should do). The `MatchException` you are seeing is that the exhaustive pattern switch has no matching label (if you put in a default, you don't get the exception).

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From vromero at openjdk.java.net  Fri May  6 17:06:45 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 6 May 2022 17:06:45 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
Message-ID: <DPtIa69a2NgNDwSmzHyrn-kQAocDY_j8WoMLhlvrA3w=.846c9409-3838-4605-9ad7-1dfcb435ceba@github.com>

On Fri, 6 May 2022 14:09:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4217:

> 4215:         }
> 4216:         ListBuffer<BindingSymbol> outBindings = new ListBuffer<>();
> 4217:         List<Type> recordTypes = expectedRecordTypes;

nit: probably a matter of style but why not reusing the already declared `expectedRecordTypes` declaring a new variable seems unnecessary

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From joe.darcy at oracle.com  Fri May  6 17:28:49 2022
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 6 May 2022 10:28:49 -0700
Subject: Non-javac compiler support for '--release N'
In-Reply-To: <CACcnpz1vmDMuQWosVhDH2XaSzy7vB44VqeNBb5dgdbhm51yirA@mail.gmail.com>
References: <CACcnpz1vmDMuQWosVhDH2XaSzy7vB44VqeNBb5dgdbhm51yirA@mail.gmail.com>
Message-ID: <01c8d628-632e-80b7-84da-1979598756f2@oracle.com>

On 5/6/2022 6:47 AM, S A wrote:
> Hi all,
>
> to summarize my question, how is a non-javac compiler expected to 
> support the '--release N' option?
>
> E.g. the Eclipse Java compiler utilizes the archive 'lib/ct.sym' that 
> is available in the JDK distributions. As far as I'm aware, the 
> structure of this archive has no official specification and? there is 
> no guarantee that the current structure will remain stable (including 
> backporting changes). So are other compilers meant to use this 
> archive, or was it added exclusively for javac?


The format and existence of the ct.sym and the incremental symbol files 
used for --release are not exported interfaces of the JDK.

Cheers,

-Joe


From jlahoda at openjdk.java.net  Fri May  6 17:43:04 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 17:43:04 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <yfzxxHdWskcWrJOxDBMMeSXV-24cL3E-kdvQ71FwArA=.b1c9b7f7-5fcd-4462-ab4d-137364a9bafd@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
 <yfzxxHdWskcWrJOxDBMMeSXV-24cL3E-kdvQ71FwArA=.b1c9b7f7-5fcd-4462-ab4d-137364a9bafd@github.com>
Message-ID: <uhs6EaCqbGo8ovGL2JmU_qH2MOTg5uJoXbHkl-E382M=.55169332-81c4-4dca-a222-4abe56c6e64c@github.com>

On Fri, 6 May 2022 15:44:22 GMT, Gavin Bierman <gbierman at openjdk.org> wrote:

> > From the JLS specdiff
> > > If the type R names a generic record class then it is a compile-time error if R is not a parameterized type.
> > 
> > 
> > The following snippet raises a `MatchException`. Shouldn't it be a compile-time error?
> > ```
> >         Box<String> r = new Box<>(null);
> > 
> >         switch (r) {
> >             case Box(String s):
> >                 System.out.println("match");
> >         }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > If this is Ok and my understanding is wrong, then why that raises an exception at all? I can make it work (as an unconditional) if I define the Box as `record Box<T extends String>` and now I am confused...
> > ping @GavinBierman @lahodaj
> 
> A couple of issues here. (1) This should be a compile-time error. (2) upon investigation I think there is a bug with the pattern matching code, because the compiler is currently saying that the pattern match here: `Box<String> bs = new Box<>(null); if (bs instanceof Box<String>(String s)) { System.out.println("match!"); }` does not succeed. (It should do). The `MatchException` you are seeing is that the exhaustive pattern switch has no matching label (if you put in a default, you don't get the exception).

Right. Will fix. Sorry for that.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Fri May  6 17:43:07 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 17:43:07 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <DPtIa69a2NgNDwSmzHyrn-kQAocDY_j8WoMLhlvrA3w=.846c9409-3838-4605-9ad7-1dfcb435ceba@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
 <DPtIa69a2NgNDwSmzHyrn-kQAocDY_j8WoMLhlvrA3w=.846c9409-3838-4605-9ad7-1dfcb435ceba@github.com>
Message-ID: <ChVux1eet_iKg6KCHWbow6et4Y_XnduA6-JNRWy-zP8=.7d3011a0-d8cb-4f14-a53a-70be44a8db84@github.com>

On Thu, 5 May 2022 18:11:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4217:
> 
>> 4215:         }
>> 4216:         ListBuffer<BindingSymbol> outBindings = new ListBuffer<>();
>> 4217:         List<Type> recordTypes = expectedRecordTypes;
> 
> nit: probably a matter of style but why not reusing the already declared `expectedRecordTypes` declaring a new variable seems unnecessary

Please note the full `expectedRecordTypes` are used for error reporting, but the reference to `List` in `recordTypes` is overwritten in the loop (at the time of an error report, it may not longer point to the full expected types, and hence cannot be used for error reporting).

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Fri May  6 17:43:11 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 17:43:11 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <BRVCNwq7xvWl2AwuqeynSn5BfSc3G7LTaXoee3r3neQ=.90f9863d-7651-405a-b2b4-10cfd75429dd@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
 <BRVCNwq7xvWl2AwuqeynSn5BfSc3G7LTaXoee3r3neQ=.90f9863d-7651-405a-b2b4-10cfd75429dd@github.com>
Message-ID: <eWTffstYzsD322uofKlfl0ixwBOqgxqonqhfmtu5lkY=.e790a2e6-5902-406a-8b79-c1e1f27aad74@github.com>

On Fri, 6 May 2022 14:30:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 752:
> 
>> 750:                                            Iterable<? extends JCCaseLabel> labels) {
>> 751:             Set<Symbol> coveredSymbols = new HashSet<>();
>> 752:             Map<Symbol, List<JCRecordPattern>> deconstructionPatternsBySymbol = new HashMap<>();
> 
> since you seem to have settled on "recordPattern" for implementation names - you can probably revisit some of these names to say "record" instead of "deconstruction".

Right. Will do.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 801:
> 
>> 799:             //i.e. represent all possible combinations.
>> 800:             //This is done by categorizing the patterns based on the type covered by the given
>> 801:             //starting component.
> 
> Example needed here. For instance (I discussed this with @biboudis):
> 
> 
> record Outer(R r) { };
> sealed interface I { };
> class A implements I { };
> class B implements I { };
> sealed interface R { };
> record Foo(I i) implements R { }
> record Bar(I i) implements R { }
> 
> switch (o) {
>    case Outer(Foo(A), Foo(A)):
>    case Outer(Foo(B), Foo(B)):
>    case Outer(Foo(A), Foo(B)):
>    case Outer(Foo(B), Foo(A)):
>    case Outer(Bar(A), Bar(A)):
>    case Outer(Bar(B), Bar(B)):
>    case Outer(Bar(A), Bar(B)):
>    case Outer(Bar(B), Bar(A)):
> }
> 
> 
> Which generates two sets:
> 
> 
>    case Outer(Foo(A), Foo(A)):
>    case Outer(Foo(B), Foo(B)):
>    case Outer(Foo(A), Foo(B)):
>    case Outer(Foo(B), Foo(A)):
> 
> 
> And
> 
> 
>    case Outer(Bar(A), Bar(A)):
>    case Outer(Bar(B), Bar(B)):
>    case Outer(Bar(A), Bar(B)):
>    case Outer(Bar(B), Bar(A)):
> 
> 
> Sorry for being pedantic - this code is tricky and I'm worried we'll all forget exactly how it works in 2 months :-)

Sure. Will try to improve.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Sat May  7 12:03:04 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Sat, 7 May 2022 12:03:04 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v3]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <UCWsOm3h-S_3hyCCHOU5s3fJojIjOXnb150BEv_yl4w=.a3fe45ff-0510-4b5b-bd32-f5bc29fd477a@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Fixing guards after record patterns.
 - Raw types are not allowed in record patterns.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8516/files
  - new: https://git.openjdk.java.net/jdk/pull/8516/files/90b37c3a..0e384fb3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=01-02

  Stats: 191 lines in 11 files changed: 157 ins; 22 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From duke at openjdk.java.net  Mon May  9 06:38:29 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Mon, 9 May 2022 06:38:29 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language [v2]
In-Reply-To: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
Message-ID: <7w6P30l41_L74tNKPhy1CTprXvXbn7Zy16XS0SWVckI=.49454ba3-9348-4f7c-9d53-8905d156dad1@github.com>

> When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
> As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
> Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.
> 
> Would you please review this fix?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8238373: Punctuation should be same in jlink help usage on Japanese language

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8417/files
  - new: https://git.openjdk.java.net/jdk/pull/8417/files/5163b9df..c881ec75

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8417&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8417&range=00-01

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8417.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8417/head:pull/8417

PR: https://git.openjdk.java.net/jdk/pull/8417

From duke at openjdk.java.net  Mon May  9 06:40:24 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Mon, 9 May 2022 06:40:24 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language [v2]
In-Reply-To: <rV9tqb5vwiaJb5Ac52dQmc3QsjJivKXypIXWbofNIls=.15a473d5-09ea-4184-aab5-15d6ce243ac1@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
 <rV9tqb5vwiaJb5Ac52dQmc3QsjJivKXypIXWbofNIls=.15a473d5-09ea-4184-aab5-15d6ce243ac1@github.com>
Message-ID: <hHTl87bMwzSt960NyTiHjPdRxUlH0dbpeAChOW1MDfQ=.bc772bfa-2c36-4458-90f6-be8377f23343@github.com>

On Wed, 27 Apr 2022 16:42:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks fine to me. Nit: please modify the copyright years for `javap` properties files, as you modified the base (`javap.properties`) file.

I?m sorry for the late reply.  
Thank you for your advice. I modified the copyright years for all files.

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

PR: https://git.openjdk.java.net/jdk/pull/8417

From mcimadamore at openjdk.java.net  Mon May  9 08:20:58 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 May 2022 08:20:58 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v3]
In-Reply-To: <UCWsOm3h-S_3hyCCHOU5s3fJojIjOXnb150BEv_yl4w=.a3fe45ff-0510-4b5b-bd32-f5bc29fd477a@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <UCWsOm3h-S_3hyCCHOU5s3fJojIjOXnb150BEv_yl4w=.a3fe45ff-0510-4b5b-bd32-f5bc29fd477a@github.com>
Message-ID: <owiWOG27psDepURelkZYBMi8MCxQVyxCMf3YoLU45_w=.e61a75f2-01f4-46b6-9a4d-8ea35fdf8884@github.com>

On Sat, 7 May 2022 12:03:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixing guards after record patterns.
>  - Raw types are not allowed in record patterns.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4208:

> 4206:         if (site.tsym.kind == Kind.TYP && ((ClassSymbol) site.tsym).isRecord()) {
> 4207:             ClassSymbol record = (ClassSymbol) site.tsym;
> 4208:             if (record.type.getTypeArguments().nonEmpty()) {

There is a `Type::isRaw()` - I supposed you tried that one? Doesn't it do what you want?

test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out line 3:

> 1: DeconstructionPatternErrors.java:15:28: compiler.err.underscore.as.identifier
> 2: DeconstructionPatternErrors.java:15:29: compiler.err.expected: token.identifier
> 3: DeconstructionPatternErrors.java:43:37: compiler.err.illegal.start.of.type

should error be more specific here? E.g. diamond not supported with type test pattern?

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Mon May  9 14:18:22 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 9 May 2022 14:18:22 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v10]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <bbC04hW5rMLCNdhlWIB3fQ0NwyhAS4p-ykSkhzlS4_Q=.df141bf2-4cf9-486a-b652-0fcc46f00fe7@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

 - Merge branch 'master' into type-patterns-third
 - Merge branch 'master' into type-patterns-third
 - Reducing MatchException constructors.
 - Merge branch 'master' into type-patterns-third
 - Reference-type pattern is not applicable at a selector of a primitive type - fixing.
 - Merge branch 'master' into type-patterns-third
 - Cleanup, fixing tests.
 - Cleanup - more total -> unconditional pattern renaming.
 - Adjusting to review feedback.
 - Cleanup.
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/4f5d73f2...1101ad46

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

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=09
  Stats: 860 lines in 52 files changed: 424 ins; 244 del; 192 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Mon May  9 14:37:35 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 9 May 2022 14:37:35 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

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

 - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
 - Using Type.isRaw instead of checking the AST structure.
 - Exhaustiveness should accept supertypes of the specified type.
 - Renaming the features from deconstruction pattern to record pattern.
 - Fixing guards after record patterns.
 - Raw types are not allowed in record patterns.
 - Reflecting review feedback.
 - 8262889: Compiler implementation for Record Patterns

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

Changes: https://git.openjdk.java.net/jdk/pull/8516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=03
  Stats: 2255 lines in 50 files changed: 2169 ins; 15 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From vromero at openjdk.java.net  Mon May  9 15:12:03 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 9 May 2022 15:12:03 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <ChVux1eet_iKg6KCHWbow6et4Y_XnduA6-JNRWy-zP8=.7d3011a0-d8cb-4f14-a53a-70be44a8db84@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
 <DPtIa69a2NgNDwSmzHyrn-kQAocDY_j8WoMLhlvrA3w=.846c9409-3838-4605-9ad7-1dfcb435ceba@github.com>
 <ChVux1eet_iKg6KCHWbow6et4Y_XnduA6-JNRWy-zP8=.7d3011a0-d8cb-4f14-a53a-70be44a8db84@github.com>
Message-ID: <bsjqYstjDXx2T5_ihOONXMDx5_3TCqDI4v4HkjjSzck=.47e9b3c4-90fc-43e0-99c5-e585d70446ef@github.com>

On Fri, 6 May 2022 17:40:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4217:
>> 
>>> 4215:         }
>>> 4216:         ListBuffer<BindingSymbol> outBindings = new ListBuffer<>();
>>> 4217:         List<Type> recordTypes = expectedRecordTypes;
>> 
>> nit: probably a matter of style but why not reusing the already declared `expectedRecordTypes` declaring a new variable seems unnecessary
>
> Please note the full `expectedRecordTypes` are used for error reporting, but the reference to `List` in `recordTypes` is overwritten in the loop (at the time of an error report, it may not longer point to the full expected types, and hence cannot be used for error reporting).

Ok I see, thanks

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From vromero at openjdk.java.net  Mon May  9 15:27:53 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 9 May 2022 15:27:53 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
Message-ID: <v5YWR1Sy_z5DmkTixE0MFifEt0Hu_7K7-poD5yKSfhM=.c7b70472-f586-4dd2-b390-dbe30ec20f3f@github.com>

On Mon, 9 May 2022 14:37:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
>  - Using Type.isRaw instead of checking the AST structure.
>  - Exhaustiveness should accept supertypes of the specified type.
>  - Renaming the features from deconstruction pattern to record pattern.
>  - Fixing guards after record patterns.
>  - Raw types are not allowed in record patterns.
>  - Reflecting review feedback.
>  - 8262889: Compiler implementation for Record Patterns

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 822:

> 820:                                                                     nestedComponentPatterns);
> 821: 
> 822:             //for each of the symbols covered by the starting component, find all deconstruction patterns

this comment should probably read: find all `record` patterns?

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From asotona at openjdk.java.net  Mon May  9 16:05:46 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 9 May 2022 16:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound
 assignments
Message-ID: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>

Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.

The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.

The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 

Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.

Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.

Thanks for your review,
Adam

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244681
  Stats: 449 lines in 26 files changed: 444 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From naoto at openjdk.java.net  Mon May  9 16:18:59 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 9 May 2022 16:18:59 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language [v2]
In-Reply-To: <7w6P30l41_L74tNKPhy1CTprXvXbn7Zy16XS0SWVckI=.49454ba3-9348-4f7c-9d53-8905d156dad1@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
 <7w6P30l41_L74tNKPhy1CTprXvXbn7Zy16XS0SWVckI=.49454ba3-9348-4f7c-9d53-8905d156dad1@github.com>
Message-ID: <LPhuW5Yvz4M4i3vfYYVE6KtT5TO2Is76U-mWSPGrvQo=.5061be04-bbb7-4b8b-b27c-5d518cec012e@github.com>

On Mon, 9 May 2022 06:38:29 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

>> When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
>> As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
>> Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.
>> 
>> Would you please review this fix?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8238373: Punctuation should be same in jlink help usage on Japanese language

I think it's ready for you to integrate. I can sponsor your changes.

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

PR: https://git.openjdk.java.net/jdk/pull/8417

From erikj at openjdk.java.net  Mon May  9 16:33:56 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 9 May 2022 16:33:56 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <QMW2y8ihFHz3GPVQLMACiUV5aGbvwcreUKbGfVwaWGg=.2b5fe22c-6331-4ac2-a05d-44a1b65e85c0@github.com>

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

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

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8599

From prr at openjdk.java.net  Mon May  9 17:55:55 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 May 2022 17:55:55 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cih52bus7vW_1tDS7D7szxNTdayfjQxSeHRJhL99DSc=.f5a417b9-844a-4a34-b0b4-8591ac4e28cb@github.com>

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

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

Marked as reviewed by prr (Reviewer).

test/langtools/tools/javac/lint/LossyConversions.java line 131:

> 129:     @SuppressWarnings("lossy-conversions")
> 130:     public void supressedLossyConversions() {
> 131:         byte a = 0;

you might want to spell suppressed correctly.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From darcy at openjdk.java.net  Mon May  9 20:26:56 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 9 May 2022 20:26:56 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <8O_QfMi1b_fhddBS7yzm9cwzf-l6nWbfNs6qFJWdtuU=.22f44b80-54e8-4249-8ece-d02be29f4267@github.com>

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

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

I see there is already a bug filed to address situations found by the new warning in the JDK's libraries (JDK-8286374). As a matter of policy, I recommend the (potential) warnings be addressed in at least the java.base and java.desktop modules before the new warning is enabled. In other words, a priority should be given to keeping java.base and java.desktop compiling successfully with all warnings enabled.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From vromero at openjdk.java.net  Mon May  9 20:55:55 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 9 May 2022 20:55:55 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
Message-ID: <p5A-Gz5Und0__YFKtbfHdrf7ryMiUXhLcOTfErMlc3M=.78efa499-486c-40a6-b139-706476c9eab3@github.com>

On Mon, 9 May 2022 14:37:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
>  - Using Type.isRaw instead of checking the AST structure.
>  - Exhaustiveness should accept supertypes of the specified type.
>  - Renaming the features from deconstruction pattern to record pattern.
>  - Fixing guards after record patterns.
>  - Raw types are not allowed in record patterns.
>  - Reflecting review feedback.
>  - 8262889: Compiler implementation for Record Patterns

I've noticed that this code:

class Test {
    String e(E e) {
        return switch (e) {
            case A -> "42";
        };
    }

    enum E {
        A, B;
    }
}

fails with:

Test.java:3: error: the switch expression does not cover all possible input values
        return switch (e) {
               ^
1 error

before this change but gets accepted with no error message after it

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From clanger at openjdk.java.net  Mon May  9 22:18:11 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 9 May 2022 22:18:11 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to
 find root cause
Message-ID: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>

After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
contains jar files with . or .. in its name. The error message, however, does not help to find
the culprit. This could be improved.

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

Commit messages:
 - JDK-8286444

Changes: https://git.openjdk.java.net/jdk/pull/8616/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8616&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286444
  Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8616/head:pull/8616

PR: https://git.openjdk.java.net/jdk/pull/8616

From clanger at openjdk.java.net  Mon May  9 22:36:51 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 9 May 2022 22:36:51 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
Message-ID: <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>

On Mon, 9 May 2022 22:10:54 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
> contains jar files with . or .. in its name. The error message, however, does not help to find
> the culprit. This could be improved.

@LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From asotona at openjdk.java.net  Tue May 10 08:46:45 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 10 May 2022 08:46:45 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <oWxFgbGHRAk_wFpGtPGtfrAlzLUVXctQCCRZ9pi43Mg=.ee995996-668b-4509-98c0-76337a2f9818@github.com>

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

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

I agree with the priority to keep java.base and java.desktop clean from possibly lossy conversions, so the related issues should probably raise from P4 priority level.

However this lint warning as a part of the javac is critical to confirm that the situations have been correctly addressed.
If we want to avoid "blind" patching, we only two possible scenarios:
1. big homogenous patch including hundreds of fixed lines of code across many "moving-target" classes, together with lint warning implemented and enabled 
2. javac lint patch (disabled for affected JDK modules build) goes first, so each case can be resolved, reviewed and validated in individual patch 

>From complexity and cost perspective I prefer the second scenario.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Tue May 10 09:07:44 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 10 May 2022 09:07:44 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v2]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>

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

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

  8244681: Add a warning for possibly lossy conversion in compound assignments
  recommended correction of the warning wording
  fixed typo in test method name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/47779ba5..6b3942b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From jlahoda at openjdk.java.net  Tue May 10 09:57:48 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 10 May 2022 09:57:48 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v5]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

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

  Fixing (non-)exhaustiveness for enum.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8516/files
  - new: https://git.openjdk.java.net/jdk/pull/8516/files/10cd9d0c..a0d0c78b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Tue May 10 09:57:48 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 10 May 2022 09:57:48 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <p5A-Gz5Und0__YFKtbfHdrf7ryMiUXhLcOTfErMlc3M=.78efa499-486c-40a6-b139-706476c9eab3@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
 <p5A-Gz5Und0__YFKtbfHdrf7ryMiUXhLcOTfErMlc3M=.78efa499-486c-40a6-b139-706476c9eab3@github.com>
Message-ID: <fWHS3ZY89choXUb8cVVyTiwFTLayaz8DaXObUWXQ5WA=.cf10a3a9-ef5e-44fb-9673-2a4df7a09746@github.com>

On Mon, 9 May 2022 20:52:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I've noticed that this code:
> 
> ```
> class Test {
>     String e(E e) {
>         return switch (e) {
>             case A -> "42";
>         };
>     }
> 
>     enum E {
>         A, B;
>     }
> }
> ```
> 
> fails with:
> 
> ```
> Test.java:3: error: the switch expression does not cover all possible input values
>         return switch (e) {
>                ^
> 1 error
> ```
> 
> before this change but gets accepted with no errors after the change in this PR

Oops, sorry, should be fixed now ([a0d0c78](https://github.com/openjdk/jdk/pull/8516/commits/a0d0c78bcbb5ecb010c2e9bd235b3ae89eb00823)).

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From shade at openjdk.java.net  Tue May 10 12:20:17 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 12:20:17 GMT
Subject: RFR: 8286475: Drop --enable-preview from instanceof pattern matching
 related tests
Message-ID: <_hYXFiUL2gLVQv9suKKs9eU0EFZibW7VavZSNDB8p2g=.a3129aa1-0afe-4ed3-9864-a424fedee259@github.com>

There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the instanceof pattern matching tests, since instanceof pattern matching have been graduated from preview in JDK 16. 

Additional testing:
 - [x] Linux x86_64 fastdebug, affected tests still pass
 - [x] Linux x86_32 fastdebug, affected tests start to pass

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

Commit messages:
 - Some

Changes: https://git.openjdk.java.net/jdk/pull/8628/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8628&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286475
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8628.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8628/head:pull/8628

PR: https://git.openjdk.java.net/jdk/pull/8628

From duke at openjdk.java.net  Tue May 10 12:29:47 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Tue, 10 May 2022 12:29:47 GMT
Subject: Integrated: 8238373: Punctuation should be same in jlink help usage on
 Japanese language
In-Reply-To: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
Message-ID: <2Y2UyuMLcj63oY8Vk4zTHmin7KWA1enWyKBU-vB0H7U=.68f55b63-ffb4-46c5-88e4-6f5a23b65d71@github.com>

On Wed, 27 Apr 2022 08:59:20 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
> As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
> Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.
> 
> Would you please review this fix?

This pull request has now been integrated.

Changeset: c4bd4499
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c4bd4499f1476dd300d967c556750cf8a5f1c5c7
Stats:     24 lines in 6 files changed: 0 ins; 0 del; 24 mod

8238373: Punctuation should be same in jlink help usage on Japanese language

Reviewed-by: naoto

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

PR: https://git.openjdk.java.net/jdk/pull/8417

From mdoerr at openjdk.java.net  Tue May 10 13:55:55 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 10 May 2022 13:55:55 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
Message-ID: <ffsUxlpoYXt7ABsFh4zbUlzjqZAHWTnrctHVwKgZw_Y=.461b26a5-5237-498e-a99f-128869a10290@github.com>

On Mon, 9 May 2022 22:10:54 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
> contains jar files with . or .. in its name. The error message, however, does not help to find
> the culprit. This could be improved.

LGTM. I think this is an important improvement. Developers should not be left alone figuring out which .jar file is responsible for the problem. There is currently no hint at all without this change.
(Note: Pre-submit test issues on 32 bit are unrelated.)

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8616

From alanb at openjdk.java.net  Tue May 10 14:05:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 14:05:49 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
Message-ID: <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>

On Mon, 9 May 2022 22:32:57 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?

It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for that in the String representation).

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From shade at openjdk.java.net  Tue May 10 14:57:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 14:57:47 GMT
Subject: RFR: 8286475: Drop --enable-preview from instanceof pattern
 matching related tests [v2]
In-Reply-To: <_hYXFiUL2gLVQv9suKKs9eU0EFZibW7VavZSNDB8p2g=.a3129aa1-0afe-4ed3-9864-a424fedee259@github.com>
References: <_hYXFiUL2gLVQv9suKKs9eU0EFZibW7VavZSNDB8p2g=.a3129aa1-0afe-4ed3-9864-a424fedee259@github.com>
Message-ID: <OEJ0LzOtoOkX02QYOqpEBaqk3LSXU6Q6CT7D0_fRtqg=.4c5ab947-7036-434b-9254-e4c941ac10f6@github.com>

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the instanceof pattern matching tests, since instanceof pattern matching have been graduated from preview in JDK 16. 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x] Linux x86_32 fastdebug, affected tests start to pass

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Copyright years

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8628/files
  - new: https://git.openjdk.java.net/jdk/pull/8628/files/c2da78bf..8dcdff4d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8628&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8628&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8628

From lancea at openjdk.java.net  Tue May 10 16:32:43 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 May 2022 16:32:43 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
Message-ID: <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>

On Tue, 10 May 2022 14:02:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> 
> It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).

I think this would be OK, but would get to get someone from our security team to bless it.  

It might not be a bad idea to add a method to return the name as a String.  There are a couple of places where we do a new String(name) so would economize any future changes

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From clanger at openjdk.java.net  Tue May 10 16:51:37 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 10 May 2022 16:51:37 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
Message-ID: <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>

On Tue, 10 May 2022 16:30:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > 
> > 
> > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> 
> I think this would be OK, but would get to get someone from our security team to bless it.
> 
> It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes

Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From brian.goetz at oracle.com  Tue May 10 16:54:48 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 10 May 2022 12:54:48 -0400
Subject: Instance qualifier for static access warning and anonymous classes
In-Reply-To: <5cbdede3-c091-9a33-1ca6-14adf994db98@oracle.com>
References: <CAE+3fjYKD3e_r6rd4zcwzzZo82VWp-1Eq43GVwYBPbGUorejQA@mail.gmail.com>
 <5cbdede3-c091-9a33-1ca6-14adf994db98@oracle.com>
Message-ID: <685ccfe8-5e40-7d61-c8b8-5e2dc17b0000@oracle.com>

In various "new" situations, we've taken the choice to close this route 
down, such as with static methods in interfaces.? Arguably, had we 
realized it, we might have done something similar with static members in 
anonymous classes (which were also new at the time), but we 
unfortunately missed this case.

I suspect that the number of cases where people actually rely on this 
feature (access a static member of an anonymous class through an 
instance) is still pretty small, so we could still consider closing it 
down after-the-fact.? May or may not be worth the fuss, as there will 
surely be some fuss.

On 4/29/2022 11:25 AM, Maurizio Cimadamore wrote:
> Well spotted - this seems like a dark corner.
>
> IMHO there are two possible interpretation, which depend on where we 
> want to go with the warning:
>
> 1. static methods accessed through instance qualifiers are Bad, and we 
> should try to wean developer off them over time (and align this with 
> interface static methods). In this case the warning should stay (but 
> of course the message needs to be fixed :-) ).
> 2. static methods accessed through instance qualifiers are a wart, but 
> something we should be prepared to live with forever - best thing we 
> can do in this space is to issue some "style" warnings, but nothing 
> more will ever happen. In this case, for this example we should turn 
> off the warning altogether.
>
> Maurizio
>
> On 29/04/2022 15:54, Tagir Valeev wrote:
>> Hello!
>>
>> Consider the following code:
>>
>> public class Demo {
>> ???? public static void main(String[] args) {
>> ???????? var obj = new Object() {
>> ???????????? static void foo() {
>> ???????????????? System.out.println("Static method of anonymous class");
>> ???????????? }
>> ???????? };
>> ???????? obj.foo(); // Cannot replace instance qualifier with class 
>> reference
>> ???? }
>> }
>>
>> With -Xlint:static, javac reports the following warning:
>>
>> Demo.java:8: warning: [static] static method should be qualified by
>> type name, <anonymous Demo$1>, instead of by an expression
>> ???????? obj.foo(); // Cannot replace instance qualifier with class 
>> reference
>> ??????????? ^
>> 1 warning
>>
>> It's questionable whether this warning should be reported at all, as
>> it's impossible to call the static method of anonymous class with
>> class name qualifier. But in any case, suggesting to use `<anonymous
>> Demo$1>` as a qualifier is invalid.
>>
>> With best regards,
>> Tagir Valeev.


From alanb at openjdk.java.net  Tue May 10 16:54:54 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 16:54:54 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
Message-ID: <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>

On Tue, 10 May 2022 16:48:30 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> I think this would be OK, but would get to get someone from our security team to bless it.

It's print the entry name, I don't think it is leaking the file path to the zip file.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From lancea at openjdk.java.net  Tue May 10 17:02:47 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 May 2022 17:02:47 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
Message-ID: <yYSzj3nN7pHVcBewPXh-Sm6Y6x0C4MZ0GRVXJfya9s0=.54612983-b10f-449b-b57f-adec30bf5126@github.com>

On Tue, 10 May 2022 16:30:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
>> 
>> It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
>
>> > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
>> 
>> It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> 
> I think this would be OK, but would get to get someone from our security team to bless it.  
> 
> It might not be a bad idea to add a method to return the name as a String.  There are a couple of places where we do a new String(name) so would economize any future changes

> > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > > 
> > > 
> > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> > 
> > 
> > I think this would be OK, but would get to get someone from our security team to bless it.
> > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes
> 
> Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.

Already did ;-)   so hopefully they will share their thoughts soon.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From lancea at openjdk.java.net  Tue May 10 17:02:47 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 May 2022 17:02:47 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
Message-ID: <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>

On Tue, 10 May 2022 16:51:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I think this would be OK, but would get to get someone from our security team to bless it.
> 
> It's print the entry name, I don't think it is leaking the file path to the zip file.

I think you are probably right I am probably being overly cautious

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From lancea at openjdk.java.net  Tue May 10 17:02:48 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 May 2022 17:02:48 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
Message-ID: <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>

On Tue, 10 May 2022 16:58:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> I think this would be OK, but would get to get someone from our security team to bless it.
>> 
>> It's print the entry name, I don't think it is leaking the file path to the zip file.
>
>> > I think this would be OK, but would get to get someone from our security team to bless it.
>> 
>> It's print the entry name, I don't think it is leaking the file path to the zip file.
> 
> I think you are probably right I am probably being overly cautious

> > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > > > 
> > > > 
> > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> > > 
> > > 
> > > I think this would be OK, but would get to get someone from our security team to bless it.
> > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes
> > 
> > 
> > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.
> 
> Already did ;-) so hopefully they will share their thoughts soon.

I think it would probably be good for a separate PR for the ZipFS change as it keeps it a bit clearer

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From mullan at openjdk.java.net  Tue May 10 21:30:02 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 10 May 2022 21:30:02 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
Message-ID: <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>

On Tue, 10 May 2022 16:59:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > > > 
> > > > 
> > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> > > 
> > > 
> > > I think this would be OK, but would get to get someone from our security team to bless it.
> > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes
> > 
> > 
> > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.
> 
> Already did ;-) so hopefully they will share their thoughts soon.

It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From mullan at openjdk.java.net  Tue May 10 21:33:50 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 10 May 2022 21:33:50 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
 <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>
Message-ID: <LK0Wm2DH5Bk474DqMvsnMPzB0IWGfEEukSXZTHzZEiY=.a1733ce2-0540-41fe-b3fc-db54f9a4a38b@github.com>

On Tue, 10 May 2022 21:26:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?

The bug report also says "The error message does not give a clue which jar file is causing the problem" but the error message includes the name "invalid.jar" so I am also confused about that.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From vromero at openjdk.java.net  Tue May 10 22:49:53 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 10 May 2022 22:49:53 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v5]
In-Reply-To: <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>
Message-ID: <Fz6ZOwDacA_o-vFe2JLgKK206dac6I-mqPjmZgavzVs=.f8fede3b-e27d-41ba-bc74-0fff66479ac4@github.com>

On Tue, 10 May 2022 09:57:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing (non-)exhaustiveness for enum.

looks good to me, great job!

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8516

From alanb at openjdk.java.net  Wed May 11 05:42:36 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 05:42:36 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <LK0Wm2DH5Bk474DqMvsnMPzB0IWGfEEukSXZTHzZEiY=.a1733ce2-0540-41fe-b3fc-db54f9a4a38b@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
 <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>
 <LK0Wm2DH5Bk474DqMvsnMPzB0IWGfEEukSXZTHzZEiY=.a1733ce2-0540-41fe-b3fc-db54f9a4a38b@github.com>
Message-ID: <EjOkZaKwGMRD7tnv8j2dz1V0neykKG6-ag38tfobH-Q=.7d114b54-be20-46c4-b3c7-f1dc6e774b8e@github.com>

On Tue, 10 May 2022 21:30:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?
> 
> The bug report also says "The error message does not give a clue which jar file is causing the problem" but the error message includes the name "invalid.jar" so I am also confused about that.

There are two parts to it. In the case of initCEN method, the proposed change is to include the name of the rejected entry in the exception message. This is not the same thing as leaking a file path in the exception message so I don't think we have a concern here.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From jrose at openjdk.java.net  Wed May 11 06:28:37 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 11 May 2022 06:28:37 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v2]
In-Reply-To: <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>
Message-ID: <sISfnxp1FBO9eR2lfA8D57iqvW-Xq2VFduvRezba1ok=.74a7448d-7f76-4be8-9180-d8b479d56c03@github.com>

On Tue, 10 May 2022 09:07:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

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

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 210:

> 208: 
> 209: javac.opt.Xlint.desc.lossy-conversions=\
> 210:     Warn about compiler possible lossy conversions.

I like this warning.  But the documentation doesn't even parse as English.

I suggest this, as more grammatical and precise:

> Warn about possible lossy conversions in compound assignments

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 07:45:39 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 07:45:39 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>

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

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

  8244681: Add a warning for possibly lossy conversion in compound assignments
  recommended correction of the warning description

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/6b3942b8..f0729396

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From gli at openjdk.java.net  Wed May 11 08:57:20 2022
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 11 May 2022 08:57:20 GMT
Subject: RFR: 8286573: Remove the unnecessary method Attr#attribTopLevel and
 its usage
Message-ID: <0vznP7hZbDoiZPOX6-UzSNFxchVj6IAb0zbIMKj-Uac=.242dab00-35a2-41c5-a052-86418f14e8f5@github.com>

Hi all,

The original patch [1] added the method `Attr#attribTopLevel` to validate the annotations of the package. Then the annotation validation was moved to the annotation pipeline [2] and the TopLevel tree node was refactored (added JCPackageDecl) [3]. So now the `Attr#attribTopLevel` is replaced by method `attribPackage` and actually is not used by any code. It is good to remove it.

And there are only 3 places (shown below) that add the `Env` instance to the `Todo` list which the `Attr` uses as input. They add the `Env` of module, package, class seperately to the todo list . So the `Attr` doesn't need to handle the situation about TopLevel JCCompilationUnit.

1. Enter::visitTopLevel  `todo.append(packageEnv)`
2. Enter::visitModuleDef `todo.append(moduleEnv)`
3. ImportsPhase::runPhase `todo.append(env)`

Thanks for taking the time to review.

Best Regards,
-- Guoxiong

[1]https://github.com/openjdk/jdk/commit/13d31713dc6ac7134d81abeb11a659df2104d71f
[2]https://github.com/openjdk/jdk/commit/da21af58f4811285f7050691d51fe32600c0e5f8
[3]https://github.com/openjdk/jdk/commit/9783b65028eba41796c3e05ebb545b1a722f56b0

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

Commit messages:
 - JDK-8286573

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

PR: https://git.openjdk.java.net/jdk/pull/8648

From ihse at openjdk.java.net  Wed May 11 13:05:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 13:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
Message-ID: <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>

On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

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

Check updates on JDK-8286374 subtasks.

make/modules/jdk.jfr/Java.gmk line 26:

> 24: #
> 25: 
> 26: DISABLED_WARNINGS_java += exports lossy-conversions

Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 

In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.

(In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)

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

Changes requested by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Wed May 11 13:05:46 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 13:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
Message-ID: <PWtwdccbXVxNM6h8D5nH5AzTqjGk9y5se7lGEE-ToHU=.135fd8e6-f702-41c0-9397-e165c29adb77@github.com>

On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

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

Lossy conversion issues for jdk.jfr and jdk.management.jfr. have been fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Wed May 11 13:08:49 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 13:08:49 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
Message-ID: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>

On Wed, 11 May 2022 12:59:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8244681: Add a warning for possibly lossy conversion in compound assignments
>>   recommended correction of the warning description
>
> make/modules/jdk.jfr/Java.gmk line 26:
> 
>> 24: #
>> 25: 
>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
> 
> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 
> 
> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.
> 
> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)

I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From ihse at openjdk.java.net  Wed May 11 13:13:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 13:13:43 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
Message-ID: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>

On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> make/modules/jdk.jfr/Java.gmk line 26:
>> 
>>> 24: #
>>> 25: 
>>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
>> 
>> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 
>> 
>> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.
>> 
>> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)
>
> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.

That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 13:26:23 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:26:23 GMT
Subject: RFR: 8286391: Address possibly lossy conversions in jdk.compiler
Message-ID: <jDtcjqvMcNT5ncPyOpSatpD8wfTBXiq8d0_6y6LFnLc=.e72f3f90-4771-43ee-9da6-c36ef80a1221@github.com>

This is a part of addressing of all possibly lossy conversions in compound assignments across JDK sources.
Two cases have been found in jdk.compiler and they are addressed by this patch.
One case in ClassWriter is resolved by changing local variable from char to int type to avoid multiple implicit and explicit conversions.
Second case in Code is resolved by making the implicit conversion from int to char explicit.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8286391: Address possibly lossy conversions in jdk.compiler

Changes: https://git.openjdk.java.net/jdk/pull/8652/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8652&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286391
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8652.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8652/head:pull/8652

PR: https://git.openjdk.java.net/jdk/pull/8652

From asotona at openjdk.java.net  Wed May 11 13:30:43 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:30:43 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
Message-ID: <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>

On Wed, 11 May 2022 13:10:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.
>
> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.

Thanks for quick reaction.
I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From rriggs at openjdk.java.net  Wed May 11 13:34:49 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 13:34:49 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
 <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
Message-ID: <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>

On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.
>
> Thanks for quick reaction.
> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.

I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From mullan at openjdk.java.net  Wed May 11 14:15:46 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 11 May 2022 14:15:46 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <EjOkZaKwGMRD7tnv8j2dz1V0neykKG6-ag38tfobH-Q=.7d114b54-be20-46c4-b3c7-f1dc6e774b8e@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
 <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>
 <LK0Wm2DH5Bk474DqMvsnMPzB0IWGfEEukSXZTHzZEiY=.a1733ce2-0540-41fe-b3fc-db54f9a4a38b@github.com>
 <EjOkZaKwGMRD7tnv8j2dz1V0neykKG6-ag3
 8tfobH-Q=.7d114b54-be20-46c4-b3c7-f1dc6e774b8e@github.com>
Message-ID: <GnCTFaQ7Mg3vWKRSJ8yq6zieWQMTaAzzWJBv3vW-DLU=.07972a0a-d90d-4a3d-8f73-4e8fc0fe1bc3@github.com>

On Wed, 11 May 2022 05:39:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?
> > 
> > 
> > The bug report also says "The error message does not give a clue which jar file is causing the problem" but the error message includes the name "invalid.jar" so I am also confused about that.
> 
> There are two parts to it. In the case of initCEN method, the proposed change is to include the name of the rejected entry in the exception message. This is not the same thing as leaking a file path in the exception message so I don't think we have a concern here.

Ok, but @RealCLanger can you address the prior comments I had on the bug report? The error messages (before and after the fix) are the same.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From asotona at openjdk.java.net  Wed May 11 13:41:30 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:41:30 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v4]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <3RgMbsaSwgdBXE2qlIwjVI680aN7Ovi6OOfu9eeNtJo=.a76eff60-8652-40ce-ae40-20f9095b1b93@github.com>

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

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

 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/f0729396..a59dfa4f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02-03

  Stats: 9179 lines in 255 files changed: 5253 ins; 2422 del; 1504 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 13:41:30 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:41:30 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
 <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
 <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
Message-ID: <6EkEbNxPc3RKNGprHlBhqM574oY7iPI9z3PpR91IMok=.9019963f-8085-49a8-951f-f8a2b2137fb0@github.com>

On Wed, 11 May 2022 13:31:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thanks for quick reaction.
>> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.
>
> I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time.

Feel free to go ahead with the java.base PR as this one still needs CSR.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 14:45:12 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 14:45:12 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v5]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cJu_ULWgPS-KxeOlGeUXs0iYI7U7DjdxrITrg0vzoTQ=.057010a4-d66f-4df7-b982-7e0bee3519c4@github.com>

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

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

  enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/a59dfa4f..32282515

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From clanger at openjdk.java.net  Wed May 11 15:45:40 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 11 May 2022 15:45:40 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause [v2]
In-Reply-To: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
Message-ID: <FHqGUtqPwHcYNpbXNX_gXVNVElJFqr_ZPXCvx3g8EH4=.0731a30e-d15e-41fb-ab4e-18b183edda19@github.com>

> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
> contains jar files with . or .. in its name. The error message, however, does not help to find
> the culprit. This could be improved.

Christoph Langer 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-8286444
 - Separate zips change from this PR
 - JDK-8286444
   
   Improve error message in javac compilation when jar files with . or .. are in classpath

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8616/files
  - new: https://git.openjdk.java.net/jdk/pull/8616/files/059d7fe1..3a196995

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8616&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8616&range=00-01

  Stats: 7333 lines in 220 files changed: 4289 ins; 1723 del; 1321 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8616/head:pull/8616

PR: https://git.openjdk.java.net/jdk/pull/8616

From clanger at openjdk.java.net  Wed May 11 15:45:40 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 11 May 2022 15:45:40 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
Message-ID: <lEkH1Nv9wkHTbp_b71TC9ZxBF9HjwxeHIIVtefgIVY4=.e088e24b-e0da-4267-9fc7-74ee29399b08@github.com>

On Tue, 10 May 2022 16:59:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> > I think this would be OK, but would get to get someone from our security team to bless it.
>>> 
>>> It's print the entry name, I don't think it is leaking the file path to the zip file.
>> 
>> I think you are probably right I am probably being overly cautious
>
>> > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
>> > > > 
>> > > > 
>> > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
>> > > 
>> > > 
>> > > I think this would be OK, but would get to get someone from our security team to bless it.
>> > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes
>> > 
>> > 
>> > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.
>> 
>> Already did ;-) so hopefully they will share their thoughts soon.
> 
> I think it would probably be good for a separate PR for the ZipFS change as it keeps it a bit clearer

> > > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > > > > 
> > > > > 
> > > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> > > > 
> > > > 
> > > > I think this would be OK, but would get to get someone from our security team to bless it.
> > > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes
> > > 
> > > 
> > > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.
> > 
> > 
> > Already did ;-) so hopefully they will share their thoughts soon.
> 
> It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?

Good catch, I pasted two times the error message after the proposed patch. Fixed.

> > > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > > > > 
> > > > > 
> > > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> > > > 
> > > > 
> > > > I think this would be OK, but would get to get someone from our security team to bless it.
> > > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes
> > > 
> > > 
> > > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.
> > 
> > 
> > Already did ;-) so hopefully they will share their thoughts soon.
> 
> I think it would probably be good for a separate PR for the ZipFS change as it keeps it a bit clearer

I've factored out the zipfs change into #8655. So this change only affects javac now.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From vromero at openjdk.java.net  Wed May 11 20:50:49 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 11 May 2022 20:50:49 GMT
Subject: RFR: 8286573: Remove the unnecessary method Attr#attribTopLevel
 and its usage
In-Reply-To: <0vznP7hZbDoiZPOX6-UzSNFxchVj6IAb0zbIMKj-Uac=.242dab00-35a2-41c5-a052-86418f14e8f5@github.com>
References: <0vznP7hZbDoiZPOX6-UzSNFxchVj6IAb0zbIMKj-Uac=.242dab00-35a2-41c5-a052-86418f14e8f5@github.com>
Message-ID: <lNyRhSpZm__6F7CRDb_nnfhMLvrOQSWlSmBy7VmvTw4=.bfce1218-649c-45d1-8a71-0a0b5b2cdf78@github.com>

On Wed, 11 May 2022 08:49:46 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The original patch [1] added the method `Attr#attribTopLevel` to validate the annotations of the package. Then the annotation validation was moved to the annotation pipeline [2] and the TopLevel tree node was refactored (added JCPackageDecl) [3]. So now the `Attr#attribTopLevel` is replaced by method `attribPackage` and actually is not used by any code. It is good to remove it.
> 
> And there are only 3 places (shown below) that add the `Env` instance to the `Todo` list which the `Attr` uses as input. They add the `Env` of module, package, class seperately to the todo list . So the `Attr` doesn't need to handle the situation about TopLevel JCCompilationUnit.
> 
> 1. Enter::visitTopLevel  `todo.append(packageEnv)`
> 2. Enter::visitModuleDef `todo.append(moduleEnv)`
> 3. ImportsPhase::runPhase `todo.append(env)`
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong
> 
> [1]https://github.com/openjdk/jdk/commit/13d31713dc6ac7134d81abeb11a659df2104d71f
> [2]https://github.com/openjdk/jdk/commit/da21af58f4811285f7050691d51fe32600c0e5f8
> [3]https://github.com/openjdk/jdk/commit/9783b65028eba41796c3e05ebb545b1a722f56b0

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8648

From darcy at openjdk.java.net  Thu May 12 01:48:20 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 01:48:20 GMT
Subject: RFR: JDK-8286617: Improve parameter names in javax.lang.model utility
 visitors
Message-ID: <AWC_32ql0DGxeOMh8ltwycjQqHYGizRkcDJ8UShu_bM=.68e0a1b4-e83c-476e-a80f-cd814ea60b7c@github.com>

Fix inconsistencies in parameter naming; will update copyrights years if needed before a push.

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

Commit messages:
 - JDK-8286617: Improve parameter names in javax.lang.model utility visitors

Changes: https://git.openjdk.java.net/jdk/pull/8671/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8671&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286617
  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8671.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8671/head:pull/8671

PR: https://git.openjdk.java.net/jdk/pull/8671

From iris at openjdk.java.net  Thu May 12 01:59:44 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 12 May 2022 01:59:44 GMT
Subject: RFR: JDK-8286617: Improve parameter names in javax.lang.model
 utility visitors
In-Reply-To: <AWC_32ql0DGxeOMh8ltwycjQqHYGizRkcDJ8UShu_bM=.68e0a1b4-e83c-476e-a80f-cd814ea60b7c@github.com>
References: <AWC_32ql0DGxeOMh8ltwycjQqHYGizRkcDJ8UShu_bM=.68e0a1b4-e83c-476e-a80f-cd814ea60b7c@github.com>
Message-ID: <JXHdZdKdfH5LXVRucpwmPzjMkyOOjKiweK676yZlZsM=.fac9b0c6-fc68-46e1-a8b5-c41b533bcbf1@github.com>

On Thu, 12 May 2022 01:41:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix inconsistencies in parameter naming; will update copyrights years if needed before a push.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8671

From abimpoudis at openjdk.java.net  Thu May 12 10:46:23 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 12 May 2022 10:46:23 GMT
Subject: RFR: 8286057: Make javac error on a generic enum friendlier
Message-ID: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>

Improves the error message for generic enumerations.

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

Commit messages:
 - 8286057: Make javac error on a generic enum friendlier

Changes: https://git.openjdk.java.net/jdk/pull/8677/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8677&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286057
  Stats: 71 lines in 5 files changed: 71 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8677.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8677/head:pull/8677

PR: https://git.openjdk.java.net/jdk/pull/8677

From jlahoda at openjdk.java.net  Thu May 12 10:54:16 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 12 May 2022 10:54:16 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v11]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Updating naming to more closely follow the spec: total patterns are renamed to unconditional patterns, unrefined is now unguarded.
 - Case label elements cannot be unguarded if they have a guard of a type different than boolean.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/1101ad46..b0fb8dcd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=09-10

  Stats: 247 lines in 12 files changed: 126 ins; 73 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From gli at openjdk.java.net  Thu May 12 13:09:49 2022
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 12 May 2022 13:09:49 GMT
Subject: RFR: 8286573: Remove the unnecessary method Attr#attribTopLevel
 and its usage
In-Reply-To: <lNyRhSpZm__6F7CRDb_nnfhMLvrOQSWlSmBy7VmvTw4=.bfce1218-649c-45d1-8a71-0a0b5b2cdf78@github.com>
References: <0vznP7hZbDoiZPOX6-UzSNFxchVj6IAb0zbIMKj-Uac=.242dab00-35a2-41c5-a052-86418f14e8f5@github.com>
 <lNyRhSpZm__6F7CRDb_nnfhMLvrOQSWlSmBy7VmvTw4=.bfce1218-649c-45d1-8a71-0a0b5b2cdf78@github.com>
Message-ID: <egRrkdElNogqMpzetuZyOVzC1xJIRiy0I_sYTdqCAzs=.8ff0f7af-dfff-4010-b957-a3b575a971a2@github.com>

On Wed, 11 May 2022 20:47:43 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hi all,
>> 
>> The original patch [1] added the method `Attr#attribTopLevel` to validate the annotations of the package. Then the annotation validation was moved to the annotation pipeline [2] and the TopLevel tree node was refactored (added JCPackageDecl) [3]. So now the `Attr#attribTopLevel` is replaced by method `attribPackage` and actually is not used by any code. It is good to remove it.
>> 
>> And there are only 3 places (shown below) that add the `Env` instance to the `Todo` list which the `Attr` uses as input. They add the `Env` of module, package, class seperately to the todo list . So the `Attr` doesn't need to handle the situation about TopLevel JCCompilationUnit.
>> 
>> 1. Enter::visitTopLevel  `todo.append(packageEnv)`
>> 2. Enter::visitModuleDef `todo.append(moduleEnv)`
>> 3. ImportsPhase::runPhase `todo.append(env)`
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>> 
>> [1]https://github.com/openjdk/jdk/commit/13d31713dc6ac7134d81abeb11a659df2104d71f
>> [2]https://github.com/openjdk/jdk/commit/da21af58f4811285f7050691d51fe32600c0e5f8
>> [3]https://github.com/openjdk/jdk/commit/9783b65028eba41796c3e05ebb545b1a722f56b0
>
> lgtm

@vicente-romero-oracle Thanks for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/8648

From gli at openjdk.java.net  Thu May 12 13:09:49 2022
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 12 May 2022 13:09:49 GMT
Subject: Integrated: 8286573: Remove the unnecessary method Attr#attribTopLevel
 and its usage
In-Reply-To: <0vznP7hZbDoiZPOX6-UzSNFxchVj6IAb0zbIMKj-Uac=.242dab00-35a2-41c5-a052-86418f14e8f5@github.com>
References: <0vznP7hZbDoiZPOX6-UzSNFxchVj6IAb0zbIMKj-Uac=.242dab00-35a2-41c5-a052-86418f14e8f5@github.com>
Message-ID: <LfqiNI7aGH10duT-4i_4bA9cMBWvKLiok4cOSE8a300=.a85defbc-2eb4-4fd0-a65c-bf32aaca9816@github.com>

On Wed, 11 May 2022 08:49:46 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The original patch [1] added the method `Attr#attribTopLevel` to validate the annotations of the package. Then the annotation validation was moved to the annotation pipeline [2] and the TopLevel tree node was refactored (added JCPackageDecl) [3]. So now the `Attr#attribTopLevel` is replaced by method `attribPackage` and actually is not used by any code. It is good to remove it.
> 
> And there are only 3 places (shown below) that add the `Env` instance to the `Todo` list which the `Attr` uses as input. They add the `Env` of module, package, class seperately to the todo list . So the `Attr` doesn't need to handle the situation about TopLevel JCCompilationUnit.
> 
> 1. Enter::visitTopLevel  `todo.append(packageEnv)`
> 2. Enter::visitModuleDef `todo.append(moduleEnv)`
> 3. ImportsPhase::runPhase `todo.append(env)`
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong
> 
> [1]https://github.com/openjdk/jdk/commit/13d31713dc6ac7134d81abeb11a659df2104d71f
> [2]https://github.com/openjdk/jdk/commit/da21af58f4811285f7050691d51fe32600c0e5f8
> [3]https://github.com/openjdk/jdk/commit/9783b65028eba41796c3e05ebb545b1a722f56b0

This pull request has now been integrated.

Changeset: 36bdd251
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/36bdd25159ff78425e5f0a1145a814d9edca97ae
Stats:     16 lines in 1 file changed: 0 ins; 16 del; 0 mod

8286573: Remove the unnecessary method Attr#attribTopLevel and its usage

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8648

From jlahoda at openjdk.java.net  Thu May 12 13:44:01 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 12 May 2022 13:44:01 GMT
Subject: Integrated: 8284283: javac crashes when several transitive supertypes
 are missing
In-Reply-To: <HfpXfqSDX1fqsrCVgYrjyBvVLhyNk_k2dWcLjpHC0g4=.2cfca39d-d7c3-4366-938a-858f36a0b06f@github.com>
References: <HfpXfqSDX1fqsrCVgYrjyBvVLhyNk_k2dWcLjpHC0g4=.2cfca39d-d7c3-4366-938a-858f36a0b06f@github.com>
Message-ID: <pjoIHaTySLo58ZPGKppMCcM7Uqdpr6FDTLMFT2HpD_w=.64af8516-01d0-4720-8dbc-d6222d29cbcb@github.com>

On Mon, 4 Apr 2022 20:24:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this testcase:
> 
> ---Lib.java
> package lib;
> public class Lib implements A, B {}
> interface A {}
> interface B {}
> ---Test.java
> public class Test<E> extends lib.Lib {}
> ---
> 
> $ javac -d out Lib.java
> $ rm out/lib/A.class out/lib/B.class
> $ javac -classpath out -XDdev Test.java
> Test.java:1: error: cannot access A
> public class Test<E> extends lib.Lib {}
>        ^
>   class file for lib.A not found
> 1 error
> 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 invoke "com.sun.tools.javac.code.Type.hasTag(com.sun.tools.javac.code.TypeTag)" because the return value of "com.sun.tools.javac.code.Type$TypeVar.getUpperBound()" is null
>         at jdk.compiler/com.sun.tools.javac.code.Types.getBounds(Types.java:2732)
> ....
> 
> 
> The reason for the cache is insufficient error recovery - when the missing class `A` and `B` are encountered, the processing in `TypeEnter` (`TypeEnter.HierarchyPhase` for `A` and `TypeEnter.HeaderPhase` for `B`) is interrupted, and the rest of the processing is skipped to the end of the phase, leaving unprocessed tree, which ultimately leads to the exception.
> 
> The proposed patch is to enhance the error recovery, catch the `CompletionFailure` for the missing classes sooner, and let the rest of the `TypeEnter` processing finish normally.

This pull request has now been integrated.

Changeset: e4439ca3
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e4439ca32abd779d7525f3a545e3635a8b02bc1c
Stats:     109 lines in 4 files changed: 103 ins; 3 del; 3 mod

8284283: javac crashes when several transitive supertypes are missing

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8095

From jjg at openjdk.java.net  Thu May 12 14:29:52 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 12 May 2022 14:29:52 GMT
Subject: RFR: JDK-8286617: Improve parameter names in javax.lang.model
 utility visitors
In-Reply-To: <AWC_32ql0DGxeOMh8ltwycjQqHYGizRkcDJ8UShu_bM=.68e0a1b4-e83c-476e-a80f-cd814ea60b7c@github.com>
References: <AWC_32ql0DGxeOMh8ltwycjQqHYGizRkcDJ8UShu_bM=.68e0a1b4-e83c-476e-a80f-cd814ea60b7c@github.com>
Message-ID: <TpiopsK4xxvTjWHJfNALy2uNtYSIP7UAKoEH-kLQtes=.64a3b209-dc50-4373-8aec-9ed7aca5d294@github.com>

On Thu, 12 May 2022 01:41:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix inconsistencies in parameter naming; will update copyrights years if needed before a push.

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8671

From mullan at openjdk.java.net  Thu May 12 15:10:59 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 12 May 2022 15:10:59 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <lEkH1Nv9wkHTbp_b71TC9ZxBF9HjwxeHIIVtefgIVY4=.e088e24b-e0da-4267-9fc7-74ee29399b08@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
 <lEkH1Nv9wkHTbp_b71TC9ZxBF9HjwxeHIIVtefgIVY4=.e088e24b-e0da-4267-9fc7-74ee29399b08@github.com>
Message-ID: <yhtlvEbcPdGciHnor6JSlAXBp3KPvti4PsLX-0QlHts=.aa1211bf-f8e8-4e65-a896-6d8057911ee6@github.com>

On Wed, 11 May 2022 15:41:00 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> > It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?
> 
> Good catch, I pasted two times the error message after the proposed patch. Fixed.

Thanks. This change and the other change in 8286594 to the exception message seems fine to me from a security perspective. However, I won't be adding my name as Reviewer as I have not reviewed the actual code.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From mdoerr at openjdk.java.net  Thu May 12 16:10:39 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 12 May 2022 16:10:39 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause [v2]
In-Reply-To: <FHqGUtqPwHcYNpbXNX_gXVNVElJFqr_ZPXCvx3g8EH4=.0731a30e-d15e-41fb-ab4e-18b183edda19@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <FHqGUtqPwHcYNpbXNX_gXVNVElJFqr_ZPXCvx3g8EH4=.0731a30e-d15e-41fb-ab4e-18b183edda19@github.com>
Message-ID: <CKtEcQx0zjFuR6PHsmJWsiR5Qx8bIlk2dqv0rk8fu_s=.b477cb12-7c4a-4a5f-8c5b-423ebc055136@github.com>

On Wed, 11 May 2022 15:45:40 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
>> contains jar files with . or .. in its name. The error message, however, does not help to find
>> the culprit. This could be improved.
>
> Christoph Langer 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-8286444
>  - Separate zips change from this PR
>  - JDK-8286444
>    
>    Improve error message in javac compilation when jar files with . or .. are in classpath

Still good. This is the essential part. I'm fine with moving the rest into the separate enhancement.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8616

From darcy at openjdk.java.net  Thu May 12 16:39:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 16:39:40 GMT
Subject: RFR: JDK-8286617: Improve parameter names in javax.lang.model
 utility visitors [v2]
In-Reply-To: <AWC_32ql0DGxeOMh8ltwycjQqHYGizRkcDJ8UShu_bM=.68e0a1b4-e83c-476e-a80f-cd814ea60b7c@github.com>
References: <AWC_32ql0DGxeOMh8ltwycjQqHYGizRkcDJ8UShu_bM=.68e0a1b4-e83c-476e-a80f-cd814ea60b7c@github.com>
Message-ID: <5TcEB3OhO1JsWq4RM8HRoEP2pQD3Fl2Hz-mcl5gDIKo=.a86f641b-d6eb-4caa-a95e-658f912ffad9@github.com>

> Fix inconsistencies in parameter naming; will update copyrights years if needed before a push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8671/files
  - new: https://git.openjdk.java.net/jdk/pull/8671/files/60d7655a..a41afee1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8671&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8671&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8671.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8671/head:pull/8671

PR: https://git.openjdk.java.net/jdk/pull/8671

From darcy at openjdk.java.net  Thu May 12 16:39:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 16:39:40 GMT
Subject: Integrated: JDK-8286617: Improve parameter names in javax.lang.model
 utility visitors
In-Reply-To: <AWC_32ql0DGxeOMh8ltwycjQqHYGizRkcDJ8UShu_bM=.68e0a1b4-e83c-476e-a80f-cd814ea60b7c@github.com>
References: <AWC_32ql0DGxeOMh8ltwycjQqHYGizRkcDJ8UShu_bM=.68e0a1b4-e83c-476e-a80f-cd814ea60b7c@github.com>
Message-ID: <1ucY13j6WEdaQ2wSGqlTcGKuwwzfC_FrSyrEzoQVKsA=.8792d10a-ed76-47f4-a930-a84ab1d4f1f6@github.com>

On Thu, 12 May 2022 01:41:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix inconsistencies in parameter naming; will update copyrights years if needed before a push.

This pull request has now been integrated.

Changeset: 0a6832b2
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a6832b24c76bb445ba8d1606d743252c1ff49c3
Stats:     8 lines in 3 files changed: 0 ins; 0 del; 8 mod

8286617: Improve parameter names in javax.lang.model utility visitors

Reviewed-by: iris, jjg

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

PR: https://git.openjdk.java.net/jdk/pull/8671

From abimpoudis at openjdk.java.net  Thu May 12 18:06:23 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 12 May 2022 18:06:23 GMT
Subject: RFR: 8286057: Make javac error on a generic enum friendlier [v2]
In-Reply-To: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
References: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
Message-ID: <viZFLAxtJQcOfI8h6whdDps-l78rFiYNJnAgNPErseM=.e2f48dbe-07b6-407b-9a3d-eae3376d68a3@github.com>

> Improves the error message for generic enumerations.

Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8286057: Make javac error on a generic enum friendlier

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8677/files
  - new: https://git.openjdk.java.net/jdk/pull/8677/files/7b920a50..0d7db485

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8677&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8677&range=00-01

  Stats: 37 lines in 3 files changed: 0 ins; 36 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8677.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8677/head:pull/8677

PR: https://git.openjdk.java.net/jdk/pull/8677

From asotona at openjdk.java.net  Fri May 13 08:32:29 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Fri, 13 May 2022 08:32:29 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v6]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <LWPvsMChniyfkaHPvxdnn1tvOwQkW9MSCwiDoJ_Fm78=.5ca8e192-b796-43d4-a621-0ac58232eae9@github.com>

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

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

 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

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

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=05
  Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From jlahoda at openjdk.java.net  Fri May 13 08:58:45 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 13 May 2022 08:58:45 GMT
Subject: RFR: 8178701: Compile error with switch statement on protected
 enum defined in parent inner class [v2]
In-Reply-To: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
References: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
Message-ID: <_R4OpHJO3gtzRSU5wHKgo7Hbnlxyb6qODioRNbj-5Dg=.c1d169a6-b768-4b6d-9e6d-ad2ca6d7e09c@github.com>

> Consider the following code in two packages:
> 
> package foo;
> 
> import bar.D.E;
> 
> public class A {
> 
>     public static class B {
> 
>         protected enum C {
>             X, Y, Z
>         }
>     }
> 
>     public static void main(String... args) {
>         new E().run(B.C.X);
>     }
> }
> 
> 
> 
> package bar;
> 
> import foo.A.B;
> 
> public class D {
> 
>     public static class E extends B {
> 
>         public void run(C arg) {
>             switch (arg) {
>                 default:
>                     System.out.println("OK");
>             }
>         }
>     }
> }
> 
> 
> Accessing `foo.A.B.C` in `bar.D.E` is OK, as it is accessible through the `E`'s superclass. But, for the `switch`, javac creates a map (array) from runtime ordinals of constants of `E` to compile-time positions. But, this mapping is in a different class that does not extend `B`, so internal method lookups fail for it, as the methods are not accessible per Java rules.
> 
> But, at runtime, the enum class is effectively public, so I think it is possible to ignore the protected access rules and accept the method invocations while generatting the mapping code, which is what this patch is trying to do.

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

 - Merge branch 'master' into JDK-8178701
 - 8178701: Compile error with switch statement on protected enum defined in parent inner class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7621/files
  - new: https://git.openjdk.java.net/jdk/pull/7621/files/3e4a7401..00066f1b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7621&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7621&range=00-01

  Stats: 506894 lines in 7080 files changed: 380732 ins; 62098 del; 64064 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7621.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7621/head:pull/7621

PR: https://git.openjdk.java.net/jdk/pull/7621

From mcimadamore at openjdk.java.net  Fri May 13 09:54:42 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 09:54:42 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v11]
In-Reply-To: <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>
Message-ID: <7I2_FqR7mCEnQ6rmAuVx8CZ7pDkv3h4WsjE3PRNLy2c=.ae1fc350-06a5-470f-a1f8-1d7ec2682d9d@github.com>

On Thu, 12 May 2022 10:54:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updating naming to more closely follow the spec: total patterns are renamed to unconditional patterns, unrefined is now unguarded.
>  - Case label elements cannot be unguarded if they have a guard of a type different than boolean.

Looks good - left some minor comments and questions.

src/java.base/share/classes/java/lang/MatchException.java line 58:

> 56:      * @param  message the detail message (which is saved for later retrieval
> 57:      *         by the {@link #getMessage()} method).
> 58:      * @param  cause the cause (which is saved for later retrieval by the

This looks odd - it seems like the sentence is like this:

`the cause ( foo ). (bar)`. E.g. the test in parenthesis exceeds the test outside parenthesis by a wide margin. I suggest both here and in the "message" @param to avoid the parenthesis and split the sentence instead. Examples:


* @param  message the detail message. The message is saved for later retrieval
*  by the {@link #getMessage()} method).


and


* @param cause the cause. The cause is saved for later retrieval by the
*  {@link #getCause()} method). A {@code null} value is
* permitted, and indicates that the cause is nonexistent or
* unknown.


Of course this is just an idea.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 177:

> 175:         allowPatternSwitch = (preview.isEnabled() || !preview.isPreview(Feature.PATTERN_SWITCH)) &&
> 176:                              Feature.PATTERN_SWITCH.allowedInSource(source);
> 177:         allowUnconditionalPatternsInstance = (preview.isEnabled() || !preview.isPreview(Feature.UNCONDITIONAL_PATTERN_IN_INSTANCEOF)) &&

Nit: perhaps adding "Of" to this already long variable name doesn't add much in terms of chars, but makes the meaning of the variable name clearer?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1802:

> 1800:                                 unguarded &&
> 1801:                                 !patternType.isErroneous() &&
> 1802:                                 types.isSubtype(types.boxedTypeOrType(types.erasure(seltype)),

This seems to be a change compared to the previous code - e.g. handling of boxing in the switch target type. Is this code even exercised? The test "NotApplicableTypes" seems to rule the combination `switch (int) ... case Integer` out.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1325:

> 1323:     }
> 1324: 
> 1325:     public record PatternPrimaryType(Type type) {}

This is no longer needed - seems just a wrapper around a type.

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From prappo at openjdk.java.net  Fri May 13 10:19:49 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 13 May 2022 10:19:49 GMT
Subject: RFR: 8286057: Make javac error on a generic enum friendlier [v2]
In-Reply-To: <viZFLAxtJQcOfI8h6whdDps-l78rFiYNJnAgNPErseM=.e2f48dbe-07b6-407b-9a3d-eae3376d68a3@github.com>
References: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
 <viZFLAxtJQcOfI8h6whdDps-l78rFiYNJnAgNPErseM=.e2f48dbe-07b6-407b-9a3d-eae3376d68a3@github.com>
Message-ID: <29N0zNq6I7V4qnVW0ttoMjixZOZzC0y4VgLe2IytpEY=.3519116c-5e50-40bb-b55d-25d4ebd5a156@github.com>

On Thu, 12 May 2022 18:06:23 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Improves the error message for generic enumerations.
>
> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8286057: Make javac error on a generic enum friendlier

Thanks for doing this! I only note that the caret `^` is a bit off as opposed to the case of a generic annotation.

Compare:

$ cat X.java 
public enum X<T> {}
$ javac X.java 
X.java:1: error: enums cannot be generic
public enum X<T> {}
                ^


$ cat Y.java 
@interface Y<T> {}
$ ./build/macosx-x64/images/jdk/bin/javac Y.java 
Y.java:1: error: annotation interface Y cannot be generic
@interface Y<T> {}
             ^
1 error

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

PR: https://git.openjdk.java.net/jdk/pull/8677

From jlahoda at openjdk.java.net  Fri May 13 11:15:56 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 13 May 2022 11:15:56 GMT
Subject: RFR: 8286057: Make javac error on a generic enum friendlier [v2]
In-Reply-To: <viZFLAxtJQcOfI8h6whdDps-l78rFiYNJnAgNPErseM=.e2f48dbe-07b6-407b-9a3d-eae3376d68a3@github.com>
References: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
 <viZFLAxtJQcOfI8h6whdDps-l78rFiYNJnAgNPErseM=.e2f48dbe-07b6-407b-9a3d-eae3376d68a3@github.com>
Message-ID: <oQ24UYrTwMhvxJofTWFIxz7JQ259Kqzc8yRJDjVYV8M=.4f78c320-ce7b-4f8f-9168-1a14436aa12e@github.com>

On Thu, 12 May 2022 18:06:23 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Improves the error message for generic enumerations.
>
> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8286057: Make javac error on a generic enum friendlier

Overall, I think this is good, thanks!

Besides Pavel's comment on the location, I added some nits.

Also - we usually have tests beside the diagnostic example. E.g. a golden file test, or something like this. This is typically for two reasons: a) such tests allow to cover all needed combination (which is not really relevant here); b) such tests allow to check/verify the specific location of the error.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4036:

> 4034:         Name name = typeName();
> 4035: 
> 4036:         if(typeParametersOpt().size() > 0) {

Nit: we usually have a space between `if` and `(`.
Nit: using `!.isEmpty()` might be better here (it would also be slightly faster for non-empty Lists, but since that would only happen in erroneous cases, it is not so critical).

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4037:

> 4035: 
> 4036:         if(typeParametersOpt().size() > 0) {
> 4037:             log.error(DiagnosticFlag.SYNTAX, S.prevToken().endPos, Errors.EnumCantBeGeneric);

I agree with Pavel the location of the error could be better - probably store the `typeParametersOpt` into a variable, and then use the content to provide a better location. Or, you could store some meaningful position based on tokens.

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

Changes requested by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8677

From jlahoda at openjdk.java.net  Fri May 13 11:39:09 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 13 May 2022 11:39:09 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v11]
In-Reply-To: <7I2_FqR7mCEnQ6rmAuVx8CZ7pDkv3h4WsjE3PRNLy2c=.ae1fc350-06a5-470f-a1f8-1d7ec2682d9d@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>
 <7I2_FqR7mCEnQ6rmAuVx8CZ7pDkv3h4WsjE3PRNLy2c=.ae1fc350-06a5-470f-a1f8-1d7ec2682d9d@github.com>
Message-ID: <tbb0gQGujOxdc7Z3FJ4tkXUWD5EztmqR4dQvJSSUwSQ=.2c7d87cf-7134-4f2a-b083-21ea04fd29d3@github.com>

On Fri, 13 May 2022 09:29:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updating naming to more closely follow the spec: total patterns are renamed to unconditional patterns, unrefined is now unguarded.
>>  - Case label elements cannot be unguarded if they have a guard of a type different than boolean.
>
> src/java.base/share/classes/java/lang/MatchException.java line 58:
> 
>> 56:      * @param  message the detail message (which is saved for later retrieval
>> 57:      *         by the {@link #getMessage()} method).
>> 58:      * @param  cause the cause (which is saved for later retrieval by the
> 
> This looks odd - it seems like the sentence is like this:
> 
> `the cause ( foo ). (bar)`. E.g. the test in parenthesis exceeds the test outside parenthesis by a wide margin. I suggest both here and in the "message" @param to avoid the parenthesis and split the sentence instead. Examples:
> 
> 
> * @param  message the detail message. The message is saved for later retrieval
> *  by the {@link #getMessage()} method).
> 
> 
> and
> 
> 
> * @param cause the cause. The cause is saved for later retrieval by the
> *  {@link #getCause()} method). A {@code null} value is
> * permitted, and indicates that the cause is nonexistent or
> * unknown.
> 
> 
> Of course this is just an idea.

I believe this text is taken form another exception in java.lang. If that would be OK, I'd look at this in a followup/separate issue.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1802:
> 
>> 1800:                                 unguarded &&
>> 1801:                                 !patternType.isErroneous() &&
>> 1802:                                 types.isSubtype(types.boxedTypeOrType(types.erasure(seltype)),
> 
> This seems to be a change compared to the previous code - e.g. handling of boxing in the switch target type. Is this code even exercised? The test "NotApplicableTypes" seems to rule the combination `switch (int) ... case Integer` out.

Yes, `switch ("int") { case Integer i -> }` is not allowed. The intent of `boxedTypeOrType` is to reduce follow-up errors, as `Integer i` will be considered to be unconditional over `int`.

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From abimpoudis at openjdk.java.net  Fri May 13 14:19:49 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 13 May 2022 14:19:49 GMT
Subject: RFR: 8286057: Make javac error on a generic enum friendlier [v3]
In-Reply-To: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
References: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
Message-ID: <gpxgv9GEhvgztk-FQnD0yaSrt_uzbp0Ra33s4VGeg3o=.21d00858-6ddc-4087-bf36-3ba32580941b@github.com>

> Improves the error message for generic enumerations.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add precise error for enums with empty parameter lists

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8677/files
  - new: https://git.openjdk.java.net/jdk/pull/8677/files/0d7db485..401b9754

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8677&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8677&range=01-02

  Stats: 35 lines in 3 files changed: 33 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8677.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8677/head:pull/8677

PR: https://git.openjdk.java.net/jdk/pull/8677

From abimpoudis at openjdk.java.net  Fri May 13 14:27:55 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 13 May 2022 14:27:55 GMT
Subject: RFR: 8286057: Make javac error on a generic enum friendlier [v4]
In-Reply-To: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
References: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
Message-ID: <w5q0E90E-XRE1AQt2NeLtJeDAOSHKUfYoKCtnuLyh3Q=.abe6b714-1cd7-4a8a-b94f-bae0ce2bb1ea@github.com>

> Improves the error message for generic enumerations.

Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Add precise error for enums with empty parameter lists

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8677/files
  - new: https://git.openjdk.java.net/jdk/pull/8677/files/401b9754..bcbafe97

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8677&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8677&range=02-03

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8677.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8677/head:pull/8677

PR: https://git.openjdk.java.net/jdk/pull/8677

From abimpoudis at openjdk.java.net  Fri May 13 14:31:58 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 13 May 2022 14:31:58 GMT
Subject: RFR: 8286057: Make javac error on a generic enum friendlier [v2]
In-Reply-To: <oQ24UYrTwMhvxJofTWFIxz7JQ259Kqzc8yRJDjVYV8M=.4f78c320-ce7b-4f8f-9168-1a14436aa12e@github.com>
References: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
 <viZFLAxtJQcOfI8h6whdDps-l78rFiYNJnAgNPErseM=.e2f48dbe-07b6-407b-9a3d-eae3376d68a3@github.com>
 <oQ24UYrTwMhvxJofTWFIxz7JQ259Kqzc8yRJDjVYV8M=.4f78c320-ce7b-4f8f-9168-1a14436aa12e@github.com>
Message-ID: <qy7NTuIhJav5VXfjXl3nXJg9XNSAfS3tPJ_qj0xxa8c=.1bbe2f23-ce07-414e-a3da-492fb5a9a564@github.com>

On Fri, 13 May 2022 11:10:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8286057: Make javac error on a generic enum friendlier
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4037:
> 
>> 4035: 
>> 4036:         if(typeParametersOpt().size() > 0) {
>> 4037:             log.error(DiagnosticFlag.SYNTAX, S.prevToken().endPos, Errors.EnumCantBeGeneric);
> 
> I agree with Pavel the location of the error could be better - probably store the `typeParametersOpt` into a variable, and then use the content to provide a better location. Or, you could store some meaningful position based on tokens.

I improved the error position. Now all the following report the same error:


  public enum E1<> {}
  public enum E2<T> {}
  public enum E3<T, T> {}


However, at a cost of a small refactoring in `typeParametersOpt` to allow (erroneous) empty lists of type parameters opt. The new version (the overload with the boolean) can be used if the caller wants to return a more precise error as in this case. The way to communicate this situation to the caller is through a `null` ret list. Despite I noticed that `null` is used in various cases, I am still a bit skeptical if this is the right way (for such small benefit).

WDYT @pavelrappo, @lahodaj

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

PR: https://git.openjdk.java.net/jdk/pull/8677

From mcimadamore at openjdk.java.net  Fri May 13 14:35:50 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 14:35:50 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v11]
In-Reply-To: <tbb0gQGujOxdc7Z3FJ4tkXUWD5EztmqR4dQvJSSUwSQ=.2c7d87cf-7134-4f2a-b083-21ea04fd29d3@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>
 <7I2_FqR7mCEnQ6rmAuVx8CZ7pDkv3h4WsjE3PRNLy2c=.ae1fc350-06a5-470f-a1f8-1d7ec2682d9d@github.com>
 <tbb0gQGujOxdc7Z3FJ4tkXUWD5EztmqR4dQvJSSUwSQ=.2c7d87cf-7134-4f2a-b083-21ea04fd29d3@github.com>
Message-ID: <6ocyE93x80LXAYdSTOTQkeTAAaqY2wr-xxC5wu8hesY=.b51814ef-a663-434f-8eb3-ac0e1b2f435d@github.com>

On Fri, 13 May 2022 11:34:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/MatchException.java line 58:
>> 
>>> 56:      * @param  message the detail message (which is saved for later retrieval
>>> 57:      *         by the {@link #getMessage()} method).
>>> 58:      * @param  cause the cause (which is saved for later retrieval by the
>> 
>> This looks odd - it seems like the sentence is like this:
>> 
>> `the cause ( foo ). (bar)`. E.g. the test in parenthesis exceeds the test outside parenthesis by a wide margin. I suggest both here and in the "message" @param to avoid the parenthesis and split the sentence instead. Examples:
>> 
>> 
>> * @param  message the detail message. The message is saved for later retrieval
>> *  by the {@link #getMessage()} method).
>> 
>> 
>> and
>> 
>> 
>> * @param cause the cause. The cause is saved for later retrieval by the
>> *  {@link #getCause()} method). A {@code null} value is
>> * permitted, and indicates that the cause is nonexistent or
>> * unknown.
>> 
>> 
>> Of course this is just an idea.
>
> I believe this text is taken form another exception in java.lang. If that would be OK, I'd look at this in a followup/separate issue.

ok!

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1802:
>> 
>>> 1800:                                 unguarded &&
>>> 1801:                                 !patternType.isErroneous() &&
>>> 1802:                                 types.isSubtype(types.boxedTypeOrType(types.erasure(seltype)),
>> 
>> This seems to be a change compared to the previous code - e.g. handling of boxing in the switch target type. Is this code even exercised? The test "NotApplicableTypes" seems to rule the combination `switch (int) ... case Integer` out.
>
> Yes, `switch ("int") { case Integer i -> }` is not allowed. The intent of `boxedTypeOrType` is to reduce follow-up errors, as `Integer i` will be considered to be unconditional over `int`.

Good - I suspected it had to do with error recovery - but wanted to make sure I didn't miss anything.

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Fri May 13 14:58:42 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 13 May 2022 14:58:42 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v12]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <xkl5A1n_rE_EWFwFf0XeEdoRbdP950QIUVMgaO5zrlY=.185cc82a-fca9-4a4d-be3e-84eb7b27023c@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

  Cleanup as suggested on the PR review.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/b0fb8dcd..e903084a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=10-11

  Stats: 14 lines in 4 files changed: 0 ins; 4 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From mcimadamore at openjdk.java.net  Fri May 13 15:23:51 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 15:23:51 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v12]
In-Reply-To: <xkl5A1n_rE_EWFwFf0XeEdoRbdP950QIUVMgaO5zrlY=.185cc82a-fca9-4a4d-be3e-84eb7b27023c@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <xkl5A1n_rE_EWFwFf0XeEdoRbdP950QIUVMgaO5zrlY=.185cc82a-fca9-4a4d-be3e-84eb7b27023c@github.com>
Message-ID: <gaqoFsXMZi25Uz1KTtgG_uhr3K9i8rHqTgSYj-cuW5Q=.f21d56c3-d9fd-4871-971b-313ae505c225@github.com>

On Fri, 13 May 2022 14:58:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup as suggested on the PR review.

Marked as reviewed by mcimadamore (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From clanger at openjdk.java.net  Sat May 14 10:59:53 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sat, 14 May 2022 10:59:53 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause [v2]
In-Reply-To: <FHqGUtqPwHcYNpbXNX_gXVNVElJFqr_ZPXCvx3g8EH4=.0731a30e-d15e-41fb-ab4e-18b183edda19@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <FHqGUtqPwHcYNpbXNX_gXVNVElJFqr_ZPXCvx3g8EH4=.0731a30e-d15e-41fb-ab4e-18b183edda19@github.com>
Message-ID: <GKGcAVTM9kqttqXxP7cIGVW3jR8_LkFvvY8PZdnB1mE=.1aae3eaa-f7fe-431f-8ea8-28e07d4a729f@github.com>

On Wed, 11 May 2022 15:45:40 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
>> contains jar files with . or .. in its name. The error message, however, does not help to find
>> the culprit. This could be improved.
>
> Christoph Langer 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-8286444
>  - Separate zips change from this PR
>  - JDK-8286444
>    
>    Improve error message in javac compilation when jar files with . or .. are in classpath

Thanks for the reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From clanger at openjdk.java.net  Sat May 14 10:59:54 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sat, 14 May 2022 10:59:54 GMT
Subject: Integrated: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
Message-ID: <h_GyRoQvof_7dpr5lgNIeA_iYM2pLAG55w0Dz7uGENY=.fe785e65-9a33-4f36-94c5-ac46834ac462@github.com>

On Mon, 9 May 2022 22:10:54 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
> contains jar files with . or .. in its name. The error message, however, does not help to find
> the culprit. This could be improved.

This pull request has now been integrated.

Changeset: 29c4b8e8
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/29c4b8e80d1860249a79cfd1941354150468fc5b
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8286444: javac errors after JDK-8251329 are not helpful enough to find root cause

Reviewed-by: mdoerr

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From jpai at openjdk.java.net  Sun May 15 02:40:39 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 15 May 2022 02:40:39 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause [v2]
In-Reply-To: <FHqGUtqPwHcYNpbXNX_gXVNVElJFqr_ZPXCvx3g8EH4=.0731a30e-d15e-41fb-ab4e-18b183edda19@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <FHqGUtqPwHcYNpbXNX_gXVNVElJFqr_ZPXCvx3g8EH4=.0731a30e-d15e-41fb-ab4e-18b183edda19@github.com>
Message-ID: <E0U_6TlyOf_uXvKR0S0Zh5RzmrzDxoKZy8vcOdpcV00=.e283941d-eb8b-4035-b692-e392c8d5015c@github.com>

On Wed, 11 May 2022 15:45:40 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
>> contains jar files with . or .. in its name. The error message, however, does not help to find
>> the culprit. This could be improved.
>
> Christoph Langer 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-8286444
>  - Separate zips change from this PR
>  - JDK-8286444
>    
>    Improve error message in javac compilation when jar files with . or .. are in classpath

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 567:

> 565:                     this.fileSystem = jarFSProvider.newFileSystem(archivePath, env);
> 566:                 } catch (ZipException ze) {
> 567:                     throw new IOException("ZipException opening \"" + archivePath + "\": " + ze.getMessage(), ze);

Hello Christoph, I'm sorry I'm a bit late to this discussion. One of the concerns raised in this PR is that we might end up leaking the file path of the jar being reported for error. The original example that you had in the JBS is something like this:


java -cp invalid.jar Hello.java

which after this change prints:


ZipException opening "invalid.jar": ZIP file can't be opened as a file system because an entry has a '.' or '..' element in its name

This is fine, IMO.

However, consider a slightly modified case. Let's consider a case where you have a different `foo.jar` in that current directory and that `foo.jar` has a `Class-Path` entry which looks like:


Manifest-Version: 1.0
Class-Path: invalid.jar
Created-By: 19-internal (N/A)

So `foo.jar` is pointing to `invalid.jar`. Now let's run the following command by passing `foo.jar` as `-cp` value (which then brings in `invalid.jar` through the `Class-Path` entry in the Manifest file):


java -cp foo.jar Hello.java

With this PR, this now returns:


ZipException opening "/private/tmp/8286444/invalid.jar": ZIP file can't be opened as a file system because an entry has a '.' or '..' element in its name

Notice that it has ended up leaking the file path of the jar that was pulled in through the `MANIFEST.MF` file. I think this is something that isn't allowed from a security point of view.

Perhaps an additional change needs to be done on top of this PR to prevent this, something like:


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
index 1336fb74916..7c40afb62af 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
@@ -564,7 +564,7 @@ public class JavacFileManager extends BaseFileManager implements StandardJavaFil
                 try {
                     this.fileSystem = jarFSProvider.newFileSystem(archivePath, env);
                 } catch (ZipException ze) {
-                    throw new IOException("ZipException opening "" + archivePath + "": " + ze.getMessage(), ze);
+                    throw new IOException("ZipException opening "" + archivePath.getFileName() + "": " + ze.getMessage(), ze);
                 }
             } else {
                 this.fileSystem = FileSystems.newFileSystem(archivePath, (ClassLoader)null);



This then just prints the name of the jar in both cases:


java -cp invalid.jar Hello.java

ZipException opening "invalid.jar": ZIP file can't be opened as a file system because an entry has a '.' or '..' element in its name


java -cp foo.jar Hello.java

ZipException opening "invalid.jar": ZIP file can't be opened as a file system because an entry has a '.' or '..' element in its name

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From jlahoda at openjdk.java.net  Mon May 16 05:36:41 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 May 2022 05:36:41 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v13]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <aR054lcdcbQUcI8Q_n4045NjZnV4JvwUmjFYXaqws9s=.8b1beed0-1cc7-4c3f-8163-4d64380f7b89@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

  Fixing test - restoring accidentally removed condition.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/e903084a..22991958

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=11-12

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Mon May 16 07:53:43 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 May 2022 07:53:43 GMT
Subject: Integrated: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview)
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <H-AnO-2I8KSjndTcCtnYpIFv6t3ber6MJ3OItizv-XA=.f681a57a-1260-44ba-93a3-3edf68f3762a@github.com>

On Mon, 11 Apr 2022 16:37:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

This pull request has now been integrated.

Changeset: 0155e4b7
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0155e4b76bb0889e516811647aede500a7812db1
Stats:     1093 lines in 56 files changed: 549 ins; 320 del; 224 mod

8282274: Compiler implementation for Pattern Matching for switch (Third Preview)

Co-authored-by: Brian Goetz <briangoetz at openjdk.org>
Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: mcimadamore, vromero, abimpoudis

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From duke at openjdk.java.net  Mon May 16 07:56:40 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Mon, 16 May 2022 07:56:40 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v5]
In-Reply-To: <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>
Message-ID: <34aWbLZTml1eYUnsbeGKnFhiSM5wfE3hE4myRHB9TGg=.ef7e3bbc-4440-472c-8e78-6a57873489d8@github.com>

On Tue, 10 May 2022 09:57:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing (non-)exhaustiveness for enum.

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout patterns-record-deconstruction3
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From shade at openjdk.java.net  Mon May 16 09:26:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 16 May 2022 09:26:47 GMT
Subject: RFR: 8286475: Drop --enable-preview from instanceof pattern
 matching related tests [v2]
In-Reply-To: <OEJ0LzOtoOkX02QYOqpEBaqk3LSXU6Q6CT7D0_fRtqg=.4c5ab947-7036-434b-9254-e4c941ac10f6@github.com>
References: <_hYXFiUL2gLVQv9suKKs9eU0EFZibW7VavZSNDB8p2g=.a3129aa1-0afe-4ed3-9864-a424fedee259@github.com>
 <OEJ0LzOtoOkX02QYOqpEBaqk3LSXU6Q6CT7D0_fRtqg=.4c5ab947-7036-434b-9254-e4c941ac10f6@github.com>
Message-ID: <G1exFRAY2b-LoOmp2bWtRs2D7b62eQZ6eDPUYpEcZwM=.b1d70486-4a5a-4083-bb18-079480508a59@github.com>

On Tue, 10 May 2022 14:57:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the instanceof pattern matching tests, since instanceof pattern matching have been graduated from preview in JDK 16. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x] Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

Any comments?

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

PR: https://git.openjdk.java.net/jdk/pull/8628

From jlahoda at openjdk.java.net  Mon May 16 09:57:49 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 May 2022 09:57:49 GMT
Subject: RFR: 8178701: Compile error with switch statement on protected
 enum defined in parent inner class [v3]
In-Reply-To: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
References: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
Message-ID: <nmJk8Y5Xi1TJ3C_SgJgcNQPjDV1YM5vE9QxxkqzsE7o=.d682e898-702f-4506-bca0-b378121792a9@github.com>

> Consider the following code in two packages:
> 
> package foo;
> 
> import bar.D.E;
> 
> public class A {
> 
>     public static class B {
> 
>         protected enum C {
>             X, Y, Z
>         }
>     }
> 
>     public static void main(String... args) {
>         new E().run(B.C.X);
>     }
> }
> 
> 
> 
> package bar;
> 
> import foo.A.B;
> 
> public class D {
> 
>     public static class E extends B {
> 
>         public void run(C arg) {
>             switch (arg) {
>                 default:
>                     System.out.println("OK");
>             }
>         }
>     }
> }
> 
> 
> Accessing `foo.A.B.C` in `bar.D.E` is OK, as it is accessible through the `E`'s superclass. But, for the `switch`, javac creates a map (array) from runtime ordinals of constants of `E` to compile-time positions. But, this mapping is in a different class that does not extend `B`, so internal method lookups fail for it, as the methods are not accessible per Java rules.
> 
> But, at runtime, the enum class is effectively public, so I think it is possible to ignore the protected access rules and accept the method invocations while generatting the mapping code, which is what this patch is trying to do.

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-8178701
 - Merge branch 'master' into JDK-8178701
 - 8178701: Compile error with switch statement on protected enum defined in parent inner class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7621/files
  - new: https://git.openjdk.java.net/jdk/pull/7621/files/00066f1b..9bd1883a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7621&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7621&range=01-02

  Stats: 69941 lines in 785 files changed: 45346 ins; 20733 del; 3862 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7621.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7621/head:pull/7621

PR: https://git.openjdk.java.net/jdk/pull/7621

From jlahoda at openjdk.java.net  Mon May 16 10:39:35 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 May 2022 10:39:35 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v6]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <2ghh_OV-ixn0tQEw6NvSOmWoi0LFDTmoGMSGyHwhFwY=.6db7ef79-e984-43ae-b4a1-e287d9cc2211@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

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

 - Post merge fix.
 - Merge branch 'master' into patterns-record-deconstruction3
 - Fixing (non-)exhaustiveness for enum.
 - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
 - Merge branch 'master' into type-patterns-third
 - Using Type.isRaw instead of checking the AST structure.
 - Exhaustiveness should accept supertypes of the specified type.
 - Renaming the features from deconstruction pattern to record pattern.
 - Fixing guards after record patterns.
 - Raw types are not allowed in record patterns.
 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0155e4b7...924daa0c

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

Changes: https://git.openjdk.java.net/jdk/pull/8516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=05
  Stats: 2255 lines in 50 files changed: 2169 ins; 15 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Mon May 16 11:56:55 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 May 2022 11:56:55 GMT
Subject: Integrated: 8178701: Compile error with switch statement on protected
 enum defined in parent inner class
In-Reply-To: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
References: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
Message-ID: <28bRdhxqQBdLqk8ucd_tLBgbj-jOfwzXwOnXRdipQus=.416429d0-83d7-444d-9f84-1e8101d2e39a@github.com>

On Fri, 25 Feb 2022 12:32:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following code in two packages:
> 
> package foo;
> 
> import bar.D.E;
> 
> public class A {
> 
>     public static class B {
> 
>         protected enum C {
>             X, Y, Z
>         }
>     }
> 
>     public static void main(String... args) {
>         new E().run(B.C.X);
>     }
> }
> 
> 
> 
> package bar;
> 
> import foo.A.B;
> 
> public class D {
> 
>     public static class E extends B {
> 
>         public void run(C arg) {
>             switch (arg) {
>                 default:
>                     System.out.println("OK");
>             }
>         }
>     }
> }
> 
> 
> Accessing `foo.A.B.C` in `bar.D.E` is OK, as it is accessible through the `E`'s superclass. But, for the `switch`, javac creates a map (array) from runtime ordinals of constants of `E` to compile-time positions. But, this mapping is in a different class that does not extend `B`, so internal method lookups fail for it, as the methods are not accessible per Java rules.
> 
> But, at runtime, the enum class is effectively public, so I think it is possible to ignore the protected access rules and accept the method invocations while generatting the mapping code, which is what this patch is trying to do.

This pull request has now been integrated.

Changeset: 77dfbb45
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77dfbb457083fd30da344d0cbea5b0510aa3a0fc
Stats:     182 lines in 4 files changed: 137 ins; 0 del; 45 mod

8178701: Compile error with switch statement on protected enum defined in parent inner class

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/7621

From asotona at openjdk.java.net  Mon May 16 14:45:25 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 16 May 2022 14:45:25 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v7]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <B9n9ovVUUAPav2KdXUFCOizjfBhzhONYzbossdB5IoQ=.dcca8271-3116-4026-a51a-0afa592cb3ad@github.com>

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

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

 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

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

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06
  Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Mon May 16 14:58:33 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 16 May 2022 14:58:33 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v8]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <6fMaRe1U4N-Uz4oe8QKOqIwy-bqkQRVR75XJJpLSXgY=.c8072af3-f0e1-430e-9ab2-33db617c5d77@github.com>

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

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

  8244681: Add a warning for possibly lossy conversion in compound assignments
  re-enabled warnings for java.base, java.rmi and java.smartcardio

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/a72644e9..74f9f4b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06-07

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From darcy at openjdk.java.net  Mon May 16 15:53:49 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 16 May 2022 15:53:49 GMT
Subject: RFR: 8286475: Drop --enable-preview from instanceof pattern
 matching related tests [v2]
In-Reply-To: <OEJ0LzOtoOkX02QYOqpEBaqk3LSXU6Q6CT7D0_fRtqg=.4c5ab947-7036-434b-9254-e4c941ac10f6@github.com>
References: <_hYXFiUL2gLVQv9suKKs9eU0EFZibW7VavZSNDB8p2g=.a3129aa1-0afe-4ed3-9864-a424fedee259@github.com>
 <OEJ0LzOtoOkX02QYOqpEBaqk3LSXU6Q6CT7D0_fRtqg=.4c5ab947-7036-434b-9254-e4c941ac10f6@github.com>
Message-ID: <FBp1-qMeHHYnLeXfYw7ZZFZj-mLto-nW22C2XOKU3NI=.cc87d381-dc87-49fd-a7e5-f2dd28a9c4dd@github.com>

On Tue, 10 May 2022 14:57:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the instanceof pattern matching tests, since instanceof pattern matching have been graduated from preview in JDK 16. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x] Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8628

From clanger at openjdk.java.net  Tue May 17 06:58:53 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 17 May 2022 06:58:53 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause [v2]
In-Reply-To: <E0U_6TlyOf_uXvKR0S0Zh5RzmrzDxoKZy8vcOdpcV00=.e283941d-eb8b-4035-b692-e392c8d5015c@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <FHqGUtqPwHcYNpbXNX_gXVNVElJFqr_ZPXCvx3g8EH4=.0731a30e-d15e-41fb-ab4e-18b183edda19@github.com>
 <E0U_6TlyOf_uXvKR0S0Zh5RzmrzDxoKZy8vcOdpcV00=.e283941d-eb8b-4035-b692-e392c8d5015c@github.com>
Message-ID: <K1es3q6spGgBzsJCtr3A7egdkc5hJ4qk2tjKrrXLQss=.29b86edb-68b9-40df-81e6-0ed2d660ea7b@github.com>

On Sun, 15 May 2022 02:36:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Christoph Langer 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-8286444
>>  - Separate zips change from this PR
>>  - JDK-8286444
>>    
>>    Improve error message in javac compilation when jar files with . or .. are in classpath
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 567:
> 
>> 565:                     this.fileSystem = jarFSProvider.newFileSystem(archivePath, env);
>> 566:                 } catch (ZipException ze) {
>> 567:                     throw new IOException("ZipException opening \"" + archivePath + "\": " + ze.getMessage(), ze);
> 
> Hello Christoph, I'm sorry I'm a bit late to this discussion. One of the concerns raised in this PR is that we might end up leaking the file path of the jar being reported for error. The original example that you had in the JBS is something like this:
> 
> 
> java -cp invalid.jar Hello.java
> 
> which after this change prints:
> 
> 
> ZipException opening "invalid.jar": ZIP file can't be opened as a file system because an entry has a '.' or '..' element in its name
> 
> This is fine, IMO.
> 
> However, consider a slightly modified case. Let's consider a case where you have a different `foo.jar` in that current directory and that `foo.jar` has a `Class-Path` entry which looks like:
> 
> 
> Manifest-Version: 1.0
> Class-Path: invalid.jar
> Created-By: 19-internal (N/A)
> 
> So `foo.jar` is pointing to `invalid.jar`. Now let's run the following command by passing `foo.jar` as `-cp` value (which then brings in `invalid.jar` through the `Class-Path` entry in the Manifest file):
> 
> 
> java -cp foo.jar Hello.java
> 
> With this PR, this now returns:
> 
> 
> ZipException opening "/private/tmp/8286444/invalid.jar": ZIP file can't be opened as a file system because an entry has a '.' or '..' element in its name
> 
> Notice that it has ended up leaking the file path of the jar that was pulled in through the `MANIFEST.MF` file. I think this is something that isn't allowed from a security point of view.
> 
> Perhaps an additional change needs to be done on top of this PR to prevent this, something like:
> 
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
> index 1336fb74916..7c40afb62af 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
> @@ -564,7 +564,7 @@ public class JavacFileManager extends BaseFileManager implements StandardJavaFil
>                  try {
>                      this.fileSystem = jarFSProvider.newFileSystem(archivePath, env);
>                  } catch (ZipException ze) {
> -                    throw new IOException("ZipException opening "" + archivePath + "": " + ze.getMessage(), ze);
> +                    throw new IOException("ZipException opening "" + archivePath.getFileName() + "": " + ze.getMessage(), ze);
>                  }
>              } else {
>                  this.fileSystem = FileSystems.newFileSystem(archivePath, (ClassLoader)null);
> 
> 
> 
> This then just prints the name of the jar in both cases:
> 
> 
> java -cp invalid.jar Hello.java
> 
> ZipException opening "invalid.jar": ZIP file can't be opened as a file system because an entry has a '.' or '..' element in its name
> 
> 
> java -cp foo.jar Hello.java
> 
> ZipException opening "invalid.jar": ZIP file can't be opened as a file system because an entry has a '.' or '..' element in its name

Hi Jai,

this is a good point. Regarding the potential leaking of the jar path in the manifest case pointed out by you, I would think that it is not problematic as the exception occurs in a (developer-) tool and there it might even be useful. However, for consistency purposes, it might be clearer to just print the jar name. I guess that's already helpful enough.

I'll open a follow up bug for this.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From shade at openjdk.java.net  Tue May 17 08:52:55 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 17 May 2022 08:52:55 GMT
Subject: RFR: 8286475: Drop --enable-preview from instanceof pattern
 matching related tests [v2]
In-Reply-To: <OEJ0LzOtoOkX02QYOqpEBaqk3LSXU6Q6CT7D0_fRtqg=.4c5ab947-7036-434b-9254-e4c941ac10f6@github.com>
References: <_hYXFiUL2gLVQv9suKKs9eU0EFZibW7VavZSNDB8p2g=.a3129aa1-0afe-4ed3-9864-a424fedee259@github.com>
 <OEJ0LzOtoOkX02QYOqpEBaqk3LSXU6Q6CT7D0_fRtqg=.4c5ab947-7036-434b-9254-e4c941ac10f6@github.com>
Message-ID: <EyDo5uQVv8dHI1hdDzfv2Gfc6P-omu4iHVVfcof1-os=.2e804436-00e6-40fd-81ed-26c8e164770e@github.com>

On Tue, 10 May 2022 14:57:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the instanceof pattern matching tests, since instanceof pattern matching have been graduated from preview in JDK 16. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x] Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8628

From shade at openjdk.java.net  Tue May 17 08:52:56 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 17 May 2022 08:52:56 GMT
Subject: Integrated: 8286475: Drop --enable-preview from instanceof pattern
 matching related tests
In-Reply-To: <_hYXFiUL2gLVQv9suKKs9eU0EFZibW7VavZSNDB8p2g=.a3129aa1-0afe-4ed3-9864-a424fedee259@github.com>
References: <_hYXFiUL2gLVQv9suKKs9eU0EFZibW7VavZSNDB8p2g=.a3129aa1-0afe-4ed3-9864-a424fedee259@github.com>
Message-ID: <OlO7rsndxowNtafo32nuwaF2woqAGmlWPJ8NkS_5YlE=.00fbe17b-2764-47bb-b261-20c31a589f16@github.com>

On Tue, 10 May 2022 12:11:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the instanceof pattern matching tests, since instanceof pattern matching have been graduated from preview in JDK 16. 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x] Linux x86_32 fastdebug, affected tests start to pass

This pull request has now been integrated.

Changeset: 8c977050
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8c977050aa20a7e9a6d0d83d18dce25defcc7a46
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8286475: Drop --enable-preview from instanceof pattern matching related tests

Reviewed-by: darcy

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

PR: https://git.openjdk.java.net/jdk/pull/8628

From abimpoudis at openjdk.java.net  Tue May 17 12:34:19 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Tue, 17 May 2022 12:34:19 GMT
Subject: RFR: 8286797: Guards of constant value false are not permitted
Message-ID: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>

Simple fix that addresses this line from the spec:

> It is a compile-time error if a when expression is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with the value false.

Extracts one small utility method `isBooleanWithValue` in `TreeInfo`.

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

Commit messages:
 - 8286797: Guards of constant value false are not permitted

Changes: https://git.openjdk.java.net/jdk/pull/8745/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8745&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286797
  Stats: 106 lines in 9 files changed: 100 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8745.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8745/head:pull/8745

PR: https://git.openjdk.java.net/jdk/pull/8745

From asotona at openjdk.java.net  Tue May 17 12:55:21 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 17 May 2022 12:55:21 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image containing
 jdk.compiler fails with --enable-preview option
Message-ID: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>

### Problem description
Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
fails to run java source launcher correctly (for example when --source N is specified).
Failing source launcher is the only one expression of internal jdk.compiler malfunction, another example is failure to run javac with --release option.

### Root cause
Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
However module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.

### Alternative patch
The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module).

### Proposed fix
This patch does fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
Plus added specific test case.

Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.

Thanks,
Adam

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

Commit messages:
 - 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option

Changes: https://git.openjdk.java.net/jdk/pull/8747/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286571
  Stats: 30 lines in 2 files changed: 29 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8747/head:pull/8747

PR: https://git.openjdk.java.net/jdk/pull/8747

From asotona at openjdk.java.net  Tue May 17 13:08:32 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 17 May 2022 13:08:32 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v2]
In-Reply-To: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
Message-ID: <B3jOs2mD5UAbmSdS0IYbIu3qVb5dl5dBsWekJQT6OUU=.e0b461a2-bc82-4c57-aa7c-f8415a61dbef@github.com>

> ### Problem description
> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
> fails to run java source launcher correctly (for example when --source N is specified).
> Failing source launcher is the only one expression of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
> 
> ### Root cause
> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
> However module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
> 
> ### Alternative patch
> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module).
> 
> ### Proposed fix
> This patch does fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
> Plus added specific test case.
> 
> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
> 
> Thanks,
> Adam

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

  fix of LimitedImage test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8747/files
  - new: https://git.openjdk.java.net/jdk/pull/8747/files/40884fd8..6bdf4a9a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=00-01

  Stats: 45 lines in 1 file changed: 0 ins; 37 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8747/head:pull/8747

PR: https://git.openjdk.java.net/jdk/pull/8747

From jlahoda at openjdk.java.net  Tue May 17 13:53:04 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 17 May 2022 13:53:04 GMT
Subject: Integrated: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
Message-ID: <zexSMn0GwOUhsRxQ3hJJw7QKAkWiVpTOKtevQDdQLlU=.f8cfd132-bd27-49ab-aaa4-cd9490c9fde2@github.com>

On Thu, 31 Mar 2022 08:13:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
> 
> interface I {}
> 
> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
> 
> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
> 
> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.

This pull request has now been integrated.

Changeset: c0d51d42
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0d51d42d9715b44df995328bba978ba61dec3af
Stats:     80 lines in 2 files changed: 80 ins; 0 del; 0 mod

8282080: Lambda deserialization fails for Object method references on interfaces

Reviewed-by: vromero, mcimadamore

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From vromero at openjdk.java.net  Tue May 17 20:16:37 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 17 May 2022 20:16:37 GMT
Subject: RFR: 8286797: Guards of constant value false are not permitted
In-Reply-To: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
References: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
Message-ID: <1BBBJjX3pIc8yJ8d0oeF1rHj1Y2B-mpm8UUeRei7H3I=.ae4ca522-6fc2-4d30-85ca-46fadf374e13@github.com>

On Tue, 17 May 2022 12:25:41 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Simple fix that addresses this line from the spec:
> 
>> It is a compile-time error if a when expression is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with the value false.
> 
> Extracts one small utility method `isBooleanWithValue` in `TreeInfo`.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 516:

> 514: 
> 515: compiler.err.guard.has.constant.expression.false=\
> 516:     this case label has a when constant expression that is false

`when` here should be: `''when''`

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

PR: https://git.openjdk.java.net/jdk/pull/8745

From jjg at openjdk.java.net  Tue May 17 22:00:17 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 17 May 2022 22:00:17 GMT
Subject: RFR: JDK-8286101: Support formatting in @value tag
Message-ID: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>

This PR is for an update to the doc comment `{@value}` tag to permit an optional [format string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html#syntax) after the name of the tag.

    {@value optional-format-string optional-reference}

If given, the format string should either begin with `%` or the string should be quoted with `"`. For example, `%4x` or `"0x%4x"`.  The format string must contain exactly one `%` character.

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

Commit messages:
 - address review feedback
 - Merge remote-tracking branch 'upstream/master' into 8286101.format-at-value
 - JDK-8286101: Support formatting in @value tag

Changes: https://git.openjdk.java.net/jdk/pull/8565/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8565&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286101
  Stats: 336 lines in 18 files changed: 322 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8565.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8565/head:pull/8565

PR: https://git.openjdk.java.net/jdk/pull/8565

From prappo at openjdk.java.net  Tue May 17 22:00:20 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 17 May 2022 22:00:20 GMT
Subject: RFR: JDK-8286101: Support formatting in @value tag
In-Reply-To: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
References: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
Message-ID: <sFwo2PPK0vhHRTZAIUqTU-SARGDOp6tF6U8u9Ww6tEQ=.e1441541-f1fb-40a3-95f0-97402a7bfa09@github.com>

On Thu, 5 May 2022 23:39:46 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This PR is for an update to the doc comment `{@value}` tag to permit an optional [format string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html#syntax) after the name of the tag.
> 
>     {@value optional-format-string optional-reference}
> 
> If given, the format string should either begin with `%` or the string should be quoted with `"`. For example, `%4x` or `"0x%4x"`.  The format string must contain exactly one `%` character.

So far the idea looks okay. My feedback is purely on its implementation.

I'm concerned about backward compatibility. If we believe that it is unlikely that javadoc can be configured to use a custom implentation of `DocTreeFactory`, then the proposed implementation looks okay. Otherwise, consider a case where a new javadoc tool reads old doc comments. Do we expect it to fail with `UnsupportedOperationException` for every `value` tag in those doc comments?

My inline comments below are about that latter case; ignore them if you don't think it's an issue.

src/jdk.compiler/share/classes/com/sun/source/doctree/ValueTree.java line 55:

> 53:     default TextTree getFormat() {
> 54:         throw new UnsupportedOperationException();
> 55:     }

Return `null` and specify this behavior in the `@implSpec` section.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1605:

> 1603:                     if (ch == '}') {
> 1604:                         nextChar();
> 1605:                         return m.at(pos).newValueTree(format, ref);

If `format == null` call `newValueTree(ref)`; otherwise call `newValueTree(format, ref)`.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 482:

> 480: 
> 481:     @Override @DefinedBy(Api.COMPILER_TREE)
> 482:     public DCValue newValueTree(ReferenceTree ref) {

Revert the implementation of this method.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ValueTaglet.java line 112:

> 110:                     text = String.format(configuration.getLocale(), f, field.getConstantValue());
> 111:                 } catch (IllegalFormatException e) {
> 112:                     messages.warning(holder,

Doesn't CSR say that it is an *error*?

test/langtools/tools/javac/doctree/ValueTest.java line 108:

> 106: */
> 107: 
> 108:     /**

Consider adding the following cases:
  * erroneous format
  * valid format and reference followed by the trailing "junk"

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

PR: https://git.openjdk.java.net/jdk/pull/8565

From jjg at openjdk.java.net  Tue May 17 22:00:20 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 17 May 2022 22:00:20 GMT
Subject: RFR: JDK-8286101: Support formatting in @value tag
In-Reply-To: <sFwo2PPK0vhHRTZAIUqTU-SARGDOp6tF6U8u9Ww6tEQ=.e1441541-f1fb-40a3-95f0-97402a7bfa09@github.com>
References: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
 <sFwo2PPK0vhHRTZAIUqTU-SARGDOp6tF6U8u9Ww6tEQ=.e1441541-f1fb-40a3-95f0-97402a7bfa09@github.com>
Message-ID: <hEiLipCf9cNO2nQ8f5iPDCYNSoy4XtgVyuJ7KfcTxxA=.4832ff46-a856-4cd4-9cdf-a3adf8bdc071@github.com>

On Mon, 16 May 2022 10:07:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> So far the idea looks okay. My feedback is purely on its implementation.
> 
> I'm concerned about backward compatibility. If we believe that it is unlikely that javadoc can be configured to use a custom implentation of `DocTreeFactory`, then the proposed implementation looks okay. Otherwise, consider a case where a new javadoc tool reads old doc comments. Do we expect it to fail with `UnsupportedOperationException` for every `value` tag in those doc comments?
> 
> My inline comments below are about that latter case; ignore them if you don't think it's an issue.

1. It is very unlikely that you could/would configure mismatched versions of the jdk.javadoc and jdk.compiler modules.
2. Note that a new javadoc tool can read old doc comments (because the format is optional) and should not throw exceptions. The problem will occur if a new javadoc tool uses and old `DocCommentParser` in a mismatched module.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1605:
> 
>> 1603:                     if (ch == '}') {
>> 1604:                         nextChar();
>> 1605:                         return m.at(pos).newValueTree(format, ref);
> 
> If `format == null` call `newValueTree(ref)`; otherwise call `newValueTree(format, ref)`.

I guess I don't think it's an issue but I'm OK with the proposed next form.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 482:
> 
>> 480: 
>> 481:     @Override @DefinedBy(Api.COMPILER_TREE)
>> 482:     public DCValue newValueTree(ReferenceTree ref) {
> 
> Revert the implementation of this method.

That's not necessary, because we're in the private implementation world here.  The important change you're suggesting is to the methods in the `DocTreeFactory` interface.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ValueTaglet.java line 112:
> 
>> 110:                     text = String.format(configuration.getLocale(), f, field.getConstantValue());
>> 111:                 } catch (IllegalFormatException e) {
>> 112:                     messages.warning(holder,
> 
> Doesn't CSR say that it is an *error*?

The CSR doesn't say, but I changed it to an error anyway.

> test/langtools/tools/javac/doctree/ValueTest.java line 108:
> 
>> 106: */
>> 107: 
>> 108:     /**
> 
> Consider adding the following cases:
>   * erroneous format
>   * valid format and reference followed by the trailing "junk"

done

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

PR: https://git.openjdk.java.net/jdk/pull/8565

From jjg at openjdk.java.net  Tue May 17 22:11:43 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 17 May 2022 22:11:43 GMT
Subject: RFR: JDK-8286101: Support formatting in @value tag [v2]
In-Reply-To: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
References: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
Message-ID: <3_2pHeqUl6MlymXxNiNK3AtIi_fDsRMZmzIorCqbL9M=.cba6f607-1edf-4651-8d0d-459f6211c49a@github.com>

> This PR is for an update to the doc comment `{@value}` tag to permit an optional [format string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html#syntax) after the name of the tag.
> 
>     {@value optional-format-string optional-reference}
> 
> If given, the format string should either begin with `%` or the string should be quoted with `"`. For example, `%4x` or `"0x%4x"`.  The format string must contain exactly one `%` character.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8565/files
  - new: https://git.openjdk.java.net/jdk/pull/8565/files/87135b61..1b5f7d5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8565&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8565&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8565.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8565/head:pull/8565

PR: https://git.openjdk.java.net/jdk/pull/8565

From jjg at openjdk.java.net  Tue May 17 22:11:44 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 17 May 2022 22:11:44 GMT
Subject: RFR: JDK-8286101: Support formatting in @value tag [v2]
In-Reply-To: <sFwo2PPK0vhHRTZAIUqTU-SARGDOp6tF6U8u9Ww6tEQ=.e1441541-f1fb-40a3-95f0-97402a7bfa09@github.com>
References: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
 <sFwo2PPK0vhHRTZAIUqTU-SARGDOp6tF6U8u9Ww6tEQ=.e1441541-f1fb-40a3-95f0-97402a7bfa09@github.com>
Message-ID: <rJ0rq-DLufV1RyFZlC92zBLl0LimBoB5nb9ucn9h9cQ=.22f05596-5932-4a0a-9769-4a10317c938c@github.com>

On Mon, 16 May 2022 09:57:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/ValueTree.java line 55:
> 
>> 53:     default TextTree getFormat() {
>> 54:         throw new UnsupportedOperationException();
>> 55:     }
> 
> Return `null` and specify this behavior in the `@implSpec` section.

done

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

PR: https://git.openjdk.java.net/jdk/pull/8565

From jjg at openjdk.java.net  Tue May 17 23:14:48 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 17 May 2022 23:14:48 GMT
Subject: RFR: JDK-8286101: Support formatting in @value tag [v3]
In-Reply-To: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
References: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
Message-ID: <CWdwdv2SqEzApFSmzK-NUF81hrLkl3xuPtRY0s5lo_Q=.fec3fd71-a560-4817-b1bf-639ff62ca167@github.com>

> This PR is for an update to the doc comment `{@value}` tag to permit an optional [format string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html#syntax) after the name of the tag.
> 
>     {@value optional-format-string optional-reference}
> 
> If given, the format string should either begin with `%` or the string should be quoted with `"`. For example, `%4x` or `"0x%4x"`.  The format string must contain exactly one `%` character.

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

 - fix typo
 - Merge remote-tracking branch 'upstream/master' into 8286101.format-at-value
 - address review feedback
 - address review feedback
 - Merge remote-tracking branch 'upstream/master' into 8286101.format-at-value
 - JDK-8286101: Support formatting in @value tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8565/files
  - new: https://git.openjdk.java.net/jdk/pull/8565/files/1b5f7d5f..30755d75

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8565&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8565&range=01-02

  Stats: 1147 lines in 12 files changed: 494 ins; 422 del; 231 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8565.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8565/head:pull/8565

PR: https://git.openjdk.java.net/jdk/pull/8565

From jpai at openjdk.java.net  Wed May 18 02:53:49 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 18 May 2022 02:53:49 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v2]
In-Reply-To: <B3jOs2mD5UAbmSdS0IYbIu3qVb5dl5dBsWekJQT6OUU=.e0b461a2-bc82-4c57-aa7c-f8415a61dbef@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <B3jOs2mD5UAbmSdS0IYbIu3qVb5dl5dBsWekJQT6OUU=.e0b461a2-bc82-4c57-aa7c-f8415a61dbef@github.com>
Message-ID: <nrGBwA6vmG_fJoHfhXkK90t94mEseybWdkeYC5QAxiw=.109d7fb0-9fd8-4e11-a03e-b796c78d3e5e@github.com>

On Tue, 17 May 2022 13:08:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix of LimitedImage test

Hello Adam, I don't have necessary knowledge of this area, so I don't know what approach would be preferred.

But a couple of questions:

- If we do decide to add the `jdk.zipfs` dependency to `jdk.compiler` module, do you think the `LimitedImage` test is still relevant? Or should it be removed? The comment on that test states:
> @summary Verify javac behaves properly in absence of zip/jar FileSystemProvider

and it does so by using `--limit-modules`. But now with the `jdk.zipfs` being a dependency, the zip/jar FileSystemProvider will not be absent and the test then would seem unnecessary.

- In the JBS issue corresponding to this PR, you noted that:

>There are actually two different issues:
>
>First in JDKPlatformProvider, which silently swallows ProviderNotFoundException. 

Should something be done there? I see that the catch block happens to reside in the `static` block of that class (which also happens to be a implementation of a Java `service`), so I'm unsure what if anything can be done there.

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From asotona at openjdk.java.net  Wed May 18 06:21:50 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 18 May 2022 06:21:50 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v2]
In-Reply-To: <nrGBwA6vmG_fJoHfhXkK90t94mEseybWdkeYC5QAxiw=.109d7fb0-9fd8-4e11-a03e-b796c78d3e5e@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <B3jOs2mD5UAbmSdS0IYbIu3qVb5dl5dBsWekJQT6OUU=.e0b461a2-bc82-4c57-aa7c-f8415a61dbef@github.com>
 <nrGBwA6vmG_fJoHfhXkK90t94mEseybWdkeYC5QAxiw=.109d7fb0-9fd8-4e11-a03e-b796c78d3e5e@github.com>
Message-ID: <MiDA9Krap0LjS2ZNIR74gSyyiAhB2FMD66uZfXt2yW8=.868bad95-6f9c-4c45-9862-ba3fe00dc166@github.com>

On Wed, 18 May 2022 02:50:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Adam, I don't have necessary knowledge of this area, so I don't know what approach would be preferred.
> 
> But a couple of questions:
> 
> * If we do decide to add the `jdk.zipfs` dependency to `jdk.compiler` module, do you think the `LimitedImage` test is still relevant? Or should it be removed? The comment on that test states:
> 
> > @summary Verify javac behaves properly in absence of zip/jar FileSystemProvider
> 
> and it does so by using `--limit-modules`. But now with the `jdk.zipfs` being a dependency, the zip/jar FileSystemProvider will not be absent and the test then would seem unnecessary.

You are right, the test description should change. The test name is LimitedImage and it verifies that javac behaves properly in limited JDK image. I think the purpose of the test is still the same, just results are different (now it pass compilation instead of failing with specific error).

Thanks for pointing it out.

> 
> * In the JBS issue corresponding to this PR, you noted that:
> 
> > There are actually two different issues:
> > First in JDKPlatformProvider, which silently swallows ProviderNotFoundException.
> 
> Should something be done there? I see that the catch block happens to reside in the `static` block of that class (which also happens to be a implementation of a Java `service`), so I'm unsure what if anything can be done there.

Silent swallow of an exception in static initializer of a service is not very good practice and it has significant effect on this issue right now. However it will express itself only in corner cases (like for example broken ct.sym file) after this patch is integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From asotona at openjdk.java.net  Wed May 18 06:30:34 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 18 May 2022 06:30:34 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
Message-ID: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>

> ### Problem description
> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
> fails to run java source launcher correctly (for example when --source N is specified).
> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
> 
> ### Root cause
> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
> 
> ### Alternative patch
> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
> 
> ### Proposed fix
> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
> Plus added specific test case.
> 
> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
> 
> Thanks,
> Adam

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

  corrected LimitedImage test description

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8747/files
  - new: https://git.openjdk.java.net/jdk/pull/8747/files/6bdf4a9a..0e55575b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From abimpoudis at openjdk.java.net  Wed May 18 07:19:06 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 18 May 2022 07:19:06 GMT
Subject: RFR: 8286797: Guards of constant value false are not permitted
 [v2]
In-Reply-To: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
References: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
Message-ID: <AutrZn9euTOSu0u5lsHkuyCK5tRazrSR_zhDmCbkHcY=.25cb3e64-3d62-41c7-b927-e17b9d72a796@github.com>

> Simple fix that addresses this line from the spec:
> 
>> It is a compile-time error if a when expression is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with the value false.
> 
> Extracts one small utility method `isBooleanWithValue` in `TreeInfo`.

Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8286797: Guards of constant value false are not permitted

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8745/files
  - new: https://git.openjdk.java.net/jdk/pull/8745/files/a1dac89c..8814f4fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8745&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8745&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8745

From abimpoudis at openjdk.java.net  Wed May 18 07:19:09 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 18 May 2022 07:19:09 GMT
Subject: RFR: 8286797: Guards of constant value false are not permitted
 [v2]
In-Reply-To: <1BBBJjX3pIc8yJ8d0oeF1rHj1Y2B-mpm8UUeRei7H3I=.ae4ca522-6fc2-4d30-85ca-46fadf374e13@github.com>
References: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
 <1BBBJjX3pIc8yJ8d0oeF1rHj1Y2B-mpm8UUeRei7H3I=.ae4ca522-6fc2-4d30-85ca-46fadf374e13@github.com>
Message-ID: <g3HoeWbiDEE60v0td3GkJNnO7nEIYOD_w5dfx72_AW8=.c095d3b8-3a2d-462f-aa3c-7e0011ed5684@github.com>

On Tue, 17 May 2022 20:13:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8286797: Guards of constant value false are not permitted
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 516:
> 
>> 514: 
>> 515: compiler.err.guard.has.constant.expression.false=\
>> 516:     this case label has a when constant expression that is false
> 
> `when` here should be: `''when''`, but shouldn't the message probably start with:
>     this case label has a guard...?

True. I improved the error message a bit.

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

PR: https://git.openjdk.java.net/jdk/pull/8745

From aivanov at openjdk.java.net  Wed May 18 13:34:24 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 13:34:24 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
Message-ID: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

Also, I fixed a couple of spelling mistakes.

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

Commit messages:
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...c7e73658

Changes: https://git.openjdk.java.net/jdk/pull/8768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284191
  Stats: 202 lines in 162 files changed: 0 ins; 11 del; 191 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From lancea at openjdk.java.net  Wed May 18 14:42:53 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:42:53 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <DOokHH_SxPtXjdpCSV9F_RmnHaNC6WnO3ChzhQNGxF8=.3fbb1072-bae7-4dc9-a424-4e9dd0cecc33@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Wed May 18 14:53:28 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 14:53:28 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
Message-ID: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

It's the last issue in the series, and it still touches different areas of the code.

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

Commit messages:
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'an? an?' in source code
 - 8284209: Replace remaining usages of 'a the' in source code
 - 8284209: Replace remaining usages of 'an the' in source code
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...8290c07e

Changes: https://git.openjdk.java.net/jdk/pull/8771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284209
  Stats: 51 lines in 41 files changed: 0 ins; 2 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From lancea at openjdk.java.net  Wed May 18 14:59:56 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:59:56 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <H0aIQ5SRJgWgvc_Hp8Y6ClzE86lEOzNYOKiV56ueWU0=.9bf1a830-fb68-4f70-a254-3b5d182739ae@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8771

From wetmore at openjdk.java.net  Wed May 18 15:15:56 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:15:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AIjhEfuQaJLjZPeDl94HgUet9eMCoEwolZpNvKGGHGs=.bb1c32b4-65d8-40f2-84c3-38dc7db54894@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Looked at 

- java.base/.../sun/security
- jdk.crypto.*
- test/*/com/sun/crypto/provider
- test/*/java/lang/SecurityManager
- test/*/java/security
- test/*/krb5
- test/*/jarsigner

and those look fine.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From wetmore at openjdk.java.net  Wed May 18 15:19:55 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:19:55 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <BlEMdHGx8wwWoDnuSLakASovW6f-yse6TPC3pbF6bcE=.8caab0de-e0bf-457d-883e-ae779ccff635@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Looked at 

-java.security.jgss.

LGTM

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From dfuchs at openjdk.java.net  Wed May 18 16:07:52 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 18 May 2022 16:07:52 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <hqiM9eFHWbK89Zfb-ZaJGalvghiDsyvw09l6hQI8YxA=.6cb984f1-c988-4f52-bd07-406a5362fe70@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Logging/JNDI OK

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From naoto at openjdk.java.net  Wed May 18 16:18:58 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 May 2022 16:18:58 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4eXpe5pmBsvw8u6fJlzd9BWsnY74LiyjTqQhQ88uxoc=.6182985a-f751-4d55-b9d0-bc605d7636da@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

LGTM for i18n changes.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From iris at openjdk.java.net  Wed May 18 16:59:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 16:59:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <pRvaphDcC8dB1bZPh6x4OhyZ8BHSfCn9ZCdBzq9Dnco=.1ca1edd4-0004-43b9-815c-3b20ffb5368f@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From iris at openjdk.java.net  Wed May 18 17:04:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 17:04:50 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <KFAmufl8fur2ZWbG3C6rN_8h7oficN_4ViuHJ7hfvg4=.3ee598c2-3fd1-4344-bd94-89459431f74b@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8771

From jjg at openjdk.java.net  Wed May 18 17:26:11 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 May 2022 17:26:11 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v2]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <sB7kbYANTeyZXSgz4_aPkRz2asHSq9OfVNTPpcfHUew=.e6153389-1b7d-481c-bcaa-680b88ac0e45@github.com>

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

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

 - merge with upstream/master
 - fix whitespace and position of HtmlStyle.refList
 - fix whitespace
 - JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec)

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

Changes: https://git.openjdk.java.net/jdk/pull/8439/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=01
  Stats: 1538 lines in 41 files changed: 1506 ins; 3 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8439/head:pull/8439

PR: https://git.openjdk.java.net/jdk/pull/8439

From vromero at openjdk.java.net  Wed May 18 17:57:54 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 18 May 2022 17:57:54 GMT
Subject: RFR: 8286797: Guards of constant value false are not permitted
 [v2]
In-Reply-To: <AutrZn9euTOSu0u5lsHkuyCK5tRazrSR_zhDmCbkHcY=.25cb3e64-3d62-41c7-b927-e17b9d72a796@github.com>
References: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
 <AutrZn9euTOSu0u5lsHkuyCK5tRazrSR_zhDmCbkHcY=.25cb3e64-3d62-41c7-b927-e17b9d72a796@github.com>
Message-ID: <4dH5oI0HVn25xP5p-68_ZTfj1vRN5eqLRaedw8gmG44=.ce2c44bb-c70b-44aa-b315-91b8034131ac@github.com>

On Wed, 18 May 2022 07:19:06 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Simple fix that addresses this line from the spec:
>> 
>>> It is a compile-time error if a when expression is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with the value false.
>> 
>> Extracts one small utility method `isBooleanWithValue` in `TreeInfo`.
>
> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8286797: Guards of constant value false are not permitted

looks good, just a minor suggestion, don't need another iteration

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 516:

> 514: 
> 515: compiler.err.guard.has.constant.expression.false=\
> 516:     this case label has a guard that is a constant expression with value false

suggestion:
`... with value ''false''`

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8745

From jjg at openjdk.java.net  Wed May 18 17:58:36 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 May 2022 17:58:36 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v3]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <UEIwMbV_DfVBPqzhXC4EVx8jiZjeN7YPLiEb6ib2xUY=.bd7972a4-a45d-493c-82d9-ce231437fcf0@github.com>

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

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix merge issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8439/files
  - new: https://git.openjdk.java.net/jdk/pull/8439/files/af1a716b..2992b6bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=01-02

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8439/head:pull/8439

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Wed May 18 18:24:57 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 May 2022 18:24:57 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v3]
In-Reply-To: <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
Message-ID: <BkFQfGAZ4PXVm6kE6MJ0M47eYWHQb-lUkqLwdv34l8g=.e96b4246-ebc3-457b-b408-77485325de02@github.com>

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

> This is nice work. I haven't seen it in detail, but I'm plannig to do so later.
> 
> What's the logistics here? There are two interrelated bugs: 6251738 and 8226279. Are you going to add an 8226279 as an issue to this PR (`/issue add 8226279`)? What about @bug tags in tests? Are they going to mention both issues?

For now, I'll track both, here in the PR and in tests. If this becomes impractical, I'll retain the old/original one and close the newer one.  The old one described the problem; the newer one described a specific solution, although the actual implementation has move on from that proposed in 8226279.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Wed May 18 18:25:00 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 May 2022 18:25:00 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v3]
In-Reply-To: <ra5mbVlZsni6K2dj4VwaCCYXWBgAgNpZwBrQXEHQLco=.908d96b1-2eaf-4bbf-a041-927f0298bfec@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
 <ra5mbVlZsni6K2dj4VwaCCYXWBgAgNpZwBrQXEHQLco=.908d96b1-2eaf-4bbf-a041-927f0298bfec@github.com>
Message-ID: <tUNa-mL0-EivSNBYv_UiejJjKU9OWnJ_MyDRIMrz0ms=.9a604019-d18c-47b5-ae96-6b23c6c0ffee@github.com>

On Tue, 3 May 2022 21:58:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 340:
>> 
>>> 338:     SnippetTree newSnippetTree(List<? extends DocTree> attributes, TextTree text);
>>> 339: 
>>> 340:     /**
>> 
>> Similar comment to that of DocTreeVisitor: consider adhering to the file style.
>
> I see there is a missing `@since` tag, which I'll fix.
> I'd prefer to leave the extra whitespace for now, and maybe cleanup the style of the other comments later.

Added @since. Removed the whitespace for now.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Wed May 18 18:43:44 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 May 2022 18:43:44 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v4]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <madEVzus8seob93AWjKQ64ifJsgBG2oAHCDYgKyAFeQ=.acba30be-d45e-4533-a2bb-b7fe89f8a2d3@github.com>

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

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8439/files
  - new: https://git.openjdk.java.net/jdk/pull/8439/files/2992b6bc..47e7179e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=02-03

  Stats: 11 lines in 2 files changed: 1 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8439/head:pull/8439

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Wed May 18 22:06:44 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 May 2022 22:06:44 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <aEkG0OZ86yGP3oWxO4p1nrLGfm0uEdI0SOvg4EczMaY=.c368691e-af13-46dc-8e60-b664f8094e00@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

javac and javadoc changes look OK

test/langtools/tools/javac/modules/T8168854/module-info.java line 4:

> 2:  * @test
> 3:  * @bug 8168854
> 4:  * @summary javac erroneously reject a service interface inner class in a provides clause

FYI, this duplication was in the JBS issue summary; now fixed there.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From abimpoudis at openjdk.java.net  Thu May 19 08:26:44 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 19 May 2022 08:26:44 GMT
Subject: RFR: 8286797: Guards of constant value false are not permitted
 [v3]
In-Reply-To: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
References: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
Message-ID: <8fau3Ecm275akB3st82AnL0ZNale8cm0FV8jcTVAuKk=.709694db-c1d3-49a1-872d-e0628d09de29@github.com>

> Simple fix that addresses this line from the spec:
> 
>> It is a compile-time error if a when expression is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with the value false.
> 
> Extracts one small utility method `isBooleanWithValue` in `TreeInfo`.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  8286797: Adjust error message

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8745/files
  - new: https://git.openjdk.java.net/jdk/pull/8745/files/8814f4fb..2983b9ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8745&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8745&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8745

From kevinw at openjdk.java.net  Thu May 19 08:43:45 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:43:45 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <c0o1YvhNkDe026TrcGqKdFaH6G93AfyQCHvBLzGNf8s=.007721e9-d02c-4319-a562-c3296fed6bbf@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java line 28:

> 26: 
> 27: /**
> 28:  * Notification emitted when a peers shutdowns the association.

Maybe: "...when a peer shuts down an association."
(could be "shuts down the association" if there is only ever one, but using "an" looks safe)

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 08:50:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:50:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:

> 346: 
> 347:     /**
> 348:      * Returns the single non-abstract {@link Method} visible from

I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:02:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:02:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <gSIQ2U9H0PmGgCBlsc4SocQff7AauSX3jiC10z26SJQ=.af26181b-5c61-4ecc-b836-5e5cff2cc901@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/opto/graphKit.cpp line 3626:

> 3624: // The optional arguments are for specialized use by intrinsics:
> 3625: //  - If 'extra_slow_test' if not null is an extra condition for the slow-path.
> 3626: //  - If 'return_size_val', report the total object size to the caller.

"reports the total"

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:09:50 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:09:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <A3yxKJkrz3h716ciAsbQHtiWg_y5gMtqLrMoDSxFTWE=.6e31ca1c-505c-4794-b1f0-622dc811388c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/interpreter/bytecodeUtils.cpp line 186:

> 184:   static const int _max_cause_detail = 5;
> 185: 
> 186:   // Merges the stack the given bci with the given stack. If there

"...the stack at the given bci..."

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:27:55 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:27:55 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <02e6mwqZ3ihNyJb4lBK-5WeIGMfiLMj3I8LpJPv4i8o=.3c56077b-54f0-4c4e-b031-5a000b9ea887@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/cds/filemap.cpp line 1914:

> 1912: 
> 1913:     // the current value of the pointers to be patched must be within this
> 1914:     // range (i.e., must be between the requested base address, and the of the current archive).

"the of the" ? 
Maybe "..and the address of the current archive",  or maybe it was a typo for "and that of the current archive".

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:35:42 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:35:42 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 84:

> 82: 
> 83:     /**
> 84:      * Create a Zip file that will result in an Zip64 Extra (EXT) header

"result in a Zip64..."

test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:

> 30: /*
> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
> 32:  * formatted individual sections in addition the main attributes tested

"in addition to the..."

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:41:57 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:41:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

test/jdk/java/net/InterfaceAddress/Equals.java line 81:

> 79:     /**
> 80:      * Returns an InterfaceAddress instance with its fields set the values
> 81:      * specificed.

probably a typo for "set to the values specified."

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From cstein at openjdk.java.net  Thu May 19 10:23:14 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 19 May 2022 10:23:14 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
Message-ID: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>

This PR adds an optional description accessor on `ToolProvider` interface.

This PR also adds short description for each of the listed tool:
- `jar`
- `javac`
- `javadoc`
- `javap` and `jdeps`
- `jlink` and `jmod`
- `jpackage`

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

Commit messages:
 - Add localized description for `jpackage`
 - Add localized description for `jlink` and `jmod`
 - Add localized description for `javap` and `jdeps`
 - Add localized description for `javadoc`
 - Add localized description for `jar`
 - Add localized description for `javac`
 - 8286654: Add an optional description accessor on ToolProvider interface

Changes: https://git.openjdk.java.net/jdk/pull/8772/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8772&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286654
  Stats: 115 lines in 19 files changed: 97 ins; 2 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8772.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8772/head:pull/8772

PR: https://git.openjdk.java.net/jdk/pull/8772

From jjg at openjdk.java.net  Thu May 19 10:23:16 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 19 May 2022 10:23:16 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <hlEn3ZTHbWSOxF99IchuV-G64886D96b1n-pEs9zELk=.4ce40936-9982-4467-b424-c4a9e469824d@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

Main issue is the one I raised at the beginning, about what grammatical form you should be using for the short description.

Also, is the description a phrase (probably not capitalized, and no terminating period) or a sentence (capitalized with a terminating period.)

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavacToolProvider.java line 30:

> 28: import com.sun.tools.javac.util.JavacMessages;
> 29: import java.io.PrintWriter;
> 30: import java.util.Optional;

at least in javac, we normally sort `java.*` and `javax.*` imports before other imports.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 387:

> 385: 
> 386: javac.description=Read Java declarations and compile them into class files
> 387: 

for your general consideration, what grammatical style do you recommend here? Should it be 3rd person (Reads) instead of 2nd person (Read)

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

PR: https://git.openjdk.java.net/jdk/pull/8772

From cstein at openjdk.java.net  Thu May 19 10:23:17 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 19 May 2022 10:23:17 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <hlEn3ZTHbWSOxF99IchuV-G64886D96b1n-pEs9zELk=.4ce40936-9982-4467-b424-c4a9e469824d@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
 <hlEn3ZTHbWSOxF99IchuV-G64886D96b1n-pEs9zELk=.4ce40936-9982-4467-b424-c4a9e469824d@github.com>
Message-ID: <M_RZg5YrQqFiI-a8faE0WLSBBtFxMctGkEN8SVEJX68=.58ab28f2-a0b5-44f9-9c72-c00c428fbf5d@github.com>

On Wed, 18 May 2022 21:47:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This PR adds an optional description accessor on `ToolProvider` interface.
>> 
>> This PR also adds short description for each of the listed tool:
>> - `jar`
>> - `javac`
>> - `javadoc`
>> - `javap` and `jdeps`
>> - `jlink` and `jmod`
>> - `jpackage`
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavacToolProvider.java line 30:
> 
>> 28: import com.sun.tools.javac.util.JavacMessages;
>> 29: import java.io.PrintWriter;
>> 30: import java.util.Optional;
> 
> at least in javac, we normally sort `java.*` and `javax.*` imports before other imports.

Sorted imports accordingly.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 387:
> 
>> 385: 
>> 386: javac.description=Read Java declarations and compile them into class files
>> 387: 
> 
> for your general consideration, what grammatical style do you recommend here? Should it be 3rd person (Reads) instead of 2nd person (Read)

I took the phrases in 2nd person style from https://docs.oracle.com/en/java/javase/18/docs/specs/man/ as templates, shortening some of them to around 80 characters for better fitting in standard terminal widths.

Perhaps, those texts should be used "as-is" as descriptions?
- 2nd person phrase-style
- lowercase start
- no terminating period
- no shortening

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

PR: https://git.openjdk.java.net/jdk/pull/8772

From cstein at openjdk.java.net  Thu May 19 10:23:18 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 19 May 2022 10:23:18 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <M_RZg5YrQqFiI-a8faE0WLSBBtFxMctGkEN8SVEJX68=.58ab28f2-a0b5-44f9-9c72-c00c428fbf5d@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
 <hlEn3ZTHbWSOxF99IchuV-G64886D96b1n-pEs9zELk=.4ce40936-9982-4467-b424-c4a9e469824d@github.com>
 <M_RZg5YrQqFiI-a8faE0WLSBBtFxMctGkEN8SVEJX68=.58ab28f2-a0b5-44f9-9c72-c00c428fbf5d@github.com>
Message-ID: <-ELlQEdCsVQaXYzAcWjtGVe_m6v3KQNdRNvoGoLdAg4=.ae788c95-4a29-41f4-892b-8816ada0796b@github.com>

On Thu, 19 May 2022 06:21:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 387:
>> 
>>> 385: 
>>> 386: javac.description=Read Java declarations and compile them into class files
>>> 387: 
>> 
>> for your general consideration, what grammatical style do you recommend here? Should it be 3rd person (Reads) instead of 2nd person (Read)
>
> I took the phrases in 2nd person style from https://docs.oracle.com/en/java/javase/18/docs/specs/man/ as templates, shortening some of them to around 80 characters for better fitting in standard terminal widths.
> 
> Perhaps, those texts should be used "as-is" as descriptions?
> - 2nd person phrase-style
> - lowercase start
> - no terminating period
> - no shortening

Took the phrases "as-is" from the overview site for the man pages: [Java? Development Kit Version 18 Tool Specifications](https://docs.oracle.com/en/java/javase/18/docs/specs/man/)

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

PR: https://git.openjdk.java.net/jdk/pull/8772

From xuelei at openjdk.java.net  Thu May 19 14:58:48 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:48 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AEcXIgzPrzjMIYqVKaZBv2j_3w8nrjL-kejrZ0nvBGE=.cb7c63c7-8f32-4cfa-b7d5-e2bb84750add@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

The security/crypto parts look good to me.

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

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From xuelei at openjdk.java.net  Thu May 19 14:58:49 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
Message-ID: <lPlIgFLf96r_Xr7YJIr2w2uODPCG9bRPhAnl2tuAo50=.82a145da-9923-4c5b-a72d-14ba982bf303@github.com>

On Thu, 19 May 2022 09:31:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> Also, I fixed a couple of spelling mistakes.
>
> test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:
> 
>> 30: /*
>> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
>> 32:  * formatted individual sections in addition the main attributes tested
> 
> "in addition to the..."

+1.

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From darcy at openjdk.java.net  Thu May 19 15:53:53 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 19 May 2022 15:53:53 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <N4kdb-3lUkKifHbm_WTwVC6QMy0xz24f0nONPj_c4Go=.dbec1895-2e88-4ed4-ae23-ccb3717902c4@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8772

From abimpoudis at openjdk.java.net  Thu May 19 16:13:54 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 19 May 2022 16:13:54 GMT
Subject: Integrated: 8286797: Guards of constant value false are not permitted
In-Reply-To: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
References: <Pg3Zz_W7UmfjmuSa8BaL8in1OaJSVDBVOZ2pmUsVSLs=.ae1418f4-83b8-4ef8-92f6-1e385fdcb86b@github.com>
Message-ID: <Q7YV_dDrwCSG-CQ_ZmMyiUPASYwFgmEhDZwzsGogsHc=.92a7d686-d8c7-4364-835c-ddad6c5f9cd9@github.com>

On Tue, 17 May 2022 12:25:41 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Simple fix that addresses this line from the spec:
> 
>> It is a compile-time error if a when expression is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with the value false.
> 
> Extracts one small utility method `isBooleanWithValue` in `TreeInfo`.

This pull request has now been integrated.

Changeset: fd36f373
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fd36f3730ec92d39f81f9d6d4d2b976938ed44bd
Stats:     106 lines in 9 files changed: 100 ins; 0 del; 6 mod

8286797: Guards of constant value false are not permitted

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8745

From jjg at openjdk.java.net  Thu May 19 16:18:07 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 19 May 2022 16:18:07 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <hf-SWZHrw3jYIJYNiqTkIhcgImjG-mDCDW9yLpwP0xM=.83a26877-1f78-4341-ab1d-cf4a59f083aa@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8772

From lancea at openjdk.java.net  Thu May 19 16:18:09 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 May 2022 16:18:09 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <VOI91dj04QvIFqK2rf7HX06_cCyg5sBSQa5afr9gkLY=.a80aeddb-ff8c-4287-bb48-9ea187e2682e@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

Marked as reviewed by lancea (Reviewer).

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 28:

> 26: ## tool
> 27: 
> 28: jar.description=create an archive for classes and resources, and manipulate or restore individual classes or resources from an archive

Not sure I love the use of  _manipulate_ but I understand that this is the wording from the tools guide for jar.

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

PR: https://git.openjdk.java.net/jdk/pull/8772

From darcy at openjdk.java.net  Thu May 19 18:02:24 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 19 May 2022 18:02:24 GMT
Subject: RFR: JDK-8284966: Update SourceVersion.RELEASE_19 description for
 language changes
Message-ID: <4siljdpcfgfvfIlKbRI1bx1GCY4XlbyNsSk2e_IaGw4=.dcf23d61-b841-429a-bb3a-3a1b3f1b553b@github.com>

Updating the description of RELEASE_19 for the anticipated language changes in Java SE 19. I'll defer pushing until the proposed-to-target record patterns compiler changes are pushed. Also adding links to the JSR 269 API in the package info files.

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

Commit messages:
 - JDK-8284966: Update SourceVersion.RELEASE_19 description for language changes

Changes: https://git.openjdk.java.net/jdk/pull/8793/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8793&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284966
  Stats: 19 lines in 6 files changed: 16 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8793.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8793/head:pull/8793

PR: https://git.openjdk.java.net/jdk/pull/8793

From cstein at openjdk.java.net  Thu May 19 18:28:47 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 19 May 2022 18:28:47 GMT
Subject: Integrated: 8286654: Add an optional description accessor on
 ToolProvider interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <XcuML4Z4r0O8ohv_AVFE62qVcR-B23LcuCDiq_LqadQ=.64317df3-3e07-42b9-84c2-f1da946384c8@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

This pull request has now been integrated.

Changeset: 655500a4
Author:    Christian Stein <cstein at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/655500a4f5e3abcff176599604deceefb6ca6640
Stats:     115 lines in 19 files changed: 97 ins; 2 del; 16 mod

8286654: Add an optional description accessor on ToolProvider interface

Reviewed-by: jjg, darcy, lancea

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

PR: https://git.openjdk.java.net/jdk/pull/8772

From aivanov at openjdk.java.net  Thu May 19 18:54:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:54:04 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <De1XJE92ZHSiL99Rs-yvnD30-uzxuj4sfIn432JAocM=.2d3d0f7a-8c35-4575-aa20-1ccc267021c4@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:

 - ...set to the values...
 - ...will result in a Zip64 Extra (EXT) header
 - ...in addition to the main attributes...
 - ...and the address of the current archive
 - Merges the stack at the given bci...
 - Returns a single ...
 - ...when a peer shuts down an association.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/c7e73658..0669cdc1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 18:59:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:59:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
Message-ID: <bBFati7RKtrl5FcrKP4_YCSO34DZrrIX7b_Daw9f91E=.dbbf28d9-92ef-4ae1-950c-f34036d483e4@github.com>

On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:
> 
>> 346: 
>> 347:     /**
>> 348:      * Returns the single non-abstract {@link Method} visible from
> 
> I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

I've accepted it, yet I'm still unsure whether ?a? or ?the??

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 19:06:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 19:06:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
Message-ID: <Hm4DXlPz0QuS87RjrcFEwxyh-97burW3YzckN3z0aGM=.6c816cc2-3256-4b2c-87d7-c2206b9f9a39@github.com>

On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

Thank you @kevinjwalls for your suggestions. I've incorporated them.

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From jjg at openjdk.java.net  Thu May 19 22:13:29 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 19 May 2022 22:13:29 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
Message-ID: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>

Please review a test-only fix to make a recent new test more robust.

The test was not fundamentally broken, so the essential functionality remains the same. However, it does assume access to the `src/jdk.javadoc` directory, and crashed when that was not available.

The mitigation is two-fold: 

1. introduce and use a new `SnippetUtils.ConfigurationException` that is thrown when the test cannot find the necessary directories.
2. introduce and use 2 new test-suite keywords, `needs-src` `needs-src-jdk_javadoc` that can be used on the jtreg command-line to filter out this test, and any similar tests in the future.

Tested locally, manually, by temporarily renaming key directories, to test the different code paths.  In all cases, if the test is run and any necessary directories are missing, the test _will still fail_, but now with a more useful and specific exception and detail message.

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

Commit messages:
 - JDK-8279513: jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after 8278795

Changes: https://git.openjdk.java.net/jdk/pull/8796/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8796&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279513
  Stats: 44 lines in 3 files changed: 37 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8796.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8796/head:pull/8796

PR: https://git.openjdk.java.net/jdk/pull/8796

From iris at openjdk.java.net  Fri May 20 03:35:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 20 May 2022 03:35:40 GMT
Subject: RFR: JDK-8284966: Update SourceVersion.RELEASE_19 description for
 language changes
In-Reply-To: <4siljdpcfgfvfIlKbRI1bx1GCY4XlbyNsSk2e_IaGw4=.dcf23d61-b841-429a-bb3a-3a1b3f1b553b@github.com>
References: <4siljdpcfgfvfIlKbRI1bx1GCY4XlbyNsSk2e_IaGw4=.dcf23d61-b841-429a-bb3a-3a1b3f1b553b@github.com>
Message-ID: <bBB1L6CUWledBF5_WtpmBGgpnVs5CzqU4ue4dkEbdCY=.2c9d7012-e875-4f0e-83f0-53998df6752e@github.com>

On Thu, 19 May 2022 17:56:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Updating the description of RELEASE_19 for the anticipated language changes in Java SE 19. I'll defer pushing until the proposed-to-target record patterns compiler changes are pushed. Also adding links to the JSR 269 API in the package info files.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8793

From ihse at openjdk.java.net  Fri May 20 08:42:44 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 20 May 2022 08:42:44 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <RmHbfRXO30BBvfEUmUW7R2l6YV8gOypiJVRi-E1Z40E=.2275399d-8168-4fd2-8f39-2a6be94db1db@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Build changes look good. Thanks for the cleanup!

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From jlahoda at openjdk.java.net  Fri May 20 18:20:58 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 20 May 2022 18:20:58 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <O1fTVr3kJlmiqfPjj74P29-2u9nnr6paGQFlVD4sl7w=.f049b649-fe9f-401c-b641-17b66d1a7edc@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

FWIW, if adding this dependency would be seen unacceptable, we could try to tweak jlink to at least produce a warning when building an image with jdk.compiler but without jdk.zipfs.

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From prappo at openjdk.java.net  Fri May 20 21:07:24 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 20 May 2022 21:07:24 GMT
Subject: RFR: 8287099: Clean up terminology regarding doc comment descriptions.
Message-ID: <-qp2x8_R1brPKsIPjnzpaq0yJOVp84v70_Jthyi0_Sk=.43673878-964a-4534-a959-9eca32bc3043@github.com>

Use the term "main description".

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

Commit messages:
 - Update copyright years
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8818/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8818&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287099
  Stats: 11 lines in 6 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8818/head:pull/8818

PR: https://git.openjdk.java.net/jdk/pull/8818

From jjg at openjdk.java.net  Fri May 20 21:07:24 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 20 May 2022 21:07:24 GMT
Subject: RFR: 8287099: Clean up terminology regarding doc comment
 descriptions.
In-Reply-To: <-qp2x8_R1brPKsIPjnzpaq0yJOVp84v70_Jthyi0_Sk=.43673878-964a-4534-a959-9eca32bc3043@github.com>
References: <-qp2x8_R1brPKsIPjnzpaq0yJOVp84v70_Jthyi0_Sk=.43673878-964a-4534-a959-9eca32bc3043@github.com>
Message-ID: <9_nBOPbxySyZ-wzckMZPoyL1U2TS7JgtB6cW8HSWKCo=.29b0300a-2ad0-4fe7-abff-f1ef57bd7dcf@github.com>

On Fri, 20 May 2022 20:55:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Use the term "main description".

Approved.

To be clear, I think we should keep the unadorned term _description_ for any narrative description in any possible, and that we should use _main description_ for the content before any block tags.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8818

From jpai at openjdk.java.net  Sat May 21 02:24:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 21 May 2022 02:24:40 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <fg6ldLSMxzqXQS89VUmjFy-hfR_sbyp0XzidZz0xWUM=.e13ab158-02a0-4f16-aeac-0c400286a826@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

Thank you for changing the description of the test. That part now looks fine to me.

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From prappo at openjdk.java.net  Sat May 21 08:51:40 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 21 May 2022 08:51:40 GMT
Subject: Integrated: 8287099: Clean up terminology regarding doc comment
 descriptions.
In-Reply-To: <-qp2x8_R1brPKsIPjnzpaq0yJOVp84v70_Jthyi0_Sk=.43673878-964a-4534-a959-9eca32bc3043@github.com>
References: <-qp2x8_R1brPKsIPjnzpaq0yJOVp84v70_Jthyi0_Sk=.43673878-964a-4534-a959-9eca32bc3043@github.com>
Message-ID: <IYCIXwBdNsrlSMqZhr0QTjbtvCcYE-4Qb2FAgOzt9JI=.9e6607b1-f559-4d2c-863f-42a26137ad50@github.com>

On Fri, 20 May 2022 20:55:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Use the term "main description".

This pull request has now been integrated.

Changeset: 7c086475
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7c0864752aa6301ec5a2123a5a96eb71bc0a83af
Stats:     11 lines in 6 files changed: 0 ins; 0 del; 11 mod

8287099: Clean up terminology regarding doc comment descriptions.

Reviewed-by: jjg

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

PR: https://git.openjdk.java.net/jdk/pull/8818

From plevart at openjdk.java.net  Sun May 22 16:57:50 2022
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 22 May 2022 16:57:50 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

My humble opinion: if java.compiler needs jdk.zipfs for full functionality (i.e. using --source N or --release X), does that mean java.compiler is useless without jdk.zipfs? If there is a meaningful functionality left in java.compiler even without jdk.zipfs, then someone might want to use that limited subset of functionality and might not want to include jdk.zipfs in its image.
So what is possible to do with java.compiler without jdk.zipfs?

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From plevart at openjdk.java.net  Sun May 22 17:07:44 2022
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 22 May 2022 17:07:44 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
 <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>
Message-ID: <X6bZR1w_7ORxLKR--p3kNLM-cqmKIThAU3OV2aJohWQ=.902cf742-280e-4d59-9990-636adda62c1b@github.com>

On Sun, 22 May 2022 16:54:25 GMT, Peter Levart <plevart at openjdk.org> wrote:

> My humble opinion: if java.compiler needs jdk.zipfs for full functionality....

Sorry, I wrongly assumed it was `java.compiler` (the library module), but this is about `jdk.compiler` (the tool)... Nevertheless, the same question applies: Does `jdk.compiler` have any meaningful functionality even without `jdk.zipfs` ?

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From asotona at openjdk.java.net  Mon May 23 07:33:37 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 07:33:37 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <X6bZR1w_7ORxLKR--p3kNLM-cqmKIThAU3OV2aJohWQ=.902cf742-280e-4d59-9990-636adda62c1b@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
 <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>
 <X6bZR1w_7ORxLKR--p3kNLM-cqmKIThAU3OV2aJohWQ=.902cf742-280e-4d59-9990-636adda62c1b@github.com>
Message-ID: <Q0qA-WGcGFlsJ0qGFSl5-QpDNMaGW_cNfzeHUCIY8Wk=.f941db3d-646d-4247-8e78-65a74b88fe87@github.com>

On Sun, 22 May 2022 17:04:30 GMT, Peter Levart <plevart at openjdk.org> wrote:

> > My humble opinion: if java.compiler needs jdk.zipfs for full functionality....
> 
> Sorry, I wrongly assumed it was `java.compiler` (the library module), but this is about `jdk.compiler` (the tool)... Nevertheless, the same question applies: Does `jdk.compiler` have any meaningful functionality even without `jdk.zipfs` ?

Basic compilation works even without presence of jdk.zipfs, however such stripped JDK is for example unable to read jar files on classpath.

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From alanb at openjdk.java.net  Mon May 23 08:21:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 08:21:40 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <Q0qA-WGcGFlsJ0qGFSl5-QpDNMaGW_cNfzeHUCIY8Wk=.f941db3d-646d-4247-8e78-65a74b88fe87@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
 <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>
 <X6bZR1w_7ORxLKR--p3kNLM-cqmKIThAU3OV2aJohWQ=.902cf742-280e-4d59-9990-636adda62c1b@github.com>
 <Q0qA-WGcGFlsJ0qGFSl5-QpDNMaGW_cNfzeHUCIY8Wk=.f941db3d-646d-4247-8e78-65a74b88fe87@github.com>
Message-ID: <_si3TMfeqHv-HR4Py0KhM2MKJRqOt1hILTuHLThFEu0=.9f38b4d5-158e-4361-8024-814e720e195a@github.com>

On Mon, 23 May 2022 07:29:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Sorry, I wrongly assumed it was `java.compiler` (the library module), but this is about `jdk.compiler` (the tool)... Nevertheless, the same question applies: Does `jdk.compiler` have any meaningful functionality even without `jdk.zipfs` ?

This came up in JDK 9 and the decision at the time was not to require jdk.zipfs as it's a service provider module. The addition of the source launcher, the addition of --enable-preview, and more use of --release N means more ct.sym usage. It probably isn't too interesting to have a small runtime image that contains jdk.compiler and not jdk.zipfs so Adam's proposal mightn't be too bad, it's just a bit weird and not something that we'd want other libraries in the eco system to do.

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From ihse at openjdk.java.net  Mon May 23 10:12:29 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 23 May 2022 10:12:29 GMT
Subject: RFR: 8287155: Additional make typos
Message-ID: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com>

Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though.

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

Commit messages:
 - 8287155: Additional make typos

Changes: https://git.openjdk.java.net/jdk/pull/8837/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8837&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287155
  Stats: 15 lines in 13 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8837.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8837/head:pull/8837

PR: https://git.openjdk.java.net/jdk/pull/8837

From mcimadamore at openjdk.java.net  Mon May 23 10:27:56 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 May 2022 10:27:56 GMT
Subject: RFR: 8286391: Address possibly lossy conversions in jdk.compiler
In-Reply-To: <jDtcjqvMcNT5ncPyOpSatpD8wfTBXiq8d0_6y6LFnLc=.e72f3f90-4771-43ee-9da6-c36ef80a1221@github.com>
References: <jDtcjqvMcNT5ncPyOpSatpD8wfTBXiq8d0_6y6LFnLc=.e72f3f90-4771-43ee-9da6-c36ef80a1221@github.com>
Message-ID: <zgZJg33h6GMbu-5rh_9vS6OvBIYri6wpb-2v9ZDRsqk=.09d6f331-efcb-4ee6-b00d-c120601189d1@github.com>

On Wed, 11 May 2022 13:20:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is a part of addressing of all possibly lossy conversions in compound assignments across JDK sources.
> Two cases have been found in jdk.compiler and they are addressed by this patch.
> One case in ClassWriter is resolved by changing local variable from char to int type to avoid multiple implicit and explicit conversions.
> Second case in Code is resolved by making the implicit conversion from int to char explicit.
> 
> Please review.
> 
> Thanks,
> Adam

Looks good. One possible fix for `adjustFlags` could be to declare all the public facing flags (e.g. ABSTRACT, INTERFACE, ...) to use a char/short instead of an int, so that the downstream code could be made tighter if required. But maybe we should attempt that as part of a more general revamp of the flag code.

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8652

From asotona at openjdk.java.net  Mon May 23 10:31:14 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 10:31:14 GMT
Subject: RFR: 8286391: Address possibly lossy conversions in jdk.compiler
In-Reply-To: <jDtcjqvMcNT5ncPyOpSatpD8wfTBXiq8d0_6y6LFnLc=.e72f3f90-4771-43ee-9da6-c36ef80a1221@github.com>
References: <jDtcjqvMcNT5ncPyOpSatpD8wfTBXiq8d0_6y6LFnLc=.e72f3f90-4771-43ee-9da6-c36ef80a1221@github.com>
Message-ID: <v9X1B9kwTSTU6JcmivAmRpXv4vAqDUlTSHX8CMizRCs=.adbae2d8-716d-4f9e-b7f9-0595ed408410@github.com>

On Wed, 11 May 2022 13:20:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is a part of addressing of all possibly lossy conversions in compound assignments across JDK sources.
> Two cases have been found in jdk.compiler and they are addressed by this patch.
> One case in ClassWriter is resolved by changing local variable from char to int type to avoid multiple implicit and explicit conversions.
> Second case in Code is resolved by making the implicit conversion from int to char explicit.
> 
> Please review.
> 
> Thanks,
> Adam

Thank you!

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

PR: https://git.openjdk.java.net/jdk/pull/8652

From asotona at openjdk.java.net  Mon May 23 10:33:02 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 10:33:02 GMT
Subject: Integrated: 8286391: Address possibly lossy conversions in
 jdk.compiler
In-Reply-To: <jDtcjqvMcNT5ncPyOpSatpD8wfTBXiq8d0_6y6LFnLc=.e72f3f90-4771-43ee-9da6-c36ef80a1221@github.com>
References: <jDtcjqvMcNT5ncPyOpSatpD8wfTBXiq8d0_6y6LFnLc=.e72f3f90-4771-43ee-9da6-c36ef80a1221@github.com>
Message-ID: <Nuk4UWAITKQZkj5jNzPws9i4_mHTfrH1SzOm2Io6rpM=.30456712-5eec-41a8-9a2a-101044233bcb@github.com>

On Wed, 11 May 2022 13:20:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is a part of addressing of all possibly lossy conversions in compound assignments across JDK sources.
> Two cases have been found in jdk.compiler and they are addressed by this patch.
> One case in ClassWriter is resolved by changing local variable from char to int type to avoid multiple implicit and explicit conversions.
> Second case in Code is resolved by making the implicit conversion from int to char explicit.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: c9065915
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c9065915b6063aeed5e9c50aebb245a64b425f17
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8286391: Address possibly lossy conversions in jdk.compiler

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.java.net/jdk/pull/8652

From asotona at openjdk.java.net  Mon May 23 10:40:40 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 10:40:40 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v9]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <W_1U5L9wg5OtyL_Ar1-3297-G3AA7DQKexeRB1qm6D8=.cf6451b5-559d-4d20-b3d6-b294f5b1cf06@github.com>

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

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

 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c9065915...455720ef

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

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08
  Stats: 441 lines in 18 files changed: 438 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Mon May 23 11:02:32 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 11:02:32 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v10]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <BjXRwHICfpOB1Ol2lbijomFjPYp0eaUL2Y2NRkHYuRQ=.346a7ec5-96ed-48a3-9c36-af1aea010a8e@github.com>

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

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/455720ef..4978c2a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08-09

  Stats: 5 lines in 3 files changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From shade at openjdk.java.net  Mon May 23 15:13:05 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 15:13:05 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration
Message-ID: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>

[JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.

Additional testing:
 - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
 - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
 - [x] Linux x86_32 fastdebug `tier3` (clean now)
 - [ ] GHA run

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

Commit messages:
 - Updates
 - Revert test groups
 - Fix 2
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/8843/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287137
  Stats: 276 lines in 3 files changed: 276 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8843/head:pull/8843

PR: https://git.openjdk.java.net/jdk/pull/8843

From alanb at openjdk.java.net  Mon May 23 15:15:09 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 15:15:09 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>

On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [ ] GHA run

test/jdk/ProblemList.txt line 894:

> 892: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java  8286642 generic-i586
> 893: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java          8286642 generic-i586
> 894: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java  8286642 generic-i586

I'm surprised that the stream tests are included as they don't run with --enable-preview.

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From shade at openjdk.java.net  Mon May 23 15:21:41 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 15:21:41 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
Message-ID: <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>

On Mon, 23 May 2022 15:13:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [ ] GHA run
>
> test/jdk/ProblemList.txt line 894:
> 
>> 892: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java  8286642 generic-i586
>> 893: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java          8286642 generic-i586
>> 894: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java  8286642 generic-i586
> 
> I'm surprised that the stream tests are included as they don't run with --enable-preview.

Those tests *do* run with preview enabled: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11 -- and I know that because I basically copy-pasted all jtreg failures that lead to `Unimplemented()` in x86_32 code.

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From prr at openjdk.java.net  Mon May 23 15:28:56 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 23 May 2022 15:28:56 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <ZxzsiPHBQGnGxXkuOz4eYvoGkjhwizLhmwFLUUZidlE=.8cb8d8d2-40b3-4dc7-9511-f6c0e5e88af2@github.com>

On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [ ] GHA run

I agree this is better than disabling the entire GHA

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8843

From alanb at openjdk.java.net  Mon May 23 15:39:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 15:39:40 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
 <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>
Message-ID: <j6KHk-lOPx98mqZVOA9lXXuEtTuIfK1N3M3afPC2qs8=.9b0ccab0-c3ba-4866-9d47-5812316be121@github.com>

On Mon, 23 May 2022 15:18:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 894:
>> 
>>> 892: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java  8286642 generic-i586
>>> 893: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java          8286642 generic-i586
>>> 894: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java  8286642 generic-i586
>> 
>> I'm surprised that the stream tests are included as they don't run with --enable-preview.
>
> Those tests *do* run with preview enabled: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11 -- and I know that because I basically copy-pasted all jtreg failures that lead to `Unimplemented()` in x86_32 code.

Okay, so the issue is SpliteratorTest uses preview APIs and having the configuration in TEST.properties means that all the streams tests are run with this option.

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From shade at openjdk.java.net  Mon May 23 15:39:40 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 15:39:40 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <j6KHk-lOPx98mqZVOA9lXXuEtTuIfK1N3M3afPC2qs8=.9b0ccab0-c3ba-4866-9d47-5812316be121@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
 <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>
 <j6KHk-lOPx98mqZVOA9lXXuEtTuIfK1N3M3afPC2qs8=.9b0ccab0-c3ba-4866-9d47-5812316be121@github.com>
Message-ID: <a8vijo-jBGq72_Ub_hdAjQUhKVMAIzF4uV29CNQbIZo=.0a52e702-e95b-409f-86d7-8b980a3351e3@github.com>

On Mon, 23 May 2022 15:34:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Those tests *do* run with preview enabled: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11 -- and I know that because I basically copy-pasted all jtreg failures that lead to `Unimplemented()` in x86_32 code.
>
> Okay, so the issue is SpliteratorTest uses preview APIs and having the configuration in TEST.properties means that all the streams tests are run with this option.

Yes, `TEST.properties` is way too broad. I'd keep the current patch as is, instead of trying to fix that one. I suspect there is some funky TestNG/othervm interaction going...

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From mcimadamore at openjdk.java.net  Mon May 23 16:50:50 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 May 2022 16:50:50 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <a8vijo-jBGq72_Ub_hdAjQUhKVMAIzF4uV29CNQbIZo=.0a52e702-e95b-409f-86d7-8b980a3351e3@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
 <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>
 <j6KHk-lOPx98mqZVOA9lXXuEtTuIfK1N3M3afPC2qs8=.9b0ccab0-c3ba-4866-9d47-5812316be121@github.com>
 <a8vijo-jBGq72_Ub_hdAjQUhKVMAIzF4uV29CNQbIZo=.0a52e702-e95b-409f-86d7-8b980a3351e3@github.com>
Message-ID: <HxvJ78fLsFmgrtMkO8FS3Kc-QWvnR6_WNMtTdYum6Nw=.f5d754f0-6800-478d-8f13-2fdd419d558c@github.com>

On Mon, 23 May 2022 15:36:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Okay, so the issue is SpliteratorTest uses preview APIs and having the configuration in TEST.properties means that all the streams tests are run with this option.
>
> Yes, `TEST.properties` is way too broad. I'd keep the current patch as is, instead of trying to fix that one. I suspect there is some funky TestNG/othervm interaction going...

These specific stream tests are odd, in the sense that they live in a test root that is TestNG and they are only "imported" into jtreg. The toplevel TEST.properties file gets only once chance to set the correct parameters, for all tests. I've tried adding more local flags, nearer to the test, w/o success. I'm obviously happy to do it another way.

I have tried adding a jtreg header in that test, but that doesn't fix the problem - because _all_ the tests are passed to testng at once, which compiles them and runs them. So either the flag is present when that happens, or it is ignored.

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From shade at openjdk.java.net  Mon May 23 17:16:28 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 17:16:28 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v2]
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <t9frIICDowzgXUtOZMbKamViP3qgG9D_cLOVpWWmumI=.1ebc7b02-65eb-46b1-851b-f7ae1a30681e@github.com>

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [ ] GHA run

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

 - Fix the tests in release JDKs
 - Merge branch 'master' into JDK-8287137-problemlist-x86_32
 - Updates
 - Revert test groups
 - Fix 2
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8843/files
  - new: https://git.openjdk.java.net/jdk/pull/8843/files/ba5c631e..5a0cd8fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=00-01

  Stats: 4568 lines in 145 files changed: 2586 ins; 1656 del; 326 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8843/head:pull/8843

PR: https://git.openjdk.java.net/jdk/pull/8843

From shade at openjdk.java.net  Mon May 23 18:25:23 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 18:25:23 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [ ] GHA run

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Another release test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8843/files
  - new: https://git.openjdk.java.net/jdk/pull/8843/files/5a0cd8fe..e223e211

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From lancea at openjdk.java.net  Mon May 23 20:03:55 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 23 May 2022 20:03:55 GMT
Subject: RFR: 8287155: Additional make typos
In-Reply-To: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com>
References: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com>
Message-ID: <gOnmPu2PT1I64JzZkR9Td89HIfp1DoqKe-gNDkHzwSE=.84f61038-3294-4328-87a0-cacdf00b0afa@github.com>

On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8837

From aivanov at openjdk.java.net  Mon May 23 20:06:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:06:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v3]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <3E93xe0v68L9AHsT3c5D58_5OdaSDEGtdg5ih7TTkfk=.45bed80f-be56-49e8-9dfb-a7fa70b9ea23@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright to 2022

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01-02

  Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From iris at openjdk.java.net  Mon May 23 20:35:56 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 23 May 2022 20:35:56 GMT
Subject: RFR: 8287155: Additional make typos
In-Reply-To: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com>
References: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com>
Message-ID: <oPPj0kOoMmLMwZOGD6ia2_oI0EjY0DAPyFdUceLAEjQ=.4d32011b-4bfb-4328-abab-8fd8f3a01430@github.com>

On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8837

From aivanov at openjdk.java.net  Mon May 23 20:46:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:46:23 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
 [v2]
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <6pmdug3Hpy1LPgcb-OIdMP6XuOWpWYngOju7mFPdDV4=.a68d1c15-58a3-4ffa-b94d-a1a14666f9eb@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge master
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'an? an?' in source code
 - 8284209: Replace remaining usages of 'a the' in source code
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/5b7d066c...fab0a4bb

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

Changes: https://git.openjdk.java.net/jdk/pull/8771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01
  Stats: 50 lines in 40 files changed: 0 ins; 2 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From jjg at openjdk.java.net  Mon May 23 20:47:49 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 23 May 2022 20:47:49 GMT
Subject: RFR: JDK-8284966: Update SourceVersion.RELEASE_19 description for
 language changes
In-Reply-To: <4siljdpcfgfvfIlKbRI1bx1GCY4XlbyNsSk2e_IaGw4=.dcf23d61-b841-429a-bb3a-3a1b3f1b553b@github.com>
References: <4siljdpcfgfvfIlKbRI1bx1GCY4XlbyNsSk2e_IaGw4=.dcf23d61-b841-429a-bb3a-3a1b3f1b553b@github.com>
Message-ID: <l4Hu48UFfGYcb56_25VEfvCWYKpm47LRrBFNfj33dTk=.9e9d8795-7d65-4acd-8160-4fe1b0ca9ae9@github.com>

On Thu, 19 May 2022 17:56:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Updating the description of RELEASE_19 for the anticipated language changes in Java SE 19. I'll defer pushing until the proposed-to-target record patterns compiler changes are pushed. Also adding links to the JSR 269 API in the package info files.

LGTM

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8793

From ihse at openjdk.java.net  Mon May 23 21:00:56 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 23 May 2022 21:00:56 GMT
Subject: Integrated: 8287155: Additional make typos
In-Reply-To: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com>
References: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com>
Message-ID: <IOuaPkutEIfc-POzdm3XqlDjbw7ZYibgxMQ5ua-uylU=.e1b1138c-4f65-4619-93ff-96a225450152@github.com>

On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though.

This pull request has now been integrated.

Changeset: 02fec1e6
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02fec1e6e5b6728c13763718c98cf5db68b1cce3
Stats:     15 lines in 13 files changed: 0 ins; 0 del; 15 mod

8287155: Additional make typos

Reviewed-by: lancea, iris

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

PR: https://git.openjdk.java.net/jdk/pull/8837

From hannesgreule at outlook.de  Tue May 24 06:27:53 2022
From: hannesgreule at outlook.de (Hannes Greule)
Date: Tue, 24 May 2022 06:27:53 +0000
Subject: Mandated/implicit parameters
Message-ID: <AM0PR03MB4577A0135FC226906946623FAFD79@AM0PR03MB4577.eurprd03.prod.outlook.com>

Hi,
I came across an oddity when using the Parameter#isImplicit()[1] method. 
According to its documentation, it returns true if the parameter is implicitly
declared in source code. The JLS 13.1 point 12[2] says "A construct emitted by
a Java compiler must be marked as *mandated* if it corresponds to a formal
parameter declared implicitly in source code" with a list of such parameters.
However, it seems like the information is only embedded when compiling
with the -parameters flag.

>From my understanding of the given section in the JLS, the mandated flag
should *always* be emitted. Is this a bug, or am I missing something?

Looking into it a bit deeper, it also seems like the parameters of a compact
constructor for records are never marked as mandated, even when compiling with
the -parameters flag (but the MethodParameters attribute is always written 
or record constructors).

I collected some code and outputs here[3] to show the differences between
compiling with and without the -parameters flag for cases that shouldn't
be different from my understanding.

If those two observations are bugs, I'd like to try contributing fixes for
them (I already spent a fair amount of time on it). As I did not contribute
to the JDK before, I'd probably need some assistance. I got two experimental
fixes for each of the problems here[4][5].

Greetings
Hannes

[1] https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/reflect/Parameter.html#isImplicit()
[2] https://docs.oracle.com/javase/specs/jls/se18/html/jls-13.html#jls-13.1
[3] https://gist.github.com/SirYwell/33995f369608634f183419362ef3c828
[4] https://github.com/SirYwell/jdk/commit/5b71f4f144267757c645a41897142a395640af91
[5] https://github.com/SirYwell/jdk/commit/d06395bceb4b84afdb046db451f1e0b15da9f5a7

From shade at openjdk.java.net  Tue May 24 07:05:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 May 2022 07:05:49 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
Message-ID: <FesuBCg2Skfbo6BcpAiermc4X7t255Oa7gU3rYZS_ms=.a11a7113-1fa9-49d2-a566-44386018d104@github.com>

On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [x] GHA run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another release test

GHA run completes fine on x86_32. There are unrelated Windows x86_64 failures in javac land, to be handled separately. 

Please approve, @AlanBateman, @mcimadamore and others?

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From jlahoda at openjdk.java.net  Tue May 24 07:53:56 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 24 May 2022 07:53:56 GMT
Subject: RFR: 8286057: Make javac error on a generic enum friendlier [v4]
In-Reply-To: <w5q0E90E-XRE1AQt2NeLtJeDAOSHKUfYoKCtnuLyh3Q=.abe6b714-1cd7-4a8a-b94f-bae0ce2bb1ea@github.com>
References: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
 <w5q0E90E-XRE1AQt2NeLtJeDAOSHKUfYoKCtnuLyh3Q=.abe6b714-1cd7-4a8a-b94f-bae0ce2bb1ea@github.com>
Message-ID: <1CjMCVtnDyDW4E6LQnh3llyoGYPH82HZozdiIoVX9eY=.c4df0bce-edd3-4238-b6ef-32ee1fc898ed@github.com>

On Fri, 13 May 2022 14:27:55 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Improves the error message for generic enumerations.
>
> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Add precise error for enums with empty parameter lists

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8677

From mcimadamore at openjdk.java.net  Tue May 24 08:10:37 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 08:10:37 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
Message-ID: <bHiUdAZBz9ZlheIyGEwNibwc40zLEVeoC59cL5Ylaus=.7e77c753-a485-4482-a0c3-8e6a1612bfde@github.com>

On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [x] GHA run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another release test

Marked as reviewed by mcimadamore (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From alanb at openjdk.java.net  Tue May 24 09:46:34 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 09:46:34 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <FesuBCg2Skfbo6BcpAiermc4X7t255Oa7gU3rYZS_ms=.a11a7113-1fa9-49d2-a566-44386018d104@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
 <FesuBCg2Skfbo6BcpAiermc4X7t255Oa7gU3rYZS_ms=.a11a7113-1fa9-49d2-a566-44386018d104@github.com>
Message-ID: <dQ7MGIpcYunGjaTPzt_83AhLoAz9X-3y0BYxMIGDDeA=.0354b553-1f11-42fd-a28b-f9909ae57eca@github.com>

On Tue, 24 May 2022 07:01:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Please approve, @AlanBateman, @mcimadamore and others?

Okay with me.

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From aivanov at openjdk.java.net  Tue May 24 09:52:29 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 09:52:29 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
 [v3]
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <yDxT1sZCfM9b18MbUqSFDeyieqOfB5aBWMLKNxZEeYg=.8278ad27-ca58-4bf7-a236-d79604a6bff9@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright to 2022

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8771/files
  - new: https://git.openjdk.java.net/jdk/pull/8771/files/fab0a4bb..4d529f79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01-02

  Stats: 24 lines in 24 files changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From lancea at openjdk.java.net  Tue May 24 09:58:42 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 24 May 2022 09:58:42 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
 [v3]
In-Reply-To: <yDxT1sZCfM9b18MbUqSFDeyieqOfB5aBWMLKNxZEeYg=.8278ad27-ca58-4bf7-a236-d79604a6bff9@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
 <yDxT1sZCfM9b18MbUqSFDeyieqOfB5aBWMLKNxZEeYg=.8278ad27-ca58-4bf7-a236-d79604a6bff9@github.com>
Message-ID: <orVtBes_pss1zNktMdUeKjQeZmAHhREnRo2NXmb4Ip0=.deb262e2-aa59-4235-9308-4232698603d2@github.com>

On Tue, 24 May 2022 09:52:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> It's the last issue in the series, and it still touches different areas of the code.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright to 2022

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8771

From abimpoudis at openjdk.java.net  Tue May 24 10:34:39 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Tue, 24 May 2022 10:34:39 GMT
Subject: Integrated: 8286057: Make javac error on a generic enum friendlier
In-Reply-To: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
References: <AIWss3pfVx7yfXbxZPEhdkcFSPmXTKxHYwWAyUCmxRk=.3fcc0688-2c19-49a4-b02e-978ba9bd6f2e@github.com>
Message-ID: <s_4WXUAXGUQ3_y0tRXMC-dLP8NwWI3qpLCAYOKyMzys=.a303d580-d2cc-4765-a306-7fd5abdf7034@github.com>

On Thu, 12 May 2022 10:39:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Improves the error message for generic enumerations.

This pull request has now been integrated.

Changeset: 9473c383
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9473c383c6c18698c551172eb20e41737025cf44
Stats:     69 lines in 5 files changed: 69 ins; 0 del; 0 mod

8286057: Make javac error on a generic enum friendlier

Reviewed-by: jlahoda

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

PR: https://git.openjdk.java.net/jdk/pull/8677

From aivanov at openjdk.java.net  Tue May 24 11:28:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 11:28:50 GMT
Subject: Integrated: 8284191: Replace usages of 'a the' in hotspot and
 java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ZIBUrN38HimpUwfEYc-LwYC3gXjfDXNaD55bHE9PU2M=.87e99c4b-c1a3-47d4-9323-421efb88ed06@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

This pull request has now been integrated.

Changeset: e0d361ce
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0d361cea91d3dd1450aece73f660b4abb7ce5fa
Stats:     303 lines in 162 files changed: 0 ins; 11 del; 292 mod

8284191: Replace usages of 'a the' in hotspot and java.base

Reviewed-by: lancea, wetmore, naoto, iris, kevinw, xuelei

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From jlahoda at openjdk.java.net  Tue May 24 11:32:12 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 24 May 2022 11:32:12 GMT
Subject: RFR: 8286895: InternalError: Exception during analyze
Message-ID: <HKXEJFSXoG7-7etDL09p1Gb39cdb13XfIOIWJd0JOcQ=.f9b4cde4-9b24-48bf-b3e9-576601c538fa@github.com>

Consider code like:

Number n = 0;
if (!n instanceof Integer i) {}

javac parses this like:

Number n = 0;
if ((!n) instanceof Integer i) {}


This is obviously erroneous, and will report an error in `Attr`, but if this code gets to `Flow`, like in JShell, then it will split the `inits`/`uninits` of variables to the `true`/`false` inits while processing the unary negation. But, then, the `instanceof` operator will try to declare a variable, which will fail with on an assertion, as that shouldn't be done when the inits are split to `true`/`false`:

Caused by: java.lang.AssertionError
        at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
        at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
        at jdk.compiler/com.sun.tools.javac.util.Bits.excl(Bits.java:220)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.newVar(Flow.java:1883)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitVarDef(Flow.java:2261)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1027)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:444)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1743)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.visitBindingPattern(TreeScanner.java:307)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitBindingPattern(Flow.java:2848)
...


The proposed solution is to use `scanExpr` when handling the `instanceof`'s expression, which will merge the `true`/`false` inits, and let the variable be declared.

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

Commit messages:
 - 8286895: InternalError: Exception during analyze

Changes: https://git.openjdk.java.net/jdk/pull/8866/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8866&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286895
  Stats: 31 lines in 4 files changed: 30 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8866.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8866/head:pull/8866

PR: https://git.openjdk.java.net/jdk/pull/8866

From jlahoda at openjdk.java.net  Tue May 24 12:53:38 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 24 May 2022 12:53:38 GMT
Subject: RFR: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
Message-ID: <dqBbi4GOVqcPhe3rFaiTLomd7aHctz3GikhhDbAg41U=.ada60bff-e02b-4792-8a95-7623b40aa278@github.com>

Normally, a switch expression must yield a value. But, there are cases where the switch expression has a value in the javac frontend, but, due to optimizations, not when the code is generated. For example:

int i = 1 + switch (0) { default -> {if (true) throw new RuntimeException(); else yield 0; } };


javac will optimize the else section away, and the switch expression will always end abruptly. But, javac's simulated stack will still contain the left value of the binary operator, which will never be removed, and javac will consequently fail:

.java:2: error: Internal error: stack sim error on t()
    private void t() {
                     ^
1 error


The proposed solution is twofold:
- the throw statement/instruction should clear the stack, which adheres more closely to the runtime behavior of the instruction. This is the change in `Code`.
- skipping code generation for expressions when the code is not "alive", as such code does not have any sense. This is similar to how statements are generated. This is the change in `Gen`.

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

Commit messages:
 - 8276836: Error in javac caused by switch expression without result expressions: Internal error: stack sim error

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

PR: https://git.openjdk.java.net/jdk/pull/8867

From shade at openjdk.java.net  Tue May 24 14:14:09 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 May 2022 14:14:09 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
Message-ID: <EQqFzl8MKu9zhRWM17twQXqSkkRhVzvp5vhlMnTC7CI=.41d6ba8a-a243-493e-82e0-e87982d8658c@github.com>

On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [x] GHA run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another release test

Thank you!

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From shade at openjdk.java.net  Tue May 24 14:14:11 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 May 2022 14:14:11 GMT
Subject: Integrated: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <Uhj76EkIXsLMDEMaJaGnjwXXtupxq8vnKnDueEVcYKs=.c4c514eb-058d-47af-b98e-34023a306864@github.com>

On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [x] GHA run

This pull request has now been integrated.

Changeset: 0a82c4eb
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a82c4ebc3748f6dfbbcd72e4421fbe0ea89e0b0
Stats:     279 lines in 3 files changed: 279 ins; 0 del; 0 mod

8287137: Problemlist failing x86_32 tests after Loom integration

Reviewed-by: prr, mcimadamore

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From alex.buckley at oracle.com  Tue May 24 15:52:33 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 24 May 2022 08:52:33 -0700
Subject: Mandated/implicit parameters
In-Reply-To: <AM0PR03MB4577A0135FC226906946623FAFD79@AM0PR03MB4577.eurprd03.prod.outlook.com>
References: <AM0PR03MB4577A0135FC226906946623FAFD79@AM0PR03MB4577.eurprd03.prod.outlook.com>
Message-ID: <bf8d0723-91f5-b9b3-14d0-84d54a49ed04@oracle.com>

On 5/23/2022 11:27 PM, Hannes Greule wrote:
> I came across an oddity when using the Parameter#isImplicit()[1] method.
> According to its documentation, it returns true if the parameter is implicitly
> declared in source code. ...
> However, it seems like the information is only embedded when compiling
> with the -parameters flag.
> 
> From my understanding of the given section in the JLS, the mandated flag
> should *always* be emitted. Is this a bug, or am I missing something?

In principle, the isImplicit() status of a parameter at run time should 
not depend on whether -parameters was given at compile time. 
Unfortunately, the class file bit that records "implicitly declared", 
for use by isImplicit(), is located in the MethodParameters attribute 
(JVMS 4.7.24) that is only emitted when -parameters is given.

It would be legitimate to emit MethodParameters without -parameters, so 
as to record `final` and "implicitly declared" but not the parameter 
name, but at some cost to implementation complexity in java.lang.reflect.

> Looking into it a bit deeper, it also seems like the parameters of a compact
> constructor for records are never marked as mandated, even when compiling with
> the -parameters flag (but the MethodParameters attribute is always written
> or record constructors).

That is weird, and sounds like a javac bug.

Alex

From prappo at openjdk.java.net  Tue May 24 17:01:08 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 May 2022 17:01:08 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v4]
In-Reply-To: <madEVzus8seob93AWjKQ64ifJsgBG2oAHCDYgKyAFeQ=.acba30be-d45e-4533-a2bb-b7fe89f8a2d3@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <madEVzus8seob93AWjKQ64ifJsgBG2oAHCDYgKyAFeQ=.acba30be-d45e-4533-a2bb-b7fe89f8a2d3@github.com>
Message-ID: <mKQRviXwPn-dr76zrftsVtrMTaNZvLX8MJ8RcAz21_8=.8313e0e3-27bb-4a2e-9fc2-9e16df09ef09@github.com>

On Wed, 18 May 2022 18:43:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 302:

> 300:      * @since 19
> 301:      */
> 302:     default R visitSpec(SpecTree node, P p) {

Nit: this method breaks the alphabetic order of visitor methods. Although `visitOther` also breaks it, we should not address it in this PR.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 515:

> 513:      * {@inheritDoc}
> 514:      *
> 515:      * @param node {@inheritDoc}

There's something wrong with the `@implSpec` tags in this and the immediately following two methods. Might be an artifact of the patch.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1533:

> 1531:                 public DCTree parse(int pos) throws ParseException {
> 1532:                     skipWhitespace();
> 1533:                     DCText url = inlineWord();

Nit: call it `uri` for consistency.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 432:

> 430: doclet.extSpec.url.title=\
> 431:     url: {0}, title: "{1}"
> 432: 

Use `uri` in all 4 resources?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 1098:

> 1096: 
> 1097:     /**
> 1098:      * Argument for command-line option {@code --spec-base-URI}.

I think the option is lower-cased `--spec-base-uri`.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 2:

> 1: /*
> 2:  * Copyright (c) 2001, 2022, Oracle and/or its affiliates. All rights reserved.

2001?

test/langtools/tools/javac/diags/examples/NoTitle.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.

2012? Is it an old file from the previous incarnation of the `@spec` tag?

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From prappo at openjdk.java.net  Tue May 24 18:57:52 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 May 2022 18:57:52 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
Message-ID: <7Rx1OT6mafjK2LhreErbNltD6yXPWgY8376tIdE2VQ0=.a9759ed5-f1be-4424-b085-34209864317a@github.com>

On Thu, 19 May 2022 22:05:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a test-only fix to make a recent new test more robust.
> 
> The test was not fundamentally broken, so the essential functionality remains the same. However, it does assume access to the `src/jdk.javadoc` directory, and crashed when that was not available.
> 
> The mitigation is two-fold: 
> 
> 1. introduce and use a new `SnippetUtils.ConfigurationException` that is thrown when the test cannot find the necessary directories.
> 2. introduce and use 2 new test-suite keywords, `needs-src` `needs-src-jdk_javadoc` that can be used on the jtreg command-line to filter out this test, and any similar tests in the future.
> 
> Tested locally, manually, by temporarily renaming key directories, to test the different code paths.  In all cases, if the test is run and any necessary directories are missing, the test _will still fail_, but now with a more useful and specific exception and detail message.

test/langtools/jdk/javadoc/doclet/testDocletExample/TestDocletExample.java line 71:

> 69:         var entryPointSnippet = snippets.getSnippetById(dc, "entry-point");
> 70:         if (entryPointSnippet == null) {
> 71:             throw new Error("Cannot find snippet \"entry-point\"");

I understand it as follows. Although this code now throws generic `Error` instead of `NullPointerException`, which the bug reporter observed, we shouldn't see that `Error` in circumstances similar to those of bug reporter. This is because in those circumstances the code will throw `ConfigurationException` earlier, at construction time, so we won't reach this check. Do I understand it correctly?

test/langtools/jdk/javadoc/doclet/testDocletExample/TestDocletExample.java line 97:

> 95:         var dc = snippets.getDocTrees().getDocCommentTree(docletPkg);
> 96:         var exampleSnippet = snippets.getSnippetById(dc, "Example.java");
> 97:         if (exampleSnippet == null) {

Same as above.

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

PR: https://git.openjdk.java.net/jdk/pull/8796

From prappo at openjdk.java.net  Tue May 24 19:32:11 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 May 2022 19:32:11 GMT
Subject: RFR: JDK-8286101: Support formatting in @value tag [v3]
In-Reply-To: <CWdwdv2SqEzApFSmzK-NUF81hrLkl3xuPtRY0s5lo_Q=.fec3fd71-a560-4817-b1bf-639ff62ca167@github.com>
References: <ZBy1vKfqdglw0yUg2kx6XOibuOCGv_wplnqLEn9joL4=.6780ee6e-f59a-4e02-b465-ecacb0a3c4f7@github.com>
 <CWdwdv2SqEzApFSmzK-NUF81hrLkl3xuPtRY0s5lo_Q=.fec3fd71-a560-4817-b1bf-639ff62ca167@github.com>
Message-ID: <ZdcXGXnG_IrSL-pb-sTRqk0wyKgaSyKifbPyt9UQ9E4=.e9ddbbb5-5965-440f-8a61-a77a5b68a29e@github.com>

On Tue, 17 May 2022 23:14:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This PR is for an update to the doc comment `{@value}` tag to permit an optional [format string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html#syntax) after the name of the tag.
>> 
>>     {@value optional-format-string optional-reference}
>> 
>> If given, the format string should either begin with `%` or the string should be quoted with `"`. For example, `%4x` or `"0x%4x"`.  The format string must contain exactly one `%` character.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - fix typo
>  - Merge remote-tracking branch 'upstream/master' into 8286101.format-at-value
>  - address review feedback
>  - address review feedback
>  - Merge remote-tracking branch 'upstream/master' into 8286101.format-at-value
>  - JDK-8286101: Support formatting in @value tag

Marked as reviewed by prappo (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8565

From jjg at openjdk.java.net  Tue May 24 19:50:41 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 May 2022 19:50:41 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v5]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <QugI_mfqGj9AfgThFTp0QzwO7VlRTHuxYicb4dqHtoM=.97923858-872c-4b5f-993f-75a2aaa05ca6@github.com>

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

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

 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - address review feedback
 - fix merge issues
 - merge with upstream/master
 - fix whitespace and position of HtmlStyle.refList
 - fix whitespace
 - JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec)

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

Changes: https://git.openjdk.java.net/jdk/pull/8439/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=04
  Stats: 1530 lines in 40 files changed: 1502 ins; 3 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8439/head:pull/8439

PR: https://git.openjdk.java.net/jdk/pull/8439

From aivanov at openjdk.java.net  Tue May 24 20:12:09 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 20:12:09 GMT
Subject: Integrated: 8284209: Replace remaining usages of 'a the' in source
 code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <JXgQy5enWm0flv2yyi6KK36WsHpPuZHj8uhkz_P13H0=.b9d1bc0a-ad41-416a-ab60-22c8271b9413@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

This pull request has now been integrated.

Changeset: 9b7e42c0
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9b7e42c0f078db778dda1011d85cd92e3e4eb979
Stats:     74 lines in 40 files changed: 0 ins; 2 del; 72 mod

8284209: Replace remaining usages of 'a the' in source code

Reviewed-by: lancea, wetmore, dfuchs, iris, jjg, ihse

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

PR: https://git.openjdk.java.net/jdk/pull/8771

From jjg at openjdk.java.net  Tue May 24 21:07:54 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 May 2022 21:07:54 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v4]
In-Reply-To: <mKQRviXwPn-dr76zrftsVtrMTaNZvLX8MJ8RcAz21_8=.8313e0e3-27bb-4a2e-9fc2-9e16df09ef09@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <madEVzus8seob93AWjKQ64ifJsgBG2oAHCDYgKyAFeQ=.acba30be-d45e-4533-a2bb-b7fe89f8a2d3@github.com>
 <mKQRviXwPn-dr76zrftsVtrMTaNZvLX8MJ8RcAz21_8=.8313e0e3-27bb-4a2e-9fc2-9e16df09ef09@github.com>
Message-ID: <yNQlxTtH6qox1CssHyIvqJAnyRT5wGjOkNJaROnzApg=.a0cdb34c-6c0d-4c22-8b1f-0267dab63e3f@github.com>

On Tue, 24 May 2022 16:18:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 302:
> 
>> 300:      * @since 19
>> 301:      */
>> 302:     default R visitSpec(SpecTree node, P p) {
> 
> Nit: this method breaks the alphabetic order of visitor methods. Although `visitOther` also breaks it, we should not address it in this PR.

Actually, fixed. Another merge issue.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Tue May 24 21:07:56 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 May 2022 21:07:56 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v5]
In-Reply-To: <B4_K5bPOTQ3SRQrjwY_IJ8FUMf0pixar5szzB12VATs=.fe364e32-cdbf-4c7b-9b48-eeaed8000c4a@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
 <B4_K5bPOTQ3SRQrjwY_IJ8FUMf0pixar5szzB12VATs=.fe364e32-cdbf-4c7b-9b48-eeaed8000c4a@github.com>
Message-ID: <paiQRAmyFiEEZ5-LPcAlFXv9sZfTaOLG1GgIpC53Efc=.6876825c-9356-4e36-b794-2f4aa5b892c2@github.com>

On Tue, 3 May 2022 22:14:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFinder.java line 277:
>> 
>>> 275: 
>>> 276:     private static boolean isNonEmpty(List<? extends DocTree> list) {
>>> 277:         return list != null && !list.isEmpty();
>> 
>> `output.inlineTags` should never be null. Separately, can this readability change be done in a separate PR? I do have one suitable PR in the works, which can include it.
>
> I'll back out these lines as long as the tests still pass.

done

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Tue May 24 21:08:02 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 May 2022 21:08:02 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v5]
In-Reply-To: <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
Message-ID: <EhtySXePu8v0wWRNRUsJ5aTVUQ-QXG0kmS03Fk7a5kc=.d0862fde-ce62-4010-a9b3-99174e01b794@github.com>

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

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - address review feedback
>>  - fix merge issues
>>  - merge with upstream/master
>>  - fix whitespace and position of HtmlStyle.refList
>>  - fix whitespace
>>  - JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec)
>
> test/langtools/tools/javac/diags/examples/NoTitle.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> It's surprising to see 2012 here.

It was derived from a file created back then. But, it's no great less to lose the 2012.

> test/langtools/tools/javac/diags/examples/NoURI.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Same as above.

Same as above

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From dholmes at openjdk.java.net  Tue May 24 21:13:59 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 24 May 2022 21:13:59 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
Message-ID: <my3reg3qq32EneIrhlsjzPOpMobJwr-Oot8lD7dlikk=.ddc77307-b08a-48ff-9c12-193b22dc0ab3@github.com>

On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [x] GHA run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another release test

There is a mistake in this changeset.  The JDK ProblemList already contained:

`java/nio/channels/FileChannel/LargeMapTest.java                 8286980 windows-all`

and this change then added:

`java/nio/channels/FileChannel/LargeMapTest.java                 8286642 generic-i586`

which appears to have negated the first entry.

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From jjg at openjdk.java.net  Tue May 24 21:16:02 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 May 2022 21:16:02 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v4]
In-Reply-To: <mKQRviXwPn-dr76zrftsVtrMTaNZvLX8MJ8RcAz21_8=.8313e0e3-27bb-4a2e-9fc2-9e16df09ef09@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <madEVzus8seob93AWjKQ64ifJsgBG2oAHCDYgKyAFeQ=.acba30be-d45e-4533-a2bb-b7fe89f8a2d3@github.com>
 <mKQRviXwPn-dr76zrftsVtrMTaNZvLX8MJ8RcAz21_8=.8313e0e3-27bb-4a2e-9fc2-9e16df09ef09@github.com>
Message-ID: <g8SYGbFqRyTX79uw59OKJosUteOtW7GxSh7ExmrFJXc=.d828be61-f902-4e0e-93ba-0c0a9a067edf@github.com>

On Tue, 24 May 2022 16:39:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 515:
> 
>> 513:      * {@inheritDoc}
>> 514:      *
>> 515:      * @param node {@inheritDoc}
> 
> There's something wrong with the `@implSpec` tags in this and the immediately following two methods. Might be an artifact of the patch.

Believed fixed.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1533:
> 
>> 1531:                 public DCTree parse(int pos) throws ParseException {
>> 1532:                     skipWhitespace();
>> 1533:                     DCText url = inlineWord();
> 
> Nit: call it `uri` for consistency.

Update, the terminology is converging on `URL` in all public places, with `java.net.URI` being used as needed within the doclet implementation.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 432:
> 
>> 430: doclet.extSpec.url.title=\
>> 431:     url: {0}, title: "{1}"
>> 432: 
> 
> Use `uri` in all 4 resources?

Converging on URL.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Tue May 24 21:24:56 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 May 2022 21:24:56 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v4]
In-Reply-To: <mKQRviXwPn-dr76zrftsVtrMTaNZvLX8MJ8RcAz21_8=.8313e0e3-27bb-4a2e-9fc2-9e16df09ef09@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <madEVzus8seob93AWjKQ64ifJsgBG2oAHCDYgKyAFeQ=.acba30be-d45e-4533-a2bb-b7fe89f8a2d3@github.com>
 <mKQRviXwPn-dr76zrftsVtrMTaNZvLX8MJ8RcAz21_8=.8313e0e3-27bb-4a2e-9fc2-9e16df09ef09@github.com>
Message-ID: <E8kPyL1rMYogGK5Wn8-bEIJEIrilaorxfR8XDnafwZs=.dfcc8d2e-cb61-4646-8242-72787ab299d5@github.com>

On Tue, 24 May 2022 16:55:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 1098:
> 
>> 1096: 
>> 1097:     /**
>> 1098:      * Argument for command-line option {@code --spec-base-URI}.
> 
> I think the option is lower-cased `--spec-base-uri`.

yes, and now `--spec-base-url`.

> test/langtools/tools/javac/diags/examples/NoTitle.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> 2012? Is it an old file from the previous incarnation of the `@spec` tag?

>From the file it was derived from.   It's always a toss-up when cloning and modifying an old file.  2012 removed.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From prappo at openjdk.java.net  Tue May 24 21:35:04 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 May 2022 21:35:04 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v5]
In-Reply-To: <QugI_mfqGj9AfgThFTp0QzwO7VlRTHuxYicb4dqHtoM=.97923858-872c-4b5f-993f-75a2aaa05ca6@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <QugI_mfqGj9AfgThFTp0QzwO7VlRTHuxYicb4dqHtoM=.97923858-872c-4b5f-993f-75a2aaa05ca6@github.com>
Message-ID: <GI7JoAbo4xhCxm4sHwMTrvtqAhyw8HHPX7s2vTdo8O4=.b8d568b4-cc84-41cc-86dd-b7e12c11a50a@github.com>

On Tue, 24 May 2022 19:50:41 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>  - address review feedback
>  - fix merge issues
>  - merge with upstream/master
>  - fix whitespace and position of HtmlStyle.refList
>  - fix whitespace
>  - JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 302:

> 300: 
> 301:     /**
> 302:      * Argument for command-line option {@code --spec-base-URI}.

Have my earlier comment on the upper case in `--spec-base-URI` disappeared? I cannot seem to find it.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From prappo at openjdk.java.net  Tue May 24 21:44:10 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 May 2022 21:44:10 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v5]
In-Reply-To: <QugI_mfqGj9AfgThFTp0QzwO7VlRTHuxYicb4dqHtoM=.97923858-872c-4b5f-993f-75a2aaa05ca6@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <QugI_mfqGj9AfgThFTp0QzwO7VlRTHuxYicb4dqHtoM=.97923858-872c-4b5f-993f-75a2aaa05ca6@github.com>
Message-ID: <UbpfXt5lrmhYChcSl_er4p-njYNrUAXCIuUx_rMP6y4=.8ef0078c-45eb-4cfc-9482-0dc85e2d36b4@github.com>

On Tue, 24 May 2022 19:50:41 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>  - address review feedback
>  - fix merge issues
>  - merge with upstream/master
>  - fix whitespace and position of HtmlStyle.refList
>  - fix whitespace
>  - JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec)

I appreciate your perseverance in this review, Jon! A note to self: when we have the next round of review, most URIs will have likely turned into URLs.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From prappo at openjdk.java.net  Tue May 24 21:35:04 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 May 2022 21:35:04 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v5]
In-Reply-To: <GI7JoAbo4xhCxm4sHwMTrvtqAhyw8HHPX7s2vTdo8O4=.b8d568b4-cc84-41cc-86dd-b7e12c11a50a@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <QugI_mfqGj9AfgThFTp0QzwO7VlRTHuxYicb4dqHtoM=.97923858-872c-4b5f-993f-75a2aaa05ca6@github.com>
 <GI7JoAbo4xhCxm4sHwMTrvtqAhyw8HHPX7s2vTdo8O4=.b8d568b4-cc84-41cc-86dd-b7e12c11a50a@github.com>
Message-ID: <2CW9duu1KNKpOT1kRvYYyLvlCuhMLftUQ9RlKUft4bc=.e04809ab-e86c-4e2a-9974-bdd446d24467@github.com>

On Tue, 24 May 2022 21:29:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
>>  - address review feedback
>>  - fix merge issues
>>  - merge with upstream/master
>>  - fix whitespace and position of HtmlStyle.refList
>>  - fix whitespace
>>  - JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec)
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 302:
> 
>> 300: 
>> 301:     /**
>> 302:      * Argument for command-line option {@code --spec-base-URI}.
> 
> Have my earlier comment on the upper case in `--spec-base-URI` disappeared? I cannot seem to find it.

Ah, found it: there are two of those cases.

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Tue May 24 22:00:57 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 May 2022 22:00:57 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v6]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <gpZOr87FvUEuhdgz8GEzkgH_PKbOq7vedQhQnMxCAAU=.18a3b998-fd02-4ea5-950d-d59bf3ff5027@github.com>

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

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8439/files
  - new: https://git.openjdk.java.net/jdk/pull/8439/files/8d98f6e1..acd43ded

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=04-05

  Stats: 167 lines in 21 files changed: 39 ins; 70 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8439/head:pull/8439

PR: https://git.openjdk.java.net/jdk/pull/8439

From jlahoda at openjdk.java.net  Wed May 25 04:20:35 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 25 May 2022 04:20:35 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v7]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <vZkgWSviWgMBL3GDPgWtwtzoAIy_YDpd4ek5_eUiQps=.4786f5fe-6978-4d29-9f31-2c57c82a298a@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

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

 - Merge branch 'master' into patterns-record-deconstruction3
 - Post merge fix.
 - Merge branch 'master' into patterns-record-deconstruction3
 - Fixing (non-)exhaustiveness for enum.
 - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
 - Merge branch 'master' into type-patterns-third
 - Using Type.isRaw instead of checking the AST structure.
 - Exhaustiveness should accept supertypes of the specified type.
 - Renaming the features from deconstruction pattern to record pattern.
 - Fixing guards after record patterns.
 - ... and 24 more: https://git.openjdk.java.net/jdk/compare/742644e2...f49d3f0a

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

Changes: https://git.openjdk.java.net/jdk/pull/8516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=06
  Stats: 2255 lines in 50 files changed: 2169 ins; 15 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From jjg at openjdk.java.net  Wed May 25 04:32:39 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 04:32:39 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v7]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <jBK9AA5rqH7reDxg-Rbmmje_881N8J_UwW1XoP_C2ZI=.241cd334-507a-44b3-bb2e-b9d816656f17@github.com>

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

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  more URI -> URL

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8439/files
  - new: https://git.openjdk.java.net/jdk/pull/8439/files/acd43ded..b03bbb62

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=05-06

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From shade at openjdk.java.net  Wed May 25 05:41:36 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 May 2022 05:41:36 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <my3reg3qq32EneIrhlsjzPOpMobJwr-Oot8lD7dlikk=.ddc77307-b08a-48ff-9c12-193b22dc0ab3@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
 <my3reg3qq32EneIrhlsjzPOpMobJwr-Oot8lD7dlikk=.ddc77307-b08a-48ff-9c12-193b22dc0ab3@github.com>
Message-ID: <Vvc9G3QcGPEWnA-2D9twMPBJgewfG_x0ty2XUcGUO5s=.47093993-797e-4b1e-b85e-35638a6aa2c1@github.com>

On Tue, 24 May 2022 21:10:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Just FYI. There is a mistake in this changeset. The JDK ProblemList already contained:
> 
> `java/nio/channels/FileChannel/LargeMapTest.java 8286980 windows-all`
> 
> and this change then added:
> 
> `java/nio/channels/FileChannel/LargeMapTest.java 8286642 generic-i586`
> 
> which appears to have negated the first entry.

Whoops, sorry. It seems not to be a problem since [JDK-8287263](https://bugs.openjdk.java.net/browse/JDK-8287263) committed a few hours ago removed the `windows-all` entry and fixed the test. I checked other ProblemLists, and there are no other double entries.

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

PR: https://git.openjdk.java.net/jdk/pull/8843

From jlahoda at openjdk.java.net  Wed May 25 11:59:20 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 25 May 2022 11:59:20 GMT
Subject: Integrated: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <o9iUH7M8YGPmrCwuOKvsAjpY5rNw4ArsFF8SmeR0w0U=.2be89934-f8bc-46d7-bddc-3656bfa751fe@github.com>

On Tue, 3 May 2022 12:07:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

This pull request has now been integrated.

Changeset: e9bddc18
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e9bddc18ab91c29d491b0e3bd145d641f6a62c5d
Stats:     2255 lines in 50 files changed: 2169 ins; 15 del; 71 mod

8262889: Compiler implementation for Record Patterns

Co-authored-by: Brian Goetz <briangoetz at openjdk.org>
Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: mcimadamore, vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From forax at openjdk.java.net  Wed May 25 13:21:04 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 May 2022 13:21:04 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v7]
In-Reply-To: <vZkgWSviWgMBL3GDPgWtwtzoAIy_YDpd4ek5_eUiQps=.4786f5fe-6978-4d29-9f31-2c57c82a298a@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <vZkgWSviWgMBL3GDPgWtwtzoAIy_YDpd4ek5_eUiQps=.4786f5fe-6978-4d29-9f31-2c57c82a298a@github.com>
Message-ID: <77MgPFVlQc-JfSO9ZeTO8tq_pPPeFk2CDWvt0A-elvo=.08516a80-31c0-4164-aef9-5232f1e15217@github.com>

On Wed, 25 May 2022 04:20:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into patterns-record-deconstruction3
>  - Post merge fix.
>  - Merge branch 'master' into patterns-record-deconstruction3
>  - Fixing (non-)exhaustiveness for enum.
>  - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
>  - Merge branch 'master' into type-patterns-third
>  - Using Type.isRaw instead of checking the AST structure.
>  - Exhaustiveness should accept supertypes of the specified type.
>  - Renaming the features from deconstruction pattern to record pattern.
>  - Fixing guards after record patterns.
>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/742644e2...f49d3f0a

Yai ! champagne (at least virtual).

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From hannesgreule at outlook.de  Wed May 25 14:42:52 2022
From: hannesgreule at outlook.de (Hannes Greule)
Date: Wed, 25 May 2022 14:42:52 +0000
Subject: Mandated/implicit parameters
Message-ID: <AM0PR03MB457746B3A0FE7D594A26E452AFD69@AM0PR03MB4577.eurprd03.prod.outlook.com>

> It would be legitimate to emit MethodParameters without -parameters, so as to record `final` and "implicitly declared" but not the parameter name, but at some cost to implementation complexity in java.lang.reflect.

What implementation complexity are you thinking of? The JVMS says "If the value of the name_index item is zero, then this parameters element indicates a formal parameter with no name."[1]. 
Shouldn't this case be already handled by the reflect impl?

Wouldn't it be also possible to just emit the attribute *with* names when it contains a mandated parameter? This would solve the problem with minimal changes as far as I can tell (with the downside of slightly increased class file sizes in such cases).

> That is weird, and sounds like a javac bug.
What would be the next steps here? Is my linked solution feasible?

Hannes

[1] https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-4.html#jvms-4.7.24

From jjg at openjdk.java.net  Wed May 25 14:48:00 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 14:48:00 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v5]
In-Reply-To: <2CW9duu1KNKpOT1kRvYYyLvlCuhMLftUQ9RlKUft4bc=.e04809ab-e86c-4e2a-9974-bdd446d24467@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <QugI_mfqGj9AfgThFTp0QzwO7VlRTHuxYicb4dqHtoM=.97923858-872c-4b5f-993f-75a2aaa05ca6@github.com>
 <GI7JoAbo4xhCxm4sHwMTrvtqAhyw8HHPX7s2vTdo8O4=.b8d568b4-cc84-41cc-86dd-b7e12c11a50a@github.com>
 <2CW9duu1KNKpOT1kRvYYyLvlCuhMLftUQ9RlKUft4bc=.e04809ab-e86c-4e2a-9974-bdd446d24467@github.com>
Message-ID: <XlUcruEYjUaxIGjhb53aWr57FrzkuTwQErT97PHh75Q=.8e3ec966-35b3-4b7b-adec-9147f22827db@github.com>

On Tue, 24 May 2022 21:30:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 302:
>> 
>>> 300: 
>>> 301:     /**
>>> 302:      * Argument for command-line option {@code --spec-base-URI}.
>> 
>> Have my earlier comment on the upper case in `--spec-base-URI` disappeared? I cannot seem to find it.
>
> Ah, found it: there are two of those cases.

I believe these have all been fixed

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Wed May 25 14:48:05 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 14:48:05 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v4]
In-Reply-To: <mKQRviXwPn-dr76zrftsVtrMTaNZvLX8MJ8RcAz21_8=.8313e0e3-27bb-4a2e-9fc2-9e16df09ef09@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <madEVzus8seob93AWjKQ64ifJsgBG2oAHCDYgKyAFeQ=.acba30be-d45e-4533-a2bb-b7fe89f8a2d3@github.com>
 <mKQRviXwPn-dr76zrftsVtrMTaNZvLX8MJ8RcAz21_8=.8313e0e3-27bb-4a2e-9fc2-9e16df09ef09@github.com>
Message-ID: <ECgh-OBAVz4B_RBE9Ct0rlo8QKzOOQPVBJOyGPCZQ3k=.f61ed8b4-9271-4be1-bc73-a6bbe22818fe@github.com>

On Tue, 24 May 2022 16:53:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2001, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> 2001?

removed

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Wed May 25 14:48:07 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 14:48:07 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v7]
In-Reply-To: <B4_K5bPOTQ3SRQrjwY_IJ8FUMf0pixar5szzB12VATs=.fe364e32-cdbf-4c7b-9b48-eeaed8000c4a@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
 <LjYSHIbscbUbZsF29_rUScrscWK-ihhYPFHn9LHAISc=.eea62ead-3764-4820-ad93-7b308534ea16@github.com>
 <B4_K5bPOTQ3SRQrjwY_IJ8FUMf0pixar5szzB12VATs=.fe364e32-cdbf-4c7b-9b48-eeaed8000c4a@github.com>
Message-ID: <nFhNaZRKzq6AMOjmq0RXfhPTXJVlq8YH_zRaqa0Aoa8=.9b11213e-b5ab-4dff-a760-57983de90244@github.com>

On Tue, 3 May 2022 22:16:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testConditionalPages/TestConditionalPages.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> Consider adding 6251738 to `@bug`.
>
> Mmmm, OK

done

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

PR: https://git.openjdk.java.net/jdk/pull/8439

From jjg at openjdk.java.net  Wed May 25 15:28:03 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 15:28:03 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v8]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <N-3ytDy3R6yCAMmL5BKsQq8LvfiY88FsNZd96Z5sHi4=.785e02b7-d6a7-4714-a73d-668886e2be0d@github.com>

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

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix copyright dates
  remove archaic obsolete build flags

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8439/files
  - new: https://git.openjdk.java.net/jdk/pull/8439/files/b03bbb62..c24c02ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=06-07

  Stats: 7 lines in 5 files changed: 1 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8439/head:pull/8439

PR: https://git.openjdk.java.net/jdk/pull/8439

From liangchenblue at gmail.com  Wed May 25 15:54:47 2022
From: liangchenblue at gmail.com (-)
Date: Wed, 25 May 2022 10:54:47 -0500
Subject: Fwd: Mandated/implicit parameters
In-Reply-To: <CABe8uE2gMRi8AjSEjJ0dARo0VFmOfVsZgKPJCWNVdvSN=i5B-Q@mail.gmail.com>
References: <AM0PR03MB457746B3A0FE7D594A26E452AFD69@AM0PR03MB4577.eurprd03.prod.outlook.com>
 <CABe8uE2gMRi8AjSEjJ0dARo0VFmOfVsZgKPJCWNVdvSN=i5B-Q@mail.gmail.com>
Message-ID: <CABe8uE0LFFFmR9hqYLsaahAeOeaO-MVSjY8C6Q5zF2-qS_EVAQ@mail.gmail.com>

I strongly agree with your recommended solution of forcing javac to emit
MethodParameters attribute without names when -parameters flag is absent.
This is related to JDK-8062582.

In fact, the main manifest of this lack of necessary parameter data is
rendered in the loss of generics when an inner class (with an implicit
outer class as first constructor argument) is scanned. For instance, in
Apple.java:

import java.lang.annotation.*;
import java.lang.reflect.*;
import java.util.*;
import java.util.function.*;

public class Apple {
    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.TYPE_USE)
    public @interface Anno {}

    public class Inner {
        public Inner(Optional<@Anno String> argument) {}
        public void test(Optional<@Anno String> argument) {}
    }

    public static void main(String... args) throws Throwable {
        System.out.println("Test constructor:");
        Constructor<?> ctor =
Inner.class.getDeclaredConstructor(Apple.class, Optional.class);
        printTypes(ctor);
        printParam(ctor.getParameters()[1]);
        System.out.println();

        System.out.println("Test method:");
        Method test = Inner.class.getDeclaredMethod("test", Optional.class);
        printTypes(test);
        printParam(test.getParameters()[0]);
        System.out.println();
    }

    private static void printTypes(Executable exec) {

System.out.println(Arrays.toString(exec.getGenericParameterTypes()));

System.out.println(Arrays.toString(exec.getAnnotatedParameterTypes()));
    }

    private static void printParam(Parameter parameter) {
        System.out.println(parameter.getParameterizedType());
        System.out.println(parameter.getAnnotatedType());
    }
}

Compile and run it in JDK 18 (without -parameters), and observe on the
inner class constructor the loss of annotations and loss of generics when
inspected through parameters:
Test constructor:
[java.util.Optional<java.lang.String>]
[Apple, java.util.Optional] // Comment: from getAnnotatedParameterTypes,
the Optional lost generics and thus, annotations
class java.util.Optional // This one doesn't depend on annotations, yet it
lost generics
java.util.Optional

Test method:
[java.util.Optional<java.lang.String>]
[java.util.Optional<@Apple$Anno() java.lang.String>]
java.util.Optional<java.lang.String>
java.util.Optional<@Apple$Anno() java.lang.String>

And this issue goes away when -parameters flag is enabled.
A similar issue exists at JDK-8284333.

So, your approach would fix all these issues reported. It all goes down to
satisfying the logic in Executable::getAllGenericParameterTypes, which can
fix (generic) signature and formal parameter count mismatch only with the
presence of MethodParameters attribute. In addition, we can move away from
the hacky, java-specific logic. in
https://github.com/openjdk/jdk/blob/e990fec195791e17ea8af5c5393fec1c92cb4717/src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java#L130
and
https://github.com/openjdk/jdk/blob/e990fec195791e17ea8af5c5393fec1c92cb4717/src/java.base/share/classes/java/lang/reflect/Executable.java#L582

On Wed, May 25, 2022 at 9:43 AM Hannes Greule <hannesgreule at outlook.de>
wrote:

> > It would be legitimate to emit MethodParameters without -parameters, so
> as to record `final` and "implicitly declared" but not the parameter name,
> but at some cost to implementation complexity in java.lang.reflect.
>
> What implementation complexity are you thinking of? The JVMS says "If the
> value of the name_index item is zero, then this parameters element
> indicates a formal parameter with no name."[1].
> Shouldn't this case be already handled by the reflect impl?
>
> Wouldn't it be also possible to just emit the attribute *with* names when
> it contains a mandated parameter? This would solve the problem with minimal
> changes as far as I can tell (with the downside of slightly increased class
> file sizes in such cases).
>
> > That is weird, and sounds like a javac bug.
> What would be the next steps here? Is my linked solution feasible?
>
> Hannes
>
> [1]
> https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-4.html#jvms-4.7.24
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220525/89395860/attachment-0001.htm>

From darcy at openjdk.java.net  Wed May 25 16:22:15 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 25 May 2022 16:22:15 GMT
Subject: RFR: JDK-8284966: Update SourceVersion.RELEASE_19 description for
 language changes [v2]
In-Reply-To: <4siljdpcfgfvfIlKbRI1bx1GCY4XlbyNsSk2e_IaGw4=.dcf23d61-b841-429a-bb3a-3a1b3f1b553b@github.com>
References: <4siljdpcfgfvfIlKbRI1bx1GCY4XlbyNsSk2e_IaGw4=.dcf23d61-b841-429a-bb3a-3a1b3f1b553b@github.com>
Message-ID: <odeKesc4cVl3WDvRKbMwZBy_7osgXRv_td3-cUtkmYY=.7558c7fe-3f76-417e-84d6-07b93bdec15e@github.com>

> Updating the description of RELEASE_19 for the anticipated language changes in Java SE 19. I'll defer pushing until the proposed-to-target record patterns compiler changes are pushed. Also adding links to the JSR 269 API in the package info files.

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

 - Merge branch 'master' into JDK-8284966
 - JDK-8284966: Update SourceVersion.RELEASE_19 description for language changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8793/files
  - new: https://git.openjdk.java.net/jdk/pull/8793/files/98977554..6df77a29

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8793&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8793&range=00-01

  Stats: 38164 lines in 650 files changed: 8903 ins; 27617 del; 1644 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8793.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8793/head:pull/8793

PR: https://git.openjdk.java.net/jdk/pull/8793

From darcy at openjdk.java.net  Wed May 25 16:29:55 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 25 May 2022 16:29:55 GMT
Subject: Integrated: JDK-8284966: Update SourceVersion.RELEASE_19 description
 for language changes
In-Reply-To: <4siljdpcfgfvfIlKbRI1bx1GCY4XlbyNsSk2e_IaGw4=.dcf23d61-b841-429a-bb3a-3a1b3f1b553b@github.com>
References: <4siljdpcfgfvfIlKbRI1bx1GCY4XlbyNsSk2e_IaGw4=.dcf23d61-b841-429a-bb3a-3a1b3f1b553b@github.com>
Message-ID: <Jb2WOcKtUAV5M2FEqNsJdEZZMPlAUym7PthvVEW2f34=.db9db377-dede-438e-ae17-faf4cea8a768@github.com>

On Thu, 19 May 2022 17:56:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Updating the description of RELEASE_19 for the anticipated language changes in Java SE 19. I'll defer pushing until the proposed-to-target record patterns compiler changes are pushed. Also adding links to the JSR 269 API in the package info files.

This pull request has now been integrated.

Changeset: 0b8dd4ac
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0b8dd4ac82d366d7003ff1eb31a2a733f9fe8a1e
Stats:     19 lines in 6 files changed: 16 ins; 0 del; 3 mod

8284966: Update SourceVersion.RELEASE_19 description for language changes

Reviewed-by: iris, jjg

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

PR: https://git.openjdk.java.net/jdk/pull/8793

From jjg at openjdk.java.net  Wed May 25 17:14:30 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 17:14:30 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <7Rx1OT6mafjK2LhreErbNltD6yXPWgY8376tIdE2VQ0=.a9759ed5-f1be-4424-b085-34209864317a@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
 <7Rx1OT6mafjK2LhreErbNltD6yXPWgY8376tIdE2VQ0=.a9759ed5-f1be-4424-b085-34209864317a@github.com>
Message-ID: <XYVGAg5fCYhVnsmmwtgbHhOmEEV3Z6WXHhizR14-0Ic=.8b058c45-f2da-4e82-a163-fdcfe1d5bf59@github.com>

On Tue, 24 May 2022 18:39:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review a test-only fix to make a recent new test more robust.
>> 
>> The test was not fundamentally broken, so the essential functionality remains the same. However, it does assume access to the `src/jdk.javadoc` directory, and crashed when that was not available.
>> 
>> The mitigation is two-fold: 
>> 
>> 1. introduce and use a new `SnippetUtils.ConfigurationException` that is thrown when the test cannot find the necessary directories.
>> 2. introduce and use 2 new test-suite keywords, `needs-src` `needs-src-jdk_javadoc` that can be used on the jtreg command-line to filter out this test, and any similar tests in the future.
>> 
>> Tested locally, manually, by temporarily renaming key directories, to test the different code paths.  In all cases, if the test is run and any necessary directories are missing, the test _will still fail_, but now with a more useful and specific exception and detail message.
>
> test/langtools/jdk/javadoc/doclet/testDocletExample/TestDocletExample.java line 71:
> 
>> 69:         var entryPointSnippet = snippets.getSnippetById(dc, "entry-point");
>> 70:         if (entryPointSnippet == null) {
>> 71:             throw new Error("Cannot find snippet \"entry-point\"");
> 
> I understand it as follows. Although this code now throws generic `Error` instead of `NullPointerException`, which the bug reporter observed, we shouldn't see that `Error` in circumstances similar to those of bug reporter. This is because in those circumstances the code will throw `ConfigurationException` earlier, at construction time, so we won't reach this check. Do I understand it correctly?

Yes. Although we could throw NPE even here, I was wanting to throw something that indicates the test is dysfunctional, as compared to failing or crashing.

> test/langtools/jdk/javadoc/doclet/testDocletExample/TestDocletExample.java line 97:
> 
>> 95:         var dc = snippets.getDocTrees().getDocCommentTree(docletPkg);
>> 96:         var exampleSnippet = snippets.getSnippetById(dc, "Example.java");
>> 97:         if (exampleSnippet == null) {
> 
> Same as above.

Yes, same reasoning. `SnippetUtils` is broken if we get a null result.

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

PR: https://git.openjdk.java.net/jdk/pull/8796

From prappo at openjdk.java.net  Wed May 25 17:14:33 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 May 2022 17:14:33 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <XYVGAg5fCYhVnsmmwtgbHhOmEEV3Z6WXHhizR14-0Ic=.8b058c45-f2da-4e82-a163-fdcfe1d5bf59@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
 <7Rx1OT6mafjK2LhreErbNltD6yXPWgY8376tIdE2VQ0=.a9759ed5-f1be-4424-b085-34209864317a@github.com>
 <XYVGAg5fCYhVnsmmwtgbHhOmEEV3Z6WXHhizR14-0Ic=.8b058c45-f2da-4e82-a163-fdcfe1d5bf59@github.com>
Message-ID: <imXTMyMNV_PltGssATm6CdZJjhHhJDpc_JbhjAnSGUw=.26336fe8-8ae5-4552-ab54-f93b319fa25e@github.com>

On Wed, 25 May 2022 17:02:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> `SnippetUtils` is broken if we get a null result.

If it's unconditionally so, which it seems to be, wouldn't it be better to throw something from `SnippetUtils.getSnippetById` instead?

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

PR: https://git.openjdk.java.net/jdk/pull/8796

From jjg at openjdk.java.net  Wed May 25 17:14:34 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 17:14:34 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <imXTMyMNV_PltGssATm6CdZJjhHhJDpc_JbhjAnSGUw=.26336fe8-8ae5-4552-ab54-f93b319fa25e@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
 <7Rx1OT6mafjK2LhreErbNltD6yXPWgY8376tIdE2VQ0=.a9759ed5-f1be-4424-b085-34209864317a@github.com>
 <XYVGAg5fCYhVnsmmwtgbHhOmEEV3Z6WXHhizR14-0Ic=.8b058c45-f2da-4e82-a163-fdcfe1d5bf59@github.com>
 <imXTMyMNV_PltGssATm6CdZJjhHhJDpc_JbhjAnSGUw=.26336fe8-8ae5-4552-ab54-f93b319fa25e@github.com>
Message-ID: <rYU2aiXYg97vt_bff8ohnJOBMNSgaaXqlof7J1GuJbo=.a6a778d1-2c3c-4597-b659-0fd65c48fedd@github.com>

On Wed, 25 May 2022 17:07:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Yes, same reasoning. `SnippetUtils` is broken if we get a null result.
>
>> `SnippetUtils` is broken if we get a null result.
> 
> If it's unconditionally so, which it seems to be, wouldn't it be better to throw something from `SnippetUtils.getSnippetById` instead?

Hmmm, The current spec of `SnippetUtils` is to return `null` if an item cannot be found.  So, it is only broken if the user really expects a non-null result.

I guess it depends if there is enough use case where you might want a null result instead of an exception.

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

PR: https://git.openjdk.java.net/jdk/pull/8796

From prappo at openjdk.java.net  Wed May 25 17:27:46 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 May 2022 17:27:46 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
Message-ID: <ZODxsZgG6U7lHlyyNahNbPNUYDWOjDdKSyIhFmSqkpM=.8e4a9e84-19bd-4933-a2c3-157a54eb7ac6@github.com>

On Thu, 19 May 2022 22:05:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a test-only fix to make a recent new test more robust.
> 
> The test was not fundamentally broken, so the essential functionality remains the same. However, it does assume access to the `src/jdk.javadoc` directory, and crashed when that was not available.
> 
> The mitigation is two-fold: 
> 
> 1. introduce and use a new `SnippetUtils.ConfigurationException` that is thrown when the test cannot find the necessary directories.
> 2. introduce and use 2 new test-suite keywords, `needs-src` `needs-src-jdk_javadoc` that can be used on the jtreg command-line to filter out this test, and any similar tests in the future.
> 
> Tested locally, manually, by temporarily renaming key directories, to test the different code paths.  In all cases, if the test is run and any necessary directories are missing, the test _will still fail_, but now with a more useful and specific exception and detail message.

> I'd prefer to leave updates to SnippetIUtils to its own separate Enhancement.

Sounds good.

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

Marked as reviewed by prappo (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8796

From prappo at openjdk.java.net  Wed May 25 17:27:49 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 May 2022 17:27:49 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <XYVGAg5fCYhVnsmmwtgbHhOmEEV3Z6WXHhizR14-0Ic=.8b058c45-f2da-4e82-a163-fdcfe1d5bf59@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
 <7Rx1OT6mafjK2LhreErbNltD6yXPWgY8376tIdE2VQ0=.a9759ed5-f1be-4424-b085-34209864317a@github.com>
 <XYVGAg5fCYhVnsmmwtgbHhOmEEV3Z6WXHhizR14-0Ic=.8b058c45-f2da-4e82-a163-fdcfe1d5bf59@github.com>
Message-ID: <KV-8f1wz20aUhsoD0aqg2a2xYKeJvMo1myplfndMqLA=.ce08b5a5-f32f-4e01-93d7-b4ed5d2b85df@github.com>

On Wed, 25 May 2022 16:59:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testDocletExample/TestDocletExample.java line 71:
>> 
>>> 69:         var entryPointSnippet = snippets.getSnippetById(dc, "entry-point");
>>> 70:         if (entryPointSnippet == null) {
>>> 71:             throw new Error("Cannot find snippet \"entry-point\"");
>> 
>> I understand it as follows. Although this code now throws generic `Error` instead of `NullPointerException`, which the bug reporter observed, we shouldn't see that `Error` in circumstances similar to those of bug reporter. This is because in those circumstances the code will throw `ConfigurationException` earlier, at construction time, so we won't reach this check. Do I understand it correctly?
>
> Yes. Although we could throw NPE even here, I was wanting to throw something that indicates the test is dysfunctional, as compared to failing or crashing.

The rationale that you provided reminds of `new FileInputStream(java.io.File)` that throws `FileNotFoundException`. Unlike not finding a file, not finding a particular snippet is an unexpected, unrecoverable programming error. I cannot imagine a reasonable test that checks that some snippet is not there.

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

PR: https://git.openjdk.java.net/jdk/pull/8796

From jjg at openjdk.java.net  Wed May 25 17:27:50 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 17:27:50 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <rYU2aiXYg97vt_bff8ohnJOBMNSgaaXqlof7J1GuJbo=.a6a778d1-2c3c-4597-b659-0fd65c48fedd@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
 <7Rx1OT6mafjK2LhreErbNltD6yXPWgY8376tIdE2VQ0=.a9759ed5-f1be-4424-b085-34209864317a@github.com>
 <XYVGAg5fCYhVnsmmwtgbHhOmEEV3Z6WXHhizR14-0Ic=.8b058c45-f2da-4e82-a163-fdcfe1d5bf59@github.com>
 <imXTMyMNV_PltGssATm6CdZJjhHhJDpc_JbhjAnSGUw=.26336fe8-8ae5-4552-ab54-f93b319fa25e@github.com>
 <rYU2aiXYg97vt_bff8ohnJOBMNSgaaXqlof7J1GuJbo=.a6a778d1-2c3c-4597-b659-0fd65c48fedd@github.com>
Message-ID: <WvT9-j-sB8m-9MmO1qaJ1iptiIqgUkdB0vPaIUwQqSI=.f6570014-7df1-42a0-94f0-ef90da75d4c0@github.com>

On Wed, 25 May 2022 17:11:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> `SnippetUtils` is broken if we get a null result.
>> 
>> If it's unconditionally so, which it seems to be, wouldn't it be better to throw something from `SnippetUtils.getSnippetById` instead?
>
> Hmmm, The current spec of `SnippetUtils` is to return `null` if an item cannot be found.  So, it is only broken if the user really expects a non-null result.
> 
> I guess it depends if there is enough use case where you might want a null result instead of an exception.

I guess the `SnippetUtils` spec does not currently define behavior if not found.

I would be more inclined to define a "returns null" behavior than to use `Optional` or throw and exception.   But more generally, I'd prefer to leave updates to `SnippetIUtils` to its own separate Enhancement.

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

PR: https://git.openjdk.java.net/jdk/pull/8796

From jjg at openjdk.java.net  Wed May 25 17:27:49 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 17:27:49 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <KV-8f1wz20aUhsoD0aqg2a2xYKeJvMo1myplfndMqLA=.ce08b5a5-f32f-4e01-93d7-b4ed5d2b85df@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
 <7Rx1OT6mafjK2LhreErbNltD6yXPWgY8376tIdE2VQ0=.a9759ed5-f1be-4424-b085-34209864317a@github.com>
 <XYVGAg5fCYhVnsmmwtgbHhOmEEV3Z6WXHhizR14-0Ic=.8b058c45-f2da-4e82-a163-fdcfe1d5bf59@github.com>
 <KV-8f1wz20aUhsoD0aqg2a2xYKeJvMo1myplfndMqLA=.ce08b5a5-f32f-4e01-93d7-b4ed5d2b85df@github.com>
Message-ID: <vWXl1Z978uOzq_lD6id0D1A03R6oOnjmcx6cnd3RU-E=.5b63a6c1-803a-4757-b6d6-7ddd267ee8dd@github.com>

On Wed, 25 May 2022 17:19:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Yes. Although we could throw NPE even here, I was wanting to throw something that indicates the test is dysfunctional, as compared to failing or crashing.
>
> The rationale that you provided reminds of `new FileInputStream(java.io.File)` that throws `FileNotFoundException`. Unlike not finding a file, not finding a particular snippet is an unexpected, unrecoverable programming error. I cannot imagine a reasonable test that checks that some snippet is not there.

It's a reasonable analogy.

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

PR: https://git.openjdk.java.net/jdk/pull/8796

From jjg at openjdk.java.net  Wed May 25 17:32:55 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 17:32:55 GMT
Subject: RFR: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <ZODxsZgG6U7lHlyyNahNbPNUYDWOjDdKSyIhFmSqkpM=.8e4a9e84-19bd-4933-a2c3-157a54eb7ac6@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
 <ZODxsZgG6U7lHlyyNahNbPNUYDWOjDdKSyIhFmSqkpM=.8e4a9e84-19bd-4933-a2c3-157a54eb7ac6@github.com>
Message-ID: <otB1ecj0jOkWuut-p05_H4qxsJXt4WxI_d_TPp7Yh2Q=.6832afbc-aa0c-4b2c-a85a-cf964e1bfba2@github.com>

On Wed, 25 May 2022 17:24:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > I'd prefer to leave updates to SnippetIUtils to its own separate Enhancement.
> 
> Sounds good.

[JDK-8287337](https://bugs.openjdk.java.net/browse/JDK-8287337)

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

PR: https://git.openjdk.java.net/jdk/pull/8796

From jjg at openjdk.java.net  Wed May 25 17:47:49 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 17:47:49 GMT
Subject: Integrated: JDK-8279513:
 jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after
 8278795
In-Reply-To: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
References: <oTRZ6Sm5mPScpndQS-Q5s9CyGfB8BD_-GZvjSCsY-Mc=.bb5b37f8-6841-478f-b280-6af1c2c74cf6@github.com>
Message-ID: <OWZ5EA1tyGVtZqgC31-drZnzeBkHk-sBU2ml-A3miVA=.1036171a-e258-4102-b4cc-51f0d92e7291@github.com>

On Thu, 19 May 2022 22:05:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a test-only fix to make a recent new test more robust.
> 
> The test was not fundamentally broken, so the essential functionality remains the same. However, it does assume access to the `src/jdk.javadoc` directory, and crashed when that was not available.
> 
> The mitigation is two-fold: 
> 
> 1. introduce and use a new `SnippetUtils.ConfigurationException` that is thrown when the test cannot find the necessary directories.
> 2. introduce and use 2 new test-suite keywords, `needs-src` `needs-src-jdk_javadoc` that can be used on the jtreg command-line to filter out this test, and any similar tests in the future.
> 
> Tested locally, manually, by temporarily renaming key directories, to test the different code paths.  In all cases, if the test is run and any necessary directories are missing, the test _will still fail_, but now with a more useful and specific exception and detail message.

This pull request has now been integrated.

Changeset: 7156f98e
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7156f98e324ffd0ab17105b2cb8cb6ce0d718e5b
Stats:     44 lines in 3 files changed: 37 ins; 0 del; 7 mod

8279513: jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after 8278795

Reviewed-by: prappo

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

PR: https://git.openjdk.java.net/jdk/pull/8796

From prappo at openjdk.java.net  Wed May 25 18:53:25 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 May 2022 18:53:25 GMT
Subject: RFR: 8287338: tools/javac/api/snippets/TestJavaxToolsSnippets.java
 failing tier1 on all platforms
Message-ID: <bbYn9i4XnWYXwTSbjz4WoavHdQrrYhDKUIvSyeepmzM=.33ab264d-976d-4ff8-9b4c-dacc006aae92@github.com>

This fixes tier1 failures caused by JDK-8279513. Test results pending.

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

Commit messages:
 - Initial commit

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

PR: https://git.openjdk.java.net/jdk/pull/8890

From jjg at openjdk.java.net  Wed May 25 18:53:25 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 18:53:25 GMT
Subject: RFR: 8287338: tools/javac/api/snippets/TestJavaxToolsSnippets.java
 failing tier1 on all platforms
In-Reply-To: <bbYn9i4XnWYXwTSbjz4WoavHdQrrYhDKUIvSyeepmzM=.33ab264d-976d-4ff8-9b4c-dacc006aae92@github.com>
References: <bbYn9i4XnWYXwTSbjz4WoavHdQrrYhDKUIvSyeepmzM=.33ab264d-976d-4ff8-9b4c-dacc006aae92@github.com>
Message-ID: <Aa9f-VMdArY8tcoXN5Bc8u2lSm31PTauifFpu1Zfr8I=.9f8f35ab-0379-48b5-9189-f537163f2ee9@github.com>

On Wed, 25 May 2022 18:43:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes tier1 failures caused by JDK-8279513. Test results pending.

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8890

From jjg at openjdk.java.net  Wed May 25 19:45:15 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 May 2022 19:45:15 GMT
Subject: RFR: JDK-8287337: SnippetUtils should throw exceptions if snippets not
 found
Message-ID: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>

Please review a simple change for `SnippetUtils` to throw a checked exception if a snippet cannot be found.

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

Commit messages:
 - JDK-8287337: SnippetUtils should throw exceptions if snippets not found

Changes: https://git.openjdk.java.net/jdk/pull/8892/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8892&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287337
  Stats: 41 lines in 2 files changed: 31 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8892.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8892/head:pull/8892

PR: https://git.openjdk.java.net/jdk/pull/8892

From prappo at openjdk.java.net  Wed May 25 19:47:07 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 May 2022 19:47:07 GMT
Subject: RFR: 8287338: tools/javac/api/snippets/TestJavaxToolsSnippets.java
 failing tier1 on all platforms
In-Reply-To: <bbYn9i4XnWYXwTSbjz4WoavHdQrrYhDKUIvSyeepmzM=.33ab264d-976d-4ff8-9b4c-dacc006aae92@github.com>
References: <bbYn9i4XnWYXwTSbjz4WoavHdQrrYhDKUIvSyeepmzM=.33ab264d-976d-4ff8-9b4c-dacc006aae92@github.com>
Message-ID: <0At1_6ZUGhn_A5FkyV4baBMrC7IWykNz6bv4K5rghig=.4cbbafb1-8d74-466c-931f-741402fd6191@github.com>

On Wed, 25 May 2022 18:43:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes tier1 failures caused by JDK-8279513. Test results pending.

tier1 tests have passed.

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

PR: https://git.openjdk.java.net/jdk/pull/8890

From prappo at openjdk.java.net  Wed May 25 19:47:08 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 May 2022 19:47:08 GMT
Subject: Integrated: 8287338:
 tools/javac/api/snippets/TestJavaxToolsSnippets.java failing tier1 on all
 platforms
In-Reply-To: <bbYn9i4XnWYXwTSbjz4WoavHdQrrYhDKUIvSyeepmzM=.33ab264d-976d-4ff8-9b4c-dacc006aae92@github.com>
References: <bbYn9i4XnWYXwTSbjz4WoavHdQrrYhDKUIvSyeepmzM=.33ab264d-976d-4ff8-9b4c-dacc006aae92@github.com>
Message-ID: <DaAEPi8btLVMj8uHpK6EKtedoGHisv_e6IYaQyz59P4=.9ead8244-d8a3-4cee-b5c6-991d3932bd6d@github.com>

On Wed, 25 May 2022 18:43:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes tier1 failures caused by JDK-8279513. Test results pending.

This pull request has now been integrated.

Changeset: 3d6d7b7e
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d6d7b7e7371dad3bd0983a9e26c39261783dcb4
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8287338: tools/javac/api/snippets/TestJavaxToolsSnippets.java failing tier1 on all platforms

Reviewed-by: jjg

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

PR: https://git.openjdk.java.net/jdk/pull/8890

From clanger at openjdk.java.net  Thu May 26 10:06:00 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Thu, 26 May 2022 10:06:00 GMT
Subject: RFR: 8286855: javac error on invalid jar should only print filename
Message-ID: <aw66t8BeavkbsNqpWG6Ql5QaUmD2KGM7U3tX6r82mLU=.7d926b55-4f3f-4a49-a496-05186f02e1ad@github.com>

As was suggested in the [review for JDK-8286444](https://github.com/openjdk/jdk/pull/8616#discussion_r873099812), javac should always print the filename only, when encountering a ZipException.

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

Commit messages:
 - JDK-8286855

Changes: https://git.openjdk.java.net/jdk/pull/8900/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8900&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286855
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8900.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8900/head:pull/8900

PR: https://git.openjdk.java.net/jdk/pull/8900

From jpai at openjdk.java.net  Thu May 26 10:33:31 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 26 May 2022 10:33:31 GMT
Subject: RFR: 8286855: javac error on invalid jar should only print
 filename
In-Reply-To: <aw66t8BeavkbsNqpWG6Ql5QaUmD2KGM7U3tX6r82mLU=.7d926b55-4f3f-4a49-a496-05186f02e1ad@github.com>
References: <aw66t8BeavkbsNqpWG6Ql5QaUmD2KGM7U3tX6r82mLU=.7d926b55-4f3f-4a49-a496-05186f02e1ad@github.com>
Message-ID: <RhwGlbpIHudRxMEg-TAJ5FLR3xJ8f_10vTOGK0ovgg8=.702aad0b-4ded-42af-a8cb-ba5c99cd2981@github.com>

On Thu, 26 May 2022 09:58:12 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> As was suggested in the [review for JDK-8286444](https://github.com/openjdk/jdk/pull/8616#discussion_r873099812), javac should always print the filename only, when encountering a ZipException.

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/8900

From darcy at openjdk.java.net  Thu May 26 22:37:15 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 22:37:15 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
Message-ID: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>

Time to start getting ready for JDK 20...

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

Commit messages:
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Update symbol information for JDK 19 b23.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/295be6f1...49c871d9

Changes: https://git.openjdk.java.net/jdk/pull/8236/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284858
  Stats: 6210 lines in 67 files changed: 6166 ins; 0 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From darcy at openjdk.java.net  Thu May 26 22:37:15 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 22:37:15 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <B29A3l_xOQdMh3jmtxcJ-hez1n7osjYQg4IQ-1joXSM=.3c8daafa-0a65-45f6-817a-527bf4709dfb@github.com>

On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start getting ready for JDK 20...

The expected kinds of updates to start up JDK 20.

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From dholmes at openjdk.java.net  Thu May 26 22:46:42 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 May 2022 22:46:42 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <OWBo909uodHc7ZOhNe_BK4q0yHcYgEUIluO1__gmDRw=.279398bf-e824-4d9d-8d0d-128285f97926@github.com>

On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start getting ready for JDK 20...

One comment below.
I ignored the sym files.
Everything else appears okay.
Thanks.

src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312:

> 310:     int V18 = 0 << 16 | 62;
> 311:     int V19 = 0 << 16 | 63;
> 312:     int V20 = 0 << 17 | 64;

17 ??

Though why do we even bother with this when the minor version is zero? Simple assignment works.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8236

From kcr at openjdk.java.net  Thu May 26 22:46:44 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 26 May 2022 22:46:44 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <jCvgOE5wGiuXGPTLvxmTuC2BCg-YdrXE8zx_zbivCyo=.61b8078b-3fe3-41de-ad15-8d893e1e4878@github.com>

On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start getting ready for JDK 20...

You also need to change the JBS version from 19 to 20 in [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4):

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From darcy at openjdk.java.net  Thu May 26 23:05:32 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 23:05:32 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>

> Time to start getting ready for JDK 20...

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/49c871d9..96be1787

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From darcy at openjdk.java.net  Thu May 26 23:05:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 23:05:33 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <jCvgOE5wGiuXGPTLvxmTuC2BCg-YdrXE8zx_zbivCyo=.61b8078b-3fe3-41de-ad15-8d893e1e4878@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <jCvgOE5wGiuXGPTLvxmTuC2BCg-YdrXE8zx_zbivCyo=.61b8078b-3fe3-41de-ad15-8d893e1e4878@github.com>
Message-ID: <kUSWYSs_79_tOb5n1wCsTJFciuQ_9Rykv1xw-OdE2K8=.543bb3ac-c033-4701-8190-e59a8b13d6f3@github.com>

On Thu, 26 May 2022 22:40:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> You also need to change the JBS version from 19 to 20 in [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4):

Acknowledged; will fix in the next push. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From darcy at openjdk.java.net  Thu May 26 23:05:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 23:05:33 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <OWBo909uodHc7ZOhNe_BK4q0yHcYgEUIluO1__gmDRw=.279398bf-e824-4d9d-8d0d-128285f97926@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <OWBo909uodHc7ZOhNe_BK4q0yHcYgEUIluO1__gmDRw=.279398bf-e824-4d9d-8d0d-128285f97926@github.com>
Message-ID: <Mwf6jz76P6Bv1EcfvQaz4V5vdXUhvWOe9rxBNMhp_cU=.ca3c9888-391f-4bf2-9410-196aabb2614c@github.com>

On Thu, 26 May 2022 22:38:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312:
> 
>> 310:     int V18 = 0 << 16 | 62;
>> 311:     int V19 = 0 << 16 | 63;
>> 312:     int V20 = 0 << 17 | 64;
> 
> 17 ??
> 
> Though why do we even bother with this when the minor version is zero? Simple assignment works.

Doh! Will fix in the next pushed.

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From kcr at openjdk.java.net  Thu May 26 23:28:36 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 26 May 2022 23:28:36 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <xzVcXALL28qJq-ehqZ4nE80Vc9F_pw6dE3kggqVh0e0=.c4c87998-8bf1-4bb1-b443-0f841581da75@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by kcr (Author).

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From iris at openjdk.java.net  Fri May 27 04:04:35 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 27 May 2022 04:04:35 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <hBtEDFsu7ZcoARe5fQvkS8mAaQji5T0oyobLuw-AWSA=.1329454b-1c6f-4c10-b901-60c8d0041437@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From dholmes at openjdk.java.net  Fri May 27 06:22:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 27 May 2022 06:22:36 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <ZQQCEKUqSLliJKT0nvSvkILQOKheOXL6g9D0SJ94FMs=.b89e74c6-f260-4840-b45a-feb1ad126f34@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From shade at openjdk.java.net  Fri May 27 12:24:28 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 27 May 2022 12:24:28 GMT
Subject: RFR: 8287439: Problemlist more failing x86_32 tests after Record
 Patterns integration
Message-ID: <sNIdS-MXHISq00qrTRIie4s_RGYrqdu7MjYiUT1D39c=.d768ed6c-2eac-4236-aaa0-3daab7faf3fa@github.com>

[JDK-8262889](https://bugs.openjdk.java.net/browse/JDK-8262889) brought more --enable-preview tests, which still fails due to incomplete Loom implementation. These fail in GHA too.

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/8920

From erikj at openjdk.java.net  Fri May 27 12:24:52 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 27 May 2022 12:24:52 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <nDBC7Dte9wQnZZt57WhgVNtrMWNCH-oTu-0HwGmQXyw=.d4a5f848-a462-45a3-b881-91fa131e4f74@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From vromero at openjdk.java.net  Fri May 27 15:45:46 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 27 May 2022 15:45:46 GMT
Subject: RFR: 8286895: InternalError: Exception during analyze
In-Reply-To: <HKXEJFSXoG7-7etDL09p1Gb39cdb13XfIOIWJd0JOcQ=.f9b4cde4-9b24-48bf-b3e9-576601c538fa@github.com>
References: <HKXEJFSXoG7-7etDL09p1Gb39cdb13XfIOIWJd0JOcQ=.f9b4cde4-9b24-48bf-b3e9-576601c538fa@github.com>
Message-ID: <ilGglXi2iPqIwx3bHa8FLo7vZRAf_w8JgY5bvE-d5g8=.13452b61-7a68-42aa-92ba-2f62fe0813a2@github.com>

On Tue, 24 May 2022 11:25:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> Number n = 0;
> if (!n instanceof Integer i) {}
> 
> javac parses this like:
> 
> Number n = 0;
> if ((!n) instanceof Integer i) {}
> 
> 
> This is obviously erroneous, and will report an error in `Attr`, but if this code gets to `Flow`, like in JShell, then it will split the `inits`/`uninits` of variables to the `true`/`false` inits while processing the unary negation. But, then, the `instanceof` operator will try to declare a variable, which will fail with on an assertion, as that shouldn't be done when the inits are split to `true`/`false`:
> 
> Caused by: java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.util.Bits.excl(Bits.java:220)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.newVar(Flow.java:1883)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitVarDef(Flow.java:2261)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1027)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:444)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1743)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.visitBindingPattern(TreeScanner.java:307)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitBindingPattern(Flow.java:2848)
> ...
> 
> 
> The proposed solution is to use `scanExpr` when handling the `instanceof`'s expression, which will merge the `true`/`false` inits, and let the variable be declared.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8866

From vromero at openjdk.java.net  Fri May 27 16:21:41 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 27 May 2022 16:21:41 GMT
Subject: RFR: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
In-Reply-To: <dqBbi4GOVqcPhe3rFaiTLomd7aHctz3GikhhDbAg41U=.ada60bff-e02b-4792-8a95-7623b40aa278@github.com>
References: <dqBbi4GOVqcPhe3rFaiTLomd7aHctz3GikhhDbAg41U=.ada60bff-e02b-4792-8a95-7623b40aa278@github.com>
Message-ID: <m_SrzAcPitk_YACVQSKRMuFmF4B_t9JDt0Yn7GO5uuE=.47ea78af-da73-4e5e-a67a-c4f3ebe3d612@github.com>

On Tue, 24 May 2022 12:47:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Normally, a switch expression must yield a value. But, there are cases where the switch expression has a value in the javac frontend, but, due to optimizations, not when the code is generated. For example:
> 
> int i = 1 + switch (0) { default -> {if (true) throw new RuntimeException(); else yield 0; } };
> 
> 
> javac will optimize the else section away, and the switch expression will always end abruptly. But, javac's simulated stack will still contain the left value of the binary operator, which will never be removed, and javac will consequently fail:
> 
> .java:2: error: Internal error: stack sim error on t()
>     private void t() {
>                      ^
> 1 error
> 
> 
> The proposed solution is twofold:
> - the throw statement/instruction should clear the stack, which adheres more closely to the runtime behavior of the instruction. This is the change in `Code`.
> - skipping code generation for expressions when the code is not "alive", as such code does not have any sense. This is similar to how statements are generated. This is the change in `Gen`.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8867

From iris at openjdk.java.net  Fri May 27 17:50:46 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 27 May 2022 17:50:46 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <iI20fWu6oqalfNEr-eik3gCtFZ0WHonoiP-su_b-e50=.4a1d00f7-77ed-4657-95b5-1b68953108c5@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From mdoerr at openjdk.java.net  Mon May 30 09:12:24 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 30 May 2022 09:12:24 GMT
Subject: RFR: 8286855: javac error on invalid jar should only print
 filename
In-Reply-To: <aw66t8BeavkbsNqpWG6Ql5QaUmD2KGM7U3tX6r82mLU=.7d926b55-4f3f-4a49-a496-05186f02e1ad@github.com>
References: <aw66t8BeavkbsNqpWG6Ql5QaUmD2KGM7U3tX6r82mLU=.7d926b55-4f3f-4a49-a496-05186f02e1ad@github.com>
Message-ID: <wYlMmlv7w1ADu66liva6nmw0NvRHNFZZQh8YYNP3rFo=.77f33ed7-045c-42ab-941b-19395759512f@github.com>

On Thu, 26 May 2022 09:58:12 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> As was suggested in the [review for JDK-8286444](https://github.com/openjdk/jdk/pull/8616#discussion_r873099812), javac should always print the filename only, when encountering a ZipException.

Ok, that was discussed in https://github.com/openjdk/jdk/pull/8616. I agree with your assessment that printing the full path should not really be problematic, but printing the file name only should be sufficient.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8900

From shade at openjdk.java.net  Mon May 30 12:47:27 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 30 May 2022 12:47:27 GMT
Subject: Withdrawn: 8287439: Problemlist more failing x86_32 tests after Record
 Patterns integration
In-Reply-To: <sNIdS-MXHISq00qrTRIie4s_RGYrqdu7MjYiUT1D39c=.d768ed6c-2eac-4236-aaa0-3daab7faf3fa@github.com>
References: <sNIdS-MXHISq00qrTRIie4s_RGYrqdu7MjYiUT1D39c=.d768ed6c-2eac-4236-aaa0-3daab7faf3fa@github.com>
Message-ID: <yRtLAD3f5XibftF-xrSHd7-kpOALk_S09HBjdVN7lyA=.9f20d034-25c9-4d6a-be24-b2fcae72d921@github.com>

On Fri, 27 May 2022 12:15:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8262889](https://bugs.openjdk.java.net/browse/JDK-8262889) brought more --enable-preview tests, which still fails due to incomplete Loom implementation. These fail in GHA too.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8920

From shade at openjdk.java.net  Mon May 30 13:28:19 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 30 May 2022 13:28:19 GMT
Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437
Message-ID: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>

[JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.

Additional testing:
 - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
 - [ ] Linux x86_32 fastdebug `tier1`
 - [ ] Linux x86_32 fastdebug `tier2`
 - [ ] Linux x86_32 fastdebug `tier3`
 - [ ] GHA run

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

Commit messages:
 - Keep GetEventWriter on problemlist
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/8946

From clanger at openjdk.java.net  Mon May 30 15:05:23 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 30 May 2022 15:05:23 GMT
Subject: RFR: 8286855: javac error on invalid jar should only print
 filename
In-Reply-To: <aw66t8BeavkbsNqpWG6Ql5QaUmD2KGM7U3tX6r82mLU=.7d926b55-4f3f-4a49-a496-05186f02e1ad@github.com>
References: <aw66t8BeavkbsNqpWG6Ql5QaUmD2KGM7U3tX6r82mLU=.7d926b55-4f3f-4a49-a496-05186f02e1ad@github.com>
Message-ID: <EZLOjGqs_ky3x7SosdZZ_5pB3RTttZ5E_6q9DoeyqCQ=.57089f56-71f2-4a21-bd0f-5e841f36cf8e@github.com>

On Thu, 26 May 2022 09:58:12 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> As was suggested in the [review for JDK-8286444](https://github.com/openjdk/jdk/pull/8616#discussion_r873099812), javac should always print the filename only, when encountering a ZipException.

Thanks for the reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/8900

From clanger at openjdk.java.net  Mon May 30 15:05:23 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 30 May 2022 15:05:23 GMT
Subject: Integrated: 8286855: javac error on invalid jar should only print
 filename
In-Reply-To: <aw66t8BeavkbsNqpWG6Ql5QaUmD2KGM7U3tX6r82mLU=.7d926b55-4f3f-4a49-a496-05186f02e1ad@github.com>
References: <aw66t8BeavkbsNqpWG6Ql5QaUmD2KGM7U3tX6r82mLU=.7d926b55-4f3f-4a49-a496-05186f02e1ad@github.com>
Message-ID: <fkwndmxNjyqPy0DbnRgsJKrm04LZIuv6DtVPf0H2KQ0=.4b5c0cf2-f462-43d5-8576-3e4fbceb8dbb@github.com>

On Thu, 26 May 2022 09:58:12 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> As was suggested in the [review for JDK-8286444](https://github.com/openjdk/jdk/pull/8616#discussion_r873099812), javac should always print the filename only, when encountering a ZipException.

This pull request has now been integrated.

Changeset: 1606d554
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1606d5545b8daad840575b7cfd97b94fd8a3d41d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8286855: javac error on invalid jar should only print filename

Reviewed-by: jpai, mdoerr

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

PR: https://git.openjdk.java.net/jdk/pull/8900

From asotona at openjdk.java.net  Tue May 31 09:39:27 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 31 May 2022 09:39:27 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <9FbplkFd9TjZnpIm_xNikh3Q80b5h0ELoLL5RADbyXw=.d83fdcc0-2ab0-4a8a-a45e-dda9af644cd1@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

Followup issues to narrow the situation with optional module dependencies have been filled:
- [8287559: Jlink should warn user about unsatisfied optional modules dependencies](https://bugs.openjdk.java.net/browse/JDK-8287559)
- [8287560: jdk.compiler dependency on jdk.zipfs should be declared as optional](https://bugs.openjdk.java.net/browse/JDK-8287560)

Please review if you agree with actual patch adding jdk.compiler dependency on jdk.zips.

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

PR: https://git.openjdk.java.net/jdk/pull/8747

From shade at openjdk.java.net  Tue May 31 10:34:29 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 May 2022 10:34:29 GMT
Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437
In-Reply-To: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
Message-ID: <ws3KBGCtl3vrtNgpNUuoUuiTlkSR1HGPfqsFJ9VoImg=.e4a15d5c-be84-46b1-bf63-771972c57bad@github.com>

On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
> 
> Additional testing:
>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [ ] GHA run

Open for reviews. The test failures on Windows x64 are known and are solved separately.

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

PR: https://git.openjdk.java.net/jdk/pull/8946

From jlahoda at openjdk.java.net  Tue May 31 11:08:47 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 31 May 2022 11:08:47 GMT
Subject: Integrated: 8276836: Error in javac caused by switch expression
 without result expressions: Internal error: stack sim error
In-Reply-To: <dqBbi4GOVqcPhe3rFaiTLomd7aHctz3GikhhDbAg41U=.ada60bff-e02b-4792-8a95-7623b40aa278@github.com>
References: <dqBbi4GOVqcPhe3rFaiTLomd7aHctz3GikhhDbAg41U=.ada60bff-e02b-4792-8a95-7623b40aa278@github.com>
Message-ID: <V5fszjBI59ZheT4xfZx7MB5Jk1StW9dyL4GauaswVwM=.93bfe6c0-be49-4a09-96b2-2bb79fbd6b77@github.com>

On Tue, 24 May 2022 12:47:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Normally, a switch expression must yield a value. But, there are cases where the switch expression has a value in the javac frontend, but, due to optimizations, not when the code is generated. For example:
> 
> int i = 1 + switch (0) { default -> {if (true) throw new RuntimeException(); else yield 0; } };
> 
> 
> javac will optimize the else section away, and the switch expression will always end abruptly. But, javac's simulated stack will still contain the left value of the binary operator, which will never be removed, and javac will consequently fail:
> 
> .java:2: error: Internal error: stack sim error on t()
>     private void t() {
>                      ^
> 1 error
> 
> 
> The proposed solution is twofold:
> - the throw statement/instruction should clear the stack, which adheres more closely to the runtime behavior of the instruction. This is the change in `Code`.
> - skipping code generation for expressions when the code is not "alive", as such code does not have any sense. This is similar to how statements are generated. This is the change in `Gen`.

This pull request has now been integrated.

Changeset: 7ef69935
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7ef6993576006d5fd09186870064d4dc1996e846
Stats:     219 lines in 3 files changed: 218 ins; 0 del; 1 mod

8276836: Error in javac caused by switch expression without result expressions: Internal error: stack sim error

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8867

From alanb at openjdk.java.net  Tue May 31 11:47:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 11:47:48 GMT
Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437
In-Reply-To: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
Message-ID: <ghz7LkXixuRxYvAy3J1wrJi_UysWA7sgo4FsKTelqu4=.2f310a57-6e5e-4464-8198-22175d868643@github.com>

On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
> 
> Additional testing:
>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [ ] GHA run

This looks okay.  If we get PR8939 in then it should be possible to do more clear out of the exclude lists.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8946

From shade at openjdk.java.net  Tue May 31 14:03:42 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 May 2022 14:03:42 GMT
Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437
In-Reply-To: <ghz7LkXixuRxYvAy3J1wrJi_UysWA7sgo4FsKTelqu4=.2f310a57-6e5e-4464-8198-22175d868643@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
 <ghz7LkXixuRxYvAy3J1wrJi_UysWA7sgo4FsKTelqu4=.2f310a57-6e5e-4464-8198-22175d868643@github.com>
Message-ID: <J5IU0BsxDE88Le03wdc3WaGL7uRrDqRyWUEC_X67UZw=.93efc962-fee2-4e81-8e9b-fe14911d7040@github.com>

On Tue, 31 May 2022 11:44:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
>> 
>> Additional testing:
>>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>>  - [x] Linux x86_32 fastdebug `tier1`
>>  - [x] GHA run
>
> This looks okay.  If we get PR8939 in then it should be possible to do more clear out of the exclude lists.

Thank you, @AlanBateman. Any other comments? I plan to integrate it soon.

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

PR: https://git.openjdk.java.net/jdk/pull/8946

From jlahoda at openjdk.java.net  Tue May 31 15:05:53 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 31 May 2022 15:05:53 GMT
Subject: Integrated: 8286895: InternalError: Exception during analyze
In-Reply-To: <HKXEJFSXoG7-7etDL09p1Gb39cdb13XfIOIWJd0JOcQ=.f9b4cde4-9b24-48bf-b3e9-576601c538fa@github.com>
References: <HKXEJFSXoG7-7etDL09p1Gb39cdb13XfIOIWJd0JOcQ=.f9b4cde4-9b24-48bf-b3e9-576601c538fa@github.com>
Message-ID: <pWJ6e2CBWMg05x91Zq1wUL5xe-Wz-P_lb_4NjRzHajM=.72cb1447-fff5-4fc7-8f5d-ccbce24fc10a@github.com>

On Tue, 24 May 2022 11:25:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> Number n = 0;
> if (!n instanceof Integer i) {}
> 
> javac parses this like:
> 
> Number n = 0;
> if ((!n) instanceof Integer i) {}
> 
> 
> This is obviously erroneous, and will report an error in `Attr`, but if this code gets to `Flow`, like in JShell, then it will split the `inits`/`uninits` of variables to the `true`/`false` inits while processing the unary negation. But, then, the `instanceof` operator will try to declare a variable, which will fail with on an assertion, as that shouldn't be done when the inits are split to `true`/`false`:
> 
> Caused by: java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.util.Bits.excl(Bits.java:220)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.newVar(Flow.java:1883)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitVarDef(Flow.java:2261)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1027)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:444)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:1743)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.visitBindingPattern(TreeScanner.java:307)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitBindingPattern(Flow.java:2848)
> ...
> 
> 
> The proposed solution is to use `scanExpr` when handling the `instanceof`'s expression, which will merge the `true`/`false` inits, and let the variable be declared.

This pull request has now been integrated.

Changeset: 171a7cdd
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/171a7cdd5d44265b17541e17304e9ebed376a9fd
Stats:     31 lines in 4 files changed: 30 ins; 0 del; 1 mod

8286895: InternalError: Exception during analyze

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8866

From hannesw at openjdk.java.net  Tue May 31 16:04:47 2022
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 31 May 2022 16:04:47 GMT
Subject: RFR: JDK-8287337: SnippetUtils should throw exceptions if snippets
 not found
In-Reply-To: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>
References: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>
Message-ID: <RN2g852VE7e7AVET2njfvnu0HO7AkaaV0NKtQBy00G4=.da58f861-16cb-4a17-9c4d-d93aa325985e@github.com>

On Wed, 25 May 2022 19:38:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple change for `SnippetUtils` to throw a checked exception if a snippet cannot be found.

Looks good to me. I'm not sure the `requireNonNull` method carries its own weight given that one `getSnippetById` method could by implemented by calling the other, but that's a minor stylistic concern.

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

Marked as reviewed by hannesw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8892

From jlahoda at openjdk.java.net  Tue May 31 16:20:24 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 31 May 2022 16:20:24 GMT
Subject: RFR: 8287236: Reorganize AST related to pattern matching for switch
Message-ID: <wPMQTWs7GB--mzTFHCTF-Ie8M-ps-tOfPZ5WsJ209vM=.8a3fde5b-c385-42cb-bb74-df6989a9f07c@github.com>

Under JEP 427, case label elements may be: a) expressions; b) patterns; c) the default. Currently, this is modeled in the Trees API in a way where all expressions and patterns extend `CaseLabelTree`.

When guarded patterns were removed in favor of guards on pattern case label element, it was necessary to augment all patterns with a guard, which is only used when the pattern is used as a case label element. This is somewhat inconsistent for the Trees API.

A use a layer of indirection is proposed here: - the `CaseLabelTree` has three subtypes: `ConstantCaseLabelTree`, which contains `ExpressionTree` as a subnode; `PatternCaseLabelTree`, which contains `PatternTree` and a guard (`ExpressionTree`) as subnodes; and the `DefaultCaseLabelTree` for the default clause.

This patch also fixes `TreeScanner.visitCase`, which currently iterates only over `CaseTree.getExpressions()`, ignoring patterns. It is changed to iterate over `CaseTree.getLabels()`, to get all labels.

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

Commit messages:
 - Renaming ExpressionCaseLabelTree to ConstantCaseLabelTree and corresponding updates.
 - Cleanup.
 - Cleanup.
 - Cleanup.
 - Cleanup.
 - Merge branch 'master' into JDK-8287236
 - Cleanup.
 - Cleaning up the pattern/caselabel API.

Changes: https://git.openjdk.java.net/jdk/pull/8959/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8959&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287236
  Stats: 647 lines in 27 files changed: 421 ins; 100 del; 126 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8959/head:pull/8959

PR: https://git.openjdk.java.net/jdk/pull/8959

From jlahoda at openjdk.java.net  Tue May 31 17:08:32 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 31 May 2022 17:08:32 GMT
Subject: RFR: 8287236: Reorganize AST related to pattern matching for
 switch [v2]
In-Reply-To: <wPMQTWs7GB--mzTFHCTF-Ie8M-ps-tOfPZ5WsJ209vM=.8a3fde5b-c385-42cb-bb74-df6989a9f07c@github.com>
References: <wPMQTWs7GB--mzTFHCTF-Ie8M-ps-tOfPZ5WsJ209vM=.8a3fde5b-c385-42cb-bb74-df6989a9f07c@github.com>
Message-ID: <qtLf3X0bR06ngl9cg9AeJGRjAoQ0xFq6swfVssTnyIQ=.283f2282-6edc-4783-80ce-d07cb21cf847@github.com>

> Under JEP 427, case label elements may be: a) expressions; b) patterns; c) the default. Currently, this is modeled in the Trees API in a way where all expressions and patterns extend `CaseLabelTree`.
> 
> When guarded patterns were removed in favor of guards on pattern case label element, it was necessary to augment all patterns with a guard, which is only used when the pattern is used as a case label element. This is somewhat inconsistent for the Trees API.
> 
> A use a layer of indirection is proposed here: - the `CaseLabelTree` has three subtypes: `ConstantCaseLabelTree`, which contains `ExpressionTree` as a subnode; `PatternCaseLabelTree`, which contains `PatternTree` and a guard (`ExpressionTree`) as subnodes; and the `DefaultCaseLabelTree` for the default clause.
> 
> This patch also fixes `TreeScanner.visitCase`, which currently iterates only over `CaseTree.getExpressions()`, ignoring patterns. It is changed to iterate over `CaseTree.getLabels()`, to get all labels.

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

  Fixing test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8959/files
  - new: https://git.openjdk.java.net/jdk/pull/8959/files/7746c9fd..7a147c2f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8959&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8959&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8959/head:pull/8959

PR: https://git.openjdk.java.net/jdk/pull/8959

From shade at openjdk.java.net  Tue May 31 17:10:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 May 2022 17:10:33 GMT
Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437 [v2]
In-Reply-To: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
Message-ID: <VyKpscMr_TrwvuceTHSCJP39sq5pzFiUuj3vsXyg1iE=.3c5506a8-c2b8-4ff0-8559-baa7b94dcab3@github.com>

> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
> 
> Additional testing:
>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [x] GHA run

Aleksey Shipilev 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-8287520-loom-x86-32-shrink
 - Keep GetEventWriter on problemlist
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8946/files
  - new: https://git.openjdk.java.net/jdk/pull/8946/files/7c90ead6..a3c3db2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8946&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8946&range=00-01

  Stats: 38619 lines in 252 files changed: 17091 ins; 16971 del; 4557 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8946.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8946/head:pull/8946

PR: https://git.openjdk.java.net/jdk/pull/8946

From jjg at openjdk.java.net  Tue May 31 18:30:50 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 31 May 2022 18:30:50 GMT
Subject: RFR: JDK-8287337: SnippetUtils should throw exceptions if snippets
 not found
In-Reply-To: <RN2g852VE7e7AVET2njfvnu0HO7AkaaV0NKtQBy00G4=.da58f861-16cb-4a17-9c4d-d93aa325985e@github.com>
References: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>
 <RN2g852VE7e7AVET2njfvnu0HO7AkaaV0NKtQBy00G4=.da58f861-16cb-4a17-9c4d-d93aa325985e@github.com>
Message-ID: <hFkdxlMPYsejWh0R_F4uitgQG_bLQd7ktwktIurv6UA=.eae0f2a2-8cac-4d4f-a879-945f1452f560@github.com>

On Tue, 31 May 2022 16:02:40 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Looks good to me. I'm not sure the `requireNonNull` method carries its own weight given that one `getSnippetById` method could by implemented by calling the other, but that's a minor stylistic concern.

Note that the `requireNonNull` method is a local method to ensure the intended specific exception is thrown. It is not plain old `Objects.requireNonNull` that throws plain old NPE.

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

PR: https://git.openjdk.java.net/jdk/pull/8892

From darcy at openjdk.java.net  Tue May 31 20:32:13 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 31 May 2022 20:32:13 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>

> Time to start getting ready for JDK 20...

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

 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Respond to review feedback.
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Update symbol information for JDK 19 b23.
 - ... and 26 more: https://git.openjdk.java.net/jdk/compare/57d97d36...eedd36bd

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/96be1787..eedd36bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=01-02

  Stats: 41686 lines in 344 files changed: 18832 ins; 17644 del; 5210 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From iris at openjdk.java.net  Tue May 31 21:47:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 31 May 2022 21:47:40 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3]
In-Reply-To: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
Message-ID: <h9kns6pddZvzfAYdA1SIDbMZRZfWOoS3P09wkSGqC6o=.5cae6eb9-2a20-4d7f-a703-c77fb94dfdab@github.com>

On Tue, 31 May 2022 20:32:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:
> 
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbol information for JDK 19 b23.
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/d01d01b5...eedd36bd

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8236

From jjg at openjdk.java.net  Tue May 31 23:08:28 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 31 May 2022 23:08:28 GMT
Subject: RFR: JDK-8287337: SnippetUtils should throw exceptions if snippets
 not found
In-Reply-To: <hFkdxlMPYsejWh0R_F4uitgQG_bLQd7ktwktIurv6UA=.eae0f2a2-8cac-4d4f-a879-945f1452f560@github.com>
References: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>
 <RN2g852VE7e7AVET2njfvnu0HO7AkaaV0NKtQBy00G4=.da58f861-16cb-4a17-9c4d-d93aa325985e@github.com>
 <hFkdxlMPYsejWh0R_F4uitgQG_bLQd7ktwktIurv6UA=.eae0f2a2-8cac-4d4f-a879-945f1452f560@github.com>
Message-ID: <A2QHt6AuwmRafcwIfhcXZ0Uhu1hwQlnKB_3XYWUqW6M=.88cce450-7eee-44c1-b279-e95aa6d29b34@github.com>

On Tue, 31 May 2022 18:27:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Looks good to me. I'm not sure the `requireNonNull` method carries its own weight given that one `getSnippetById` method could by implemented by calling the other, but that's a minor stylistic concern.

OK, I looked at this again, and now see what you mean. I'll look at simplifying this.

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

PR: https://git.openjdk.java.net/jdk/pull/8892

From jjg at openjdk.java.net  Tue May 31 23:43:34 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 31 May 2022 23:43:34 GMT
Subject: RFR: JDK-8287337: SnippetUtils should throw exceptions if snippets
 not found [v2]
In-Reply-To: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>
References: <BK1HMeP0XsOw6QgvmUAj_qtxCGeSgCETTh8JBJhhAPE=.f35bdcdd-e568-47d3-a50f-01f9c9610e4e@github.com>
Message-ID: <DUmSuSqVS7zzX9yn10gDa4c5avpX2saIYnk33u63t6s=.286975b3-0a1d-4adc-8369-d01a4b02ab04@github.com>

> Please review a simple change for `SnippetUtils` to throw a checked exception if a snippet cannot be found.

Jonathan Gibbons 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:

 - address review feedback
 - Merge remote-tracking branch 'upstream/master' into 8287337.snippetutils
 - JDK-8287337: SnippetUtils should throw exceptions if snippets not found

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8892/files
  - new: https://git.openjdk.java.net/jdk/pull/8892/files/1d40bb1d..6d0f55fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8892&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8892&range=00-01

  Stats: 42320 lines in 364 files changed: 19210 ins; 17720 del; 5390 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8892.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8892/head:pull/8892

PR: https://git.openjdk.java.net/jdk/pull/8892