From jjg at openjdk.org  Thu Dec  1 00:53:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 00:53:23 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <ilsNgmMPrHB9Pm4jpbWYHTvxRF5_49JBZLbKEw_LwMI=.d9c2eba3-6aab-4bb4-9be3-bea34efc38ff@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11416

From cushon at openjdk.org  Thu Dec  1 01:29:40 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 01:29:40 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v3]
In-Reply-To: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
Message-ID: <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>

> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Improve test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11441/files
  - new: https://git.openjdk.org/jdk/pull/11441/files/eaab9b03..9abb827f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11441&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11441&range=01-02

  Stats: 33 lines in 1 file changed: 16 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11441.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11441/head:pull/11441

PR: https://git.openjdk.org/jdk/pull/11441

From cushon at openjdk.org  Thu Dec  1 01:29:44 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 01:29:44 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v2]
In-Reply-To: <GjT8_41bjngKPTaHub_trg66aUrtwNoLROS-MWxc89A=.4a670172-951a-40e5-960a-ac797f63401f@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com>
 <GjT8_41bjngKPTaHub_trg66aUrtwNoLROS-MWxc89A=.4a670172-951a-40e5-960a-ac797f63401f@github.com>
Message-ID: <QtDakxXJiOqyj1ZAYk70yV3Bh7GDFzw4brIfo0-Tdi8=.7247e1c6-57b9-424f-ab3a-f2ca51ea7c0d@github.com>

On Wed, 30 Nov 2022 22:15:14 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use TestNG, and assert on the compression method
>
> test/jdk/tools/jar/ManifestDirectoryCompression.java line 52:
> 
>> 50: 
>> 51:     /** Remove dirs & files needed for test. */
>> 52:     private static void cleanup(Path dir) {
> 
> This can leverage the @afterMethod annotation if the code is reworked slightly to make it more TestNG friendly

Thanks, done

> test/jdk/tools/jar/ManifestDirectoryCompression.java line 60:
> 
>> 58:             }
>> 59:             Files.delete(dir);
>> 60:         } catch (IOException e) {
> 
> Have the method throw IOException and you do not need the catch block

Unfortunately it's recursing on `cleanup` in the lambda, so it can't throw checked exceptions without more refactoring. This is imitating the recursive deletion approach in another jar test, I'm happy to swap this out if you'd prefer a different approach

> test/jdk/tools/jar/ManifestDirectoryCompression.java line 72:
> 
>> 70:             doTest(topDir.resolve("test.jar"), entry);
>> 71:         } finally {
>> 72:             cleanup(topDir);
> 
> See comment above regarding cleanup()

Thanks, I moved the cleanup into a separate `@AfterMethod`

> test/jdk/tools/jar/ManifestDirectoryCompression.java line 83:
> 
>> 81:         try (JarFile jarFile = new JarFile(jar.toFile())) {
>> 82:             ZipEntry zipEntry = jarFile.getEntry("META-INF/");
>> 83:             assertEquals(zipEntry.getMethod(), ZipEntry.STORED);
> 
> Probably worth verifying zipEntry is not null so you do not get an NPE

Done

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

PR: https://git.openjdk.org/jdk/pull/11441

From jlahoda at openjdk.org  Thu Dec  1 08:05:36 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Dec 2022 08:05:36 GMT
Subject: Integrated: 8294942: Compiler implementation for Record Patterns
 (Second Preview)
In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
Message-ID: <KfOd4NawXYYpvmMa2BdqM7r6yYqTOx5ETlPAmG7yUxk=.b4fec399-756a-4a63-936f-cc1f43358793@github.com>

On Fri, 21 Oct 2022 11:56:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
> 
>  - removal of named record patterns
>  - (preview) type inference for type test and record patterns
>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>  - fixing exhaustiveness of certain switches
> 
> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
> 
> For more information on the changes please see:
>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
> 
> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
> 
> Any feedback is welcome.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 756dd5bb
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/756dd5bb0d2ab3f956ecc6cfcf2b87810c763572
Stats:     1565 lines in 39 files changed: 1176 ins; 279 del; 110 mod

8294942: Compiler implementation for Record Patterns (Second Preview)
8294945: Compiler implementation for Pattern Matching for switch (Fourth Preview)

Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore, vromero

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

PR: https://git.openjdk.org/jdk/pull/10814

From jlahoda at openjdk.org  Thu Dec  1 08:13:18 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Dec 2022 08:13:18 GMT
Subject: RFR: 8297118: Change IncompatibleClassChangeError to
 MatchException for exhaustive switch statements and switch expressions [v2]
In-Reply-To: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
References: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
Message-ID: <Kc1lg-xMQyTe2Q-iLPi82q8VSck-ENcTMHfORagjShU=.fb134928-8608-41e1-bfcc-902cb4789e1d@github.com>

> As per recent update of the JEP 433 specification, javac should use MatchException instead of IncompatbileClassChangeError to flag switches over enum values that were exhaustive at compile time, but no longer are exhaustive at runtime. This patch implements that change.

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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11189/files
  - new: https://git.openjdk.org/jdk/pull/11189/files/c3385215..c3385215

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11189&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11189&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11189.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11189/head:pull/11189

PR: https://git.openjdk.org/jdk/pull/11189

From michal at kleczek.org  Thu Dec  1 08:24:07 2022
From: michal at kleczek.org (=?utf-8?Q?Micha=C5=82_K=C5=82eczek?=)
Date: Thu, 1 Dec 2022 09:24:07 +0100
Subject: Uses directive not visible in annotation processor when provider
 class not existing (yet)
Message-ID: <C70E4304-755D-47AE-9459-1492863D2ADD@kleczek.org>

Hi,

I am implementing an annotation processor that (among other things) is supposed to generate service provider classes that delegate calls to beans from a Spring application context.

The idea is to mark a module in module-info with an annotation and add ?provides Service with Implementation? where Implementation is not existent (yet).
Unfortunately it seems ModuleElement.getDirectives() does not return such a provides directive.

Is it a bug or I am missing something?

Thanks,
Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221201/54f0c693/attachment-0001.htm>

From alanb at openjdk.org  Thu Dec  1 09:21:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 09:21:33 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v3]
In-Reply-To: <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
Message-ID: <ug09RwQOFM0bijwdwzrCrIAz_Di9AwBF9XYOHQ2ltzk=.4b2f2270-ceb5-4471-bc1a-e551a5aca282@github.com>

On Thu, 1 Dec 2022 01:29:40 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 878:

> 876:                 ZipEntry e = new ZipEntry(MANIFEST_DIR);
> 877:                 setZipEntryTime(e);
> 878:                 e.setMethod(ZipEntry.STORED);

This should be okay, consistent with addFile where it will use STORED for directories.

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

PR: https://git.openjdk.org/jdk/pull/11441

From jlahoda at openjdk.org  Thu Dec  1 10:26:15 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Dec 2022 10:26:15 GMT
Subject: RFR: 8297118: Change IncompatibleClassChangeError to
 MatchException for exhaustive switch statements and switch expressions [v3]
In-Reply-To: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
References: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
Message-ID: <Usf6WHBrWElVViFOvdSfsM46KtYouw_IG-exqI_0rxA=.fc2bdccd-abcd-4e26-85e0-3bbd4f7242c5@github.com>

> As per recent update of the JEP 433 specification, javac should use MatchException instead of IncompatbileClassChangeError to flag switches over enum values that were exhaustive at compile time, but no longer are exhaustive at runtime. This patch implements that change.

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

 - Merge branch 'master' into IncompatibleClassChangeError-to-MatchException
 - Using pattern switch instead of record patterns as the feature key to determine whether MatchException should be used instead of ICCE.
 - 8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions
 - Using skipTypeVars as suggested.
 - Reflecting review feedback - proper handling of type vars and intersection types.
 - Not looking for common supertype, not solving in a loop.
 - Reflecting review comment.
 - Apply suggestions from code review
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Better tests for inference with recursive bounds, and related fixes.
 - Adding a kind to InstanceOfTree, as suggested.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/fa0c599a...1483a220

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

Changes: https://git.openjdk.org/jdk/pull/11189/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11189&range=02
  Stats: 226 lines in 4 files changed: 220 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11189.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11189/head:pull/11189

PR: https://git.openjdk.org/jdk/pull/11189

From jlahoda at openjdk.org  Thu Dec  1 10:56:36 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Dec 2022 10:56:36 GMT
Subject: Integrated: 8297118: Change IncompatibleClassChangeError to
 MatchException for exhaustive switch statements and switch expressions
In-Reply-To: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
References: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
Message-ID: <UNcYbP4DNjZvYYGIL4ahzNRjrMs_L-ty3-FfngFvEOw=.4a70d8a4-5649-4c5c-b8d4-58f48cf66db2@github.com>

On Wed, 16 Nov 2022 15:11:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As per recent update of the JEP 433 specification, javac should use MatchException instead of IncompatbileClassChangeError to flag switches over enum values that were exhaustive at compile time, but no longer are exhaustive at runtime. This patch implements that change.

This pull request has now been integrated.

Changeset: b60cce6f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b60cce6f3bf7dc96d632aa361a6eb10691dcf5c1
Stats:     226 lines in 4 files changed: 220 ins; 1 del; 5 mod

8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/11189

From abimpoudis at openjdk.org  Thu Dec  1 11:12:34 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 1 Dec 2022 11:12:34 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v19]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <SuSHj8WHe28LVO4WQxuA6W-nOJpUAfvx1wtNRqC8Du4=.399a96f4-240b-40ca-ab73-3eccb3cff818@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'JDK-8294942' into for-patterns
 - Merge branch 'master' into JDK-8294942
 - Move parsing tests to DisambiguatePatterns.java
 - Fixing handling of brackets in for/enhanced for/pattern enhanced for disambiguation. (#2)
   
   Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
 - Disable parsing test
 - Fix some classification issues (#3)
   
   * Fix some classification issues
   
   * Add tests
   (Note: compiler crashes on the type annotation)
 - Add @enablePreview
 - Merge branch 'JDK-8294942' into for-patterns
 - Merge branch 'master' into JDK-8294942
 - Fix selector type
 - ... and 32 more: https://git.openjdk.org/jdk/compare/7af6b4b5...38795e86

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

Changes: https://git.openjdk.org/jdk/pull/10798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=18
  Stats: 2410 lines in 54 files changed: 1950 ins; 286 del; 174 mod
  Patch: https://git.openjdk.org/jdk/pull/10798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798

PR: https://git.openjdk.org/jdk/pull/10798

From abimpoudis at openjdk.org  Thu Dec  1 11:37:30 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 1 Dec 2022 11:37:30 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v20]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <rrt92OFum9xj5RvCaF9T00wzS7AlIxWVvgIuppYteKw=.c41b62f2-ca93-48a9-836b-158eca2aa017@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:

 - Merge branch 'master' into for-patterns
 - Merge branch 'JDK-8294942' into for-patterns
 - Merge branch 'master' into JDK-8294942
 - Move parsing tests to DisambiguatePatterns.java
 - Fixing handling of brackets in for/enhanced for/pattern enhanced for disambiguation. (#2)
   
   Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
 - Disable parsing test
 - Fix some classification issues (#3)
   
   * Fix some classification issues
   
   * Add tests
   (Note: compiler crashes on the type annotation)
 - Add @enablePreview
 - Merge branch 'JDK-8294942' into for-patterns
 - Merge branch 'master' into JDK-8294942
 - ... and 33 more: https://git.openjdk.org/jdk/compare/b60cce6f...573c7dae

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

Changes: https://git.openjdk.org/jdk/pull/10798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=19
  Stats: 845 lines in 27 files changed: 774 ins; 7 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/10798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798

PR: https://git.openjdk.org/jdk/pull/10798

From lancea at openjdk.org  Thu Dec  1 11:51:27 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 1 Dec 2022 11:51:27 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v3]
In-Reply-To: <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
Message-ID: <hS22g3Dps56Hbj9yvUrSMbgykfBSsua5zTaQEM-DLyQ=.57413b78-855c-49df-9c75-b5e8539e37b4@github.com>

On Thu, 1 Dec 2022 01:29:40 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test

Thank you again for the latest updates.  I think we are close.  Please see the comments to further streamline the test and once addressed we should be good to go.

test/jdk/tools/jar/ManifestDirectoryCompression.java line 81:

> 79: 
> 80:     @Test
> 81:     public void run() throws Exception {

Please rename `run() `to something like `TestDirectoryCompressionMethod()`.  We are trying to make new tests have more meaningful names.

test/jdk/tools/jar/ManifestDirectoryCompression.java line 83:

> 81:     public void run() throws Exception {
> 82:         Path entryPath = Files.writeString(tempDir.resolve("test.txt"), "Some text...");
> 83:         Path jar = tempDir.resolve("test.jar");

Please see comment above regarding the cleanup method.

One other thought you could consider given you only create a jar and file to add to the jar, is to simply add File.deleteIfExists() calls and not bother with a cleanup method given the test case is small and pretty straight forward.  Your choice though :-)

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

PR: https://git.openjdk.org/jdk/pull/11441

From lancea at openjdk.org  Thu Dec  1 11:51:27 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 1 Dec 2022 11:51:27 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v2]
In-Reply-To: <QtDakxXJiOqyj1ZAYk70yV3Bh7GDFzw4brIfo0-Tdi8=.7247e1c6-57b9-424f-ab3a-f2ca51ea7c0d@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com>
 <GjT8_41bjngKPTaHub_trg66aUrtwNoLROS-MWxc89A=.4a670172-951a-40e5-960a-ac797f63401f@github.com>
 <QtDakxXJiOqyj1ZAYk70yV3Bh7GDFzw4brIfo0-Tdi8=.7247e1c6-57b9-424f-ab3a-f2ca51ea7c0d@github.com>
Message-ID: <7Nsh7xymaq8A6j6SPB_QDWH9xVZi1E2JL_UtM9bSDd8=.8c2afbb1-076f-495d-b3e9-e5077f149be2@github.com>

On Thu, 1 Dec 2022 01:21:13 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> test/jdk/tools/jar/ManifestDirectoryCompression.java line 60:
>> 
>>> 58:             }
>>> 59:             Files.delete(dir);
>>> 60:         } catch (IOException e) {
>> 
>> Have the method throw IOException and you do not need the catch block
>
> Unfortunately it's recursing on `cleanup` in the lambda, so it can't throw checked exceptions without more refactoring. This is imitating the recursive deletion approach in another jar test, I'm happy to swap this out if you'd prefer a different approach

Thanks for the reminder regarding lambada/checked exceptions. I think this can be simplified to just write the jar and test file to the current directory and then just call


Files.deleteIfExists(Path.of(JAR_FILE_NAME));
Files.deleteIfExists(Path.of(FILE_NAME));


as they are the only files used by the test .

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

PR: https://git.openjdk.org/jdk/pull/11441

From abimpoudis at openjdk.org  Thu Dec  1 12:44:11 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 1 Dec 2022 12:44:11 GMT
Subject: Integrated: 8294943: Implement record patterns in enhanced for
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <uhwuP9Go7L_2xEWgdPv_oheUJkNxoKU8BnZGrQ-neGI=.57a44eb4-9781-47f6-9053-9159a3400cc0@github.com>

On Thu, 20 Oct 2022 16:39:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

This pull request has now been integrated.

Changeset: 2cb64a75
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cb64a75578ccc15a1dfc8c2843aa11d05ca8aa7
Stats:     845 lines in 27 files changed: 774 ins; 7 del; 64 mod

8294943: Implement record patterns in enhanced for
8296802: Parse errors when deconstructing a record using the enhanced for loop of JEP 432

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore, vromero

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

PR: https://git.openjdk.org/jdk/pull/10798

From jan.lahoda at oracle.com  Thu Dec  1 15:45:53 2022
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 1 Dec 2022 16:45:53 +0100
Subject: Uses directive not visible in annotation processor when provider
 class not existing (yet)
In-Reply-To: <C70E4304-755D-47AE-9459-1492863D2ADD@kleczek.org>
References: <C70E4304-755D-47AE-9459-1492863D2ADD@kleczek.org>
Message-ID: <4f6b5f0b-00ad-84fb-9acf-03ccecc7c17d@oracle.com>

Hi Michal,


The provides directive returns TypeElement as the service and a list of 
TypeElements as the implementations, and I don't think we can reasonably 
model non-existing types as TypeElements (normally missing types are 
modeled as erroneous TypeMirrors, I believe). So, having the 
non-existent implementation listed in the directive is probably 
difficult. Currently, when there are no implementations, the directive 
is skipped altogether - it might be possible to change that, although I 
am not sure if that would be helpful (as the non-existent type would not 
be in the directive anyway).


Overall, I wonder how exactly is this meant to work. Using the 
(javac-specific) AST, one could get the (qualified) name that refers to 
the type that does not exist, but that may be a simple name, and depend 
on an import, so the correct FQN must be inferable somehow?


Thanks,

Jan


On 01. 12. 22 9:24, Micha? K?eczek wrote:
> Hi,
>
> I am implementing an annotation processor that (among other things) is 
> supposed to generate service provider classes that delegate calls to 
> beans from a Spring application context.
>
> The idea is to mark a module in module-info with an annotation and add 
> ?provides Service with Implementation? where Implementation is not 
> existent (yet).
> Unfortunately it seems ModuleElement.getDirectives() does not return 
> such a provides directive.
>
> Is it a bug or I am missing something?
>
> Thanks,
> Michal 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221201/fae6d8fb/attachment.htm>

From michal at kleczek.org  Thu Dec  1 16:42:35 2022
From: michal at kleczek.org (=?utf-8?Q?Micha=C5=82_K=C5=82eczek?=)
Date: Thu, 1 Dec 2022 17:42:35 +0100
Subject: Uses directive not visible in annotation processor when provider
 class not existing (yet)
In-Reply-To: <4f6b5f0b-00ad-84fb-9acf-03ccecc7c17d@oracle.com>
References: <C70E4304-755D-47AE-9459-1492863D2ADD@kleczek.org>
 <4f6b5f0b-00ad-84fb-9acf-03ccecc7c17d@oracle.com>
Message-ID: <5E3A3688-1DD0-46C0-AC96-C041FDD94964@kleczek.org>

Hi Jan,

Thanks for a quick response.

I am afraid I am not knowledgeable enough to tell how it might be implemented but the common pattern in annotation processors is to generate non-existing classes that are already used in the source code, ex:

@Immutable.Value
Interface MyImmutable extends WithMyImmutable { //WithMyImmutable is generated by annotation processor
}

I understand the difference is that in this case annotation processor doesn?t actually need to get the extended interface name but assumes the programmer follows a certain naming convention.

In my case I could extend the module annotation with an attribute containing some metadata used to generate classes. But that would require specifying them twice: in the annotation and in the actual provides directive.

From what I understand it is not easy to achieve without major API change. Will need to find a workaround then :)

Thanks,
Michal

> On 1 Dec 2022, at 16:45, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> Hi Michal,
> 
> 
> 
> The provides directive returns TypeElement as the service and a list of TypeElements as the implementations, and I don't think we can reasonably model non-existing types as TypeElements (normally missing types are modeled as erroneous TypeMirrors, I believe). So, having the non-existent implementation listed in the directive is probably difficult. Currently, when there are no implementations, the directive is skipped altogether - it might be possible to change that, although I am not sure if that would be helpful (as the non-existent type would not be in the directive anyway).
> 
> 
> 
> Overall, I wonder how exactly is this meant to work. Using the (javac-specific) AST, one could get the (qualified) name that refers to the type that does not exist, but that may be a simple name, and depend on an import, so the correct FQN must be inferable somehow?
> 
> 
> 
> Thanks,
> 
> Jan
> 
> 
> 
> On 01. 12. 22 9:24, Micha? K?eczek wrote:
>> Hi,
>> 
>> I am implementing an annotation processor that (among other things) is supposed to generate service provider classes that delegate calls to beans from a Spring application context.
>> 
>> The idea is to mark a module in module-info with an annotation and add ?provides Service with Implementation? where Implementation is not existent (yet).
>> Unfortunately it seems ModuleElement.getDirectives() does not return such a provides directive.
>> 
>> Is it a bug or I am missing something?
>> 
>> Thanks,
>> Michal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221201/0ad768c8/attachment-0001.htm>

From michal at kleczek.org  Thu Dec  1 16:42:35 2022
From: michal at kleczek.org (=?utf-8?Q?Micha=C5=82_K=C5=82eczek?=)
Date: Thu, 1 Dec 2022 17:42:35 +0100
Subject: Uses directive not visible in annotation processor when provider
 class not existing (yet)
In-Reply-To: <4f6b5f0b-00ad-84fb-9acf-03ccecc7c17d@oracle.com>
References: <C70E4304-755D-47AE-9459-1492863D2ADD@kleczek.org>
 <4f6b5f0b-00ad-84fb-9acf-03ccecc7c17d@oracle.com>
Message-ID: <5E3A3688-1DD0-46C0-AC96-C041FDD94964@kleczek.org>

Hi Jan,

Thanks for a quick response.

I am afraid I am not knowledgeable enough to tell how it might be implemented but the common pattern in annotation processors is to generate non-existing classes that are already used in the source code, ex:

@Immutable.Value
Interface MyImmutable extends WithMyImmutable { //WithMyImmutable is generated by annotation processor
}

I understand the difference is that in this case annotation processor doesn?t actually need to get the extended interface name but assumes the programmer follows a certain naming convention.

In my case I could extend the module annotation with an attribute containing some metadata used to generate classes. But that would require specifying them twice: in the annotation and in the actual provides directive.

From what I understand it is not easy to achieve without major API change. Will need to find a workaround then :)

Thanks,
Michal

> On 1 Dec 2022, at 16:45, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> Hi Michal,
> 
> 
> 
> The provides directive returns TypeElement as the service and a list of TypeElements as the implementations, and I don't think we can reasonably model non-existing types as TypeElements (normally missing types are modeled as erroneous TypeMirrors, I believe). So, having the non-existent implementation listed in the directive is probably difficult. Currently, when there are no implementations, the directive is skipped altogether - it might be possible to change that, although I am not sure if that would be helpful (as the non-existent type would not be in the directive anyway).
> 
> 
> 
> Overall, I wonder how exactly is this meant to work. Using the (javac-specific) AST, one could get the (qualified) name that refers to the type that does not exist, but that may be a simple name, and depend on an import, so the correct FQN must be inferable somehow?
> 
> 
> 
> Thanks,
> 
> Jan
> 
> 
> 
> On 01. 12. 22 9:24, Micha? K?eczek wrote:
>> Hi,
>> 
>> I am implementing an annotation processor that (among other things) is supposed to generate service provider classes that delegate calls to beans from a Spring application context.
>> 
>> The idea is to mark a module in module-info with an annotation and add ?provides Service with Implementation? where Implementation is not existent (yet).
>> Unfortunately it seems ModuleElement.getDirectives() does not return such a provides directive.
>> 
>> Is it a bug or I am missing something?
>> 
>> Thanks,
>> Michal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221201/0ad768c8/attachment-0002.htm>

From mcimadamore at openjdk.org  Thu Dec  1 16:51:29 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Dec 2022 16:51:29 GMT
Subject: RFR: 8297294: compiler/c2/irTests/TestMulNodeIdealization.java
 failed compilation [v2]
In-Reply-To: <Je1PdVZyuh4w6QJlisb1NVMyhV1vFPHDIxHKVMc4kio=.17c182fd-5c30-4ae4-bbff-41801fd4ac2e@github.com>
References: <WHc5ImdfAZ0dAlJdlHgevNuRTzAR_yZnURbcAfPYl-4=.122d1242-e5e3-406b-b3d8-52bae99b4b7b@github.com>
 <Je1PdVZyuh4w6QJlisb1NVMyhV1vFPHDIxHKVMc4kio=.17c182fd-5c30-4ae4-bbff-41801fd4ac2e@github.com>
Message-ID: <Dt29D14tHaMAHniJSqM4r-HCZIW4eqkzJMbjpWFYeEM=.fd71bfdc-2230-4e2a-88ab-9d131bae5109@github.com>

On Wed, 30 Nov 2022 18:29:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Given that the reported issue is intermittent I think we have two options here:
>> 
>> 1 - change the most probable use of a non-deterministic data structure that could be provoking this bug, to a deterministic one
>> 2 - change all uses of non-deterministic data structures
>> 
>> I first tried option `1` but TBH after going again to the code I can't find a clear suspect. I thought we had reduced the options for non-determinism in the inference engine to zero, rien, niente. But it seems like that's not the case. So I have gone for option `2`.
>> 
>> Comments?
>> TIA
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8297294' of https://github.com/vicente-romero-oracle/jdk into JDK-8297294
>  - 8297294: compiler/c2/irTests/TestMulNodeIdealization.java failed compilation

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11437

From cstein at openjdk.org  Thu Dec  1 16:52:36 2022
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 1 Dec 2022 16:52:36 GMT
Subject: Integrated: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <lZAtUZEOklC8hkoGANSV8U9RQosigGI36_pJft8Cpgk=.b18b40d7-32a1-4a25-95cf-159f554b4698@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

This pull request has now been integrated.

Changeset: c70d1e1b
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c70d1e1bd32c71e0d2df635bc565201a09084a83
Stats:     9 lines in 8 files changed: 0 ins; 0 del; 9 mod

8296710: Update to use jtreg 7.1

Reviewed-by: erikj, alanb, jjg

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

PR: https://git.openjdk.org/jdk/pull/11416

From cushon at openjdk.org  Thu Dec  1 17:00:02 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 17:00:02 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v4]
In-Reply-To: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
Message-ID: <sL7nHuMbpB_VELaadNz3leUnTEFu-KStN33EamCt6YE=.37ad0bee-c233-432c-9c9e-3db47eba721a@github.com>

> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Test improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11441/files
  - new: https://git.openjdk.org/jdk/pull/11441/files/9abb827f..96de05ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11441&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11441&range=02-03

  Stats: 32 lines in 1 file changed: 1 ins; 23 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11441.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11441/head:pull/11441

PR: https://git.openjdk.org/jdk/pull/11441

From cushon at openjdk.org  Thu Dec  1 17:00:03 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 17:00:03 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v2]
In-Reply-To: <7Nsh7xymaq8A6j6SPB_QDWH9xVZi1E2JL_UtM9bSDd8=.8c2afbb1-076f-495d-b3e9-e5077f149be2@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com>
 <GjT8_41bjngKPTaHub_trg66aUrtwNoLROS-MWxc89A=.4a670172-951a-40e5-960a-ac797f63401f@github.com>
 <QtDakxXJiOqyj1ZAYk70yV3Bh7GDFzw4brIfo0-Tdi8=.7247e1c6-57b9-424f-ab3a-f2ca51ea7c0d@github.com>
 <7Nsh7xymaq8A6j6SPB_QDWH9xVZi1E2JL_UtM9bSDd8=.8c2afbb1-076f-495d-b3e9-e5077f149be2@github.com>
Message-ID: <gAoMp2UQYJbwYyxepmn3EdfGh3L9tyVlYPSCreyY9Ec=.7281479b-3670-41fd-9316-47067a9fc7c0@github.com>

On Thu, 1 Dec 2022 11:44:07 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Unfortunately it's recursing on `cleanup` in the lambda, so it can't throw checked exceptions without more refactoring. This is imitating the recursive deletion approach in another jar test, I'm happy to swap this out if you'd prefer a different approach
>
> Thanks for the reminder regarding lambada/checked exceptions. I think this can be simplified to just write the jar and test file to the current directory and then just call
> 
> 
> Files.deleteIfExists(Path.of(JAR_FILE_NAME));
> Files.deleteIfExists(Path.of(FILE_NAME));
> 
> 
> as they are the only files used by the test .

Done, thanks

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

PR: https://git.openjdk.org/jdk/pull/11441

From cushon at openjdk.org  Thu Dec  1 17:00:07 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 17:00:07 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v3]
In-Reply-To: <hS22g3Dps56Hbj9yvUrSMbgykfBSsua5zTaQEM-DLyQ=.57413b78-855c-49df-9c75-b5e8539e37b4@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
 <hS22g3Dps56Hbj9yvUrSMbgykfBSsua5zTaQEM-DLyQ=.57413b78-855c-49df-9c75-b5e8539e37b4@github.com>
Message-ID: <fV-Ht1484VHuCDp0Y5CCJnz5MEKinXWxrDf5cJc-U5w=.6891443d-2cac-49d4-b26d-dbe2edb22591@github.com>

On Thu, 1 Dec 2022 11:44:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve test
>
> test/jdk/tools/jar/ManifestDirectoryCompression.java line 81:
> 
>> 79: 
>> 80:     @Test
>> 81:     public void run() throws Exception {
> 
> Please rename `run() `to something like `TestDirectoryCompressionMethod()`.  We are trying to make new tests have more meaningful names.

Done

> test/jdk/tools/jar/ManifestDirectoryCompression.java line 83:
> 
>> 81:     public void run() throws Exception {
>> 82:         Path entryPath = Files.writeString(tempDir.resolve("test.txt"), "Some text...");
>> 83:         Path jar = tempDir.resolve("test.jar");
> 
> Please see comment above regarding the cleanup method.
> 
> One other thought you could consider given you only create a jar and file to add to the jar, is to simply add File.deleteIfExists() calls and not bother with a cleanup method given the test case is small and pretty straight forward.  Your choice though :-)

Thanks - I left the cleanup in an `@After` method for now, but I'm happy to change it.

One small reason to keep the `@After` method is that I think it ensures the cleanup happens even if the test fails and exits early, without having to wrap the test body in a `try`/`finally`.

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

PR: https://git.openjdk.org/jdk/pull/11441

From lancea at openjdk.org  Thu Dec  1 18:06:17 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 1 Dec 2022 18:06:17 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v4]
In-Reply-To: <sL7nHuMbpB_VELaadNz3leUnTEFu-KStN33EamCt6YE=.37ad0bee-c233-432c-9c9e-3db47eba721a@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <sL7nHuMbpB_VELaadNz3leUnTEFu-KStN33EamCt6YE=.37ad0bee-c233-432c-9c9e-3db47eba721a@github.com>
Message-ID: <uuk1vCPqFKzQ8VrD37HYPERfis8s1LAaOR6ZK4liic4=.dd8b1bbe-7ad3-4298-a164-b297aaf37b5f@github.com>

On Thu, 1 Dec 2022 17:00:02 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test improvements

Thank you for the updates.  I think this is good to go :-)

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11441

From darcy at openjdk.org  Thu Dec  1 18:53:38 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Dec 2022 18:53:38 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v2]
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <ffGFfKVVqXYcANRB1UdVKkYHUs2obgp3P1aF8mv2bUU=.1a8c9d0c-5110-4516-8d25-ffa4956532f2@github.com>

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

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 14 additional commits since the last revision:

 - Update symbol information for JDK 20 build 26.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Fix failed HotSpot regression tests.
 - Merge branch 'master' into JDK-8296149
 - Update symbol information to JDK 20 build 24.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbols for JDK 20 b23.
 - Merge branch 'master' into JDK-8296149
 - ... and 4 more: https://git.openjdk.org/jdk/compare/c9a32e22...89731cb2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10924/files
  - new: https://git.openjdk.org/jdk/pull/10924/files/5810345e..89731cb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=00-01

  Stats: 14898 lines in 525 files changed: 8720 ins; 3390 del; 2788 mod
  Patch: https://git.openjdk.org/jdk/pull/10924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10924/head:pull/10924

PR: https://git.openjdk.org/jdk/pull/10924

From iris at openjdk.org  Thu Dec  1 19:18:28 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 1 Dec 2022 19:18:28 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v2]
In-Reply-To: <ffGFfKVVqXYcANRB1UdVKkYHUs2obgp3P1aF8mv2bUU=.1a8c9d0c-5110-4516-8d25-ffa4956532f2@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <ffGFfKVVqXYcANRB1UdVKkYHUs2obgp3P1aF8mv2bUU=.1a8c9d0c-5110-4516-8d25-ffa4956532f2@github.com>
Message-ID: <Z6o91npEbHUWgq5J7rXo9O4ftM206E2Iipsqe5_Cv6Q=.e37cf7c0-ec5f-4647-b2dc-8f8f75fef395@github.com>

On Thu, 1 Dec 2022 18:53:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> 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 14 additional commits since the last revision:
> 
>  - Update symbol information for JDK 20 build 26.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Fix failed HotSpot regression tests.
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information to JDK 20 build 24.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Update symbols for JDK 20 b23.
>  - Merge branch 'master' into JDK-8296149
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/03d7ad1d...89731cb2

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10924

From jjg at openjdk.org  Thu Dec  1 19:36:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:36:16 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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 five additional commits since the last revision:

 - Change ietf.org URLs to use rfc-editor.org
 - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
 - Remove updates from unexported files
 - Prefix RFC titles with `RFC NNNN:`
 - JDK-8296547: Add @spec tags to API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/3905ac83..07882ffc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=02-03

  Stats: 83309 lines in 1834 files changed: 38491 ins; 27762 del; 17056 mod
  Patch: https://git.openjdk.org/jdk/pull/11073.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073

PR: https://git.openjdk.org/jdk/pull/11073

From jjg at openjdk.org  Thu Dec  1 19:40:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:40:16 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
Message-ID: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>

On Thu, 10 Nov 2022 23:51:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> 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 five additional commits since the last revision:
>> 
>>  - Change ietf.org URLs to use rfc-editor.org
>>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>>  - Remove updates from unexported files
>>  - Prefix RFC titles with `RFC NNNN:`
>>  - JDK-8296547: Add @spec tags to API
>
> src/java.base/share/classes/java/lang/Character.java line 172:
> 
>> 170:  * occur. For example, in a future release, synchronization may fail.
>> 171:  *
>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
> 
> This should probably be removed, as the original link (explaining `U+n` notation) is broken.

@naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

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

PR: https://git.openjdk.org/jdk/pull/11073

From jjg at openjdk.org  Thu Dec  1 19:57:33 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:57:33 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
Message-ID: <XVUIV3LMzWV4Y-0veldczkRr4bD_X-2JxbRLJRDikeI=.36f81c4a-f467-4352-90ba-cc3fc656791f@github.com>

On Wed, 23 Nov 2022 23:04:36 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove updates from unexported files
>
> src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:
> 
>> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
>> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
>> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition
> 
> Hi Jon,
> 
> I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
> points to the fifth edition while @see second.
> 
> A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.
> 
> [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

The presentation of lists of `@spec` tags was fixed separately (JDK-8297802), and is incorporated into the latest docs that demo this work.   The same algorithm is now used for both `@see` and `@spec` tags ... if the links are short and do not contain commas, they will be displayed as an inline list; otherwise, they will be displayed in a bulleted list.

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

PR: https://git.openjdk.org/jdk/pull/11073

From naoto at openjdk.org  Thu Dec  1 21:23:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Dec 2022 21:23:09 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
 <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
Message-ID: <NzMOOFfncZ1U5XWrfhkWjwcvhKxiand9c5VfptjGehM=.9d78d127-3374-4c48-8a7d-614b64fcdb0a@github.com>

On Thu, 1 Dec 2022 19:37:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 172:
>> 
>>> 170:  * occur. For example, in a future release, synchronization may fail.
>>> 171:  *
>>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
>> 
>> This should probably be removed, as the original link (explaining `U+n` notation) is broken.
>
> @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

Either way is fine with me. I will fix it up if you choose the latter.

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

PR: https://git.openjdk.org/jdk/pull/11073

From jonathan.gibbons at oracle.com  Thu Dec  1 21:37:35 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 13:37:35 -0800
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <FVrTbaSxMtpBDeg9b-elYkMoCM_M72PLSAQGVplwe1Q=.44879b38-e84d-436d-a23c-43f2522acf9e@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <FVrTbaSxMtpBDeg9b-elYkMoCM_M72PLSAQGVplwe1Q=.44879b38-e84d-436d-a23c-43f2522acf9e@github.com>
Message-ID: <db794031-9464-a4f9-0486-547124ce1452@oracle.com>


On 11/10/22 8:18 PM, Chris Plummer wrote:
> On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
>
>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>>
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>>
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>>
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>>
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>>
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>>
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>>
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>>
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
> src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/Connection.java line 105:
>
>> 103:      *          If the length of the packet (as indictaed by the first
>> 104:      *          4 bytes) is less than 11 bytes, or an I/O error occurs.
>> 105:      * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/com/sun/jdi/connect/spi/Connection.html#readPacket()
>
> Within this javadoc page the jdwp-spec.html references are titled "JDWP Specification", but these `@spec` references are titled "Java Debug Wire Protocol". I suggest making them more consistent. There is one more case below and this same issue also applies to TransportService.java. Perhaps the title in jdwp-spec.html should be updated. I think "Java Debug Wire Protocol (JDWP) Specification" would be good.
>
> src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java line 79:
>
>> 77:  * target VM.
>> 78:  *
>> 79:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> See above comment for Connection.java.
>
> src/jdk.jdi/share/classes/module-info.java line 107:
>
>> 105:  *
>> 106:  *
>> 107:  * @spec jpda/jpda.html Java Platform Debugger Architecture
> http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/module-summary.html
>
> `@spec` and `@see` sections end up one right after the other with the same content, except the `@see` section has the preferred hyperlink title. Suggest you remove the `@see` section and also update `@spec` hyperlink title to include "(JPDA)", or update the actual title in the jpda.html doc so it includes "(JPDA)" in it and then rerun your tool.
>
> src/jdk.jdwp.agent/share/classes/module-info.java line 30:
>
>> 28:  *
>> 29:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
>> 30:  * @spec jdwp/jdwp-transport.html Java Debug Wire Protocol Transport Interface (jdwpTransport)
> http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdwp.agent/module-summary.html
>
> The end result here is not very clean. You have the same two specs being referred to just a few lines apart, and the hyperlink titles are not even close to be the same, even though the links are the same. Maybe the "@see" section should be removed.


Chris,

The general problem is that we're starting from an inconsistent code base.

Like you, I believe we should strive for consistency, especially between 
the title of the document and the label used in any URLs that point 
directly at the document.

This patch is generated by tooling that understands specific families of 
specs, including sites like `ietf.org` and the sibling `specs` 
directory.? I can update the title used in any `@spec` tag for any 
document in the sibling specs directory, but it is out of scope for this 
work to change the title within any specific document. That would need 
to be done in separate Enhancements, preferably by the teams owning the 
relevant documents.

As for `@see` tags, the tooling currently has the ability to remove a 
`@see` tag if both the URL and title match, although I have not enabled 
that option in the work so far.?? It might be reasonable to 
automatically remove the `@see` tag if just the URL matches, meaning it 
points to the same page, with no #fragment identifier.

-- Jon


>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/11073

From vromero at openjdk.org  Thu Dec  1 22:02:16 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 Dec 2022 22:02:16 GMT
Subject: Integrated: 8297294: compiler/c2/irTests/TestMulNodeIdealization.java
 failed compilation
In-Reply-To: <WHc5ImdfAZ0dAlJdlHgevNuRTzAR_yZnURbcAfPYl-4=.122d1242-e5e3-406b-b3d8-52bae99b4b7b@github.com>
References: <WHc5ImdfAZ0dAlJdlHgevNuRTzAR_yZnURbcAfPYl-4=.122d1242-e5e3-406b-b3d8-52bae99b4b7b@github.com>
Message-ID: <3q9jWT__8eDNA0Hzm9aWQbptuVi6j9qvQV13hiPpCvw=.5c023cdf-0d13-438c-98a9-b224be83d284@github.com>

On Wed, 30 Nov 2022 17:20:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Given that the reported issue is intermittent I think we have two options here:
> 
> 1 - change the most probable use of a non-deterministic data structure that could be provoking this bug, to a deterministic one
> 2 - change all uses of non-deterministic data structures
> 
> I first tried option `1` but TBH after going again to the code I can't find a clear suspect. I thought we had reduced the options for non-determinism in the inference engine to zero, rien, niente. But it seems like that's not the case. So I have gone for option `2`.
> 
> Comments?
> TIA

This pull request has now been integrated.

Changeset: 82031d32
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82031d32a002d183d2a18bd1e50bd5826b65380c
Stats:     7 lines in 2 files changed: 0 ins; 2 del; 5 mod

8297294: compiler/c2/irTests/TestMulNodeIdealization.java failed compilation

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/11437

From cushon at openjdk.org  Thu Dec  1 22:12:11 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 22:12:11 GMT
Subject: Integrated: 8297875: jar should not compress the manifest directory
 entry
In-Reply-To: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
Message-ID: <gnVE4y6Or5xfH2rmzDFVB5O-ghrtEu-hVahIf1sokYE=.96e27db2-76bb-4cf8-97f6-da67bb8f4b18@github.com>

On Wed, 30 Nov 2022 18:48:30 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

This pull request has now been integrated.

Changeset: e846b043
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e846b0438ca12f457ee763fed3a435d3a863c383
Stats:     75 lines in 2 files changed: 75 ins; 0 del; 0 mod

8297875: jar should not compress the manifest directory entry

Reviewed-by: lancea

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

PR: https://git.openjdk.org/jdk/pull/11441

From ihse at openjdk.org  Thu Dec  1 23:17:46 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Dec 2022 23:17:46 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v4]
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <Pe4HleOGP1lpFkT4ccYrcLk-vfEDFXpjETmtcvmlAh4=.49ae88da-cac1-4e35-b4dd-85a2ddf2f710@github.com>

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use Server.class instead of hard-coding a string

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11298/files
  - new: https://git.openjdk.org/jdk/pull/11298/files/82998663..414c8ac1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11298&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11298&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/11298

From ihse at openjdk.org  Thu Dec  1 23:17:47 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Dec 2022 23:17:47 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v3]
In-Reply-To: <OlS33zMeauZeFqPD85eKiYa4Pra2PypEp2_BKNdF3Tw=.5ab80a9f-94bc-4802-9c2a-be702f93e9ba@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
 <OlS33zMeauZeFqPD85eKiYa4Pra2PypEp2_BKNdF3Tw=.5ab80a9f-94bc-4802-9c2a-be702f93e9ba@github.com>
Message-ID: <rD4AUFKbN9wDNV_wThYwd-4X-ahDLrH-wvoJfmX7vIM=.cb28eaa5-ec5d-4825-97e8-5365ed57a790@github.com>

On Thu, 24 Nov 2022 20:36:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
>> 
>> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

I have now tested a variety of different scenarios, with incremental rebuilds with and without modified files, with and without syntax errors, and also with JDK_FILTER. I have also inadvertently found a way to crash javac (!) and verified that the stack trace too propagated just as it should. :-) (I will file a bug for this on javac)

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

PR: https://git.openjdk.org/jdk/pull/11298

From ihse at openjdk.org  Thu Dec  1 23:24:00 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Dec 2022 23:24:00 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <Woore_UT7iIJwUZ4t3oODIoHEacW2uGXr41Zkk_x2L4=.13e7db0d-e814-460e-976b-48acdbde5359@github.com>

On Tue, 22 Nov 2022 20:50:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

I have now verified that the interim compiler is indeed used (made it say bad words and fail at startup, so there is no doubt about it :)). As to the reason why this is so, here is the magic incantation from `$(INTERIM_LANGTOOLS_ARGS)`:


    --limit-modules java.base,jdk.zipfs,$(INTERIM_LANGTOOLS_MODULES_COMMA) \
    --add-modules $(INTERIM_LANGTOOLS_MODULES_COMMA) \
    --module-path $(BUILDTOOLS_OUTPUTDIR)/interim_langtools_modules \
    --patch-module java.base=$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim \
    --add-exports java.base/sun.reflect.annotation=jdk.compiler.interim \
    --add-exports java.base/jdk.internal.jmod=jdk.compiler.interim \
    --add-exports java.base/jdk.internal.misc=jdk.compiler.interim \
    --add-exports java.base/sun.invoke.util=jdk.compiler.interim \
    --add-exports java.base/jdk.internal.javac=java.compiler.interim \
    --add-exports java.base/jdk.internal.javac=jdk.compiler.interim \


I hope you are not asking me to explain in detail how or why this works. :-)

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

PR: https://git.openjdk.org/jdk/pull/11299

From ihse at openjdk.org  Thu Dec  1 23:45:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Dec 2022 23:45:08 GMT
Subject: Integrated: 8297444: Refactor the javacserver build tool
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <Ch4uRLEXKA7S9GXIjU8JqSGazORbjVyjEeIUyV6S-YE=.2cd1f1c7-eaf9-4c62-8117-d7cd0253f5f3@github.com>

On Tue, 22 Nov 2022 19:54:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

This pull request has now been integrated.

Changeset: 257aa15f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/257aa15f15bb835310132e6fb23e0362cafeb16a
Stats:     3441 lines in 35 files changed: 1199 ins; 2212 del; 30 mod

8297444: Refactor the javacserver build tool

Reviewed-by: erikj, cstein

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

PR: https://git.openjdk.org/jdk/pull/11298

From ihse at openjdk.org  Thu Dec  1 23:56:30 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Dec 2022 23:56:30 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac [v2]
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <aLoDwYu_YjlhQCr8ZbO5AwvIZCEQmYMh9xpXLwGQtjw=.2418e023-2e9c-4d35-97a5-3fb25d8d3831@github.com>

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

Magnus Ihse Bursie 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11299/files
  - new: https://git.openjdk.org/jdk/pull/11299/files/1ab659c0..1ab659c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11299&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11299&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11299.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11299/head:pull/11299

PR: https://git.openjdk.org/jdk/pull/11299

From ihse at openjdk.org  Fri Dec  2 00:03:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 00:03:37 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac [v3]
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <1HxbsqrXvFq1m9TWFZc9mYtqRml3uJDJy6ZzQY5j_tc=.fd3be40e-0212-4c1a-8892-2a077c232d62@github.com>

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into use-toolprovider-in-javacserver
 - 8297455: Use the official ToolProvider API to call javac
 - 8297444: Refactor the javacserver build tool

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

Changes: https://git.openjdk.org/jdk/pull/11299/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11299&range=02
  Stats: 12 lines in 1 file changed: 7 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11299.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11299/head:pull/11299

PR: https://git.openjdk.org/jdk/pull/11299

From ihse at openjdk.org  Fri Dec  2 00:06:53 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 00:06:53 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac [v4]
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <YGh4BYfV3G4_x3NCNlcIFTAFk3CSN_RGX2pSN0_m2Bk=.1b7ccca0-9ca2-43a0-be1a-e708db731d0d@github.com>

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge regressions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11299/files
  - new: https://git.openjdk.org/jdk/pull/11299/files/d2cd5690..d029b282

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11299&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11299&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/11299

From ihse at openjdk.org  Fri Dec  2 00:12:29 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 00:12:29 GMT
Subject: Integrated: 8297455: Use the official ToolProvider API to call javac
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <opnOVVsZSUPqoCKmDFIqCeybMtYo7uSs-rYIR6ZZ9TA=.9cbaca58-b382-4352-8828-b97d6f064d16@github.com>

On Tue, 22 Nov 2022 20:50:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

This pull request has now been integrated.

Changeset: b035056d
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b035056d28a1c6c738fed6dd7f3b4d9dac75c6c7
Stats:     10 lines in 1 file changed: 7 ins; 2 del; 1 mod

8297455: Use the official ToolProvider API to call javac

Reviewed-by: erikj

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

PR: https://git.openjdk.org/jdk/pull/11299

From jlahoda at openjdk.org  Fri Dec  2 10:37:54 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 Dec 2022 10:37:54 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v9]
In-Reply-To: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
Message-ID: <veaJLTJqEu4GvFS_3ZbPGzLKTJin8QGOBMD9xw1fo1o=.25106c5b-6e44-441f-a2d3-11e28100e603@github.com>

> This is an attempt to improve the performance and scalability of switches with record patterns.
> 
> There are two main parts of this patch:
> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
> 
> switch (obj) {
>      case Box(String s) -> {}
>      case Box(Integer i) -> {}
>      case Box(Number n) -> {}
>      ...
> }
> =>
> switch (obj) {
>      case Box b ->
>           switch (b.o()) {
>               case String s -> {}
>               case Integer i -> {}
>               case Number n -> {}
>               default -> continue-with-outer-switch;
>           };
>     ...
> }
> 
> 
> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
> 
> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
> 
> I ran the new code through a JMH benchmark:
> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
> 
> The results are:
>  - for "long" testcase (a switch with many cases):
> 
> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
> 
>  - for "short" testcase (a switch with no so many cases):
> 
> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
> 
> 
> So, the performance seems to be improved, at least in these cases.
> 
> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).

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

 - Post-merge fix.
 - Merge branch 'master' into JDK-8291769
 - Merge branch 'master' into JDK-8291769
 - Removing extra whitespace.
 - Reflecting review feedback.
 - Merge branch 'master' into JDK-8291769
 - Merge branch 'master' into JDK-8291769
 - Merge branch 'master' into JDK-8291769
 - Reflecting review feedback.
 - Merge branch 'master' into JDK-8291769
 - ... and 4 more: https://git.openjdk.org/jdk/compare/9f94cbec...0a51a780

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

Changes: https://git.openjdk.org/jdk/pull/9746/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=08
  Stats: 1440 lines in 13 files changed: 1276 ins; 67 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/9746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9746/head:pull/9746

PR: https://git.openjdk.org/jdk/pull/9746

From jlahoda at openjdk.org  Fri Dec  2 11:57:24 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 Dec 2022 11:57:24 GMT
Subject: RFR: 8297974: ClassCastException in
 com.sun.tools.javac.comp.AttrRecover.doRecovery
Message-ID: <_jkBBMI1mr4i5EgP6pdQpM3jdWdpQ3zHxMji5bTsvB0=.b16de08c-5778-448c-b791-529da586c35f@github.com>

Considering code like:

class RecoveryTest {

    interface I {
        int convert(int i);
    }

    void t(I f, String e) {
        t(param -> param); //a parameter missing here
    }

}


This is clearly wrong (the invocation of `t` is missing a parameter). But, running this crashes the compiler in addition to reporting the error:

$ javac -XDdev RecoveryTest.java

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

Commit messages:
 - 8297974: ClassCastException in com.sun.tools.javac.comp.AttrRecover.doRecovery

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

PR: https://git.openjdk.org/jdk/pull/11479

From dfuchs at openjdk.org  Fri Dec  2 12:15:23 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 2 Dec 2022 12:15:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
Message-ID: <4EIiX-uBShLoH1cl1MdngnvCc1HfVFXT_GJgFl5LoTE=.b07eefdf-8c2d-439e-a3c1-8ecfe323e2fd@github.com>

On Thu, 1 Dec 2022 19:36:16 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> 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 five additional commits since the last revision:
> 
>  - Change ietf.org URLs to use rfc-editor.org
>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>  - Remove updates from unexported files
>  - Prefix RFC titles with `RFC NNNN:`
>  - JDK-8296547: Add @spec tags to API

I have reviewed again the java.net, java.net.http, jdk.httpserver, java.naming, and javax.management changes - and I spotted a few places where the `@spec` duplicates an `@see` (noted below). I believe the duplicated `@see` should be removed now.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 62:

> 60:      * @spec https://www.rfc-editor.org/info/rfc919 RFC 919: Broadcasting Internet Datagrams
> 61:      * @see <a href="http://www.ietf.org/rfc/rfc919.txt">RFC&nbsp;929:
> 62:      * Broadcasting Internet Datagrams</a>

This `@see` line should now be removed since it's referencing the exact same document.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 83:

> 81:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 82:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122
> 83:      * Requirements for Internet Hosts -- Communication Layers</a>

Same remark here: please remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 154:

> 152:      * @spec https://www.rfc-editor.org/info/rfc1323 RFC 1323: TCP Extensions for High Performance
> 153:      * @see <a href="http://www.ietf.org/rfc/rfc1323.txt">RFC&nbsp;1323: TCP
> 154:      * Extensions for High Performance</a>

Remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 186:

> 184:      *
> 185:      * @spec https://www.rfc-editor.org/info/rfc793 RFC 793: Transmission Control Protocol
> 186:      * @see <a href="http://www.ietf.org/rfc/rfc793.txt">RFC&nbsp;793: Transmission

Remove the @see

src/java.base/share/classes/java/net/StandardSocketOptions.java line 377:

> 375:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 376:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122:
> 377:      * Requirements for Internet Hosts -- Communication Layers</a>

Remove the @see

src/java.management/share/classes/javax/management/remote/JMXServiceURL.java line 122:

> 120:  * @see <a
> 121:  * href="http://www.ietf.org/rfc/rfc2609.txt">RFC 2609,
> 122:  * "Service Templates and <code>Service:</code> Schemes"</a>

The two `@see` should now be removed

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

Changes requested by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11073

From erikj at openjdk.org  Fri Dec  2 13:42:15 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 Dec 2022 13:42:15 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
In-Reply-To: <Woore_UT7iIJwUZ4t3oODIoHEacW2uGXr41Zkk_x2L4=.13e7db0d-e814-460e-976b-48acdbde5359@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
 <Woore_UT7iIJwUZ4t3oODIoHEacW2uGXr41Zkk_x2L4=.13e7db0d-e814-460e-976b-48acdbde5359@github.com>
Message-ID: <rLu1oo3e5-o4FGW5nkjKLl4PMXB-PZ6SPoY6CX_0YXs=.011a7d11-4968-4640-ba8a-c8c05e46953d@github.com>

On Thu, 1 Dec 2022 23:21:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have now verified that the interim compiler is indeed used (made it say bad words and fail at startup, so there is no doubt about it :)). As to the reason why this is so, here is the magic incantation from `$(INTERIM_LANGTOOLS_ARGS)`:
> 
> ```
>     --limit-modules java.base,jdk.zipfs,$(INTERIM_LANGTOOLS_MODULES_COMMA) \
>     --add-modules $(INTERIM_LANGTOOLS_MODULES_COMMA) \
>     --module-path $(BUILDTOOLS_OUTPUTDIR)/interim_langtools_modules \
>     --patch-module java.base=$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim \
>     --add-exports java.base/sun.reflect.annotation=jdk.compiler.interim \
>     --add-exports java.base/jdk.internal.jmod=jdk.compiler.interim \
>     --add-exports java.base/jdk.internal.misc=jdk.compiler.interim \
>     --add-exports java.base/sun.invoke.util=jdk.compiler.interim \
>     --add-exports java.base/jdk.internal.javac=java.compiler.interim \
>     --add-exports java.base/jdk.internal.javac=jdk.compiler.interim \
> ```
> 
> I hope you are not asking me to explain in detail how or why this works. :-)

Thanks! Yeah, that rings a bell and I think I understand how it works, but I surely wouldn't be able to replicate this from memory.

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

PR: https://git.openjdk.org/jdk/pull/11299

From erikj at openjdk.org  Fri Dec  2 14:31:00 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 Dec 2022 14:31:00 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v30]
In-Reply-To: <ol0E1_Wje0XRQgoaDlbboZ9l_Zr9vV3dQ_VoryUJphg=.70bd7bd1-c56f-420e-a0e4-7fca91776d9c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
 <ol0E1_Wje0XRQgoaDlbboZ9l_Zr9vV3dQ_VoryUJphg=.70bd7bd1-c56f-420e-a0e4-7fca91776d9c@github.com>
Message-ID: <Bz9N4O4qUKCuVAt7ZoAZl1FkR48qI6iKm_S0FiJDANs=.511266f5-95b3-4e0b-82f6-fb5730ecdae2@github.com>

On Wed, 23 Nov 2022 15:38:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > /issue add JDK-8296302
> 
> The BOT comment at the top says /issue cannot refer to a CSR. You'll need to /issue remove it before integration.

Roger is correct, please do not add CSR issues with `/issue add`. The bot should auto discover CSRs if linked correctly in JBS. You need to `/issue remove` the CSR.

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

PR: https://git.openjdk.org/jdk/pull/10889

From vromero at openjdk.org  Fri Dec  2 15:31:22 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Dec 2022 15:31:22 GMT
Subject: RFR: 8297974: ClassCastException in
 com.sun.tools.javac.comp.AttrRecover.doRecovery
In-Reply-To: <_jkBBMI1mr4i5EgP6pdQpM3jdWdpQ3zHxMji5bTsvB0=.b16de08c-5778-448c-b791-529da586c35f@github.com>
References: <_jkBBMI1mr4i5EgP6pdQpM3jdWdpQ3zHxMji5bTsvB0=.b16de08c-5778-448c-b791-529da586c35f@github.com>
Message-ID: <Blfhk43gMCqiNIIZkhw7COiV6Up0LfumxRY-4d_Q3Mk=.27e45799-bbd1-4bfb-9fe6-bdc371b7bca1@github.com>

On Fri, 2 Dec 2022 11:46:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> class RecoveryTest {
> 
>     interface I {
>         int convert(int i);
>     }
> 
>     void t(I f, String e) {
>         t(param -> param); //a parameter missing here
>     }
> 
> }
> 
> 
> This is clearly wrong (the invocation of `t` is missing a parameter). But, running this crashes the compiler in addition to reporting the error:
> 
> $ javac -XDdev RecoveryTest.java

looks good

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11479

From ihse at openjdk.org  Fri Dec  2 16:46:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:46:11 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
Message-ID: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>

According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.

We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").

After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)

Doing so has a dual benefit:

1) It makes it clear to everyone reading the code that there is a trailing space and it is intended

2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.

Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

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

Commit messages:
 - 8298044: Fix hidden but significant trailing whitespace in properties files for langtools code

Changes: https://git.openjdk.org/jdk/pull/11487/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298044
  Stats: 18 lines in 10 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/11487.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11487/head:pull/11487

PR: https://git.openjdk.org/jdk/pull/11487

From ihse at openjdk.org  Fri Dec  2 16:46:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:46:11 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <vOT287F-td6cT6UHj7rw3ER9XFJKOX6j9ybpiH34WS0=.a736db14-bc4c-4227-aaf2-a9184bc79ab1@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

**A note to reviewers:**

This PR has been automatically generated by converting all trailing spaces in key-value lines (ignoring empty lines and comments) in the property files into unicode sequences.

In a way, this is a no-op, converting one representation of the already existing space into another. But I think that most of these instances are likely to be bugs, and should thus be fixed.

I think the easiest way to fix those instances is to use the Github "suggestion" review mechanism: 
If you see a value where the trailing space should be removed, press the blue `+` in the gutter as usual, and then in the comment box press the `+/-` icon (or press `ctrl-G`/`cmd-G`). Now you get a copy of the offending line, and can edit it to remove the trailing unicode sequence. I can then easily accept the suggestion into the PR.

But you can also come with review feedback like "remove trailing spaces for all files in directory XXX" and I'll fix that for you.

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

PR: https://git.openjdk.org/jdk/pull/11487

From jlaskey at openjdk.org  Fri Dec  2 16:51:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Dec 2022 16:51:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v32]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <U2ZZfoc2VKb3KdXhEy9dKR4yU6lUeawIDV9auD3nGkI=.fc56de1c-6752-4a41-ab64-6b33f784ad29@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:

 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - Seal Digits
 - Requested changes #11
 - Typo
 - Requested changes #10
 - Requested changes #9
 - Requested changes #8
 - ... and 37 more: https://git.openjdk.org/jdk/compare/6065696e...581e0f7a

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=31
  Stats: 9519 lines in 81 files changed: 9356 ins; 28 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From ihse at openjdk.org  Fri Dec  2 17:12:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:37 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:

[JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.

[JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Fri Dec  2 17:12:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:39 GMT
Subject: Withdrawn: 8295729: Add jcheck whitespace checking for properties
 files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <FucejIc47XdfLlKe8MOVxYBnv1k7GvnH1TgHiinx9ak=.b06a548a-3575-4456-8df4-f8804114105b@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Fri Dec  2 17:15:19 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Dec 2022 17:15:19 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
Message-ID: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>

On Fri, 2 Dec 2022 17:10:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> and instead I have split up this work in five different bugs

would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

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

PR: https://git.openjdk.org/jdk/pull/10792

From vromero at openjdk.org  Fri Dec  2 18:37:13 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Dec 2022 18:37:13 GMT
Subject: RFR: 8291769: Translation of switch with record patterns could be
 improved [v9]
In-Reply-To: <veaJLTJqEu4GvFS_3ZbPGzLKTJin8QGOBMD9xw1fo1o=.25106c5b-6e44-441f-a2d3-11e28100e603@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
 <veaJLTJqEu4GvFS_3ZbPGzLKTJin8QGOBMD9xw1fo1o=.25106c5b-6e44-441f-a2d3-11e28100e603@github.com>
Message-ID: <fUbxUpvcZ5feSyQtMvQc19c-wtGCgM2nKf7kXrenD1I=.56ce11f6-614d-49bd-9f2c-8097034044e8@github.com>

On Fri, 2 Dec 2022 10:37:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an attempt to improve the performance and scalability of switches with record patterns.
>> 
>> There are two main parts of this patch:
>> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
>> 
>> switch (obj) {
>>      case Box(String s) -> {}
>>      case Box(Integer i) -> {}
>>      case Box(Number n) -> {}
>>      ...
>> }
>> =>
>> switch (obj) {
>>      case Box b ->
>>           switch (b.o()) {
>>               case String s -> {}
>>               case Integer i -> {}
>>               case Number n -> {}
>>               default -> continue-with-outer-switch;
>>           };
>>     ...
>> }
>> 
>> 
>> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
>> 
>> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
>> 
>> I ran the new code through a JMH benchmark:
>> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
>> 
>> The results are:
>>  - for "long" testcase (a switch with many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
>> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
>> 
>>  - for "short" testcase (a switch with no so many cases):
>> 
>> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
>> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
>> 
>> 
>> So, the performance seems to be improved, at least in these cases.
>> 
>> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Post-merge fix.
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Removing extra whitespace.
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Merge branch 'master' into JDK-8291769
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291769
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/9f94cbec...0a51a780

looks good

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9746

From ihse at openjdk.org  Fri Dec  2 23:06:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 23:06:08 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
 <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
Message-ID: <BJDInfZQ8pfjgoiYRHsRTcw2dxBWSu4ZcsNC0wktKPM=.9fef5722-e842-4119-a380-46b5dd3bbc02@github.com>

On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:
>> 
>> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.
>> 
>> [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.
>
>> and instead I have split up this work in five different bugs
> 
> would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

@andy-goryachev-oracle No. Any such test is up to the component owners to write, if they deem it fitting.

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

PR: https://git.openjdk.org/jdk/pull/10792

From jjg at openjdk.org  Sat Dec  3 01:33:05 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 3 Dec 2022 01:33:05 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <OuwxEWxGXoHL8v7yO8cLObyH3RBpV1FIuwhu0W2NDi8=.61335f18-a62e-43b5-bbcc-c05e696c572a@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

All the files are localized versions of the underlying English files.

There are no changes in any of the underlying English files.  That suggests we should just let these localized versions "catch up" with the normal localization process, unless there is reason to believe that will not happen.

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

PR: https://git.openjdk.org/jdk/pull/11487

From darcy at openjdk.org  Sat Dec  3 23:10:48 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Dec 2022 23:10:48 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v3]
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

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 16 additional commits since the last revision:

 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbol information for JDK 20 build 26.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Fix failed HotSpot regression tests.
 - Merge branch 'master' into JDK-8296149
 - Update symbol information to JDK 20 build 24.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - ... and 6 more: https://git.openjdk.org/jdk/compare/7be0c7e6...515002c7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10924/files
  - new: https://git.openjdk.org/jdk/pull/10924/files/89731cb2..515002c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=01-02

  Stats: 14769 lines in 190 files changed: 1917 ins; 12471 del; 381 mod
  Patch: https://git.openjdk.org/jdk/pull/10924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10924/head:pull/10924

PR: https://git.openjdk.org/jdk/pull/10924

From jwaters at openjdk.org  Sun Dec  4 14:33:59 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 14:33:59 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <7I1sECma4ZPnJovaDu0nWm6IbIswf5cAq2OEI-pL2Ew=.ec62dcc8-e4f0-40f3-871f-068432123010@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

Just a heads up, this change seems to be responsible for the test failure on linux-x86 that's recently been persisting for quite a while

STDOUT:
config Test8296012.setUp(): failure
java.lang.IllegalStateException: Launching JShell execution engine threw: FailOverExecutionControlProvider: FAILED: 0:jdi:hostname(127.0.0.1) --
  Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3

Some closer examination suggests that something about the way this test is configured is not agreeing with the JVMTI implementation inside HotSpot:
`src/hotspot/share/prims/jni.cpp GetEnv()`

// No JVM TI with --enable-preview and no continuations support.
if (!VMContinuations && Arguments::enable_preview() && JvmtiExport::is_jvmti_version(version)) {
  *penv = NULL;
  ret = JNI_EVERSION;
  return ret;
}

(JNI_EVERSION is -3, which is the same error code the test failure produces)

I'm unfortunately not in the position to set up a Linux x86 environment and figure out what exactly is going wrong at the moment

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

PR: https://git.openjdk.org/jdk/pull/11363

From jwaters at openjdk.org  Sun Dec  4 15:05:17 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 15:05:17 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <72pN1GWz5XJLLjax1sjOr2aKVclchq6JyfMl1aDgZas=.74c7abe8-469c-4981-a6f8-163cd019127b@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

Nevermind, the cause was simpler than I expected, -XX:-VMContinuations is not on by default for every platform. I've just created a quick fix for this

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

PR: https://git.openjdk.org/jdk/pull/11363

From abimpoudis at openjdk.org  Sun Dec  4 15:30:02 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sun, 4 Dec 2022 15:30:02 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <aAzYTHXSp8ba_kAYChia8zp911b-iaOtj5mEJ0VFgsU=.777b0871-fb53-48b4-a917-8783cfd63d44@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

Thanks for the quick fix. However, why this commit triggered this failure? I assume `--enable-preview` is responsible for this. I wonder, no other JShell tests were passing `--enable-preview` before?

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

PR: https://git.openjdk.org/jdk/pull/11363

From jlahoda at openjdk.org  Mon Dec  5 07:19:43 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Dec 2022 07:19:43 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <SJ54H2Wd4DzQQnc8rVGrkRNAb0jDhN0r2_d-A4wg5uI=.5ba5096c-bd72-4e96-bdb4-24636088cfea@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

Hasn't the x86 failure been already resolved as https://github.com/openjdk/jdk/pull/11428 ?

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

PR: https://git.openjdk.org/jdk/pull/11363

From duke at openjdk.org  Mon Dec  5 07:25:59 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 07:25:59 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <ibwX-zVvNNEglc0O8Ath7yc_d7XiHJsBNRglPBU31F4=.e054fede-4d5a-4df5-9779-d5d9a95ac4a2@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties line 142:

> 140: doclet.Implementing_Classes=\u65E2\u77E5\u306E\u5B9F\u88C5\u30AF\u30E9\u30B9\u306E\u30EA\u30B9\u30C8:
> 141: doclet.Functional_Interface=\u6A5F\u80FD\u30A4\u30F3\u30BF\u30D5\u30A7\u30FC\u30B9
> 142: doclet.Functional_Interface_Message=\u3053\u308C\u306F\u6A5F\u80FD\u30A4\u30F3\u30BF\u30D5\u30A7\u30FC\u30B9\u306A\u306E\u3067\u3001\u30E9\u30E0\u30C0\u5F0F\u307E\u305F\u306F\u30E1\u30BD\u30C3\u30C9\u53C2\u7167\u306E\u5272\u5F53\u3066\u30BF\u30FC\u30B2\u30C3\u30C8\u3068\u3057\u3066\u4F7F\u7528\u3067\u304D\u307E\u3059\u3002\u0020

standard.properties (en, de, zh) does not have a trailing white space for doclet.Functional_Interface_Message.

For consistency, there should not be a space here.

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

PR: https://git.openjdk.org/jdk/pull/11487

From aturbanov at openjdk.org  Mon Dec  5 07:26:06 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Dec 2022 07:26:06 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v3]
In-Reply-To: <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>
Message-ID: <SPl9kw8GbMVLEIezNTdF6o5_S8m3dkaZo-WPNQjvTe4=.81bce95b-b3c7-4533-a877-15e4c2d3e366@github.com>

On Sat, 3 Dec 2022 23:10:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> 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 16 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information for JDK 20 build 26.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Fix failed HotSpot regression tests.
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information to JDK 20 build 24.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/c3a218e2...515002c7

test/langtools/tools/javac/versions/Versions.java line 91:

> 89:         EIGHTEEN(false,  "62.0", "18", Versions::checksrc18),
> 90:         NINETEEN(false,  "63.0", "19", Versions::checksrc19),
> 91:         TWENTY(false,  "64.0", "20", Versions::checksrc20),

nit:
Suggestion:

        TWENTY(false, "64.0", "20", Versions::checksrc20),

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

PR: https://git.openjdk.org/jdk/pull/10924

From duke at openjdk.org  Mon Dec  5 07:40:01 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 07:40:01 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <yBOkrZYiUK06kMHW4XJb_bxaO4kIaWJCwZBK3h28USk=.c17d71f8-5d83-45b5-83d5-c7df3b560b83@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 170:

> 168: jshell.console.no.javadoc = <Keine Dokumentation gefunden>
> 169: jshell.console.do.nothing = Nichts machen
> 170: jshell.console.choice = Auswahl:\u0020

This is correct.  However, the original l10n.properties did not get the change as intended.

l10n.properties had it implemented as 

`jshell.console.choice = Choice: `

The trailing white space was enclosed with a trailing `` (probably to signify the white space is intentional) and thus hidden from the script.

It should be changed to `jshell.console.choice = Choice:\u0020` for consistency

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

PR: https://git.openjdk.org/jdk/pull/11487

From jpai at openjdk.org  Mon Dec  5 09:28:02 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 Dec 2022 09:28:02 GMT
Subject: RFR: 8297682: Use Collections.emptyIterator where applicable
In-Reply-To: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
References: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
Message-ID: <ERqRMz7nA-5S0nOeOEeErdlDB6o6zkt-Gc_vIBlY-Vs=.441c50ab-e99c-468f-ae3f-b40118ce26e0@github.com>

On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
> Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

UnixFileSystem change looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11025

From jwaters at openjdk.org  Mon Dec  5 09:36:18 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Dec 2022 09:36:18 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <LFho9wSB910fSN9KsmhpiX4Hd5WnO48D5JBPkmKETzY=.babf3e92-621d-42ec-884d-12400e4b4c85@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

> Hasn't the x86 failure been already resolved as #11428 ?

Not entirely, the test this change added also needed `@requires vm.continuations` as well. I've already pushed a fix for it, so it should be good now

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

PR: https://git.openjdk.org/jdk/pull/11363

From jlahoda at openjdk.org  Mon Dec  5 09:37:54 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Dec 2022 09:37:54 GMT
Subject: Integrated: 8297974: ClassCastException in
 com.sun.tools.javac.comp.AttrRecover.doRecovery
In-Reply-To: <_jkBBMI1mr4i5EgP6pdQpM3jdWdpQ3zHxMji5bTsvB0=.b16de08c-5778-448c-b791-529da586c35f@github.com>
References: <_jkBBMI1mr4i5EgP6pdQpM3jdWdpQ3zHxMji5bTsvB0=.b16de08c-5778-448c-b791-529da586c35f@github.com>
Message-ID: <QxT_o9vr5G_tj-fmE2wPsezPpqa_J23jz4C9T5HFxSk=.9402c111-9cdf-4f79-9e29-7f9537265fc6@github.com>

On Fri, 2 Dec 2022 11:46:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> class RecoveryTest {
> 
>     interface I {
>         int convert(int i);
>     }
> 
>     void t(I f, String e) {
>         t(param -> param); //a parameter missing here
>     }
> 
> }
> 
> 
> This is clearly wrong (the invocation of `t` is missing a parameter). But, running this crashes the compiler in addition to reporting the error:
> 
> $ javac -XDdev RecoveryTest.java

This pull request has now been integrated.

Changeset: 777fb52e
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/777fb52ef5b0d95b756ce4fa71a7ddf2d7d2a8f1
Stats:     105 lines in 2 files changed: 104 ins; 0 del; 1 mod

8297974: ClassCastException in com.sun.tools.javac.comp.AttrRecover.doRecovery

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/11479

From sadayapalam at openjdk.org  Mon Dec  5 12:06:33 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Mon, 5 Dec 2022 12:06:33 GMT
Subject: RFR: 8295184: Printing messages with a RecordComponentElement does not
 include position
Message-ID: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>

Stash away a copy of the record component declaration from the header for use in diagnostics

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

Commit messages:
 - 8295184: Printing messages with a RecordComponentElement does not include position

Changes: https://git.openjdk.org/jdk/pull/11511/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11511&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295184
  Stats: 225 lines in 7 files changed: 209 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11511.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11511/head:pull/11511

PR: https://git.openjdk.org/jdk/pull/11511

From jlahoda at openjdk.org  Mon Dec  5 12:07:16 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Dec 2022 12:07:16 GMT
Subject: Integrated: 8291769: Translation of switch with record patterns could
 be improved
In-Reply-To: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
References: <Q4vgVSDLI9QVj0BONltn6ewb1ZDVWArZ3wVBxszo5nU=.7115a6df-e849-40ed-af1c-7cc540c3c75b@github.com>
Message-ID: <vmqMLO84U0V6VWCgnF1GLyEjR0zLkPaNYXqwnAtzXqw=.d3184e55-dc21-453d-ad40-e9521d42ce73@github.com>

On Thu, 4 Aug 2022 14:55:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an attempt to improve the performance and scalability of switches with record patterns.
> 
> There are two main parts of this patch:
> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.:
> 
> switch (obj) {
>      case Box(String s) -> {}
>      case Box(Integer i) -> {}
>      case Box(Number n) -> {}
>      ...
> }
> =>
> switch (obj) {
>      case Box b ->
>           switch (b.o()) {
>               case String s -> {}
>               case Integer i -> {}
>               case Number n -> {}
>               default -> continue-with-outer-switch;
>           };
>     ...
> }
> 
> 
> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible.
> 
> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers.
> 
> I ran the new code through a JMH benchmark:
> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt)
> 
> The results are:
>  - for "long" testcase (a switch with many cases):
> 
> PatternsOptimizationTest.testExistingTranslationLongSwitch   thrpt   25  1025740.668 ? 15325.355  ops/s
> PatternsOptimizationTest.testNewTranslationLongSwitch        thrpt   25  1588461.471 ? 15315.509  ops/s
> 
>  - for "short" testcase (a switch with no so many cases):
> 
> PatternsOptimizationTest.testExistingTranslationShortSwitch  thrpt   25  6418845.624 ? 75981.939  ops/s
> PatternsOptimizationTest.testNewTranslationShortSwitch       thrpt   25  6894823.439 ? 67420.858  ops/s
> 
> 
> So, the performance seems to be improved, at least in these cases.
> 
> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`).

This pull request has now been integrated.

Changeset: 2300ed45
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2300ed458dcda568afad818d2d3133e545a58ad5
Stats:     1440 lines in 13 files changed: 1276 ins; 67 del; 97 mod

8291769: Translation of switch with record patterns could be improved

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/9746

From jlahoda at openjdk.org  Mon Dec  5 12:09:32 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Dec 2022 12:09:32 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v3]
In-Reply-To: <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>
Message-ID: <ywUKswr0B5PnsPDUybLkFitaFpj0LkrrX4KpwdixuQk=.7cd41c9f-dca1-49ed-b34f-14b871353fb6@github.com>

On Sat, 3 Dec 2022 23:10:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> 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 16 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information for JDK 20 build 26.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Fix failed HotSpot regression tests.
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information to JDK 20 build 24.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ea5d4b3a...515002c7

javac changes look fine to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10924

From sadayapalam at openjdk.org  Mon Dec  5 12:51:06 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Mon, 5 Dec 2022 12:51:06 GMT
Subject: RFR: 8295184: Printing messages with a RecordComponentElement does
 not include position
In-Reply-To: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
References: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
Message-ID: <H7gDWBIxP5zBMpGCj4gN1coyZ5wwyy48ADk2MQcPL90=.ebdc4dec-8121-4cc9-808b-58aba8fefbdd@github.com>

On Mon, 5 Dec 2022 11:57:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Stash away a copy of the record component declaration from the header for use in diagnostics

At the moment, Record components as modelled by Javac do not have a backing AST. The record header declaration which according to JLS actually declares the record components, is folded into the private field declarations. When an annotation processor wants to print a message involving a record component, this becomes a blocker.

The present PR solves this problem by building upon what javac already does - for various reasons javac squirrels away the full list of annotations applied to a record component in the field originalAnnos of RecordComponent. Rather than just save away annotations alone, the present fix stashes away the entire AST, so this can be surfaced when required.

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

PR: https://git.openjdk.org/jdk/pull/11511

From vromero at openjdk.org  Mon Dec  5 16:32:14 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 5 Dec 2022 16:32:14 GMT
Subject: RFR: 8295184: Printing messages with a RecordComponentElement does
 not include position
In-Reply-To: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
References: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
Message-ID: <0UOdUg7_iQgsQmQiOXcYkaSnLuhzzpm9rEQxh3R5DmY=.6df38a07-700c-4773-a707-7128c7cc8674@github.com>

On Mon, 5 Dec 2022 11:57:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Stash away a copy of the record component declaration from the header for use in diagnostics

just a minor suggestion, looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1797:

> 1795:         private final boolean isVarargs;
> 1796: 
> 1797:         public JCVariableDecl ast;

I wouldn't let this field, public we would like to at least control that nobody can accidentally overwrite this field, so my proposal is to make it private and let clients read it

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11511

From sadayapalam at openjdk.org  Tue Dec  6 03:48:56 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Tue, 6 Dec 2022 03:48:56 GMT
Subject: RFR: 8295184: Printing messages with a RecordComponentElement does
 not include position [v2]
In-Reply-To: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
References: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
Message-ID: <CTGJpbcsOJwtoG4oW34KGqaoO3d2Miaf6DRBpqDvXRQ=.74255a22-8275-49d9-a55c-afb139c67a67@github.com>

> Stash away a copy of the record component declaration from the header for use in diagnostics

Srikanth Adayapalam 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-8295184
 - 8295184: Printing messages with a RecordComponentElement does not include position

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11511/files
  - new: https://git.openjdk.org/jdk/pull/11511/files/754966c6..804eb9c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11511&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11511&range=00-01

  Stats: 19386 lines in 367 files changed: 9783 ins; 5230 del; 4373 mod
  Patch: https://git.openjdk.org/jdk/pull/11511.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11511/head:pull/11511

PR: https://git.openjdk.org/jdk/pull/11511

From sadayapalam at openjdk.org  Tue Dec  6 04:10:26 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Tue, 6 Dec 2022 04:10:26 GMT
Subject: RFR: 8295184: Printing messages with a RecordComponentElement does
 not include position [v3]
In-Reply-To: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
References: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
Message-ID: <Yx6go8XgjCfkzFuw-sCWtT4gSVsRcKn2G0vVZhTzeWs=.100c2e12-608f-4501-87ba-75467476bb62@github.com>

> Stash away a copy of the record component declaration from the header for use in diagnostics

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate review comments from Vicente (Thanks!)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11511/files
  - new: https://git.openjdk.org/jdk/pull/11511/files/804eb9c3..a35c12b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11511&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11511&range=01-02

  Stats: 5 lines in 3 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11511.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11511/head:pull/11511

PR: https://git.openjdk.org/jdk/pull/11511

From sadayapalam at openjdk.org  Tue Dec  6 04:27:52 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Tue, 6 Dec 2022 04:27:52 GMT
Subject: Integrated: 8295184: Printing messages with a RecordComponentElement
 does not include position
In-Reply-To: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
References: <WLK6ZpgeDDlGmr6g74wvIZHRKRjtgTGkIJb3Psk7Eic=.0e67844e-84b1-473f-88b8-ab55c532bb94@github.com>
Message-ID: <M6GnOCoN-wwij6G8ZGl3-SznP4wgq5hGGJnFNDppCX4=.79adf1ee-8af0-49ae-86a6-62702d4ddf8a@github.com>

On Mon, 5 Dec 2022 11:57:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Stash away a copy of the record component declaration from the header for use in diagnostics

This pull request has now been integrated.

Changeset: ee9ba745
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee9ba7456403c59a6e14d22cf9c2f53eef97ea57
Stats:     227 lines in 7 files changed: 211 ins; 4 del; 12 mod

8295184: Printing messages with a RecordComponentElement does not include position

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/11511

From darcy at openjdk.org  Tue Dec  6 05:43:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Dec 2022 05:43:14 GMT
Subject: RFR: JDK-8298142: Update internal comment on language features in
 SourceVersion
Message-ID: <keywDlqXol42j_hszbAZwWFZDX3BdX8pQbJdMRIlfg4=.79344269-1886-49e4-902a-008cdad485d1@github.com>

Update the comments on the various source-versioning enums on the language changes in recent releases.

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

Commit messages:
 - JDK-8298142: Update internal comment on language features in SourceVersion

Changes: https://git.openjdk.org/jdk/pull/11525/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11525&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298142
  Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11525/head:pull/11525

PR: https://git.openjdk.org/jdk/pull/11525

From sundar at openjdk.org  Tue Dec  6 05:43:14 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 6 Dec 2022 05:43:14 GMT
Subject: RFR: JDK-8298142: Update internal comment on language features in
 SourceVersion
In-Reply-To: <keywDlqXol42j_hszbAZwWFZDX3BdX8pQbJdMRIlfg4=.79344269-1886-49e4-902a-008cdad485d1@github.com>
References: <keywDlqXol42j_hszbAZwWFZDX3BdX8pQbJdMRIlfg4=.79344269-1886-49e4-902a-008cdad485d1@github.com>
Message-ID: <X7I4QePpGwRFjbxlbl9sqx4By2_Z3B3rNcdzaiZEhQA=.0d9ef59a-34ac-4900-943e-217c9cb4012f@github.com>

On Tue, 6 Dec 2022 05:33:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update the comments on the various source-versioning enums on the language changes in recent releases.

LGTM

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

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11525

From abimpoudis at openjdk.org  Tue Dec  6 09:38:31 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 6 Dec 2022 09:38:31 GMT
Subject: RFR: 8297602: Compiler crash with type annotation and generic record
 during pattern matching
Message-ID: <tgoGyWX4Dt86Y8eoFVFKO-hDd39lnBcIdv7JO_Snj64=.4076d6c4-06a4-45d0-a4f1-2dfee375eee8@github.com>

In this PR we erase the annotation in the unhandled case of deconstruction patterns.

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

Commit messages:
 - 8297602: Compiler crash with type annotation and generic record during pattern matching

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

PR: https://git.openjdk.org/jdk/pull/11532

From jlahoda at openjdk.org  Tue Dec  6 09:38:31 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 6 Dec 2022 09:38:31 GMT
Subject: RFR: 8297602: Compiler crash with type annotation and generic
 record during pattern matching
In-Reply-To: <tgoGyWX4Dt86Y8eoFVFKO-hDd39lnBcIdv7JO_Snj64=.4076d6c4-06a4-45d0-a4f1-2dfee375eee8@github.com>
References: <tgoGyWX4Dt86Y8eoFVFKO-hDd39lnBcIdv7JO_Snj64=.4076d6c4-06a4-45d0-a4f1-2dfee375eee8@github.com>
Message-ID: <bmg8YAQHPkszz_9kPMGs5OmqPPgqq7crc9rekgGfNMg=.4e69d5df-c4c0-414b-852b-3241135b6b7d@github.com>

On Tue, 6 Dec 2022 09:28:56 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In this PR we erase the annotation in the unhandled case of deconstruction patterns.

Looks reasonable.

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

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11532

From jlahoda at openjdk.org  Tue Dec  6 12:09:09 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 6 Dec 2022 12:09:09 GMT
Subject: RFR: JDK-8298142: Update internal comment on language features in
 SourceVersion
In-Reply-To: <keywDlqXol42j_hszbAZwWFZDX3BdX8pQbJdMRIlfg4=.79344269-1886-49e4-902a-008cdad485d1@github.com>
References: <keywDlqXol42j_hszbAZwWFZDX3BdX8pQbJdMRIlfg4=.79344269-1886-49e4-902a-008cdad485d1@github.com>
Message-ID: <FfWqa5KBSEi4szMxcOHK64jC7o1db5dEk7zpoWMmCgI=.96f77687-17e5-44fc-be02-3113e8bd0d91@github.com>

On Tue, 6 Dec 2022 05:33:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update the comments on the various source-versioning enums on the language changes in recent releases.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11525

From jlahoda at openjdk.org  Tue Dec  6 12:28:46 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 6 Dec 2022 12:28:46 GMT
Subject: RFR: 8297988: NPE in JavacTypes.getOverriddenMethods from doclint
Message-ID: <PUt-yaGeDPhayis-ghpopFiTRnXDjVmJEE-cQPG0wQQ=.41ec6fc2-c97f-4ce4-be6c-e49ebac73704@github.com>

There are a few cases where `javac` parses Java source code, reads some name from the AST, and throws it away. This is used e.g. when validating `exports` directive in the `module-info`, if there are no classfiles and no source files used in the current compilation from the given package, `javac` will peek into the sources in the package, looking at their package clause[1]. The ASTs produced by such parses are thrown away/not part of the upcoming compilation.

But, even parses like this are reported to the `TaskListener`s, and some of the listeners may expect that the AST is eventually attributed - but it is not, as it was used only to read some name from the source code. Specifically, for DocLint, this may lead to an NPE, but it may cause other issues as well.

The proposal here is to simply avoid sending the "parse" event for parses that are not part of the actual compilation.

[1] https://github.com/openjdk/jdk/blob/84b927a05bcb7bf32a12829070ffd3a5670066d2/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1040

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

Commit messages:
 - 8297988: NPE in JavacTypes.getOverriddenMethods from doclint

Changes: https://git.openjdk.org/jdk/pull/11535/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11535&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297988
  Stats: 115 lines in 2 files changed: 111 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11535.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11535/head:pull/11535

PR: https://git.openjdk.org/jdk/pull/11535

From abimpoudis at openjdk.org  Tue Dec  6 13:04:12 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 6 Dec 2022 13:04:12 GMT
Subject: Integrated: 8297602: Compiler crash with type annotation and generic
 record during pattern matching
In-Reply-To: <tgoGyWX4Dt86Y8eoFVFKO-hDd39lnBcIdv7JO_Snj64=.4076d6c4-06a4-45d0-a4f1-2dfee375eee8@github.com>
References: <tgoGyWX4Dt86Y8eoFVFKO-hDd39lnBcIdv7JO_Snj64=.4076d6c4-06a4-45d0-a4f1-2dfee375eee8@github.com>
Message-ID: <HFo8YhUvzZJMm_rX9njIonG4AUEjeTD1OIxmLVWsjxg=.72c363a8-edb6-43d5-9e07-c4d4bf2b0d59@github.com>

On Tue, 6 Dec 2022 09:28:56 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In this PR we erase the annotation in the unhandled case of deconstruction patterns.

This pull request has now been integrated.

Changeset: 1e468320
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e468320dc6e495343dbdf392cbcbda79672c7ad
Stats:     57 lines in 2 files changed: 56 ins; 0 del; 1 mod

8297602: Compiler crash with type annotation and generic record during pattern matching

Reviewed-by: jlahoda

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

PR: https://git.openjdk.org/jdk/pull/11532

From duke at openjdk.org  Tue Dec  6 14:39:13 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 6 Dec 2022 14:39:13 GMT
Subject: RFR: 8193904: Uninitialized final field access and qualified this
 [v2]
In-Reply-To: <2p11BvHQ9v3hUxKasK-izVlTleuJkdxSLIJ7HVu0sH4=.857f50c9-6eea-4239-aa6f-1c300aa0b497@github.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <2p11BvHQ9v3hUxKasK-izVlTleuJkdxSLIJ7HVu0sH4=.857f50c9-6eea-4239-aa6f-1c300aa0b497@github.com>
Message-ID: <cN0uBbIxBBWhH2awdQTxQCwSiDu4M4gMnXSlnstE7ag=.022ab780-2295-4af0-9e0e-adc59d3b9a51@github.com>

On Thu, 17 Nov 2022 19:10:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> If a class `MyClass` has a blank final field `foo` that has not yet been assigned, the compiler prevents you from accessing it via the expressions `foo` or `this.foo`. However, it does not prevent you from accessing it via the expression `MyClass.this.foo`.
>> 
>> Here's a simple example:
>> 
>> class QualifiedThis {
>>     final int foo;
>>     QualifiedThis() {
>>         System.err.println(QualifiedThis.this.foo);   // should get an error here
>>         this.foo = 42;
>>     }
>> }
>> 
>> 
>> This patch fixes that omission.
>> 
>> I couldn't find an existing method that answers the question "Is this AST tree a reference to the current instance of the class I'm now compiling?" so I wrote a new one `TreeInfo.isThisReference()`.
>> 
>> The question itself is a little tricky. For example, `this` alone always is, but `Foo.this` is if the class being compiled is `Foo` or any supertype of `Foo`, *except* when `Foo` is an outer class containing the class being compiled, when it instead refers to that outer instance.
>> 
>> On the other hand, `Foo.super` (which, unlike `Foo.this`, can only be used to invoke a method), when `Foo` is a type and not a variable, refers to the current 'this' instance when the class being compiled is `Foo` or any supertype of `Foo`, period.
>
> Archie L. Cobbs 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:
> 
>  - Replace any remaining uses of TreeInfo.isThisQualifier().
>    
>    Bug 8193904 describes how "A.this.foo" is not detected as an early reference to
>    the uninitialized final variable "foo". There is also a flip-side to this bug,
>    which is that "A.this.foo = ..." is not accepted as a valid assignment to the
>    uninitialized final variable "foo". This commit fixes that part of the bug.
>    
>    Also do some minor refactoring for clarity.
>  - Merge branch 'master' into JDK-8193904
>  - Disallow early access to final fields via qualified 'this'.

This was [discussed on amber-dev](https://mail.openjdk.org/pipermail/amber-dev/2022-December/007610.html) and it was decided to leave the spec alone for the time being.

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

PR: https://git.openjdk.org/jdk/pull/10956

From duke at openjdk.org  Tue Dec  6 14:39:15 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 6 Dec 2022 14:39:15 GMT
Subject: Withdrawn: 8193904: Uninitialized final field access and qualified
 this
In-Reply-To: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
Message-ID: <PQcZIGD8uCjfXPIe7CclokCsjM3wkdyfyUPqlPqbLCo=.2bf583cb-9e56-4fa1-b5d3-277c086c7ce4@github.com>

On Wed, 2 Nov 2022 19:04:45 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> If a class `MyClass` has a blank final field `foo` that has not yet been assigned, the compiler prevents you from accessing it via the expressions `foo` or `this.foo`. However, it does not prevent you from accessing it via the expression `MyClass.this.foo`.
> 
> Here's a simple example:
> 
> class QualifiedThis {
>     final int foo;
>     QualifiedThis() {
>         System.err.println(QualifiedThis.this.foo);   // should get an error here
>         this.foo = 42;
>     }
> }
> 
> 
> This patch fixes that omission.
> 
> I couldn't find an existing method that answers the question "Is this AST tree a reference to the current instance of the class I'm now compiling?" so I wrote a new one `TreeInfo.isThisReference()`.
> 
> The question itself is a little tricky. For example, `this` alone always is, but `Foo.this` is if the class being compiled is `Foo` or any supertype of `Foo`, *except* when `Foo` is an outer class containing the class being compiled, when it instead refers to that outer instance.
> 
> On the other hand, `Foo.super` (which, unlike `Foo.this`, can only be used to invoke a method), when `Foo` is a type and not a variable, refers to the current 'this' instance when the class being compiled is `Foo` or any supertype of `Foo`, period.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10956

From cstein at openjdk.org  Tue Dec  6 16:18:39 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 16:18:39 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
Message-ID: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>

Please review the change to update to using jtreg 7.1.1.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

This pull request was created by copying the following and using 7.1.1 at appropriate places:
- https://github.com/openjdk/jdk/pull/11416

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

Commit messages:
 - 8298178: Update to use jtreg 7.1.1

Changes: https://git.openjdk.org/jdk/pull/11542/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298178
  Stats: 9 lines in 8 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11542.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11542/head:pull/11542

PR: https://git.openjdk.org/jdk/pull/11542

From cstein at openjdk.org  Tue Dec  6 16:18:40 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 16:18:40 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <DpjzUNDkTEhe5okO87rinHGfKI_5TdH_YcF3i0sVkq8=.bcec390d-771b-4fc4-a092-d5cf8685a542@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Fails due to missing tag `jtreg-7.1.1+1` at https://github.com/openjdk/jtreg/commit/3ea7f9f8fe7389d0eadc8cd02df38431043dd6fe

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

PR: https://git.openjdk.org/jdk/pull/11542

From darcy at openjdk.org  Tue Dec  6 16:59:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Dec 2022 16:59:27 GMT
Subject: Integrated: JDK-8298142: Update internal comment on language features
 in SourceVersion
In-Reply-To: <keywDlqXol42j_hszbAZwWFZDX3BdX8pQbJdMRIlfg4=.79344269-1886-49e4-902a-008cdad485d1@github.com>
References: <keywDlqXol42j_hszbAZwWFZDX3BdX8pQbJdMRIlfg4=.79344269-1886-49e4-902a-008cdad485d1@github.com>
Message-ID: <5quPpAfsInKwCBdk-G5QAKi6QNINZH1Fa1R1eC86U-w=.4f24a6c9-ea55-4723-95c9-0e00abea6325@github.com>

On Tue, 6 Dec 2022 05:33:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update the comments on the various source-versioning enums on the language changes in recent releases.

This pull request has now been integrated.

Changeset: 0d2a9ee5
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d2a9ee5287779c2e33fc0bfda84aa6128d8f479
Stats:     9 lines in 2 files changed: 4 ins; 0 del; 5 mod

8298142: Update internal comment on language features in SourceVersion

Reviewed-by: sundar, jlahoda

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

PR: https://git.openjdk.org/jdk/pull/11525

From darcy at openjdk.org  Tue Dec  6 17:05:16 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Dec 2022 17:05:16 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v4]
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <UECiEmgmeZJITMUwqB3jhQJMET3cdxeUca6Be0VUaPc=.a605d399-63db-4c13-8700-415ca3f4b11e@github.com>

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbol information for JDK 20 build 26.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Fix failed HotSpot regression tests.
 - Merge branch 'master' into JDK-8296149
 - ... and 9 more: https://git.openjdk.org/jdk/compare/0d2a9ee5...e252e83a

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

Changes: https://git.openjdk.org/jdk/pull/10924/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=03
  Stats: 3717 lines in 70 files changed: 3672 ins; 1 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/10924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10924/head:pull/10924

PR: https://git.openjdk.org/jdk/pull/10924

From jlahoda at openjdk.org  Tue Dec  6 17:05:50 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 6 Dec 2022 17:05:50 GMT
Subject: RFR: 8298184: Incorrect record component type in record patterns
Message-ID: <Wn82CLj4kP0z6dghTWD-7pP32iYChFutkWb_4eVXD7s=.066403af-2cd0-4e97-8ee0-f52c92ca5129@github.com>

When a type of a record type is a generic type with wildcards, per specification[1] we should do upward projection on the component type. But the current code removes wildcards. As a consequence, for record type e.g. `Box<? super String>` the type of the record component is determined to be `String`, instead of `Object`, and as a consequence code like this:

    int runIfSuperBound(I<? super String> b) {
        if (b instanceof Box(var v)) return 1;
        return -1;
    }


will return `-1` for `new Box<>(new StringBuilder())`.

The proposed fix is to use upward projections as per specification to compute the type of the record components.

[1] http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221115/specs/patterns-switch-record-patterns-jls.html#jls-14.30.1

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

Commit messages:
 - 8298184: Incorrect record component type in record patterns

Changes: https://git.openjdk.org/jdk/pull/11543/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11543&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298184
  Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11543.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11543/head:pull/11543

PR: https://git.openjdk.org/jdk/pull/11543

From erikj at openjdk.org  Tue Dec  6 17:24:43 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Dec 2022 17:24:43 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <WaxaNiKlHmIKgFGXDqswGhrbLjtfezJ0ceIFR2gCo7M=.7bb864d4-b3d4-473a-977e-83c410d9bceb@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11542

From iris at openjdk.org  Tue Dec  6 17:26:07 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 6 Dec 2022 17:26:07 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v4]
In-Reply-To: <UECiEmgmeZJITMUwqB3jhQJMET3cdxeUca6Be0VUaPc=.a605d399-63db-4c13-8700-415ca3f4b11e@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <UECiEmgmeZJITMUwqB3jhQJMET3cdxeUca6Be0VUaPc=.a605d399-63db-4c13-8700-415ca3f4b11e@github.com>
Message-ID: <6e9IQwG-3a6fzbD13_qpOZOob8vsFke3z1ecLQBZcYo=.e80a76b1-87c5-42a1-b2d2-fab62476b985@github.com>

On Tue, 6 Dec 2022 17:05:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information for JDK 20 build 26.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Fix failed HotSpot regression tests.
>  - Merge branch 'master' into JDK-8296149
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/0d2a9ee5...e252e83a

Still looks good.

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

PR: https://git.openjdk.org/jdk/pull/10924

From cstein at openjdk.org  Tue Dec  6 17:31:03 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:31:03 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <442ULv75pFX-axmZePsFEhAqdTqj0ms-Sn6WpZXB8Bw=.e6997aac-9b1f-4f81-9af0-864ba1dfd853@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Tag [jtreg-7.1.1+1](https://github.com/openjdk/jtreg/releases/tag/jtreg-7.1.1+1) was just added. Is it possible to restart "pre-submit tests" without performing a "noop" (touching a file) commit?

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

PR: https://git.openjdk.org/jdk/pull/11542

From darcy at openjdk.org  Tue Dec  6 17:38:29 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Dec 2022 17:38:29 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v5]
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <R3u4O7-zTndZc3wG4kUwdC2rRhV-KvsVzDjF6eDlwjY=.b34f30cb-ec77-40e6-b110-fe731bde5a52@github.com>

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback; reformat test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10924/files
  - new: https://git.openjdk.org/jdk/pull/10924/files/e252e83a..fc28c49a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=03-04

  Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10924/head:pull/10924

PR: https://git.openjdk.org/jdk/pull/10924

From cstein at openjdk.org  Tue Dec  6 17:45:06 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:45:06 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1 [v2]
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <_4nUcA_FoL0cLK-FE825zUMfVQ15bM0e0YNPmxe0reA=.799970b2-9770-4f5a-9cee-9a1197a6d431@github.com>

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Christian Stein has updated the pull request incrementally with two additional commits since the last revision:

 - Restart actions
 - [skip ci] Prepare restart of actions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11542/files
  - new: https://git.openjdk.org/jdk/pull/11542/files/35c49b7e..de8f785e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11542.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11542/head:pull/11542

PR: https://git.openjdk.org/jdk/pull/11542

From cstein at openjdk.org  Tue Dec  6 17:48:25 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:48:25 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1 [v3]
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <htSNzX0Tc8YPWY-ufy1AIfJxj_tpeGmjnang73y75Mg=.9c106ab7-1ddc-40df-8e30-b31d29c69b2c@github.com>

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Christian Stein has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:

 - [skip ci] Prepare restart of actions
 - 8298178: Update to use jtreg 7.1.1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11542/files
  - new: https://git.openjdk.org/jdk/pull/11542/files/de8f785e..96fcbf96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/11542

From cstein at openjdk.org  Tue Dec  6 17:50:14 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:50:14 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1 [v2]
In-Reply-To: <_4nUcA_FoL0cLK-FE825zUMfVQ15bM0e0YNPmxe0reA=.799970b2-9770-4f5a-9cee-9a1197a6d431@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
 <_4nUcA_FoL0cLK-FE825zUMfVQ15bM0e0YNPmxe0reA=.799970b2-9770-4f5a-9cee-9a1197a6d431@github.com>
Message-ID: <sh57rFLn0TBgSOd48dEAsELiZwLskYyjHqU95JqEedA=.6de2e612-53c9-4956-855f-4b6f2d5bb235@github.com>

On Tue, 6 Dec 2022 17:45:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.1.1.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>> 
>> This pull request was created by copying the following and using 7.1.1 at appropriate places:
>> - https://github.com/openjdk/jdk/pull/11416
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restart actions
>  - [skip ci] Prepare restart of actions

Restarted actions are running at: https://github.com/sormuras/jdk/actions/runs/3632002366

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

PR: https://git.openjdk.org/jdk/pull/11542

From cstein at openjdk.org  Tue Dec  6 20:54:52 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 20:54:52 GMT
Subject: Integrated: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <bZ95FikXXwOfFnn7nor8EnwNTmcPK1yc6djOUS8PmQc=.2f8fb567-dde6-474a-b583-8f201a8bc65e@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

This pull request has now been integrated.

Changeset: 2cdc0195
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cdc0195655317cb0b04f76fd8dce5e40bf52774
Stats:     9 lines in 8 files changed: 0 ins; 0 del; 9 mod

8298178: Update to use jtreg 7.1.1

Reviewed-by: erikj

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

PR: https://git.openjdk.org/jdk/pull/11542

From vromero at openjdk.org  Tue Dec  6 23:21:05 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 6 Dec 2022 23:21:05 GMT
Subject: RFR: 8298184: Incorrect record component type in record patterns
In-Reply-To: <Wn82CLj4kP0z6dghTWD-7pP32iYChFutkWb_4eVXD7s=.066403af-2cd0-4e97-8ee0-f52c92ca5129@github.com>
References: <Wn82CLj4kP0z6dghTWD-7pP32iYChFutkWb_4eVXD7s=.066403af-2cd0-4e97-8ee0-f52c92ca5129@github.com>
Message-ID: <p9wWqfCgx4IY39edRfXjMagcRv_53aCT6XTiMM7ptIg=.76a20a34-031f-4c07-878c-5b78434d1cfb@github.com>

On Tue, 6 Dec 2022 16:56:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When a type of a record type is a generic type with wildcards, per specification[1] we should do upward projection on the component type. But the current code removes wildcards. As a consequence, for record type e.g. `Box<? super String>` the type of the record component is determined to be `String`, instead of `Object`, and as a consequence code like this:
> 
>     int runIfSuperBound(I<? super String> b) {
>         if (b instanceof Box(var v)) return 1;
>         return -1;
>     }
> 
> 
> will return `-1` for `new Box<>(new StringBuilder())`.
> 
> The proposed fix is to use upward projections as per specification to compute the type of the record components.
> 
> [1] http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221115/specs/patterns-switch-record-patterns-jls.html#jls-14.30.1

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11543

From jlahoda at openjdk.org  Wed Dec  7 12:07:01 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Dec 2022 12:07:01 GMT
Subject: Integrated: 8298184: Incorrect record component type in record
 patterns
In-Reply-To: <Wn82CLj4kP0z6dghTWD-7pP32iYChFutkWb_4eVXD7s=.066403af-2cd0-4e97-8ee0-f52c92ca5129@github.com>
References: <Wn82CLj4kP0z6dghTWD-7pP32iYChFutkWb_4eVXD7s=.066403af-2cd0-4e97-8ee0-f52c92ca5129@github.com>
Message-ID: <ftLDWNiH3tx5ITRgCm6n4lLXWpAlCqkuKp-QxW1RJUs=.aa684786-908b-4193-b692-37027a1a72bc@github.com>

On Tue, 6 Dec 2022 16:56:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When a type of a record type is a generic type with wildcards, per specification[1] we should do upward projection on the component type. But the current code removes wildcards. As a consequence, for record type e.g. `Box<? super String>` the type of the record component is determined to be `String`, instead of `Object`, and as a consequence code like this:
> 
>     int runIfSuperBound(I<? super String> b) {
>         if (b instanceof Box(var v)) return 1;
>         return -1;
>     }
> 
> 
> will return `-1` for `new Box<>(new StringBuilder())`.
> 
> The proposed fix is to use upward projections as per specification to compute the type of the record components.
> 
> [1] http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221115/specs/patterns-switch-record-patterns-jls.html#jls-14.30.1

This pull request has now been integrated.

Changeset: cf63f2e3
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf63f2e3ea93cf339d08e2865034e128d683e515
Stats:     14 lines in 2 files changed: 12 ins; 0 del; 2 mod

8298184: Incorrect record component type in record patterns

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/11543

From jjg at openjdk.org  Thu Dec  8 00:22:40 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Dec 2022 00:22:40 GMT
Subject: RFR: 8200610: Compiling fails with
 java.nio.file.ReadOnlyFileSystemException [v2]
In-Reply-To: <FgpEG0__pgxvRdyuB8HnjGXSgNNzAcLsvM3LKcyf9_M=.2457f9a8-21e9-45f2-937e-dd1d504190f9@github.com>
References: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
 <FgpEG0__pgxvRdyuB8HnjGXSgNNzAcLsvM3LKcyf9_M=.2457f9a8-21e9-45f2-937e-dd1d504190f9@github.com>
Message-ID: <rJWBbKGKTT8jdVXPx3nCcQ3XDSiKBbVLZFSWuRuqshw=.98bc435b-9f4d-4d65-b0f3-e4a5056b18e6@github.com>

On Thu, 17 Nov 2022 19:11:06 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> In `JavaCompiler`, when trying to write a class file, if an `IOException`s is thrown, instead of crashing, we report a normal error" `error while writing [file]: ...`.
>> 
>> However there are some I/O errors that can generate `RuntimeException`s not caught by this logic. So instead these errors cause a compiler crash.
>> 
>> An example is given in JDK-8200610, where the compiler tries to write into a ZIP file system and a `java.nio.file.ReadOnlyFileSystemException` is thrown.
>> 
>> This patch adds that exception and a couple of others which (in my estimation) could reasonably be expected to be thrown in various obscure cases involving alternative file systems: `FileSystemNotFoundException` and `InvalidPathException`.
>> 
>> Any suggestions on what the most appropriate list of exception types to include here are appreciated.
>
> Archie L. Cobbs 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-8200610
>  - Catch and report some java.nio.file.* exceptions along with IOException.

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1643:

> 1641:                 if (results != null && file != null)
> 1642:                     results.add(file);
> 1643:             } catch (IOException | FileSystemNotFoundException | InvalidPathException | ReadOnlyFileSystemException ex) {

If we're hypothesizing plausible unchecked exceptions, maybe consider adding `UncheckedIOException` ?

I'd also recommend one exception per line, breaking the line before the `|`


} catch (IOException 
    | FileSystemNotFoundException 
    | InvalidPathException 
    | ReadOnlyFileSystemException 
    | UncheckedIOException ex) {

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

PR: https://git.openjdk.org/jdk/pull/10818

From duke at openjdk.org  Thu Dec  8 02:22:23 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 8 Dec 2022 02:22:23 GMT
Subject: RFR: 8200610: Compiling fails with
 java.nio.file.ReadOnlyFileSystemException [v3]
In-Reply-To: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
References: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
Message-ID: <ASETKAOENNVB2tm8-NQawlt6wS0O6RcpdBUC2s6aJLc=.547cf801-b291-4b8f-bf2e-cd665e39e0a4@github.com>

> In `JavaCompiler`, when trying to write a class file, if an `IOException`s is thrown, instead of crashing, we report a normal error" `error while writing [file]: ...`.
> 
> However there are some I/O errors that can generate `RuntimeException`s not caught by this logic. So instead these errors cause a compiler crash.
> 
> An example is given in JDK-8200610, where the compiler tries to write into a ZIP file system and a `java.nio.file.ReadOnlyFileSystemException` is thrown.
> 
> This patch adds that exception and a couple of others which (in my estimation) could reasonably be expected to be thrown in various obscure cases involving alternative file systems: `FileSystemNotFoundException` and `InvalidPathException`.
> 
> Any suggestions on what the most appropriate list of exception types to include here are appreciated.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8200610
 - Address review items (add UncheckedIOException and reformat).
 - Merge branch 'master' into JDK-8200610
 - Catch and report some java.nio.file.* exceptions along with IOException.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10818/files
  - new: https://git.openjdk.org/jdk/pull/10818/files/ecdd8b55..1bcf9501

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10818&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10818&range=01-02

  Stats: 121257 lines in 1930 files changed: 59528 ins; 42127 del; 19602 mod
  Patch: https://git.openjdk.org/jdk/pull/10818.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10818/head:pull/10818

PR: https://git.openjdk.org/jdk/pull/10818

From duke at openjdk.org  Thu Dec  8 02:22:30 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 8 Dec 2022 02:22:30 GMT
Subject: RFR: 8200610: Compiling fails with
 java.nio.file.ReadOnlyFileSystemException [v2]
In-Reply-To: <rJWBbKGKTT8jdVXPx3nCcQ3XDSiKBbVLZFSWuRuqshw=.98bc435b-9f4d-4d65-b0f3-e4a5056b18e6@github.com>
References: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
 <FgpEG0__pgxvRdyuB8HnjGXSgNNzAcLsvM3LKcyf9_M=.2457f9a8-21e9-45f2-937e-dd1d504190f9@github.com>
 <rJWBbKGKTT8jdVXPx3nCcQ3XDSiKBbVLZFSWuRuqshw=.98bc435b-9f4d-4d65-b0f3-e4a5056b18e6@github.com>
Message-ID: <alFvnDM1fs0qNk_SU7H3BGBKwdIxOnivQmAcnnrxIzw=.7756456a-c8f4-4430-90b5-058c610bfb59@github.com>

On Thu, 8 Dec 2022 00:18:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Archie L. Cobbs 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-8200610
>>  - Catch and report some java.nio.file.* exceptions along with IOException.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1643:
> 
>> 1641:                 if (results != null && file != null)
>> 1642:                     results.add(file);
>> 1643:             } catch (IOException | FileSystemNotFoundException | InvalidPathException | ReadOnlyFileSystemException ex) {
> 
> If we're hypothesizing plausible unchecked exceptions, maybe consider adding `UncheckedIOException` ?
> 
> I'd also recommend one exception per line, breaking the line before the `|`
> 
> 
> } catch (IOException 
>     | FileSystemNotFoundException 
>     | InvalidPathException 
>     | ReadOnlyFileSystemException 
>     | UncheckedIOException ex) {

Perfect - thanks.

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

PR: https://git.openjdk.org/jdk/pull/10818

From darcy at openjdk.org  Thu Dec  8 16:08:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Dec 2022 16:08:10 GMT
Subject: Integrated: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <qMPCxRnIrpq8gEc6SoGI3iiybj5joeLV9aTu-vviXYM=.6daf4167-8194-49fe-b837-9dd09632d2c8@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

This pull request has now been integrated.

Changeset: 175e3d3f
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/175e3d3ff332be25cca9822c58c46f1e012953c2
Stats:     3726 lines in 70 files changed: 3672 ins; 1 del; 53 mod

8296149: Start of release updates for JDK 21
8296150: Add SourceVersion.RELEASE_21
8296151: Add source 21 and target 21 to javac

Reviewed-by: dholmes, iris, erikj, vromero, jlahoda

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

PR: https://git.openjdk.org/jdk/pull/10924

From jlahoda at openjdk.org  Thu Dec  8 18:16:04 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 8 Dec 2022 18:16:04 GMT
Subject: RFR: 8297988: NPE in JavacTypes.getOverriddenMethods from doclint
In-Reply-To: <PUt-yaGeDPhayis-ghpopFiTRnXDjVmJEE-cQPG0wQQ=.41ec6fc2-c97f-4ce4-be6c-e49ebac73704@github.com>
References: <PUt-yaGeDPhayis-ghpopFiTRnXDjVmJEE-cQPG0wQQ=.41ec6fc2-c97f-4ce4-be6c-e49ebac73704@github.com>
Message-ID: <Bu7ktaQIj9IRYzSZxSkALE4N1SfFRu5HANL3I256fwQ=.a7e6d1c6-da86-4254-8eb8-80f1b7a212e8@github.com>

On Tue, 6 Dec 2022 12:18:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There are a few cases where `javac` parses Java source code, reads some name from the AST, and throws it away. This is used e.g. when validating `exports` directive in the `module-info`, if there are no classfiles and no source files used in the current compilation from the given package, `javac` will peek into the sources in the package, looking at their package clause[1]. The ASTs produced by such parses are thrown away/not part of the upcoming compilation.
> 
> But, even parses like this are reported to the `TaskListener`s, and some of the listeners may expect that the AST is eventually attributed - but it is not, as it was used only to read some name from the source code. Specifically, for DocLint, this may lead to an NPE, but it may cause other issues as well.
> 
> The proposal here is to simply avoid sending the "parse" event for parses that are not part of the actual compilation.
> 
> [1] https://github.com/openjdk/jdk/blob/84b927a05bcb7bf32a12829070ffd3a5670066d2/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1040

Resubmitted as https://github.com/openjdk/jdk20/pull/2 for JDK 20.

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

PR: https://git.openjdk.org/jdk/pull/11535

From jlahoda at openjdk.org  Thu Dec  8 18:16:05 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 8 Dec 2022 18:16:05 GMT
Subject: Withdrawn: 8297988: NPE in JavacTypes.getOverriddenMethods from
 doclint
In-Reply-To: <PUt-yaGeDPhayis-ghpopFiTRnXDjVmJEE-cQPG0wQQ=.41ec6fc2-c97f-4ce4-be6c-e49ebac73704@github.com>
References: <PUt-yaGeDPhayis-ghpopFiTRnXDjVmJEE-cQPG0wQQ=.41ec6fc2-c97f-4ce4-be6c-e49ebac73704@github.com>
Message-ID: <uDwkUxUAonEBWWpsMZsqqXzwdtEF2P4pWJtE6Ud_Vb0=.85c56038-befd-447b-b850-02101802f02f@github.com>

On Tue, 6 Dec 2022 12:18:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There are a few cases where `javac` parses Java source code, reads some name from the AST, and throws it away. This is used e.g. when validating `exports` directive in the `module-info`, if there are no classfiles and no source files used in the current compilation from the given package, `javac` will peek into the sources in the package, looking at their package clause[1]. The ASTs produced by such parses are thrown away/not part of the upcoming compilation.
> 
> But, even parses like this are reported to the `TaskListener`s, and some of the listeners may expect that the AST is eventually attributed - but it is not, as it was used only to read some name from the source code. Specifically, for DocLint, this may lead to an NPE, but it may cause other issues as well.
> 
> The proposal here is to simply avoid sending the "parse" event for parses that are not part of the actual compilation.
> 
> [1] https://github.com/openjdk/jdk/blob/84b927a05bcb7bf32a12829070ffd3a5670066d2/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1040

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/11535

From jlahoda at openjdk.org  Thu Dec  8 18:28:35 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 8 Dec 2022 18:28:35 GMT
Subject: [jdk20] RFR: 8297988: NPE in JavacTypes.getOverriddenMethods from
 doclint
Message-ID: <3UOqJOHmrgg_j96L_gsbA_F1FsDvQjoo1xe_-PzzUQ8=.193d124a-3f81-45d3-9f8a-ea68de1475a1@github.com>

[This PR was originally submitted as https://github.com/openjdk/jdk/pull/11535 to the mainline JDK.]

There are a few cases where `javac` parses Java source code, reads some name from the AST, and throws it away. This is used e.g. when validating `exports` directive in the `module-info`, if there are no classfiles and no source files used in the current compilation from the given package, `javac` will peek into the sources in the package, looking at their package clause[1]. The ASTs produced by such parses are thrown away/not part of the upcoming compilation.

But, even parses like this are reported to the `TaskListener`s, and some of the listeners may expect that the AST is eventually attributed - but it is not, as it was used only to read some name from the source code. Specifically, for DocLint, this may lead to an NPE, but it may cause other issues as well.

The proposal here is to simply avoid sending the "parse" event for parses that are not part of the actual compilation.

[1] https://github.com/openjdk/jdk/blob/84b927a05bcb7bf32a12829070ffd3a5670066d2/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1040

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

Commit messages:
 - 8297988: NPE in JavacTypes.getOverriddenMethods from doclint

Changes: https://git.openjdk.org/jdk20/pull/2/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=2&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297988
  Stats: 115 lines in 2 files changed: 111 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk20/pull/2.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/2/head:pull/2

PR: https://git.openjdk.org/jdk20/pull/2

From vromero at openjdk.org  Thu Dec  8 19:32:01 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 Dec 2022 19:32:01 GMT
Subject: [jdk20] RFR: 8297988: NPE in JavacTypes.getOverriddenMethods from
 doclint
In-Reply-To: <3UOqJOHmrgg_j96L_gsbA_F1FsDvQjoo1xe_-PzzUQ8=.193d124a-3f81-45d3-9f8a-ea68de1475a1@github.com>
References: <3UOqJOHmrgg_j96L_gsbA_F1FsDvQjoo1xe_-PzzUQ8=.193d124a-3f81-45d3-9f8a-ea68de1475a1@github.com>
Message-ID: <pICB6CjZM9h4kuW6rBPJ2V9rtqb6R6pI0hj9C3KPRPQ=.818a0693-57f8-4cee-ae25-ba7b8f84e72c@github.com>

On Thu, 8 Dec 2022 18:12:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> [This PR was originally submitted as https://github.com/openjdk/jdk/pull/11535 to the mainline JDK.]
> 
> There are a few cases where `javac` parses Java source code, reads some name from the AST, and throws it away. This is used e.g. when validating `exports` directive in the `module-info`, if there are no classfiles and no source files used in the current compilation from the given package, `javac` will peek into the sources in the package, looking at their package clause[1]. The ASTs produced by such parses are thrown away/not part of the upcoming compilation.
> 
> But, even parses like this are reported to the `TaskListener`s, and some of the listeners may expect that the AST is eventually attributed - but it is not, as it was used only to read some name from the source code. Specifically, for DocLint, this may lead to an NPE, but it may cause other issues as well.
> 
> The proposal here is to simply avoid sending the "parse" event for parses that are not part of the actual compilation.
> 
> [1] https://github.com/openjdk/jdk/blob/84b927a05bcb7bf32a12829070ffd3a5670066d2/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1040

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/2

From jjg at openjdk.org  Thu Dec  8 23:14:52 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Dec 2022 23:14:52 GMT
Subject: [jdk20] RFR: 8297988: NPE in JavacTypes.getOverriddenMethods from
 doclint
In-Reply-To: <3UOqJOHmrgg_j96L_gsbA_F1FsDvQjoo1xe_-PzzUQ8=.193d124a-3f81-45d3-9f8a-ea68de1475a1@github.com>
References: <3UOqJOHmrgg_j96L_gsbA_F1FsDvQjoo1xe_-PzzUQ8=.193d124a-3f81-45d3-9f8a-ea68de1475a1@github.com>
Message-ID: <N-zu09b-QxA7RPNGk3NHL6HlAa0FwrayNgzzCt9VYM4=.f1c7b10b-2447-41f6-b844-a558d533d8b3@github.com>

On Thu, 8 Dec 2022 18:12:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> [This PR was originally submitted as https://github.com/openjdk/jdk/pull/11535 to the mainline JDK.]
> 
> There are a few cases where `javac` parses Java source code, reads some name from the AST, and throws it away. This is used e.g. when validating `exports` directive in the `module-info`, if there are no classfiles and no source files used in the current compilation from the given package, `javac` will peek into the sources in the package, looking at their package clause[1]. The ASTs produced by such parses are thrown away/not part of the upcoming compilation.
> 
> But, even parses like this are reported to the `TaskListener`s, and some of the listeners may expect that the AST is eventually attributed - but it is not, as it was used only to read some name from the source code. Specifically, for DocLint, this may lead to an NPE, but it may cause other issues as well.
> 
> The proposal here is to simply avoid sending the "parse" event for parses that are not part of the actual compilation.
> 
> [1] https://github.com/openjdk/jdk/blob/84b927a05bcb7bf32a12829070ffd3a5670066d2/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1040

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/2

From duke at openjdk.org  Fri Dec  9 10:03:30 2022
From: duke at openjdk.org (duke)
Date: Fri, 9 Dec 2022 10:03:30 GMT
Subject: Withdrawn: JDK-8042981: Strip type annotations in Types' utility
 methods
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <A9dVOmn8WJ2Twq0euVr6Bs02tMEDv0qghnXrWtc3Q-c=.3782987d-4817-4a0e-b779-9c5a4e0c411e@github.com>

On Thu, 2 Jun 2022 01:09:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/8984

From jlahoda at openjdk.org  Fri Dec  9 11:14:18 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 9 Dec 2022 11:14:18 GMT
Subject: [jdk20] Integrated: 8297988: NPE in JavacTypes.getOverriddenMethods
 from doclint
In-Reply-To: <3UOqJOHmrgg_j96L_gsbA_F1FsDvQjoo1xe_-PzzUQ8=.193d124a-3f81-45d3-9f8a-ea68de1475a1@github.com>
References: <3UOqJOHmrgg_j96L_gsbA_F1FsDvQjoo1xe_-PzzUQ8=.193d124a-3f81-45d3-9f8a-ea68de1475a1@github.com>
Message-ID: <YhqZWVo8x7TQ0THK0c1Nb6KhcwZscl-l109A-8rckt4=.c9369bb8-e6b8-4c15-b6ab-72d064d162b6@github.com>

On Thu, 8 Dec 2022 18:12:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> [This PR was originally submitted as https://github.com/openjdk/jdk/pull/11535 to the mainline JDK.]
> 
> There are a few cases where `javac` parses Java source code, reads some name from the AST, and throws it away. This is used e.g. when validating `exports` directive in the `module-info`, if there are no classfiles and no source files used in the current compilation from the given package, `javac` will peek into the sources in the package, looking at their package clause[1]. The ASTs produced by such parses are thrown away/not part of the upcoming compilation.
> 
> But, even parses like this are reported to the `TaskListener`s, and some of the listeners may expect that the AST is eventually attributed - but it is not, as it was used only to read some name from the source code. Specifically, for DocLint, this may lead to an NPE, but it may cause other issues as well.
> 
> The proposal here is to simply avoid sending the "parse" event for parses that are not part of the actual compilation.
> 
> [1] https://github.com/openjdk/jdk/blob/84b927a05bcb7bf32a12829070ffd3a5670066d2/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1040

This pull request has now been integrated.

Changeset: 133ad8e1
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/133ad8e1734f002f013dd3c73d496e323e9e881e
Stats:     115 lines in 2 files changed: 111 ins; 0 del; 4 mod

8297988: NPE in JavacTypes.getOverriddenMethods from doclint

Reviewed-by: vromero, jjg

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

PR: https://git.openjdk.org/jdk20/pull/2

From jlahoda at openjdk.org  Fri Dec  9 14:11:21 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 9 Dec 2022 14:11:21 GMT
Subject: [jdk20] RFR: 8298463: tools/javac/modules/EdgeCases.java fails on
 Windows after JDK-8297988
Message-ID: <O9nDAfO12YCyvaMguzivXPddIlb8wEmjNNAmA93oFIo=.5f635a0c-b5eb-431b-8d59-02062dcf6ece@github.com>

`JavaFileObject.getName()` uses platform-specific name separators in the path. The test needs to normalize name separators before comparing them with expected output.

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

Commit messages:
 - 8298463: tools/javac/modules/EdgeCases.java fails on Windows after JDK-8297988

Changes: https://git.openjdk.org/jdk20/pull/12/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=12&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298463
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/12.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/12/head:pull/12

PR: https://git.openjdk.org/jdk20/pull/12

From jjg at openjdk.org  Fri Dec  9 16:38:49 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Dec 2022 16:38:49 GMT
Subject: [jdk20] RFR: 8298463: tools/javac/modules/EdgeCases.java fails on
 Windows after JDK-8297988
In-Reply-To: <O9nDAfO12YCyvaMguzivXPddIlb8wEmjNNAmA93oFIo=.5f635a0c-b5eb-431b-8d59-02062dcf6ece@github.com>
References: <O9nDAfO12YCyvaMguzivXPddIlb8wEmjNNAmA93oFIo=.5f635a0c-b5eb-431b-8d59-02062dcf6ece@github.com>
Message-ID: <D1mC_F0376ZYzWaIULZb9Ghr2iXDuObL7CSI-E6HEPg=.efea5898-0ff3-4e76-93d4-a456385a1a67@github.com>

On Fri, 9 Dec 2022 14:04:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `JavaFileObject.getName()` uses platform-specific name separators in the path. The test needs to normalize name separators before comparing them with expected output.

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/12

From jlahoda at openjdk.org  Fri Dec  9 16:44:32 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 9 Dec 2022 16:44:32 GMT
Subject: [jdk20] Integrated: 8298463: tools/javac/modules/EdgeCases.java fails
 on Windows after JDK-8297988
In-Reply-To: <O9nDAfO12YCyvaMguzivXPddIlb8wEmjNNAmA93oFIo=.5f635a0c-b5eb-431b-8d59-02062dcf6ece@github.com>
References: <O9nDAfO12YCyvaMguzivXPddIlb8wEmjNNAmA93oFIo=.5f635a0c-b5eb-431b-8d59-02062dcf6ece@github.com>
Message-ID: <YkUKz7pIlAqsknBdX0IAT-hXjOeoXhCjeewFYaEAmhE=.3671dac8-708a-4b28-9f87-0a03aea02112@github.com>

On Fri, 9 Dec 2022 14:04:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `JavaFileObject.getName()` uses platform-specific name separators in the path. The test needs to normalize name separators before comparing them with expected output.

This pull request has now been integrated.

Changeset: 52fffdd2
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/52fffdd2c8426e98d3a0198ef4607750732bab93
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8298463: tools/javac/modules/EdgeCases.java fails on Windows after JDK-8297988

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jdk20/pull/12

From darcy at openjdk.org  Fri Dec  9 18:44:07 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 Dec 2022 18:44:07 GMT
Subject: RFR: JDK-8298190: Update --release 20 symbol information for JDK 20
 build 27
Message-ID: <6KbUK0qeOxImWzpZWNxvVNfJCAc33b__TInZwLNv978=.121d8e8d-7594-4181-a2e6-7a095b038ed7@github.com>

Usual updates of the symbol file to the current build, in this case JDK 20 build 27.

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

Commit messages:
 - JDK-8298190: Update --release 20 symbol information for JDK 20 build 27

Changes: https://git.openjdk.org/jdk/pull/11613/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11613&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298190
  Stats: 624 lines in 8 files changed: 558 ins; 10 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/11613.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11613/head:pull/11613

PR: https://git.openjdk.org/jdk/pull/11613

From jwilhelm at openjdk.org  Fri Dec  9 18:54:02 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 9 Dec 2022 18:54:02 GMT
Subject: RFR: Merge jdk20
Message-ID: <623yCPD6mDuZDBu16Bw0mumoJwDQvMbOyhM6baxvAME=.a307baef-104b-4790-9ef1-454a44400953@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge
 - 8298225: [AIX] Disable PPC64LE continuations on AIX
 - 8298463: tools/javac/modules/EdgeCases.java fails on Windows after JDK-8297988
 - 8298353: C2 fails with assert(opaq->outcnt() == 1 && opaq->in(1) == limit) failed
 - 8298340: java/net/httpclient/CancelRequestTest.java fails with AssertionError: Found some subscribers for testPostInterrupt
 - 8298455: JFR: Add logging to TestClose.java
 - 8297988: NPE in JavacTypes.getOverriddenMethods from doclint
 - 8298402: ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11614&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11614&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11614/files
  Stats: 262 lines in 13 files changed: 250 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11614.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11614/head:pull/11614

PR: https://git.openjdk.org/jdk/pull/11614

From iris at openjdk.org  Fri Dec  9 19:39:36 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 9 Dec 2022 19:39:36 GMT
Subject: RFR: JDK-8298190: Update --release 20 symbol information for JDK
 20 build 27
In-Reply-To: <6KbUK0qeOxImWzpZWNxvVNfJCAc33b__TInZwLNv978=.121d8e8d-7594-4181-a2e6-7a095b038ed7@github.com>
References: <6KbUK0qeOxImWzpZWNxvVNfJCAc33b__TInZwLNv978=.121d8e8d-7594-4181-a2e6-7a095b038ed7@github.com>
Message-ID: <sCUXfDgxeU40j7-M2E5V2dVL5z1VRMM0FEA7gosfJ8k=.15b1db5b-9c33-4831-add3-df62583fd026@github.com>

On Fri, 9 Dec 2022 18:33:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual updates of the symbol file to the current build, in this case JDK 20 build 27.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11613

From darcy at openjdk.org  Fri Dec  9 19:59:55 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 Dec 2022 19:59:55 GMT
Subject: Integrated: JDK-8298190: Update --release 20 symbol information for
 JDK 20 build 27
In-Reply-To: <6KbUK0qeOxImWzpZWNxvVNfJCAc33b__TInZwLNv978=.121d8e8d-7594-4181-a2e6-7a095b038ed7@github.com>
References: <6KbUK0qeOxImWzpZWNxvVNfJCAc33b__TInZwLNv978=.121d8e8d-7594-4181-a2e6-7a095b038ed7@github.com>
Message-ID: <1-exZaOrmBNFFhP0Xe0-mANDhc3n1kdBrBPEZBfqehU=.8f178c04-42c8-4b1f-9327-def16e41cebc@github.com>

On Fri, 9 Dec 2022 18:33:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual updates of the symbol file to the current build, in this case JDK 20 build 27.

This pull request has now been integrated.

Changeset: 7dbdd83d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7dbdd83da0eefd56927bdb68d7aedfee5c0c0ab5
Stats:     624 lines in 8 files changed: 558 ins; 10 del; 56 mod

8298190: Update --release 20 symbol information for JDK 20 build 27

Reviewed-by: iris

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

PR: https://git.openjdk.org/jdk/pull/11613

From jwilhelm at openjdk.org  Fri Dec  9 22:03:09 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 9 Dec 2022 22:03:09 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <623yCPD6mDuZDBu16Bw0mumoJwDQvMbOyhM6baxvAME=.a307baef-104b-4790-9ef1-454a44400953@github.com>
References: <623yCPD6mDuZDBu16Bw0mumoJwDQvMbOyhM6baxvAME=.a307baef-104b-4790-9ef1-454a44400953@github.com>
Message-ID: <7u7OtmjFU9bcXtf2gL0ig1tG-_zgP0g0R__V68W7MLo=.6a2e0eef-313c-4df5-8769-dcab1961b6ac@github.com>

On Fri, 9 Dec 2022 18:45:40 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 715bf704
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/715bf7045968e341182e61343651f464a437f83f
Stats:     262 lines in 13 files changed: 250 ins; 1 del; 11 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11614

From vromero at openjdk.org  Mon Dec 12 16:19:01 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Dec 2022 16:19:01 GMT
Subject: RFR: 8200610: Compiling fails with
 java.nio.file.ReadOnlyFileSystemException [v3]
In-Reply-To: <ASETKAOENNVB2tm8-NQawlt6wS0O6RcpdBUC2s6aJLc=.547cf801-b291-4b8f-bf2e-cd665e39e0a4@github.com>
References: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
 <ASETKAOENNVB2tm8-NQawlt6wS0O6RcpdBUC2s6aJLc=.547cf801-b291-4b8f-bf2e-cd665e39e0a4@github.com>
Message-ID: <gQJ9T33HyzKGKHq3hYqxbb4Uu8Af1ACVrx52OErYMsE=.f9234c9f-5576-4120-8d6e-dec7f16b860b@github.com>

On Thu, 8 Dec 2022 02:22:23 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> In `JavaCompiler`, when trying to write a class file, if an `IOException`s is thrown, instead of crashing, we report a normal error" `error while writing [file]: ...`.
>> 
>> However there are some I/O errors that can generate `RuntimeException`s not caught by this logic. So instead these errors cause a compiler crash.
>> 
>> An example is given in JDK-8200610, where the compiler tries to write into a ZIP file system and a `java.nio.file.ReadOnlyFileSystemException` is thrown.
>> 
>> This patch adds that exception and a couple of others which (in my estimation) could reasonably be expected to be thrown in various obscure cases involving alternative file systems: `FileSystemNotFoundException` and `InvalidPathException`.
>> 
>> Any suggestions on what the most appropriate list of exception types to include here are appreciated.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8200610
>  - Address review items (add UncheckedIOException and reformat).
>  - Merge branch 'master' into JDK-8200610
>  - Catch and report some java.nio.file.* exceptions along with IOException.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10818

From duke at openjdk.org  Mon Dec 12 16:19:01 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 12 Dec 2022 16:19:01 GMT
Subject: RFR: 8200610: Compiling fails with
 java.nio.file.ReadOnlyFileSystemException [v3]
In-Reply-To: <ASETKAOENNVB2tm8-NQawlt6wS0O6RcpdBUC2s6aJLc=.547cf801-b291-4b8f-bf2e-cd665e39e0a4@github.com>
References: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
 <ASETKAOENNVB2tm8-NQawlt6wS0O6RcpdBUC2s6aJLc=.547cf801-b291-4b8f-bf2e-cd665e39e0a4@github.com>
Message-ID: <sfFKr0wLP4c0AcocD1RJTRcV6U7MZooD4bGEH4cIyq8=.1f4bb839-68fb-4392-a840-18194df16487@github.com>

On Thu, 8 Dec 2022 02:22:23 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> In `JavaCompiler`, when trying to write a class file, if an `IOException`s is thrown, instead of crashing, we report a normal error" `error while writing [file]: ...`.
>> 
>> However there are some I/O errors that can generate `RuntimeException`s not caught by this logic. So instead these errors cause a compiler crash.
>> 
>> An example is given in JDK-8200610, where the compiler tries to write into a ZIP file system and a `java.nio.file.ReadOnlyFileSystemException` is thrown.
>> 
>> This patch adds that exception and a couple of others which (in my estimation) could reasonably be expected to be thrown in various obscure cases involving alternative file systems: `FileSystemNotFoundException` and `InvalidPathException`.
>> 
>> Any suggestions on what the most appropriate list of exception types to include here are appreciated.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8200610
>  - Address review items (add UncheckedIOException and reformat).
>  - Merge branch 'master' into JDK-8200610
>  - Catch and report some java.nio.file.* exceptions along with IOException.

Thanks!

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

PR: https://git.openjdk.org/jdk/pull/10818

From darcy at openjdk.org  Tue Dec 13 20:29:34 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Dec 2022 20:29:34 GMT
Subject: [jdk20] RFR: JDK-8297305: Clarify that
 javax.lang.model.util.Elements.overrides is irreflexive
Message-ID: <qEEtonQsO9MTI9kQoe6TVi9YT8yux1r7inObn1JPUgY=.bc0e58f0-2e3e-40f8-8e1f-7322134999c6@github.com>

Please review this spec clarification and its companion CSR https://bugs.openjdk.org/browse/JDK-8298698

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

Commit messages:
 - JDK-8297305: Clarify that javax.lang.model.util.Elements.overrides is irreflexive

Changes: https://git.openjdk.org/jdk20/pull/27/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=27&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297305
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/27.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/27/head:pull/27

PR: https://git.openjdk.org/jdk20/pull/27

From jjg at openjdk.org  Tue Dec 13 20:45:02 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 13 Dec 2022 20:45:02 GMT
Subject: [jdk20] RFR: JDK-8297305: Clarify that
 javax.lang.model.util.Elements.overrides is irreflexive
In-Reply-To: <qEEtonQsO9MTI9kQoe6TVi9YT8yux1r7inObn1JPUgY=.bc0e58f0-2e3e-40f8-8e1f-7322134999c6@github.com>
References: <qEEtonQsO9MTI9kQoe6TVi9YT8yux1r7inObn1JPUgY=.bc0e58f0-2e3e-40f8-8e1f-7322134999c6@github.com>
Message-ID: <sR6zbPwohnY5BXSjmCkVZ5v-PX-56O9KdICJd3HJpZo=.232b88cb-9afd-4e67-83cf-c102b011a9fb@github.com>

On Tue, 13 Dec 2022 20:21:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this spec clarification and its companion CSR https://bugs.openjdk.org/browse/JDK-8298698

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/27

From darcy at openjdk.org  Tue Dec 13 20:52:35 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Dec 2022 20:52:35 GMT
Subject: [jdk20] Integrated: JDK-8297305: Clarify that
 javax.lang.model.util.Elements.overrides is irreflexive
In-Reply-To: <qEEtonQsO9MTI9kQoe6TVi9YT8yux1r7inObn1JPUgY=.bc0e58f0-2e3e-40f8-8e1f-7322134999c6@github.com>
References: <qEEtonQsO9MTI9kQoe6TVi9YT8yux1r7inObn1JPUgY=.bc0e58f0-2e3e-40f8-8e1f-7322134999c6@github.com>
Message-ID: <P9Aq4xTadLKWyr7n3P9mhqpqPR2Dsw_Fb7hLWXoL9qs=.b9bc7be3-5db4-4201-b2cc-c167c2dbd006@github.com>

On Tue, 13 Dec 2022 20:21:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this spec clarification and its companion CSR https://bugs.openjdk.org/browse/JDK-8298698

This pull request has now been integrated.

Changeset: c6f22b41
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/c6f22b416072a9be5436f45e2f595ceea228f3bd
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8297305: Clarify that javax.lang.model.util.Elements.overrides is irreflexive

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jdk20/pull/27

From jjg at openjdk.org  Tue Dec 13 22:34:08 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 13 Dec 2022 22:34:08 GMT
Subject: [jdk20] RFR: JDK-8298700: Typo in DocTree comment
Message-ID: <giYebLoq6JN_AlL8PphW_Xoi0VjDVcmAVIBM06A2UKY=.3d601659-c5f6-4351-aa54-125daead7053@github.com>

Please review a trivial fix to a long-standing copy-paste typo.

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

Commit messages:
 - JDK-8298700: Typo in DocTree comment

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

PR: https://git.openjdk.org/jdk20/pull/28

From darcy at openjdk.org  Tue Dec 13 22:46:13 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Dec 2022 22:46:13 GMT
Subject: [jdk20] RFR: JDK-8298700: Typo in DocTree comment
In-Reply-To: <giYebLoq6JN_AlL8PphW_Xoi0VjDVcmAVIBM06A2UKY=.3d601659-c5f6-4351-aa54-125daead7053@github.com>
References: <giYebLoq6JN_AlL8PphW_Xoi0VjDVcmAVIBM06A2UKY=.3d601659-c5f6-4351-aa54-125daead7053@github.com>
Message-ID: <4vjbP72kPppCt8a7a_Q6BkDw3W3mPmCeT2Wx33DRkOw=.651a847a-bf69-43c0-857a-8cb1f72b3e10@github.com>

On Tue, 13 Dec 2022 22:27:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial fix to a long-standing copy-paste typo.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/28

From jjg at openjdk.org  Tue Dec 13 23:24:55 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 13 Dec 2022 23:24:55 GMT
Subject: [jdk20] Integrated: JDK-8298700: Typo in DocTree comment
In-Reply-To: <giYebLoq6JN_AlL8PphW_Xoi0VjDVcmAVIBM06A2UKY=.3d601659-c5f6-4351-aa54-125daead7053@github.com>
References: <giYebLoq6JN_AlL8PphW_Xoi0VjDVcmAVIBM06A2UKY=.3d601659-c5f6-4351-aa54-125daead7053@github.com>
Message-ID: <BKbPlUZMI9BHLOnncnAPNIaG4yP95knWEpOSkwJeBL0=.f084e822-fe0d-463c-b1d6-9e1aad34db7f@github.com>

On Tue, 13 Dec 2022 22:27:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial fix to a long-standing copy-paste typo.

This pull request has now been integrated.

Changeset: 61ab16f7
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/61ab16f79a735a98b3c095daf1b541f4fc5413c0
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8298700: Typo in DocTree comment

Reviewed-by: darcy

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

PR: https://git.openjdk.org/jdk20/pull/28

From jlahoda at openjdk.org  Wed Dec 14 11:17:45 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Dec 2022 11:17:45 GMT
Subject: [jdk20] RFR: 8298727: Trees.getPath may crash for unnamed package
Message-ID: <7Tl0sEwegXfG2pNBBApi9SdvYV8JAzrqq-QupCZ5QXU=.7377ae09-bc1c-4f93-adf8-1e7fbbbf04f7@github.com>

Considering an empty `package-info.java` file is normally accepted by javac (as a `package-info` for the unnamed module). But, if `Trees.getPath` is used on the unnamed package, a NPE occurs:

java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.tree.JCTree.accept(com.sun.tools.javac.tree.JCTree$Visitor)" because "tree" is null
at jdk.compiler/com.sun.tools.javac.tree.TreeInfo.declarationFor(TreeInfo.java:811)
at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:779)
at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:799)
at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getPath(JavacTrees.java:331)
at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getPath(JavacTrees.java:321)


The reason is that `Env.tree` is initialized to the package clause in `Enter.visitTopLevel`, but when the package clause is missing, `Env.tree` is `null`, leading to the error above.

The proposed fix is to set `Env.tree` to the top-level tree in this case, to keep it non-null. As the empty `package-info` can be compiled, it seems reasonable for the model to work on is as well, so a non-null tree needs to be set, and there's no other tree that could be used, I believe.

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

Commit messages:
 - 8298727: Trees.getPath may crash for unnamed package

Changes: https://git.openjdk.org/jdk20/pull/31/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=31&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298727
  Stats: 137 lines in 2 files changed: 136 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/31.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/31/head:pull/31

PR: https://git.openjdk.org/jdk20/pull/31

From vromero at openjdk.org  Wed Dec 14 15:32:59 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 14 Dec 2022 15:32:59 GMT
Subject: [jdk20] RFR: 8298727: Trees.getPath may crash for unnamed package
In-Reply-To: <7Tl0sEwegXfG2pNBBApi9SdvYV8JAzrqq-QupCZ5QXU=.7377ae09-bc1c-4f93-adf8-1e7fbbbf04f7@github.com>
References: <7Tl0sEwegXfG2pNBBApi9SdvYV8JAzrqq-QupCZ5QXU=.7377ae09-bc1c-4f93-adf8-1e7fbbbf04f7@github.com>
Message-ID: <KWzio2wukqyRRd5E4ZIueGZ7lJIKDR-ylAPM0C9VhwU=.8410e8af-091c-4c8e-90bb-2a46d7bb582f@github.com>

On Wed, 14 Dec 2022 11:08:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering an empty `package-info.java` file is normally accepted by javac (as a `package-info` for the unnamed module). But, if `Trees.getPath` is used on the unnamed package, a NPE occurs:
> 
> java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.tree.JCTree.accept(com.sun.tools.javac.tree.JCTree$Visitor)" because "tree" is null
> at jdk.compiler/com.sun.tools.javac.tree.TreeInfo.declarationFor(TreeInfo.java:811)
> at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:779)
> at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:799)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getPath(JavacTrees.java:331)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getPath(JavacTrees.java:321)
> 
> 
> The reason is that `Env.tree` is initialized to the package clause in `Enter.visitTopLevel`, but when the package clause is missing, `Env.tree` is `null`, leading to the error above.
> 
> The proposed fix is to set `Env.tree` to the top-level tree in this case, to keep it non-null. As the empty `package-info` can be compiled, it seems reasonable for the model to work on is as well, so a non-null tree needs to be set, and there's no other tree that could be used, I believe.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/31

From jwilhelm at openjdk.org  Wed Dec 14 17:11:21 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 14 Dec 2022 17:11:21 GMT
Subject: RFR: Merge jdk20
Message-ID: <MfIrkifsuA1GWjwbhgOaCGmwBUSkPIy0QZnt_yUJoj0=.e5687e4f-5661-4593-8e8d-f061b3bf705f@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax
 - 8298649: JFR: RemoteRecordingStream support for checkpoint event sizes beyond u4
 - 8298296: gc/TestFullGCCount.java fails with "System.gc collections miscounted."
 - 8294902: Undefined Behavior in C2 regalloc with null references
 - 8298425: System.console().readLine() hangs in jshell
 - 8298520: C2: assert(found_opaque == res) failed: wrong pattern
 - 8298527: Cygwin's uname -m returns different string than before
 - 8298700: Typo in DocTree comment
 - 8297305: Clarify that javax.lang.model.util.Elements.overrides is irreflexive
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c05dbac3...873a7e3a

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11678&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11678&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11678/files
  Stats: 216 lines in 17 files changed: 132 ins; 41 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/11678.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11678/head:pull/11678

PR: https://git.openjdk.org/jdk/pull/11678

From jwilhelm at openjdk.org  Wed Dec 14 21:51:13 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 14 Dec 2022 21:51:13 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <MfIrkifsuA1GWjwbhgOaCGmwBUSkPIy0QZnt_yUJoj0=.e5687e4f-5661-4593-8e8d-f061b3bf705f@github.com>
References: <MfIrkifsuA1GWjwbhgOaCGmwBUSkPIy0QZnt_yUJoj0=.e5687e4f-5661-4593-8e8d-f061b3bf705f@github.com>
Message-ID: <I5vQumlhaL6cXwuMXUTwTNcFmgSqghC2VhvOpXP-fDk=.a1608d39-d043-4bdd-9711-ff01a50a67fa@github.com>

On Wed, 14 Dec 2022 16:59:54 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: a130c8a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a130c8a6688fcdda92e0f6295ec06f1591382328
Stats:     216 lines in 17 files changed: 132 ins; 41 del; 43 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11678

From dnguyen at openjdk.org  Wed Dec 14 23:47:55 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 14 Dec 2022 23:47:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop
 10
Message-ID: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>

Open l10n drop
All tests passed

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

Commit messages:
 - open l10n drop

Changes: https://git.openjdk.org/jdk20/pull/35/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298133
  Stats: 1177 lines in 110 files changed: 783 ins; 207 del; 187 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From achung at openjdk.org  Thu Dec 15 00:07:04 2022
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 15 Dec 2022 00:07:04 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <Sfe4uUeYHsI1HUSpkDyn-dbJiiReR3yQCyzrBo1H_7k=.52ee8dbe-28b5-4b59-a4d9-3b2dda6ac0b8@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

looks good

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

Marked as reviewed by achung (Committer).

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 01:01:05 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:01:05 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:

> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
> 187: 
> 188: main.plugin.category=\u7C7B\u522B 

As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.

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

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 01:07:14 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:07:14 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:

> 24: #
> 25: 
> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten

`jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?

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

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 01:16:13 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:16:13 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
Message-ID: <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>

On Thu, 15 Dec 2022 00:58:06 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
> 
>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>> 187: 
>> 188: main.plugin.category=\u7C7B\u522B 
> 
> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.

Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 02:26:12 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 02:26:12 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
Message-ID: <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>

On Thu, 15 Dec 2022 01:04:12 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:
> 
>> 24: #
>> 25: 
>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten
> 
> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?

I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19.

I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated.

And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 02:45:48 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 02:45:48 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Removed trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/39511b7a..54d2ec5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From jlahoda at openjdk.org  Thu Dec 15 11:37:13 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 15 Dec 2022 11:37:13 GMT
Subject: [jdk20] RFR: 8298727: Trees.getPath may crash for unnamed package
In-Reply-To: <7Tl0sEwegXfG2pNBBApi9SdvYV8JAzrqq-QupCZ5QXU=.7377ae09-bc1c-4f93-adf8-1e7fbbbf04f7@github.com>
References: <7Tl0sEwegXfG2pNBBApi9SdvYV8JAzrqq-QupCZ5QXU=.7377ae09-bc1c-4f93-adf8-1e7fbbbf04f7@github.com>
Message-ID: <Lr-v0DqKoEEgKoXcJPupfaOII69fjlAwP0RzUwWWOHI=.8f9f5a22-176a-47eb-8e78-dcf7b2fbecfe@github.com>

On Wed, 14 Dec 2022 11:08:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering an empty `package-info.java` file is normally accepted by javac (as a `package-info` for the unnamed module). But, if `Trees.getPath` is used on the unnamed package, a NPE occurs:
> 
> java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.tree.JCTree.accept(com.sun.tools.javac.tree.JCTree$Visitor)" because "tree" is null
> at jdk.compiler/com.sun.tools.javac.tree.TreeInfo.declarationFor(TreeInfo.java:811)
> at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:779)
> at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:799)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getPath(JavacTrees.java:331)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getPath(JavacTrees.java:321)
> 
> 
> The reason is that `Env.tree` is initialized to the package clause in `Enter.visitTopLevel`, but when the package clause is missing, `Env.tree` is `null`, leading to the error above.
> 
> The proposed fix is to set `Env.tree` to the top-level tree in this case, to keep it non-null. As the empty `package-info` can be compiled, it seems reasonable for the model to work on is as well, so a non-null tree needs to be set, and there's no other tree that could be used, I believe.

Thanks for the review, Vicente!

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

PR: https://git.openjdk.org/jdk20/pull/31

From jlahoda at openjdk.org  Thu Dec 15 11:37:15 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 15 Dec 2022 11:37:15 GMT
Subject: [jdk20] Integrated: 8298727: Trees.getPath may crash for unnamed
 package
In-Reply-To: <7Tl0sEwegXfG2pNBBApi9SdvYV8JAzrqq-QupCZ5QXU=.7377ae09-bc1c-4f93-adf8-1e7fbbbf04f7@github.com>
References: <7Tl0sEwegXfG2pNBBApi9SdvYV8JAzrqq-QupCZ5QXU=.7377ae09-bc1c-4f93-adf8-1e7fbbbf04f7@github.com>
Message-ID: <dU6utKgZri_TSf00z8BMRYxPLyy8t6Gk6LhR0Zl2dC8=.177f844e-f56e-4609-93ae-8d16892dd531@github.com>

On Wed, 14 Dec 2022 11:08:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering an empty `package-info.java` file is normally accepted by javac (as a `package-info` for the unnamed module). But, if `Trees.getPath` is used on the unnamed package, a NPE occurs:
> 
> java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.tree.JCTree.accept(com.sun.tools.javac.tree.JCTree$Visitor)" because "tree" is null
> at jdk.compiler/com.sun.tools.javac.tree.TreeInfo.declarationFor(TreeInfo.java:811)
> at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:779)
> at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:799)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getPath(JavacTrees.java:331)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getPath(JavacTrees.java:321)
> 
> 
> The reason is that `Env.tree` is initialized to the package clause in `Enter.visitTopLevel`, but when the package clause is missing, `Env.tree` is `null`, leading to the error above.
> 
> The proposed fix is to set `Env.tree` to the top-level tree in this case, to keep it non-null. As the empty `package-info` can be compiled, it seems reasonable for the model to work on is as well, so a non-null tree needs to be set, and there's no other tree that could be used, I believe.

This pull request has now been integrated.

Changeset: 22a6b591
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/22a6b5910290cb8a3876f94213ba60db86e60718
Stats:     137 lines in 2 files changed: 136 ins; 0 del; 1 mod

8298727: Trees.getPath may crash for unnamed package

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk20/pull/31

From dnguyen at openjdk.org  Thu Dec 15 12:06:10 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 12:06:10 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
 <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>
Message-ID: <iBTNjKoPxhwIA8LhLguE4u7j67wbLJolkZ4jx-1uz5g=.be6291cd-2fd4-403a-bb37-1f88479f967e@github.com>

On Thu, 15 Dec 2022 01:13:32 GMT, Justin Lu <duke at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
>> 
>>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>>> 187: 
>>> 188: main.plugin.category=\u7C7B\u522B 
>> 
>> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.
>
> Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop

In our discussion, Kate mentioned that some languages are double byte, so this extra space may be correct but she hasn't looked in detail yet. I looked through all of the changes and these two instances of trailing whitespaces were the only two. I removed the extra spaces to reduce the changes as it seems useless due to the previous version not having the whitespace.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 18:54:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 18:54:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
 <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>
Message-ID: <YYf976GjBqhqZZlsCUy6oz6Tx_KLFXz7iCsU86GAKSM=.5bd572ce-1523-4b69-a17a-1a2b70c896f0@github.com>

On Thu, 15 Dec 2022 02:23:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:
>> 
>>> 24: #
>>> 25: 
>>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten
>> 
>> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?
>
> I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19.
> 
> I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated.
> 
> And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated.

I conversed with Kate and the problem seems to come from the extraction process. We went through the source files that were sent for translation as a zip, and some changes would be missing. We confirmed that everything in this zip was translated, so the issue was in the extraction to create the source files to send for translation.  

For example, the plugin.properties missing text didn't show in the source.zip but showed on my forked repo used in the extraction. I re-ran the extraction script but still did not see the new text in the generated zip.

Kate thinks a similar issue occurred in the previous drop and this jmod.properties change wasn't captured in the extraction process. So now it is captured in this drop and translated here. It could be syncing or branch issues, but while working with Kate, I learned to better see what files are pulled from the extraction script. So for future drops, I can better check to make sure changes I expect to be translated will appear.

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

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 18:58:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 18:58:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
Message-ID: <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>

On Thu, 15 Dec 2022 02:45:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespace

Changes requested by naoto (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 217:

> 215: javac.msg.usage.nonstandard.footer=Diese zus\u00E4tzlichen Optionen k\u00F6nnen jederzeit ohne vorherige Ank\u00FCndigung ge\u00E4ndert werden.
> 216: 
> 217: javac.msg.bug=Im Compiler ({0}) ist eine Ausnahme aufgetreten. Erstellen Sie auf der Java-Seite zum Melden von Bugs (http://bugreport.java.com) einen Bugbericht, nachdem Sie die Bugdatenbank (http://bugs.java.com) auf Duplikate gepr\u00FCft haben. Geben Sie in Ihrem Bericht Ihr Programm, die folgende Diagnose und die Parameter an, die Sie dem Java-Compiler \u00FCbergeben haben. Vielen Dank.

How come `https` turned into `http`? I see these happening all over the places other than this location as well.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134:

> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung
> 133: artifact.not.found=nicht gefunden
> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 20:43:42 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 20:43:42 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix https and changed URL back

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/54d2ec5f..09140a05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01-02

  Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 20:55:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 20:55:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
 <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>
Message-ID: <Wq-WW8kfFkrS08vlPmgmD_ApiBVdboI6hEoARHr72zk=.7d3ca55c-db6e-4734-8724-75cb5d0a2f82@github.com>

On Thu, 15 Dec 2022 18:52:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespace
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134:
> 
>> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung
>> 133: artifact.not.found=nicht gefunden
>> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
> 
> This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales.

This and the https->http differences seem to also be a part of the extraction issue. The resource generation files show "http" and "java.net", but I see differently on my local repo that I used for the extraction.

I will run a new extraction job on a fresh repo/branch to see if this issue is reproducible and narrow down the source of the extraction issue.

As discussed with Naoto, these are small edits, and they have been addressed in the latest PR.

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

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 21:16:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 21:16:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
Message-ID: <pE7z2olK_Ec3qJO1w1KbXo55BIsYVK7Cu1_MPUMUmkg=.48f8c2f4-0b68-47ba-a46f-d8cb8d17d481@github.com>

On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix https and changed URL back

Thanks for the update, Damon. Looks good for this drop.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 23:01:35 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 23:01:35 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert double quote as well

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/09140a05..57c42206

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02-03

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 23:12:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 23:12:06 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <orIjM2vHBgrTyKBL5fjG9TX1ZI8AuJ48PGF2nqlSip0=.7f9e9cb5-0cfa-4985-8bff-aa5ead6f1c6d@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

Marked as reviewed by naoto (Reviewer).

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26:

> 24: #
> 25: 
> 26: main.usage=Verwendung: jdeprscan [Optionen] '{dir|jar|class}' ...\n\nOptionen:\n        --class-path PATH\n        --for-removal\n        --full-version\n  -? -h --help\n  -l    --list\n        --release {0}\n  -v    --verbose\n        --version

Good catch!

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

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Thu Dec 15 23:17:12 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 15 Dec 2022 23:17:12 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
Message-ID: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>

On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix https and changed URL back

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:

> 80: 
> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt

error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties line 82:

> 80: 
> 81: error.foreign-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306B.jpackage.xml\u30D5\u30A1\u30A4\u30EB\u304C\u3042\u308A\u307E\u305B\u3093
> 82: error.invalid-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306F\u5225\u306Ejpackage\u30D0\u30FC\u30B8\u30E7\u30F3\u307E\u305F\u306F\u4E0D\u6B63\u306A.jpackage.xml\u3067\u751F\u6210\u3055\u308C\u307E\u3057\u305F

Same as "de" translation.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties line 82:

> 80: 
> 81: error.foreign-app-image=\u9519\u8BEF\uFF1Aapp-image \u76EE\u5F55 ({0}) \u4E2D\u7F3A\u5C11 .jpackage.xml \u6587\u4EF6
> 82: error.invalid-app-image=\u9519\u8BEF\uFF1A\u53E6\u4E00\u4E2A jpackage \u7248\u672C\u6216\u683C\u5F0F\u9519\u8BEF\u7684 .jpackage.xml \u751F\u6210\u4E86 app-image \u76EE\u5F55 ({0})

Same as "de" translation.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">

Why "de-de" was changed to "de"?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="ja" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">

Why "ja-jp" to "ja"?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 37:

> 35: resource.post-app-image-script=Auszuf\u00FChrendes Skript nach dem Auff\u00FCllen des Anwendungsimages
> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Why this was changed?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:

> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Why this was changed?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 37:

> 35: resource.post-app-image-script=\u8981\u5728\u586B\u5145\u5E94\u7528\u7A0B\u5E8F\u6620\u50CF\u4E4B\u540E\u8FD0\u884C\u7684\u811A\u672C
> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Same as above.

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

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Thu Dec 15 23:17:15 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 15 Dec 2022 23:17:15 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 15:

> 13:   <String Id="ShortcutPromptDlgStartMenuShortcutControlLabel">????????????????????</String>
> 14:   <String Id="InstallDirNotEmptyDlg_Title">[ProductName]??????</String>
> 15:   <String Id="ContextMenuCommandLabel">Open with [ProductName]</String>

Why it was removed in all translations, except English?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51:

> 49: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen
> 50: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden
> 51: error.icon-swap=Failed to update icon for {0}

Why this was removed?

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

PR: https://git.openjdk.org/jdk20/pull/35

From weijun at openjdk.org  Thu Dec 15 23:34:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Dec 2022 23:34:10 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:

> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},

The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.

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

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 23:40:10 2022
From: duke at openjdk.org (duke)
Date: Thu, 15 Dec 2022 23:40:10 GMT
Subject: Withdrawn: 8064931: tools/javac/scope/DupUnsharedTest.java needs to be
 updated to add the bug id
In-Reply-To: <ZsHhpuB7WpP8v5heIy3W4y-s3ixm7dLP6Ums5U2zGb4=.b35f60e9-a2f9-49e4-bd0a-7c7a350a0f83@github.com>
References: <ZsHhpuB7WpP8v5heIy3W4y-s3ixm7dLP6Ums5U2zGb4=.b35f60e9-a2f9-49e4-bd0a-7c7a350a0f83@github.com>
Message-ID: <ZY3ogbMkIdLCSRsXZQziqZZpixrVjxqH08KAOpMs-2U=.82cee5a2-b690-47d1-a234-14fcb5cf4b9c@github.com>

On Thu, 20 Oct 2022 01:47:43 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> 8064931: tools/javac/scope/DupUnsharedTest.java needs to be updated to add the bug id

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10777

From duke at openjdk.org  Thu Dec 15 23:47:08 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 15 Dec 2022 23:47:08 GMT
Subject: RFR: 8219810: javac throws NullPointerException [v2]
In-Reply-To: <7zparHfFb_VqJAO3dUHq-zx85G6i79FBEogM_ncd4qg=.2d27b84d-3ec9-4e17-b13c-4f2743ce230d@github.com>
References: <PNAXdaGgA5nNPEm4fb-jWSoTuZHtAqfSvtaiCyZ5vzM=.cfb759ae-f8d9-4fe8-8c19-35251b3a586e@github.com>
 <7zparHfFb_VqJAO3dUHq-zx85G6i79FBEogM_ncd4qg=.2d27b84d-3ec9-4e17-b13c-4f2743ce230d@github.com>
Message-ID: <QNJXedgWnvYw_c06-jsPDS1ghv13lCp6w8lt0LsLX9Y=.88fd3cf5-a682-43dd-a147-f1f1ade67380@github.com>

On Thu, 17 Nov 2022 19:11:25 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JVMS 4.5 states:
>> 
>>> Each field of a class may have at most one of its ACC_PUBLIC, ACC_PRIVATE, and ACC_PROTECTED flags set (JLS ?8.3.1), and must not have both its ACC_FINAL and ACC_VOLATILE flags set (JLS ?8.3.1.4).
>> 
>> and JVMS 4.6 states:
>> 
>>> Each method of a class may have at most one of its ACC_PUBLIC, ACC_PRIVATE, and ACC_PROTECTED flags set (JLS ?8.4.3). 
>> 
>> However, when reading class files these illegal combinations are not actually checked, and this can lead to compiler crashes as in the bug example.
>> 
>> This patch adds checks for these illegal combinations.
>
> Archie L. Cobbs 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-8219810
>  - Also disallow field access flags from having both FINAL and VOLATILE.
>  - Detect invalid access flag combinations for fields and methods in classfiles.

keepalive

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

PR: https://git.openjdk.org/jdk/pull/10826

From duke at openjdk.org  Thu Dec 15 23:48:13 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 15 Dec 2022 23:48:13 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v3]
In-Reply-To: <X0oiPC_N0W-ipAJksCkgeAbL_mSdqvjNOKkRoK-PkK0=.9045fbe9-8739-4ce5-8a9d-effc122db075@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
 <X0oiPC_N0W-ipAJksCkgeAbL_mSdqvjNOKkRoK-PkK0=.9045fbe9-8739-4ce5-8a9d-effc122db075@github.com>
Message-ID: <NKPLQehC8eJCp8Dna4BIIhCZzdmNxQQC6PMKH4NqG78=.a842a292-6833-4b11-9823-2caccd541579@github.com>

On Thu, 17 Nov 2022 19:11:18 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is both a minor optimization and a fix for JDK-7176515.
>> 
>> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
>> 
>> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
>> 
>> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
>> 
>> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
>> 
>> This results in two improvements:
>> * It avoids building the lookup table for switches on self
>> * It fixes JDK-7176515 as stated
>> 
>> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
>> 
>> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
>> 
>> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.
>
> Archie L. Cobbs 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-7176515
>  - Give test a better name and don't rely on assertions being enabled.
>  - Skip enum switch lookup tables when compiling the enum switch class.

keepalive

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

PR: https://git.openjdk.org/jdk/pull/10797

From duke at openjdk.org  Thu Dec 15 23:48:15 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 15 Dec 2022 23:48:15 GMT
Subject: RFR: 8155259: Suspicious buffer allocation in
 com.sun.tools.javac.file.BaseFileManager [v2]
In-Reply-To: <h8eLLAo5jXsAwKc6-jCNpva3lEu3yCsWMMEDkQ32EXE=.7ed16262-b40c-48bb-8693-f93d4517f574@github.com>
References: <a0jq1KJR3VGCmm-vEnlUcHw_CYNlHmJNJd6tlgceEUs=.07787b9f-b04f-4d33-9b46-f0c0420b8398@github.com>
 <h8eLLAo5jXsAwKc6-jCNpva3lEu3yCsWMMEDkQ32EXE=.7ed16262-b40c-48bb-8693-f93d4517f574@github.com>
Message-ID: <wr9gGltKIEEmCSQSdi2hAGfGyeWkJHvGGBuUNr9rAjg=.aad4b1a8-8a6c-4b05-a02c-0e51d8962f27@github.com>

On Thu, 17 Nov 2022 19:11:14 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JDK-8155259 notes that in `BaseFileManager` this code:
>> 
>> ByteBuffer.allocate(capacity + capacity>>1)
>> 
>> is actually equivalent (assuming no overflow) to:
>> 
>> ByteBuffer.allocate(capacity)
>> 
>> because in Java the `+` operator has higher precedence than the `>>` operator.
>> 
>> In the bug it is suggested that this be changed to reflect the presumed original intent to over-allocate by 50%, i.e.:
>> 
>> ByteBuffer.allocate(capacity + (capacity>>1))
>> 
>> however, this patch is more conservative in that it leaves the existing behavior alone and instead just simplifies it to:
>> 
>> ByteBuffer.allocate(capacity)
>> 
>> allowing us to at least resolve JDK-8155259.
>
> Archie L. Cobbs 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-8155259
>  - 8155259: Suspicious buffer allocation in com.sun.tools.javac.file.BaseFileManager

keepalive

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

PR: https://git.openjdk.org/jdk/pull/10803

From duke at openjdk.org  Thu Dec 15 23:48:16 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 15 Dec 2022 23:48:16 GMT
Subject: RFR: 8043251: Bogus javac error: required: no arguments,
 found: no arguments [v2]
In-Reply-To: <bloQnoxGgoYjCi756qXF-04sPgs2CRoQzm9ol1a0Hk8=.514795a1-776d-44ca-a94c-3559090796b2@github.com>
References: <ttyl1QzWEJGynqGR_A3okSQE1raIc9Z_k964MzAx1Fw=.30f27c1a-ed84-4876-88b2-9bc58f2ad3f4@github.com>
 <bloQnoxGgoYjCi756qXF-04sPgs2CRoQzm9ol1a0Hk8=.514795a1-776d-44ca-a94c-3559090796b2@github.com>
Message-ID: <e2FkVZsKBTTe5BkVOXzyakAcQ7YYnDb7KreVwp-cH1M=.726eab09-d960-4c17-8a2c-c5e5b9be16a1@github.com>

On Thu, 17 Nov 2022 19:10:59 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> We have an error message `compiler.err.cant.apply.symbol` for cases where a method invocation doesn't resolve. It shows the "required" parameters and the "found" parameters, plus a further description of the problem.
>> 
>> This message being used inappropriately when the problem is actually due to explicitly passed method type parameters instead of regular method parameters.
>> 
>> For example, if you do this:
>> 
>> Function<String, String> f = Function.<String, String>identity();
>> 
>> the error reported is this:
>> 
>> error: method identity in interface Function<T,R> cannot be applied to given types;
>>     Function<String, String> f = Function.<String, String>identity();
>>                                          ^
>>   required: no arguments
>>   found:    no arguments
>>   reason: wrong number of type arguments; required 1
>>   where T,R are type-variables:
>>     T extends Object declared in interface Function
>>     R extends Object declared in interface Function
>> 
>> The real error here is `wrong number of type arguments; required 1`, but the `compiler.err.cant.apply.symbol` error message that assumes the problem is with the regular parameters, which it displays. The result is the appearance of the useless and confusing `required` and `found` lines.
>> 
>> This patch creates an alternate version of that error message (`compiler.err.cant.apply.symbol.noargs`) that omits the `required` and `found` lines, and makes the compiler use this alternate message when the error is due to type parameters (specifically, when the underlying error is "wrong number of type arguments" or "explicit type argument X does not conform to declared bound(s)").
>> 
>> This improves the error for example above to this:
>> 
>> error: method identity in interface Function<T,R> cannot be applied to given types;
>>     Function<String, String> f = Function.<String, String>identity();
>>                                          ^
>>   reason: wrong number of type arguments; required 1
>>   where T,R are type-variables:
>>     T extends Object declared in interface Function
>>     R extends Object declared in interface Function
>> 1 error
>
> Archie L. Cobbs 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-8043251
>  - Fix confusing error message regarding wrong number of type parameters.

keepalive

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

PR: https://git.openjdk.org/jdk/pull/10799

From duke at openjdk.org  Thu Dec 15 23:50:08 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 15 Dec 2022 23:50:08 GMT
Subject: RFR: 8184444: The compiler error
 "variable not initialized in the default constructor" is not apt in case of
 static final variables [v2]
In-Reply-To: <kma982o4buot6_vVMO59n-62-sE3D0e67XnESp3IOX0=.f41647e2-fade-4dfc-9569-8be876d07e7a@github.com>
References: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
 <kma982o4buot6_vVMO59n-62-sE3D0e67XnESp3IOX0=.f41647e2-fade-4dfc-9569-8be876d07e7a@github.com>
Message-ID: <9E1aUVULwDzw3MNsjOX8mkUHlNF9oLkZ8LSNdpXiJWw=.ee1deca5-3123-438f-9bce-ac0bf1154407@github.com>

On Thu, 17 Nov 2022 19:11:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug causes this class:
>> 
>> class StaticFinalInit {
>>     static final int foo;
>> }
>> 
>> to fail to compile as it should but with a confusing error message:
>> 
>> StaticFinalInit.java:2: error: variable foo not initialized in the default constructor
>>     static final int foo;
>>                      ^
>> 
>> In another variant, if there is a non-default constructor:
>> 
>> class StaticFinalInit {
>>     static final int foo;
>>     StaticFinalInit() { }
>> }
>> 
>> the compiler gives the right error message but shows the wrong source code location:
>> 
>> StaticFinalInit.java:3: error: variable foo might not have been initialized
>>     StaticFinalInit() { }
>>                         ^
>> 
>> This behavior is a side-effect of the roundabout way we currently check for definite assignment of static final fields.
>> 
>> When recursing into a class definition in `Flow.AssignAnalyzer`, we first initialize DA/DU analysis for static fields, and then recurse on the static initializers to pick up static field assignments. However, we don't then check for definite assignment of static final fields. Instead, we proceed with the analysis, and then later, whenever we visit an initial constructor (i.e., one that invokes `super()` instead of `this()`), we check for definite assignment of both static final and instance final fields.
>> 
>> This works because every class has at least one initial constructor, so static fields will always get checked at least once. Of course, it also results in doing some redundant work (if there are multiple initial constructors) and it generates the wrong error message and/or source code position.
>> 
>> This patch adds a check for definite assignment of static final fields (with the appropriate error message) after we recurse on the static initializers, and it filters out static fields from the checks being done in initial constructors. It also updates a couple of existing unit tests that were expecting the wrong source code position.
>> 
>> The two examples above now both generate this error message:
>> 
>> StaticFinalInit.java:2: error: variable foo might not have been initialized
>>     static final int foo;
>>                      ^
>
> Archie L. Cobbs 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-8184444
>  - Fix confusing error message for uninitialized static final fields.

keepalive

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

PR: https://git.openjdk.org/jdk/pull/10896

From duke at openjdk.org  Fri Dec 16 00:03:09 2022
From: duke at openjdk.org (duke)
Date: Fri, 16 Dec 2022 00:03:09 GMT
Subject: Withdrawn: 8043179: Lambda expression can mutate final field
In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
Message-ID: <k71llBjsxowlCQhClm_zJYSzbhl_RrYgKIOm4mWi6l8=.ad91c3d4-9d17-421d-89d1-163b6350dc99@github.com>

On Wed, 21 Sep 2022 23:03:45 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> (Description revised)
> 
> JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime:
> 
>>  _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._
> 
> This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10381

From dnguyen at openjdk.org  Fri Dec 16 00:20:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 00:20:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
Message-ID: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>

On Thu, 15 Dec 2022 22:57:31 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix https and changed URL back
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:
> 
>> 80: 
>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt
> 
> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?

I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
> 
> Why "de-de" was changed to "de"?

Also not sure why this was changed in the translation. I'm reverting all instances of these language codes.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 00:28:14 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 00:28:14 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
Message-ID: <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>

On Thu, 15 Dec 2022 23:13:22 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix https and changed URL back
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:
> 
>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Why this was changed?

Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.

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

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Fri Dec 16 00:55:07 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 00:55:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
Message-ID: <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>

On Fri, 16 Dec 2022 00:15:51 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:
>> 
>>> 80: 
>>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
>>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt
>> 
>> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?
>
> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?

Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.

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

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Fri Dec 16 00:59:08 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 00:59:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>
Message-ID: <ybG8PSIdt0XyYOo4JF4ozp2yRpZDnPQUpDxoDeFTiCo=.fbe7a6d5-9bc3-4097-bd02-164f015bcaf6@github.com>

On Fri, 16 Dec 2022 00:24:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:
>> 
>>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
>> 
>> Why this was changed?
>
> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.

Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 01:05:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 01:05:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
 <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
Message-ID: <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>

On Fri, 16 Dec 2022 00:51:55 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?
>
> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.

I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then.

>> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.
>
> Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code.

This drop had some issues with the extraction which will be resolved. Some of the changes are correct while some seem to be old. It seems these jpackage files were are older? I can revert these changes for jpackage then.

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

PR: https://git.openjdk.org/jdk20/pull/35

From joehw at openjdk.org  Fri Dec 16 01:25:18 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 16 Dec 2022 01:25:18 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <ienEQpq9KGQ0-B04HBvRrPpNQDISigGzx4lTtzjuDVY=.7bcc0fd3-51c9-4e51-9684-266a98e521ec@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

The changes in the java.xml area look good to me.

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

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:38:54 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:54 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert old translation. Fix lang codes

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/57c42206..29880af9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03-04

  Stats: 18 lines in 9 files changed: 6 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:38:56 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:56 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
 <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
 <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>
Message-ID: <_Dir5hjsOpTXHLKfV6SM_6kUJfNcHSkgHjrRAHbGUfw=.db9fe398-4a22-4aab-90ef-72d67f5c708e@github.com>

On Fri, 16 Dec 2022 01:02:03 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.
>
> I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then.

The translated text here has been reverted to its original English. The same has been done for its locales.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:38:58 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:58 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
Message-ID: <AkPK7pgS3BMYAhNKSN0Xz0Jr0ey_vcQHGP8UmdXy1II=.9691952b-cf52-4724-8c48-3496dfa671c8@github.com>

On Fri, 16 Dec 2022 00:17:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
>> 
>>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
>> 
>> Why "de-de" was changed to "de"?
>
> Also not sure why this was changed in the translation. I'm reverting all instances of these language codes.

This has been reverted as it was a regression for all locales of MsiInstallerStrings.wxl

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:39:01 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:39:01 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>
Message-ID: <bbvTT7_7dNA1j9sUSiPADGEnuneemJPFgiiIAI8SsxU=.7e1290eb-107a-458e-a4ee-2cab3b9e7fbf@github.com>

On Thu, 15 Dec 2022 23:12:58 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespace
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51:
> 
>> 49: error.msi-product-version-build-out-of-range=Build-Teil der Version muss im Bereich [0, 65535] liegen
>> 50: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen
>> 51: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden
> 
> Why this was removed?

This line was added back to all locales as it was a regression from the translation process.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:45:07 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:45:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
Message-ID: <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>

On Thu, 15 Dec 2022 23:30:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert double quote as well
>
> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:
> 
>> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
>> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
> 
> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.

I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:58:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:58:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

@dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team.

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

PR: https://git.openjdk.org/jdk20/pull/35

From cjplummer at openjdk.org  Fri Dec 16 04:12:17 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 Dec 2022 04:12:17 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <XK9d6e9V7rnGtOvMP2mHVDwxsaO_cQCWhnehjTarZ_w=.01c61275-fd0e-4532-8a17-a13c16734bb8@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

`src/jdk.jdi/share/classes/com/sun/tools` changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Fri Dec 16 05:17:11 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 05:17:11 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <J3GyIIuioqw6EvIvhMXFm2MByz1cylrmF-jSJcyg3RM=.cd6f3f83-a261-4fa1-ab46-c7d017709595@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

jpackage changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From dfuchs at openjdk.org  Fri Dec 16 09:22:29 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Dec 2022 09:22:29 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:

> 32: # Translators please note do not translate the options themselves
> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E4n
 glichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--vali
 date-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hilfe
  zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]\n
                   \
> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f
 \u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n

This change seems wrong, unless I'm mistaken the option name is `--disable- at files`, not `-disable- at files`

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

PR: https://git.openjdk.org/jdk20/pull/35

From dfuchs at openjdk.org  Fri Dec 16 09:48:59 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Dec 2022 09:48:59 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
Message-ID: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>

On Fri, 16 Dec 2022 09:20:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:
> 
>> 32: # Translators please note do not translate the options themselves
>> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E4
 nglichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--val
 idate-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hilf
 e zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]\
 n                  \
>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument 
 f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n
> 
> This change seems wrong, unless I'm mistaken the option name is still  `--disable- at files`, not `-disable- at files`

I'm unfortunately not familiar with any of these resources files,  and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation.
Find-in-files revealed that the source is still using --disable- at files. See:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131

https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121

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

PR: https://git.openjdk.org/jdk20/pull/35

From alanb at openjdk.org  Fri Dec 16 10:13:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Dec 2022 10:13:04 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>
Message-ID: <s7AGBhlHie3pq-e0NT_2pQ3hWQ15Oyt1dR_t2D9YM3g=.01648378-0fb2-4f51-a9bf-1f5066e40158@github.com>

On Fri, 16 Dec 2022 03:55:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> @dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team.

@DamonGuy There seems to be several glitches in this refresh. It's also surprising that the translations appear to be done on several out of date files. On the positive front, it's good to see this update has caught the attention of Naoto, Weijun, and others. Once the identified issues have been fixed then it would be good to try to get a review from someone that is native in each of the languages.

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

PR: https://git.openjdk.org/jdk20/pull/35

From jwilhelm at openjdk.org  Fri Dec 16 13:33:14 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 16 Dec 2022 13:33:14 GMT
Subject: RFR: Merge jdk20
Message-ID: <YSHTcwXEKi0AYIOzrJy89CKa6GDNBwOXsUj0qcvrtz0=.249e0882-9bd1-49da-abcd-19e0a3d9ef5b@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge
 - 8298797: Specification of some restricted methods is incorrect
 - 8287699: jdk/jfr/api/consumer/TestRecordingFileWrite.java fails with exception: java.lang.Exception: Found event that should not be there.
 - 8297979: ZGC: Ensure consistent MemoryUsage from MemoryMXBean.getHeapMemoryUsage()
 - 8298083: The "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
 - 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx
 - 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected
 - 8298050: Add links to graph output for javadoc
 - 8298376: ZGC: thaws stackChunk with stale oops
 - 8298727: Trees.getPath may crash for unnamed package
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ac2fcf3f...f069db65

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11710&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11710&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11710/files
  Stats: 250 lines in 15 files changed: 180 ins; 52 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/11710.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11710/head:pull/11710

PR: https://git.openjdk.org/jdk/pull/11710

From naoto at openjdk.org  Fri Dec 16 13:46:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Dec 2022 13:46:02 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <FkE6xWy1f_931bWkjLEGooZJgRw31mF1UNMMMjICFUQ=.90de6a4a-57c3-41c4-8c9c-2c582f4696c0@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

There is another translation drop scheduled in January, so our plan is to figure out why the source extraction in this drop mistakenly used old files till then, then address it in the January l10n drop.

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

PR: https://git.openjdk.org/jdk20/pull/35

From weijun at openjdk.org  Fri Dec 16 15:05:55 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Dec 2022 15:05:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
Message-ID: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>

On Fri, 16 Dec 2022 03:41:09 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:
>> 
>>> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
>>> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>>> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>> 
>> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.
>
> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?

Yes, you can replace all "??????" (that is not after ""???") to "?????????".

There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.

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

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Fri Dec 16 15:18:38 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 16 Dec 2022 15:18:38 GMT
Subject: RFR: 8298943: Add missing escapes for single quotes in
 compiler.properties
Message-ID: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>

The source file `compiler.properties` contains the English message bundle for compiler warnings, errors, etc.

Since the strings in this file are format strings, any single quotes must be escaped by doubling them.

An example of a properly encoded entry is:


compiler.err.cant.assign.val.to.this=\
????cannot assign to ''this''


There are three entries that appear to be not escaped when they should be.

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

Commit messages:
 - Add missing escapes for single quotes.

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

PR: https://git.openjdk.org/jdk/pull/11712

From jwilhelm at openjdk.org  Fri Dec 16 15:52:00 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 16 Dec 2022 15:52:00 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <YSHTcwXEKi0AYIOzrJy89CKa6GDNBwOXsUj0qcvrtz0=.249e0882-9bd1-49da-abcd-19e0a3d9ef5b@github.com>
References: <YSHTcwXEKi0AYIOzrJy89CKa6GDNBwOXsUj0qcvrtz0=.249e0882-9bd1-49da-abcd-19e0a3d9ef5b@github.com>
Message-ID: <z_G2NJpaW0cmxQZFzSX6rOdwLniXiNqi1pJnO1i3px0=.5f7eff5b-3931-4541-b0b1-717d7e2eecd6@github.com>

On Fri, 16 Dec 2022 13:25:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 3696711e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3696711efa566fb776d6923da86e17b0e1e22964
Stats:     250 lines in 15 files changed: 180 ins; 52 del; 18 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11710

From dnguyen at openjdk.org  Fri Dec 16 16:53:59 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 16:53:59 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <eKoHNhbn6nSejGumOAm87rtEJh5ZyQVEaFblB2t7jOA=.3366bc22-6709-479c-a23a-d41f1aa49b33@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

Right, Naoto's comment is correct. This time, the source extraction used some older files. To resolve this for this drop, I went through the files and reverted any changes that would be deemed as regressions or outdated files. Any other updates missed in this drop will be handled in the close upcoming drop in January.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:02:44 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:02:44 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
 <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>
Message-ID: <uipT8s-ZFfoJgsIH3b7vP8Pgu15BiK3gx4EmIZ09pyQ=.c1ead06a-8b31-41d3-8601-52c4ed8d854e@github.com>

On Fri, 16 Dec 2022 09:46:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:
>> 
>>> 32: # Translators please note do not translate the options themselves
>>> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E
 4nglichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--va
 lidate-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hil
 fe zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]
 \n                  \
>>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument
  f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n
>> 
>> This change seems wrong, unless I'm mistaken the option name is still  `--disable- at files`, not `-disable- at files`
>
> I'm unfortunately not familiar with any of these resources files,  and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation.
> Find-in-files revealed that the source is still using --disable- at files. See:
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121

Thanks for taking a look. I fixed this removed dash from the translation in the latest PR.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:02:42 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:02:42 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v6]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing dash

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/29880af9..62a19a83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04-05

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From prr at openjdk.org  Fri Dec 16 17:28:56 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Dec 2022 17:28:56 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v6]
In-Reply-To: <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
Message-ID: <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>

On Fri, 16 Dec 2022 17:02:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing dash

src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430:

> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A
> 429: 
> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145, \u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6

I was asked to review SwingSet2 changes but this isn't code.
But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:42:17 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:42:17 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v7]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <joe6G_LIkLeUlpKw1IqhH00g23fEFnyi4ItJUUbQDxk=.89bfe214-866a-4e27-98eb-ba925b45dd05@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert swingset. Consistency in CN

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/62a19a83..fe18e4ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05-06

  Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:45:05 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:45:05 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
 <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
Message-ID: <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>

On Fri, 16 Dec 2022 15:02:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?
>
> Yes, you can replace all "??????" (that is not after ""???") to "?????????".
> 
> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.

Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. 

Could you re-review the current changes for this drop?

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:51:19 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:51:19 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v8]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <HHXCd5IsWRZEjWoBRIxu95AEttEQXvgPx-uzGBjHn8I=.34a5040a-1cf9-4ac2-b664-b710cab2e7cf@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Swingset newline

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/fe18e4ea..f058a1de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06-07

  Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:51:20 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:51:20 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
 <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>
Message-ID: <Z2W3BZQLpjHfGyASnkwSyvXnU9U0eou4iovSpNWPrX8=.896c41fd-df2d-4cac-be80-7cb28c32959c@github.com>

On Fri, 16 Dec 2022 17:26:18 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430:
> 
>> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A
>> 429: 
>> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145\uFF0C\u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6
> 
> I was asked to review SwingSet2 changes but this isn't code.
> But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble.

Thanks. I removed the changes to swingset's translation to avoid causing any issues.

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

PR: https://git.openjdk.org/jdk20/pull/35

From weijun at openjdk.org  Fri Dec 16 18:02:55 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Dec 2022 18:02:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
 <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
 <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>
Message-ID: <szezmXXF_0qzSfcp7mcIRk885jnyJf63o7prZfi2VJ8=.e6528252-60de-45c9-9bbd-0157164d890f@github.com>

On Fri, 16 Dec 2022 17:41:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Yes, you can replace all "??????" (that is not after ""???") to "?????????".
>> 
>> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.
>
> Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. 
> 
> Could you re-review the current changes for this drop?

The updated file looks fine to me. Thanks.

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

PR: https://git.openjdk.org/jdk20/pull/35

From jjg at openjdk.org  Fri Dec 16 21:17:49 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 16 Dec 2022 21:17:49 GMT
Subject: RFR: 8298943: Add missing escapes for single quotes in
 compiler.properties
In-Reply-To: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
References: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
Message-ID: <p6AHc9hdPPll11_9c_W8UpBVEVcZH6G0Qu7FweEh5Ho=.8961e18b-105b-4b34-af02-a76bd246b086@github.com>

On Fri, 16 Dec 2022 15:11:18 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The source file `compiler.properties` contains the English message bundle for compiler warnings, errors, etc.
> 
> Since the strings in this file are format strings, any single quotes must be escaped by doubling them.
> 
> An example of a properly encoded entry is:
> 
> 
> compiler.err.cant.assign.val.to.this=\
> ????cannot assign to ''this''
> 
> 
> There are three entries that appear to be not escaped when they should be.

Marked as reviewed by jjg (Reviewer).

@archiecobbs You need to fix the PR title.

An interesting followup might be to update the `CheckResourceKeys` test to proactively check for this error condition.

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

PR: https://git.openjdk.org/jdk/pull/11712

From dnguyen at openjdk.org  Fri Dec 16 21:18:58 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 21:18:58 GMT
Subject: [jdk20] Integrated: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <3RA_5D04t20xCtp1jJI-KMZt7Ev8f7bJv2zlanOnE-E=.d82daa27-fd0d-4eca-88cd-61ace8ba0d4a@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

This pull request has now been integrated.

Changeset: c997b5bf
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/c997b5bffd0ebbd6d68332572639c8cea05ccdb1
Stats:     1128 lines in 99 files changed: 783 ins; 198 del; 147 mod

8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10

Reviewed-by: achung, naoto, joehw, cjplummer, almatvee

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

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Sat Dec 17 16:48:38 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 17 Dec 2022 16:48:38 GMT
Subject: RFR: 8298943: Missing escapes for single quote marks in
 compiler.properties [v2]
In-Reply-To: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
References: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
Message-ID: <Yc6KOkmzdxSrwmFhy9xcUyqs4bOIoW8nnw84_VXNkjE=.03b3eb9b-a28a-4026-83a5-823d8daf2a7e@github.com>

> The source file `compiler.properties` contains the English message bundle for compiler warnings, errors, etc.
> 
> Since the strings in this file are format strings, any single quotes must be escaped by doubling them.
> 
> An example of a properly encoded entry is:
> 
> 
> compiler.err.cant.assign.val.to.this=\
> ????cannot assign to ''this''
> 
> 
> There are three entries that appear to be not escaped when they should be.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add syntax checking of MessageFormat patterns in resouce bundles.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11712/files
  - new: https://git.openjdk.org/jdk/pull/11712/files/e427291c..c01be470

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11712&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11712&range=00-01

  Stats: 128 lines in 1 file changed: 128 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11712.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11712/head:pull/11712

PR: https://git.openjdk.org/jdk/pull/11712

From duke at openjdk.org  Sat Dec 17 16:48:40 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 17 Dec 2022 16:48:40 GMT
Subject: RFR: 8298943: Missing escapes for single quote marks in
 compiler.properties
In-Reply-To: <p6AHc9hdPPll11_9c_W8UpBVEVcZH6G0Qu7FweEh5Ho=.8961e18b-105b-4b34-af02-a76bd246b086@github.com>
References: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
 <p6AHc9hdPPll11_9c_W8UpBVEVcZH6G0Qu7FweEh5Ho=.8961e18b-105b-4b34-af02-a76bd246b086@github.com>
Message-ID: <s1b9Ez0Ooqii0_xeWypVTTqc5JMFVlXkv2lm8duAO-Q=.107bd6c7-393d-47ff-98cf-7f57ade44a28@github.com>

On Fri, 16 Dec 2022 21:15:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> An interesting followup might be to update the `CheckResourceKeys` test to proactively check for this error condition.

Great idea...  and no reason not to check for overall `MessageFormat` syntactical correctness since we effectively must replicate its (simplistic & quirky) parsing algorithm to do this.

Added in c01be470ba6.

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

PR: https://git.openjdk.org/jdk/pull/11712

From duke at openjdk.org  Sat Dec 17 16:52:15 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 17 Dec 2022 16:52:15 GMT
Subject: RFR: 8298943: Missing escapes for single quote marks in
 compiler.properties [v3]
In-Reply-To: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
References: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
Message-ID: <diVus5UjT25Wjb7lsldupYbZimdTzIfTktDRbsZt9f8=.b5dae684-58b5-40e8-8139-d3fcc754e6d8@github.com>

> The source file `compiler.properties` contains the English message bundle for compiler warnings, errors, etc.
> 
> Since the strings in this file are format strings, any single quotes must be escaped by doubling them.
> 
> An example of a properly encoded entry is:
> 
> 
> compiler.err.cant.assign.val.to.this=\
> ????cannot assign to ''this''
> 
> 
> There are three entries that appear to be not escaped when they should be.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Allow quoting of ',' characters.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11712/files
  - new: https://git.openjdk.org/jdk/pull/11712/files/c01be470..fe523617

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11712&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11712&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/11712

From forax at univ-mlv.fr  Sun Dec 18 13:25:39 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 18 Dec 2022 14:25:39 +0100 (CET)
Subject: Calling the constructor of a capturing local class in a static
 context throws a NPE
Message-ID: <601349861.68993242.1671369939583.JavaMail.zimbra@u-pem.fr>

Hi everybody,
a Christmas bug :)

public class StaticFieldInsideCapturingLocalClass {
  public static void test(int value) {
    class Foo {
      private static final Foo FOO = new Foo();

      public void m() {
        System.out.println(value);
      }
    }
    Foo.FOO.m();
  }
}

For me, "new Foo()" should not be allowed in a static context given that Foo capture the local variable "value".

I was able to reproduce the issue with Java 16, 17, 19 and 20 but not with Java 11 and 15.
This bug seems to have been introduced in Java 16 when Java starts to allow static final field in local class.


~/jdk/jdk-20-valhalla.jdk/Contents/Home/bin/javac StaticFieldInsideCapturingLocalClass.java 
An exception has occurred in the compiler (20-valhalla). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[0]" is null
        at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570)
        at jdk.compiler/com.sun.tools.javac.jvm.Items$SelfItem.load(Items.java:369)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitIdent(Gen.java:2354)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2735)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:902)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:927)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:2031)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1925)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:902)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitAssign(Gen.java:2087)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCAssign.accept(JCTree.java:2114)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:902)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1812)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1657)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:631)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:666)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:652)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:703)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1130)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1097)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:631)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:666)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:992)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:955)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:923)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:631)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2505)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:738)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1636)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1604)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:947)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)

happy Christmas,
R?mi

From duke at openjdk.org  Mon Dec 19 15:44:08 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:44:08 GMT
Subject: RFR: 8163229: test test/tools/javac/CaptureInSubtype.java has a
 main method that is never executed Export [v3]
In-Reply-To: <43_ndNUnEtQisakxCPVIqZGvizAmLUd2cKQ60X_3HRs=.05235cae-336f-4cb4-9e2a-88c4ba5753b8@github.com>
References: <43_ndNUnEtQisakxCPVIqZGvizAmLUd2cKQ60X_3HRs=.05235cae-336f-4cb4-9e2a-88c4ba5753b8@github.com>
Message-ID: <sFhntGYc1A6wcU19sCZnpj0tViQgyDi-1QBoOqQfqaQ=.33765451-e9b1-4c45-aedf-41a90d7901e4@github.com>

> This PR deals with some housekeeping relating to compiler unit tests.
> 
> JDK-8163229 points out that there are several tests that have a `public static void main(String[])` method, but because the test expects to fail during compilation, the test is never actually run, and so these `main` methods are just clutter that can be removed.
> 
> However, there are also some tests where the test is never run, but the `main()` method generates one or more of the expected compilation errors. Obviously we need to keep those, but they don't need to be declared as `public static void main(String[])` which is misleading. So instead we rename these methods to `meth()`, and also we remove the `String[]` parameter when it's not needed by the test.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8163229
 - Merge branch 'master' into JDK-8163229
 - Rename or remove "main()" methods in tests that never actually run.

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

Changes: https://git.openjdk.org/jdk/pull/10992/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10992&range=02
  Stats: 187 lines in 127 files changed: 0 ins; 68 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/10992.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10992/head:pull/10992

PR: https://git.openjdk.org/jdk/pull/10992

From duke at openjdk.org  Mon Dec 19 15:44:21 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:44:21 GMT
Subject: RFR: 8043251: Bogus javac error: required: no arguments,
 found: no arguments [v3]
In-Reply-To: <ttyl1QzWEJGynqGR_A3okSQE1raIc9Z_k964MzAx1Fw=.30f27c1a-ed84-4876-88b2-9bc58f2ad3f4@github.com>
References: <ttyl1QzWEJGynqGR_A3okSQE1raIc9Z_k964MzAx1Fw=.30f27c1a-ed84-4876-88b2-9bc58f2ad3f4@github.com>
Message-ID: <RfxVgB2DG8QlbDmgZnCZteUc6iuXqCmxN4QobDc4WCs=.34f15d85-109e-4fdb-b806-2693056c055e@github.com>

> We have an error message `compiler.err.cant.apply.symbol` for cases where a method invocation doesn't resolve. It shows the "required" parameters and the "found" parameters, plus a further description of the problem.
> 
> This message being used inappropriately when the problem is actually due to explicitly passed method type parameters instead of regular method parameters.
> 
> For example, if you do this:
> 
> Function<String, String> f = Function.<String, String>identity();
> 
> the error reported is this:
> 
> error: method identity in interface Function<T,R> cannot be applied to given types;
>     Function<String, String> f = Function.<String, String>identity();
>                                          ^
>   required: no arguments
>   found:    no arguments
>   reason: wrong number of type arguments; required 1
>   where T,R are type-variables:
>     T extends Object declared in interface Function
>     R extends Object declared in interface Function
> 
> The real error here is `wrong number of type arguments; required 1`, but the `compiler.err.cant.apply.symbol` error message that assumes the problem is with the regular parameters, which it displays. The result is the appearance of the useless and confusing `required` and `found` lines.
> 
> This patch creates an alternate version of that error message (`compiler.err.cant.apply.symbol.noargs`) that omits the `required` and `found` lines, and makes the compiler use this alternate message when the error is due to type parameters (specifically, when the underlying error is "wrong number of type arguments" or "explicit type argument X does not conform to declared bound(s)").
> 
> This improves the error for example above to this:
> 
> error: method identity in interface Function<T,R> cannot be applied to given types;
>     Function<String, String> f = Function.<String, String>identity();
>                                          ^
>   reason: wrong number of type arguments; required 1
>   where T,R are type-variables:
>     T extends Object declared in interface Function
>     R extends Object declared in interface Function
> 1 error

Archie L. Cobbs 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-8043251
 - Merge branch 'master' into JDK-8043251
 - Fix confusing error message regarding wrong number of type parameters.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10799/files
  - new: https://git.openjdk.org/jdk/pull/10799/files/2615d24b..92338830

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10799&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10799&range=01-02

  Stats: 136482 lines in 2312 files changed: 69468 ins; 45399 del; 21615 mod
  Patch: https://git.openjdk.org/jdk/pull/10799.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10799/head:pull/10799

PR: https://git.openjdk.org/jdk/pull/10799

From duke at openjdk.org  Mon Dec 19 15:44:25 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:44:25 GMT
Subject: RFR: 8298943: Missing escapes for single quote marks in
 compiler.properties [v4]
In-Reply-To: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
References: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
Message-ID: <hA8n2Utrg6D9RQ7A-cslfrHzK6Ekp3iSwsHGyHwwH8I=.a6991938-0223-4916-adb6-4497cdfefeda@github.com>

> The source file `compiler.properties` contains the English message bundle for compiler warnings, errors, etc.
> 
> Since the strings in this file are format strings, any single quotes must be escaped by doubling them.
> 
> An example of a properly encoded entry is:
> 
> 
> compiler.err.cant.assign.val.to.this=\
> ????cannot assign to ''this''
> 
> 
> There are three entries that appear to be not escaped when they should be.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8298943
 - Allow quoting of ',' characters.
 - Add syntax checking of MessageFormat patterns in resouce bundles.
 - Add missing escapes for single quotes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11712/files
  - new: https://git.openjdk.org/jdk/pull/11712/files/fe523617..ec386574

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11712&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11712&range=02-03

  Stats: 1859 lines in 73 files changed: 858 ins; 309 del; 692 mod
  Patch: https://git.openjdk.org/jdk/pull/11712.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11712/head:pull/11712

PR: https://git.openjdk.org/jdk/pull/11712

From duke at openjdk.org  Mon Dec 19 15:44:30 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:44:30 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v4]
In-Reply-To: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
Message-ID: <fJK-tBiANte5Py17tEXBhJC1HX_jujONBibCCS3wdRE=.a88a54e9-21ff-490e-9952-44e2292da2c3@github.com>

> This patch is both a minor optimization and a fix for JDK-7176515.
> 
> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
> 
> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
> 
> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
> 
> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
> 
> This results in two improvements:
> * It avoids building the lookup table for switches on self
> * It fixes JDK-7176515 as stated
> 
> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
> 
> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
> 
> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-7176515
 - Merge branch 'master' into JDK-7176515
 - Give test a better name and don't rely on assertions being enabled.
 - Skip enum switch lookup tables when compiling the enum switch class.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10797/files
  - new: https://git.openjdk.org/jdk/pull/10797/files/b5da18df..05fb5e76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10797&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10797&range=02-03

  Stats: 136482 lines in 2312 files changed: 69468 ins; 45399 del; 21615 mod
  Patch: https://git.openjdk.org/jdk/pull/10797.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10797/head:pull/10797

PR: https://git.openjdk.org/jdk/pull/10797

From duke at openjdk.org  Mon Dec 19 15:44:39 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:44:39 GMT
Subject: RFR: 8184444: The compiler error
 "variable not initialized in the default constructor" is not apt in case of
 static final variables [v3]
In-Reply-To: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
References: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
Message-ID: <v2JGDuFtVhFqCbsczLLl6qFQiOrGw2n--rGF4HbPqQo=.8c3e5415-61e9-40c0-b437-c3fcfa7f2cdf@github.com>

> This bug causes this class:
> 
> class StaticFinalInit {
>     static final int foo;
> }
> 
> to fail to compile as it should but with a confusing error message:
> 
> StaticFinalInit.java:2: error: variable foo not initialized in the default constructor
>     static final int foo;
>                      ^
> 
> In another variant, if there is a non-default constructor:
> 
> class StaticFinalInit {
>     static final int foo;
>     StaticFinalInit() { }
> }
> 
> the compiler gives the right error message but shows the wrong source code location:
> 
> StaticFinalInit.java:3: error: variable foo might not have been initialized
>     StaticFinalInit() { }
>                         ^
> 
> This behavior is a side-effect of the roundabout way we currently check for definite assignment of static final fields.
> 
> When recursing into a class definition in `Flow.AssignAnalyzer`, we first initialize DA/DU analysis for static fields, and then recurse on the static initializers to pick up static field assignments. However, we don't then check for definite assignment of static final fields. Instead, we proceed with the analysis, and then later, whenever we visit an initial constructor (i.e., one that invokes `super()` instead of `this()`), we check for definite assignment of both static final and instance final fields.
> 
> This works because every class has at least one initial constructor, so static fields will always get checked at least once. Of course, it also results in doing some redundant work (if there are multiple initial constructors) and it generates the wrong error message and/or source code position.
> 
> This patch adds a check for definite assignment of static final fields (with the appropriate error message) after we recurse on the static initializers, and it filters out static fields from the checks being done in initial constructors. It also updates a couple of existing unit tests that were expecting the wrong source code position.
> 
> The two examples above now both generate this error message:
> 
> StaticFinalInit.java:2: error: variable foo might not have been initialized
>     static final int foo;
>                      ^

Archie L. Cobbs 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-8184444
 - Merge branch 'master' into JDK-8184444
 - Fix confusing error message for uninitialized static final fields.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10896/files
  - new: https://git.openjdk.org/jdk/pull/10896/files/1e6594d2..d9ef373f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10896&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10896&range=01-02

  Stats: 136482 lines in 2312 files changed: 69468 ins; 45399 del; 21615 mod
  Patch: https://git.openjdk.org/jdk/pull/10896.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10896/head:pull/10896

PR: https://git.openjdk.org/jdk/pull/10896

From duke at openjdk.org  Mon Dec 19 15:44:43 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:44:43 GMT
Subject: RFR: 8064931: tools/javac/scope/DupUnsharedTest.java needs to be
 updated to add the bug id [v3]
In-Reply-To: <ZsHhpuB7WpP8v5heIy3W4y-s3ixm7dLP6Ums5U2zGb4=.b35f60e9-a2f9-49e4-bd0a-7c7a350a0f83@github.com>
References: <ZsHhpuB7WpP8v5heIy3W4y-s3ixm7dLP6Ums5U2zGb4=.b35f60e9-a2f9-49e4-bd0a-7c7a350a0f83@github.com>
Message-ID: <tEPG34KnFmDRhmJwV8oDcUSPpONxZtvvcV2iJ50cuCM=.c983bec2-3fea-4139-9843-efd3ac38648e@github.com>

> 8064931: tools/javac/scope/DupUnsharedTest.java needs to be updated to add the bug id

Archie L. Cobbs 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-8064931
 - Merge branch 'master' into JDK-8064931
 - Add missing @bug tag to unit test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10777/files
  - new: https://git.openjdk.org/jdk/pull/10777/files/46d87b73..63acabfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10777&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10777&range=01-02

  Stats: 136482 lines in 2312 files changed: 69468 ins; 45399 del; 21615 mod
  Patch: https://git.openjdk.org/jdk/pull/10777.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10777/head:pull/10777

PR: https://git.openjdk.org/jdk/pull/10777

From duke at openjdk.org  Mon Dec 19 15:44:49 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:44:49 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v12]
In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
Message-ID: <uww6VaA-X-zCasHAiyVrY2fyrYkma0u33MLdZd7c9xM=.795bd5c7-b917-4f0a-afcd-734351279527@github.com>

> (Description revised)
> 
> JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime:
> 
>>  _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._
> 
> This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body.

Archie L. Cobbs 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 10 additional commits since the last revision:

 - Merge branch 'master' into JDK-8043179
 - Merge branch 'master' into JDK-8043179
 - Update failed test output line numbers after removing @author tags.
 - Remove @author tags from tests.
 - Add a unit test verifying a change in reported error for final variables.
   
   Before this change, compiling this class:
   
       class LambdaMutateFinalVar {
           LambdaMutateFinalVar() {
               final String x;
               Runnable r1 = () -> x = "not ok";
               x = "ok";
           }
       }
   
   would report this error:
   
     local variables referenced from a lambda expression must be final or effectively final
   
   That error is not really appropriate; after all, the variable IS final. The
   real problem is that it can't be assigned from within the lambda because it
   can't be assumed to be DU.
   
   After this change, this error is reported instead:
   
     variable x might already have been assigned
 - Fix previously incorrect logic and update unit tests.
 - Fix @author in test to match github username per instructions.
 - Move unit test into a more appropriate subdirectory.
 - Use /nodynamiccopyright/ for "golden file" test per instructions.
 - 8043179: Lambda expression can mutate final field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10381/files
  - new: https://git.openjdk.org/jdk/pull/10381/files/1e38c30f..86808b2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=10-11

  Stats: 136482 lines in 2312 files changed: 69468 ins; 45399 del; 21615 mod
  Patch: https://git.openjdk.org/jdk/pull/10381.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381

PR: https://git.openjdk.org/jdk/pull/10381

From duke at openjdk.org  Mon Dec 19 15:44:53 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:44:53 GMT
Subject: RFR: 8155259: Suspicious buffer allocation in
 com.sun.tools.javac.file.BaseFileManager [v3]
In-Reply-To: <a0jq1KJR3VGCmm-vEnlUcHw_CYNlHmJNJd6tlgceEUs=.07787b9f-b04f-4d33-9b46-f0c0420b8398@github.com>
References: <a0jq1KJR3VGCmm-vEnlUcHw_CYNlHmJNJd6tlgceEUs=.07787b9f-b04f-4d33-9b46-f0c0420b8398@github.com>
Message-ID: <4ACny_Pa1V2gwf0xo1lXQTpgYDD_A9JtVHkH16NMuzA=.aa79f43a-46fb-4ab4-b14a-020340684282@github.com>

> JDK-8155259 notes that in `BaseFileManager` this code:
> 
> ByteBuffer.allocate(capacity + capacity>>1)
> 
> is actually equivalent (assuming no overflow) to:
> 
> ByteBuffer.allocate(capacity)
> 
> because in Java the `+` operator has higher precedence than the `>>` operator.
> 
> In the bug it is suggested that this be changed to reflect the presumed original intent to over-allocate by 50%, i.e.:
> 
> ByteBuffer.allocate(capacity + (capacity>>1))
> 
> however, this patch is more conservative in that it leaves the existing behavior alone and instead just simplifies it to:
> 
> ByteBuffer.allocate(capacity)
> 
> allowing us to at least resolve JDK-8155259.

Archie L. Cobbs 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-8155259
 - Merge branch 'master' into JDK-8155259
 - 8155259: Suspicious buffer allocation in com.sun.tools.javac.file.BaseFileManager

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10803/files
  - new: https://git.openjdk.org/jdk/pull/10803/files/4dfeba3b..f79f51fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10803&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10803&range=01-02

  Stats: 136482 lines in 2312 files changed: 69468 ins; 45399 del; 21615 mod
  Patch: https://git.openjdk.org/jdk/pull/10803.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10803/head:pull/10803

PR: https://git.openjdk.org/jdk/pull/10803

From duke at openjdk.org  Mon Dec 19 15:44:57 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:44:57 GMT
Subject: RFR: 8219810: javac throws NullPointerException [v3]
In-Reply-To: <PNAXdaGgA5nNPEm4fb-jWSoTuZHtAqfSvtaiCyZ5vzM=.cfb759ae-f8d9-4fe8-8c19-35251b3a586e@github.com>
References: <PNAXdaGgA5nNPEm4fb-jWSoTuZHtAqfSvtaiCyZ5vzM=.cfb759ae-f8d9-4fe8-8c19-35251b3a586e@github.com>
Message-ID: <Ra0BnQY6xyfa6SenDcWQBg_GprXrricfPcGWRCVKK2c=.97b0305f-82ce-4245-8314-4c1c81ba6b0a@github.com>

> JVMS 4.5 states:
> 
>> Each field of a class may have at most one of its ACC_PUBLIC, ACC_PRIVATE, and ACC_PROTECTED flags set (JLS ?8.3.1), and must not have both its ACC_FINAL and ACC_VOLATILE flags set (JLS ?8.3.1.4).
> 
> and JVMS 4.6 states:
> 
>> Each method of a class may have at most one of its ACC_PUBLIC, ACC_PRIVATE, and ACC_PROTECTED flags set (JLS ?8.4.3). 
> 
> However, when reading class files these illegal combinations are not actually checked, and this can lead to compiler crashes as in the bug example.
> 
> This patch adds checks for these illegal combinations.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8219810
 - Merge branch 'master' into JDK-8219810
 - Also disallow field access flags from having both FINAL and VOLATILE.
 - Detect invalid access flag combinations for fields and methods in classfiles.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10826/files
  - new: https://git.openjdk.org/jdk/pull/10826/files/b2667d90..94cb9924

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10826&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10826&range=01-02

  Stats: 136482 lines in 2312 files changed: 69468 ins; 45399 del; 21615 mod
  Patch: https://git.openjdk.org/jdk/pull/10826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10826/head:pull/10826

PR: https://git.openjdk.org/jdk/pull/10826

From duke at openjdk.org  Mon Dec 19 15:48:34 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 15:48:34 GMT
Subject: RFR: 8200610: Compiling fails with
 java.nio.file.ReadOnlyFileSystemException [v4]
In-Reply-To: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
References: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
Message-ID: <tf9vjvsLFxJBqqmnX-cYjrhxd5EMHucWavAZYEh3VJI=.07509677-5351-4b30-94a0-30a9b5913d79@github.com>

> In `JavaCompiler`, when trying to write a class file, if an `IOException`s is thrown, instead of crashing, we report a normal error" `error while writing [file]: ...`.
> 
> However there are some I/O errors that can generate `RuntimeException`s not caught by this logic. So instead these errors cause a compiler crash.
> 
> An example is given in JDK-8200610, where the compiler tries to write into a ZIP file system and a `java.nio.file.ReadOnlyFileSystemException` is thrown.
> 
> This patch adds that exception and a couple of others which (in my estimation) could reasonably be expected to be thrown in various obscure cases involving alternative file systems: `FileSystemNotFoundException` and `InvalidPathException`.
> 
> Any suggestions on what the most appropriate list of exception types to include here are appreciated.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into JDK-8200610
 - Merge branch 'master' into JDK-8200610
 - Address review items (add UncheckedIOException and reformat).
 - Merge branch 'master' into JDK-8200610
 - Catch and report some java.nio.file.* exceptions along with IOException.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10818/files
  - new: https://git.openjdk.org/jdk/pull/10818/files/1bcf9501..913695c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10818&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10818&range=02-03

  Stats: 16087 lines in 541 files changed: 10112 ins; 3440 del; 2535 mod
  Patch: https://git.openjdk.org/jdk/pull/10818.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10818/head:pull/10818

PR: https://git.openjdk.org/jdk/pull/10818

From jjg at openjdk.org  Mon Dec 19 18:09:53 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 19 Dec 2022 18:09:53 GMT
Subject: RFR: 8298943: Missing escapes for single quote marks in
 compiler.properties [v4]
In-Reply-To: <hA8n2Utrg6D9RQ7A-cslfrHzK6Ekp3iSwsHGyHwwH8I=.a6991938-0223-4916-adb6-4497cdfefeda@github.com>
References: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
 <hA8n2Utrg6D9RQ7A-cslfrHzK6Ekp3iSwsHGyHwwH8I=.a6991938-0223-4916-adb6-4497cdfefeda@github.com>
Message-ID: <tiwEfvC1D-SyUvFWt-pJ1Xg50O9huUifaqoHuyE_Uw0=.e5155103-fd9f-44e9-a209-e007b13bc119@github.com>

On Mon, 19 Dec 2022 15:44:25 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The source file `compiler.properties` contains the English message bundle for compiler warnings, errors, etc.
>> 
>> Since the strings in this file are format strings, any single quotes must be escaped by doubling them.
>> 
>> An example of a properly encoded entry is:
>> 
>> 
>> compiler.err.cant.assign.val.to.this=\
>> ????cannot assign to ''this''
>> 
>> 
>> There are three entries that appear to be not escaped when they should be.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8298943
>  - Allow quoting of ',' characters.
>  - Add syntax checking of MessageFormat patterns in resouce bundles.
>  - Add missing escapes for single quotes.

Thanks for adding in the check.

At some point (not here and now in this review) we should maybe try and merge this with the copy-pasted version for javadoc, also called CheckResourceKeys.

test/langtools/tools/javac/diags/CheckResourceKeys.java line 345:

> 343:      * <p>
> 344:      * This checks for balanced braces and unnecessary quoting.
> 345:      * Code cut, pasted, &amp; simplified from {@link java.text.MessageFormat#applyPattern}.

I'm guessing you copied it, not cut it .... :-)

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11712

From duke at openjdk.org  Mon Dec 19 19:25:50 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 19:25:50 GMT
Subject: RFR: 8298943: Missing escapes for single quote marks in
 compiler.properties [v4]
In-Reply-To: <tiwEfvC1D-SyUvFWt-pJ1Xg50O9huUifaqoHuyE_Uw0=.e5155103-fd9f-44e9-a209-e007b13bc119@github.com>
References: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
 <hA8n2Utrg6D9RQ7A-cslfrHzK6Ekp3iSwsHGyHwwH8I=.a6991938-0223-4916-adb6-4497cdfefeda@github.com>
 <tiwEfvC1D-SyUvFWt-pJ1Xg50O9huUifaqoHuyE_Uw0=.e5155103-fd9f-44e9-a209-e007b13bc119@github.com>
Message-ID: <IVi3oXT3N7l6VrY9qTVkmfgIeIynMCmZtvr0OZhclvQ=.78f6f3ee-b828-48e3-a4fb-fd9e5cc5878e@github.com>

On Mon, 19 Dec 2022 18:07:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> At some point (not here and now in this review) we should maybe try and merge this with the copy-pasted version for javadoc, also called CheckResourceKeys.

Agreed... and to expand/digress even further, what would really be nice is for `MessageFormat` to make its double secret parsing algorithm (which supports arbitrarily many levels of nesting) available to the general public somehow. This would make it easier to develop tools related to format strings (see also [this class](https://github.com/archiecobbs/dellroad-stuff/blob/master/dellroad-stuff-main/src/main/java/org/dellroad/stuff/text/MessageFmt.java) which relies on introspection hacks).

Thanks for the review.

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

PR: https://git.openjdk.org/jdk/pull/11712

From jjg at openjdk.org  Mon Dec 19 19:51:53 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 19 Dec 2022 19:51:53 GMT
Subject: RFR: 8298943: Missing escapes for single quote marks in
 compiler.properties [v4]
In-Reply-To: <IVi3oXT3N7l6VrY9qTVkmfgIeIynMCmZtvr0OZhclvQ=.78f6f3ee-b828-48e3-a4fb-fd9e5cc5878e@github.com>
References: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
 <hA8n2Utrg6D9RQ7A-cslfrHzK6Ekp3iSwsHGyHwwH8I=.a6991938-0223-4916-adb6-4497cdfefeda@github.com>
 <tiwEfvC1D-SyUvFWt-pJ1Xg50O9huUifaqoHuyE_Uw0=.e5155103-fd9f-44e9-a209-e007b13bc119@github.com>
 <IVi3oXT3N7l6VrY9qTVkmfgIeIynMCmZtvr0OZhclvQ=.78f6f3ee-b828-48e3-a4fb-fd9e5cc5878e@github.com>
Message-ID: <5s63IDQr97bEzUsDPbnNZW8t2eJlNJczYnncpdI_5ls=.3aca7fdc-c80b-4545-9b59-2a3e9f7e91da@github.com>

On Mon, 19 Dec 2022 19:22:38 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> > At some point (not here and now in this review) we should maybe try and merge this with the copy-pasted version for javadoc, also called CheckResourceKeys.
> 

A different JDK-specific place to put the format checks might be the properties compiler used in the JDK build to convert resource files from .properties format to compiled Java classes.

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

PR: https://git.openjdk.org/jdk/pull/11712

From duke at openjdk.org  Mon Dec 19 19:51:55 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 19:51:55 GMT
Subject: Integrated: 8298943: Missing escapes for single quote marks in
 compiler.properties
In-Reply-To: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
References: <ilCaRtFIL6YjR82x06tsLzLgwhvfF6nDEgSeVc69Sws=.03f4f6c2-7fe8-416a-b009-32d71b48e1de@github.com>
Message-ID: <FJY2bFuOhQrbnmqmC_rdOD5zta3J-3nywwyX_j3X7NQ=.b1b4aa04-26f2-478d-b182-fd81179d310b@github.com>

On Fri, 16 Dec 2022 15:11:18 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The source file `compiler.properties` contains the English message bundle for compiler warnings, errors, etc.
> 
> Since the strings in this file are format strings, any single quotes must be escaped by doubling them.
> 
> An example of a properly encoded entry is:
> 
> 
> compiler.err.cant.assign.val.to.this=\
> ????cannot assign to ''this''
> 
> 
> There are three entries that appear to be not escaped when they should be.

This pull request has now been integrated.

Changeset: 40cb431f
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/40cb431fee7c1f193b2f445c397c1444ed2e0015
Stats:     131 lines in 2 files changed: 128 ins; 0 del; 3 mod

8298943: Missing escapes for single quote marks in compiler.properties

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jdk/pull/11712

From jjg at openjdk.org  Mon Dec 19 21:03:47 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 19 Dec 2022 21:03:47 GMT
Subject: RFR: JDK-8299045: tools/doclint/BadPackageCommentTest.java fails after
 JDK-8298943
Message-ID: <P78DwkdQ8x8xkHLsiGrSlpr56XIBMuPDDEgls5eqUrs=.26f79718-7c05-48df-8567-3ee693939466@github.com>

Please review a fix for the golden-file for a test, required after quotes in resources were fixed in JDK-8298943.

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

Commit messages:
 - JDK-8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943

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

PR: https://git.openjdk.org/jdk/pull/11732

From vromero at openjdk.org  Mon Dec 19 21:08:50 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 Dec 2022 21:08:50 GMT
Subject: RFR: JDK-8299045: tools/doclint/BadPackageCommentTest.java fails
 after JDK-8298943
In-Reply-To: <P78DwkdQ8x8xkHLsiGrSlpr56XIBMuPDDEgls5eqUrs=.26f79718-7c05-48df-8567-3ee693939466@github.com>
References: <P78DwkdQ8x8xkHLsiGrSlpr56XIBMuPDDEgls5eqUrs=.26f79718-7c05-48df-8567-3ee693939466@github.com>
Message-ID: <F4nYcIyVA-CGMih8F3ENlpgJc284RC_XpVettBha5uA=.d8cb497c-da69-4edc-8ae5-8b00bc3e500b@github.com>

On Mon, 19 Dec 2022 20:56:14 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix for the golden-file for a test, required after quotes in resources were fixed in JDK-8298943.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11732

From jjg at openjdk.org  Mon Dec 19 21:11:54 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 19 Dec 2022 21:11:54 GMT
Subject: Integrated: JDK-8299045: tools/doclint/BadPackageCommentTest.java
 fails after JDK-8298943
In-Reply-To: <P78DwkdQ8x8xkHLsiGrSlpr56XIBMuPDDEgls5eqUrs=.26f79718-7c05-48df-8567-3ee693939466@github.com>
References: <P78DwkdQ8x8xkHLsiGrSlpr56XIBMuPDDEgls5eqUrs=.26f79718-7c05-48df-8567-3ee693939466@github.com>
Message-ID: <hXaP1BmRRIKu-ULHWarFYv03y4WRVhZAgAz742PgkaQ=.60d708f9-e162-40d6-86e8-304224b2a241@github.com>

On Mon, 19 Dec 2022 20:56:14 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix for the golden-file for a test, required after quotes in resources were fixed in JDK-8298943.

This pull request has now been integrated.

Changeset: 5d330f52
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d330f5285b535b37dde5cd4e42374d92fafb550
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/11732

From duke at openjdk.org  Mon Dec 19 21:14:54 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 19 Dec 2022 21:14:54 GMT
Subject: RFR: JDK-8299045: tools/doclint/BadPackageCommentTest.java fails
 after JDK-8298943
In-Reply-To: <P78DwkdQ8x8xkHLsiGrSlpr56XIBMuPDDEgls5eqUrs=.26f79718-7c05-48df-8567-3ee693939466@github.com>
References: <P78DwkdQ8x8xkHLsiGrSlpr56XIBMuPDDEgls5eqUrs=.26f79718-7c05-48df-8567-3ee693939466@github.com>
Message-ID: <6m0JtLRxs79NtQPKhWQiO3hCFnTLI5T6luFEtkINi4w=.c3075cda-6256-410c-ae68-0c085a809c8a@github.com>

On Mon, 19 Dec 2022 20:56:14 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix for the golden-file for a test, required after quotes in resources were fixed in JDK-8298943.

Oops - my fault. Thanks for fixing.

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

PR: https://git.openjdk.org/jdk/pull/11732

From jwilhelm at openjdk.org  Tue Dec 20 11:13:46 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:13:46 GMT
Subject: RFR: Merge jdk20
Message-ID: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298784: JFR: Test chunk integrity
 - 8298215: gc/g1/TestVerifyGCType.java failed with "Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false"
 - 4958969: ObjectOutputStream example leads to non-working code
 - 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits
 - 4512626: Non-editable JTextArea provides no visual indication of keyboard focus
 - 8277074: Qualified exported types show up in JavaDoc
 - 8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError
 - 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
 - 8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display
 - ... and 6 more: https://git.openjdk.org/jdk/compare/36de61c4...d70f5831

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11739/files
  Stats: 2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

PR: https://git.openjdk.org/jdk/pull/11739

From jwilhelm at openjdk.org  Tue Dec 20 11:47:31 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:31 GMT
Subject: RFR: Merge jdk20 [v2]
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <FnOGkSoOkKJfJ5JjgZo7uwEF2JILRWkjhHgWx1sprIc=.38ff283a-01ab-401c-9411-f0d8c86702b6@github.com>

> Forwardport JDK 20 -> JDK 21

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits:

 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298865: Excessive memory allocation in CipherOutputStream AEAD decryption
   
   Reviewed-by: valeriep, ascarpino
 - 8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException
   
   Reviewed-by: serb
 - 8298974: Add ftcolor.c to imported freetype sources
   
   Reviewed-by: serb
 - 8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
   
   Reviewed-by: serb, honkar
 - 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943
   
   Reviewed-by: vromero
 - 8298943: Missing escapes for single quote marks in compiler.properties
   
   Reviewed-by: jjg
 - 8298701: Cleanup SA entries in ProblemList-zgc.txt.
   
   Reviewed-by: sspitsyn, amenkov
 - 8298470: Short cut java.lang.Object super class loading
   
   Reviewed-by: dholmes, iklam
 - 8299022: Linux ppc64le and s390x build issues after JDK-8160404
   
   Reviewed-by: mdoerr, lucy
 - ... and 97 more: https://git.openjdk.org/jdk/compare/3dd2cfab...d70f5831

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

Changes: https://git.openjdk.org/jdk/pull/11739/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=01
  Stats: 13539 lines in 425 files changed: 8409 ins; 3097 del; 2033 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

PR: https://git.openjdk.org/jdk/pull/11739

From jwilhelm at openjdk.org  Tue Dec 20 11:47:33 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:33 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <pk7xFH2bCEPTLw_KlI3RkDUTMMlze8j0j2fNKoqnm5Q=.49972633-6c2a-41af-be30-114c9f119772@github.com>

On Tue, 20 Dec 2022 10:57:44 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: c5a4a7a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5a4a7a679ec76cb08a999a198e5c73e9cd9d2f0
Stats:     2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11739

From jjg at openjdk.org  Tue Dec 20 21:38:22 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 20 Dec 2022 21:38:22 GMT
Subject: [jdk20] RFR: JDK-8299156: Broken link in jdk.compiler/module-info.java
Message-ID: <iUp-BGSPaUT6vcNLEn9oLBgkzKWABhGbbOPzJAexnUM=.b41eae7e-77a2-461c-b7ab-15047e29260e@github.com>

Please review a trivial documentation fix to fix a broken link.

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

Commit messages:
 - JDK-8299156: Broken link in jdk.compiler/module-info.java

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

PR: https://git.openjdk.org/jdk20/pull/67

From iris at openjdk.org  Tue Dec 20 22:40:58 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 20 Dec 2022 22:40:58 GMT
Subject: [jdk20] RFR: JDK-8299156: Broken link in
 jdk.compiler/module-info.java
In-Reply-To: <iUp-BGSPaUT6vcNLEn9oLBgkzKWABhGbbOPzJAexnUM=.b41eae7e-77a2-461c-b7ab-15047e29260e@github.com>
References: <iUp-BGSPaUT6vcNLEn9oLBgkzKWABhGbbOPzJAexnUM=.b41eae7e-77a2-461c-b7ab-15047e29260e@github.com>
Message-ID: <SPHPzFn-piZ3zInV0a4K13W4GmN0VHqPOKlSn6naaUc=.5bdcdf11-27a4-41e5-adc2-c991a33ad57e@github.com>

On Tue, 20 Dec 2022 21:31:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial documentation fix to fix a broken link.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/67

From jjg at openjdk.org  Tue Dec 20 22:56:57 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 20 Dec 2022 22:56:57 GMT
Subject: [jdk20] Integrated: JDK-8299156: Broken link in
 jdk.compiler/module-info.java
In-Reply-To: <iUp-BGSPaUT6vcNLEn9oLBgkzKWABhGbbOPzJAexnUM=.b41eae7e-77a2-461c-b7ab-15047e29260e@github.com>
References: <iUp-BGSPaUT6vcNLEn9oLBgkzKWABhGbbOPzJAexnUM=.b41eae7e-77a2-461c-b7ab-15047e29260e@github.com>
Message-ID: <tjI8zg9nveVAqlSspvDMY_eyG4KNJg5WQN2V4HAG6Cg=.aaf45f6d-6e6a-44fc-922d-4891c88a6fbc@github.com>

On Tue, 20 Dec 2022 21:31:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial documentation fix to fix a broken link.

This pull request has now been integrated.

Changeset: f7be5b53
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/f7be5b530d10005ba928309870c9adc42afdf66a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8299156: Broken link in jdk.compiler/module-info.java

Reviewed-by: iris

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

PR: https://git.openjdk.org/jdk20/pull/67

From aturbanov at openjdk.org  Wed Dec 21 08:18:55 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Dec 2022 08:18:55 GMT
Subject: Integrated: 8297682: Use Collections.emptyIterator where applicable
In-Reply-To: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
References: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
Message-ID: <YLH7S8y_sfUynnYyvRETgG33x8GY36UsdfHraOuT9Ew=.a62360fe-b327-490c-b2a3-3488f3b59915@github.com>

On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
> Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

This pull request has now been integrated.

Changeset: 85f9b37d
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85f9b37d71852d35a75d404e1657db0562dacac5
Stats:     4 lines in 2 files changed: 0 ins; 2 del; 2 mod

8297682: Use Collections.emptyIterator where applicable

Reviewed-by: stsypanov, alanb, jpai

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

PR: https://git.openjdk.org/jdk/pull/11025

From jwilhelm at openjdk.org  Wed Dec 21 23:25:52 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 21 Dec 2022 23:25:52 GMT
Subject: RFR: Merge jdk20
Message-ID: <0xaeZuF6GgxwolCQSpQDkMLgWEclWAxo-1ap7iRED9A=.bc32b592-312b-4593-8307-19436a758d77@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298893: Rename option UsePolyIntrinsics to UsePoly1305Intrinsics
 - 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds
 - 8298642: ParallelGC -XX:+UseNUMA eden spaces allocated on wrong node
 - 8298588: WebSockets: HandshakeUrlEncodingTest unnecessarily depends on a response body
 - 8299156: Broken link in jdk.compiler/module-info.java
 - 8298947: compiler/codecache/MHIntrinsicAllocFailureTest.java fails intermittently
 - 8299147: Minor accessibility errors in the specs and man index pages

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/11759/files
  Stats: 16 lines in 9 files changed: 4 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11759.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11759/head:pull/11759

PR: https://git.openjdk.org/jdk/pull/11759

From jwilhelm at openjdk.org  Wed Dec 21 23:53:56 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 21 Dec 2022 23:53:56 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <0xaeZuF6GgxwolCQSpQDkMLgWEclWAxo-1ap7iRED9A=.bc32b592-312b-4593-8307-19436a758d77@github.com>
References: <0xaeZuF6GgxwolCQSpQDkMLgWEclWAxo-1ap7iRED9A=.bc32b592-312b-4593-8307-19436a758d77@github.com>
Message-ID: <fk09a_rJzzd5ENJyEkwmohXv1-vcdSSjCbh_EqtL3yo=.27c8aaf5-693f-4c33-88ff-f04c6bee857f@github.com>

On Wed, 21 Dec 2022 23:18:08 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 34cdda5b
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34cdda5b8359cce33c2d4f92a41a620aea4f96e7
Stats:     16 lines in 9 files changed: 4 ins; 0 del; 12 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11759

From mernst at openjdk.org  Tue Dec 27 14:26:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Michael Ernst 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 ../jdk-openjdk into typos-typos
 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

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

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=02
  Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Tue Dec 27 14:26:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
 <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
Message-ID: <KQM3bb5WQ1wCnIsc8lnqTrD54nkWyrhnHyk7hkSfp70=.5924492b-d7e8-4a26-bbe7-f78f0c9f9959@github.com>

On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.
>
>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.
> 
> I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes.
I have pulled master and resolved merge conflicts.  Only 11 typo fixes remain.
Could someone shepherd those into the codebase?  Thanks!

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

PR: https://git.openjdk.org/jdk/pull/10029