From abimpoudis at openjdk.org  Fri Dec  1 07:16:18 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Dec 2023 07:16:18 GMT
Subject: Integrated: 8320145: Compiler should accept final variable in Record
 Pattern
In-Reply-To: <iSGtUvRACyNXm1CZwwBVQhd-u5B4-sqH2Z1kTC7IErw=.901d5bea-eaca-4e39-b231-86a0f4e4be83@github.com>
References: <iSGtUvRACyNXm1CZwwBVQhd-u5B4-sqH2Z1kTC7IErw=.901d5bea-eaca-4e39-b231-86a0f4e4be83@github.com>
Message-ID: <sPIy9pGlLThgGTWmnMZ5_w3TumbNC2GB0fPu9up5mJ4=.4930b4d0-9124-4d90-b819-8dc35ddc2933@github.com>

On Thu, 30 Nov 2023 11:03:09 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> With this PR, if the `final` keyword is detected, `analyzePattern` returns `PatternResult.PATTERN` and `parseCaseLabel` goes through the correct if-branch in line 3268.
> 
> This improves the error message in the case of record patterns for https://github.com/openjdk/jdk/pull/15997 as well.

This pull request has now been integrated.

Changeset: 4ba94ef6
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ba94ef69ef2ee576c50bb6003a795746dcdf30d
Stats:     48 lines in 3 files changed: 44 ins; 2 del; 2 mod

8320145: Compiler should accept final variable in Record Pattern

Reviewed-by: jlahoda

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

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

From alanb at openjdk.org  Fri Dec  1 08:57:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Dec 2023 08:57:05 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
Message-ID: <Lx5ZzbGIV584QK73SK4GaA8OF-41M-BECYxzWGmh8Fk=.37a42cf6-50e9-48f4-9d76-b071c2ead567@github.com>

On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol files to JDK 22 b26.

Good good. I assume you'll bump the copyright header on the files that need it before integration, e.g. JavacTestingAbstractProcessor.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1759306298

From cstein at openjdk.org  Fri Dec  1 10:15:28 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 1 Dec 2023 10:15:28 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v6]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <1MbgHCU0hYZ4kbLQzcbE5_6kXrKTrgR2CkZZ4_Xpu4U=.b2a2db93-a1fc-44e9-8707-838767b14a8c@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
> 
> ### Open Ends
> 
> - [ ] Tests with [JEP 463: Implicitly Declared Classes and Instance Main Methods (Second Preview))](https://bugs.openjdk.org/browse/JDK-8315398)
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`

Christian Stein 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 one additional commit since the last revision:

  8306914: Launch Multi-File Source-Code Programs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/a988ba0c..26329c25

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

  Stats: 764750 lines in 4746 files changed: 169722 ins; 507892 del; 87136 mod
  Patch: https://git.openjdk.org/jdk/pull/13712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13712/head:pull/13712

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

From prappo at openjdk.org  Fri Dec  1 11:22:33 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Dec 2023 11:22:33 GMT
Subject: RFR: 8321114: Rename "Unnamed Classes" to
 "Implicitly Declared Classes" better [v2]
In-Reply-To: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
References: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
Message-ID: <NwoT4GfVEnRAJkwM9fl2TZ1DBj2l5uVGV6RRGqkZgrc=.cf5565ae-6c40-46eb-8031-b2774ca5183c@github.com>

> Please review this PR to correctly rename "Unnamed Class" to "Implicitly Declared Class", not "Implicit Class".
> 
> Renaming is fixed where it affects documentation or the end-user. Renaming is not fixed where it only affects code: it's perfectly okay to derive an internal element name from "Implicit Class" rather than "Implicitly Declared Class", for brevity.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Remove a comment typo introduced in JEP 445

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16904/files
  - new: https://git.openjdk.org/jdk/pull/16904/files/089aeee2..3676b500

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

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

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

From prappo at openjdk.org  Fri Dec  1 11:22:35 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Dec 2023 11:22:35 GMT
Subject: RFR: 8321114: Rename "Unnamed Classes" to
 "Implicitly Declared Classes" better [v2]
In-Reply-To: <GG8vHiLmpF27IH7i1FsCeVMGVSApXD1Ie3gkc2w3zLM=.b4baf3d5-652a-4fdb-92f6-974e53bd3d4b@github.com>
References: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
 <GG8vHiLmpF27IH7i1FsCeVMGVSApXD1Ie3gkc2w3zLM=.b4baf3d5-652a-4fdb-92f6-974e53bd3d4b@github.com>
Message-ID: <YfzcP47LOx0aMNoi1xqxmVKpHjrYy5Mm206sxj2dDXg=.cf749939-2c0f-4bae-9e59-25437fa59786@github.com>

On Thu, 30 Nov 2023 16:11:01 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove a comment typo introduced in JEP 445
>
> LGTM

@JimLaskey please re-review this PR due to a newly pushed [3676b50](https://github.com/openjdk/jdk/pull/16904/commits/3676b500834cd5e91b5829545e3fed71e43312a7). Also, please double-check if the comment is still valid factually.

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

PR Comment: https://git.openjdk.org/jdk/pull/16904#issuecomment-1835914750

From jlaskey at openjdk.org  Fri Dec  1 11:49:05 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 1 Dec 2023 11:49:05 GMT
Subject: RFR: 8321114: Rename "Unnamed Classes" to
 "Implicitly Declared Classes" better [v2]
In-Reply-To: <NwoT4GfVEnRAJkwM9fl2TZ1DBj2l5uVGV6RRGqkZgrc=.cf5565ae-6c40-46eb-8031-b2774ca5183c@github.com>
References: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
 <NwoT4GfVEnRAJkwM9fl2TZ1DBj2l5uVGV6RRGqkZgrc=.cf5565ae-6c40-46eb-8031-b2774ca5183c@github.com>
Message-ID: <6IOB2NP-9rEDhWnsUHQGMYZbC9-hSJ4z8_dp-5cI9fg=.cd69a6ed-4e4c-4cea-8023-af78ffc8a503@github.com>

On Fri, 1 Dec 2023 11:22:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to correctly rename "Unnamed Class" to "Implicitly Declared Class", not "Implicit Class".
>> 
>> Renaming is fixed where it affects documentation or the end-user. Renaming is not fixed where it only affects code: it's perfectly okay to derive an internal element name from "Implicit Class" rather than "Implicitly Declared Class", for brevity.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove a comment typo introduced in JEP 445

Marked as reviewed by jlaskey (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16904#pullrequestreview-1759655045

From prappo at openjdk.org  Fri Dec  1 11:54:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Dec 2023 11:54:13 GMT
Subject: Integrated: 8321114: Rename "Unnamed Classes" to
 "Implicitly Declared Classes" better
In-Reply-To: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
References: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
Message-ID: <VGKZuEfvKuoe7A811l21TjPoaj_SpPcR4D8TrSeuaTo=.175e8fcd-e5e0-4600-9ed4-a8cd70a41eec@github.com>

On Thu, 30 Nov 2023 15:00:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to correctly rename "Unnamed Class" to "Implicitly Declared Class", not "Implicit Class".
> 
> Renaming is fixed where it affects documentation or the end-user. Renaming is not fixed where it only affects code: it's perfectly okay to derive an internal element name from "Implicit Class" rather than "Implicitly Declared Class", for brevity.

This pull request has now been integrated.

Changeset: 8f1d40b4
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f1d40b48bf145144ae90b1d147d418d3905661b
Stats:     19 lines in 8 files changed: 0 ins; 0 del; 19 mod

8321114: Rename "Unnamed Classes" to "Implicitly Declared Classes" better

Reviewed-by: jlaskey

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

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

From cstein at openjdk.org  Fri Dec  1 12:41:16 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 1 Dec 2023 12:41:16 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v7]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <QFupK20fU3AUEe37HO95ML-aaXVNOxpqWudiuPN38UI=.dd71299d-4c28-4c4a-a03f-4541f10e558d@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
> 
> ### Open Ends
> 
> - [ ] Tests with [JEP 463: Implicitly Declared Classes and Instance Main Methods (Second Preview))](https://bugs.openjdk.org/browse/JDK-8315398)
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update test for implicit classes
  
  Preview notes normally emitted by `javac` are
  suppressed now, as they contain hints that
  does not apply to the source launcher and will
  lead to errors. For example: `-Xlint:preview`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/26329c25..63551153

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=05-06

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

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

From jlaskey at openjdk.org  Fri Dec  1 13:02:38 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 1 Dec 2023 13:02:38 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v7]
In-Reply-To: <QFupK20fU3AUEe37HO95ML-aaXVNOxpqWudiuPN38UI=.dd71299d-4c28-4c4a-a03f-4541f10e558d@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <QFupK20fU3AUEe37HO95ML-aaXVNOxpqWudiuPN38UI=.dd71299d-4c28-4c4a-a03f-4541f10e558d@github.com>
Message-ID: <poFL-szCA-a4W-5ZoTfdUx8XikUAPnAkd4kFSCVTxwA=.e00e3b8a-b967-481d-9ae0-6849ca1e9342@github.com>

On Fri, 1 Dec 2023 12:41:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
>> 
>> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
>> 
>> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
>> 
>> ### Open Ends
>> 
>> - [ ] Tests with [JEP 463: Implicitly Declared Classes and Instance Main Methods (Second Preview))](https://bugs.openjdk.org/browse/JDK-8315398)
>> 
>> ### OpenJDK's Demo Programs
>> 
>> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
>> 
>> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
>> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
>> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
>> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
>> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
>> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
>> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
>> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
>> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
>> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
>> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
>> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test for implicit classes
>   
>   Preview notes normally emitted by `javac` are
>   suppressed now, as they contain hints that
>   does not apply to the source launcher and will
>   lead to errors. For example: `-Xlint:preview`

Just nits. Nice work.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 59:

> 57:  * as any like-named classes that might be found on the application class path.)
> 58:  *
> 59:  * <p><b>This is NOT part of any supported API.

< strong > instead of < b >

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 68:

> 66:  * If you write code that depends on this, you do so at your own
> 67:  * risk.  This code and its internal interfaces are subject to change
> 68:  * or deletion without notice.</b></p>

< strong > instead of < b >

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryFileManager.java line 50:

> 48:  * If you write code that depends on this, you do so at your own
> 49:  * risk.  This code and its internal interfaces are subject to change
> 50:  * or deletion without notice.</b></p>

< strong >

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryModuleFinder.java line 49:

> 47: 
> 48: import jdk.internal.module.Resources;
> 49: 

This is NOT part of any supported API. ...

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java line 48:

> 46:  * risk.  This code and its internal interfaces are subject to change
> 47:  * or deletion without notice.</b></p>
> 48:  */

< strong >

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Result.java line 36:

> 34:  * @param classNames the names of classes compiled into memory.
> 35:  */
> 36: public record Result(Class<?> programClass, Set<String> classNames) {}

This is NOT part of any supported API. ...

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 54:

> 52:  * risk.  This code and its internal interfaces are subject to change
> 53:  * or deletion without notice.</b></p>
> 54:  */

< strong >

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

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13712#pullrequestreview-1759748762
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1412065454
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1412066706
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1412067763
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1412069097
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1412070654
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1412072074
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1412072305

From asotona at openjdk.org  Fri Dec  1 13:18:30 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Dec 2023 13:18:30 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v32]
In-Reply-To: <e0eptru-lnzIXRfqrFBT1fy-oDsLORN-roOsdUzshUY=.68ff8e2b-68fb-4457-94fb-f0623eb3f96a@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com>
 <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com>
 <Fd3Aa-rvhh0iWNFsGnOMCAMPvI5JiesSWh0tvPhPg5M=.379e7492-46d4-41f2-94c6-393b6701cad2@github.com>
 <e0eptru-lnzIXRfqrFBT1fy-oDsLORN-roOsdUzshUY=.68ff8e2b-68fb-4457-94fb-f0623eb3f96a@github.com>
Message-ID: <JOJKj3mt-3DRIVKUTDXwMYvh_g-P9hVax9PZ0MiLcyU=.ab0b0bd2-6101-4f87-bac0-49cc401e8452@github.com>

On Wed, 29 Nov 2023 08:46:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This is explicit list of supported class file versions, so I don't see any other way.
>
> Would it not be possible to expose an immutable `Map<Integer, Integer>` that maps from Java version to major class version?

This is actually out of scope of this PR. Feel free to request a new ClassFile API feature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1412090733

From asotona at openjdk.org  Fri Dec  1 13:46:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Dec 2023 13:46:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v33]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <smvNLtt0YumYsmswb7vrmD5O9V2wVvfR7VCHgtrHg8k=.c6a7c0c7-2984-4041-8a3c-134c2180a318@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 371 commits:

 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - fixed SwitchBootstrapTest
 - fixed SwitchBootstrap and StackMapsTest
 - fixed SwtichBootstrapTest and ModuleVersionTest
 - Merge branch 'master' into JDK-8308753-preview
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java
 - added new package-info snippets and fixed ClassFile::parse throws javadoc description
 - fixed lambda tests
 - Merge branch 'master' into JDK-8308753-preview
 - ... and 361 more: https://git.openjdk.org/jdk/compare/3b30095a...b7b2e4e4

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=32
  Stats: 32362 lines in 787 files changed: 14660 ins; 14113 del; 3589 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

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

From jlahoda at openjdk.org  Fri Dec  1 14:03:06 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 1 Dec 2023 14:03:06 GMT
Subject: RFR: 8312560: Annotation on Decomposed Record Component in
 Enhanced For Loop Fails Compilation
In-Reply-To: <3-oKNoDlUTffP9LLnTo3cTTbH6FbTPACxkvYjP-YlX0=.3557c05f-6f8f-4f90-bc3c-56db8dffd171@github.com>
References: <3-oKNoDlUTffP9LLnTo3cTTbH6FbTPACxkvYjP-YlX0=.3557c05f-6f8f-4f90-bc3c-56db8dffd171@github.com>
Message-ID: <Fl9x8-Dixq8hgpG4mGToqeapMpuQsQtRkXKeeLZYqis=.132bcf2f-8729-4682-8e31-63137720d0fd@github.com>

On Mon, 20 Nov 2023 17:24:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR fixes the attribution of record patterns which have var and an annotation. The scheduling of the attribution was skipped for this occasion.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16745#pullrequestreview-1759866658

From abimpoudis at openjdk.org  Fri Dec  1 14:18:20 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Dec 2023 14:18:20 GMT
Subject: Integrated: 8312560: Annotation on Decomposed Record Component in
 Enhanced For Loop Fails Compilation
In-Reply-To: <3-oKNoDlUTffP9LLnTo3cTTbH6FbTPACxkvYjP-YlX0=.3557c05f-6f8f-4f90-bc3c-56db8dffd171@github.com>
References: <3-oKNoDlUTffP9LLnTo3cTTbH6FbTPACxkvYjP-YlX0=.3557c05f-6f8f-4f90-bc3c-56db8dffd171@github.com>
Message-ID: <29KoLuluP89qS15nx0VNHv_-fGTeMvk5Ww-9FLWMW_E=.a6163b9a-f519-4890-8611-6939b7c2120e@github.com>

On Mon, 20 Nov 2023 17:24:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR fixes the attribution of record patterns which have var and an annotation. The scheduling of the attribution was skipped for this occasion.

This pull request has now been integrated.

Changeset: 54957ac5
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54957ac55f8c6c68efc80436417ff30d4e9e2d37
Stats:     47 lines in 2 files changed: 44 ins; 1 del; 2 mod

8312560: Annotation on Decomposed Record Component in Enhanced For Loop Fails Compilation

Reviewed-by: jlahoda

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

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

From cstein at openjdk.org  Fri Dec  1 14:48:04 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 1 Dec 2023 14:48:04 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v8]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <rHOEegg2JzBt9uZY1J2oife-25CSH4mMRdwnaAOuPYk=.bd2a7ff0-4fbd-4f00-a1b2-d87c4c953ec7@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
> 
> The following demo programs do not start out of the box:
> 
> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Lower number of composed gatherers
  
  Prevent stack overflows on 32-bit machines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/63551153..bcf69dc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=06-07

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

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

From vromero at openjdk.org  Fri Dec  1 15:02:38 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Dec 2023 15:02:38 GMT
Subject: RFR: 8320948: NPE due to unreported compiler error
Message-ID: <v4z8go1zox0TA-6Ttl9JSYyAGi8uOwViMMoj-ifOEQo=.6495897e-980b-45b1-98a5-762f8705dd42@github.com>

The compiler is using some heuristics to decide whether or not to report a compiler error while doing recovery on deferred types. For the erroneous code included in the test case, the current heuristics decide not to report the error so ASTs with null types manage to get up to the code generation phase. This fix's proposal is to look into the speculative types of a deferred type and if all the speculative types are erroneous, then use a recovery type as the target type, which later on in the pipeline will imply reporting errors if any

TIA

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

Commit messages:
 - removing import
 - 8320948: NPE due to unreported compiler error

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

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

From duke at openjdk.org  Fri Dec  1 15:39:13 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 1 Dec 2023 15:39:13 GMT
Subject: RFR: 8321182: SourceExample.SOURCE_14 comment should refer to 'switch
 expressions' instead of 'text blocks'
Message-ID: <Cl0SyzLPodHknSQJlz527g7oJgzTfDUgBpO5lJwjoDY=.d62c3ded-5f1b-4bdc-affe-4d05d09670ba@github.com>

The `Versions` test has a comment referring to 'text blocks' when the feature introduced in Java 14 was actually 'switch expressions'. This looks like a simple copy/paste mistake.

This PR fixes the comment. While touching the code, I also took the liberty to do the following improvements:

- Fixed a typo in `requirements' in a code comment
- Removed some unused imports
- Reduced duplication of `JavaCompiler` option conversion by introducing a separate method `javaCompilerOptions`. (Used the 'extract method' refactoring in IntelliJ IDEA which replaced 3 duplicates)

If the last fix is considered gratuitous, let me know and I can simplify the PR.

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

Commit messages:
 - Correctly refer to SOURCE_14 feature as 'switch expressions'. Extract method javaCompilerOptions. Fix 'requirements' typo.

Changes: https://git.openjdk.org/jdk/pull/16924/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16924&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321182
  Stats: 51 lines in 1 file changed: 19 ins; 28 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16924/head:pull/16924

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

From darcy at openjdk.org  Fri Dec  1 17:57:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 1 Dec 2023 17:57:07 GMT
Subject: RFR: 8321182: SourceExample.SOURCE_14 comment should refer to
 'switch expressions' instead of 'text blocks'
In-Reply-To: <Cl0SyzLPodHknSQJlz527g7oJgzTfDUgBpO5lJwjoDY=.d62c3ded-5f1b-4bdc-affe-4d05d09670ba@github.com>
References: <Cl0SyzLPodHknSQJlz527g7oJgzTfDUgBpO5lJwjoDY=.d62c3ded-5f1b-4bdc-affe-4d05d09670ba@github.com>
Message-ID: <FPMnF1RifnvF7Myx1lkrICF2geMeRoVVuoQ69ollsMY=.0c8b0a44-fc00-48e1-b397-2ee3cc155c41@github.com>

On Fri, 1 Dec 2023 15:21:37 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `Versions` test has a comment referring to 'text blocks' when the feature introduced in Java 14 was actually 'switch expressions'. This looks like a simple copy/paste mistake.
> 
> This PR fixes the comment. While touching the code, I also took the liberty to do the following improvements:
> 
> - Fixed a typo in `requirements' in a code comment
> - Removed some unused imports
> - Reduced duplication of `JavaCompiler` option conversion by introducing a separate method `javaCompilerOptions`. (Used the 'extract method' refactoring in IntelliJ IDEA which replaced 3 duplicates)
> 
> If the last fix is considered gratuitous, let me know and I can simplify the PR.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16924#pullrequestreview-1760314918

From vromero at openjdk.org  Fri Dec  1 18:34:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Dec 2023 18:34:05 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
Message-ID: <xWX4clN3bYSCxLaE03Oi4g8D5jDDJNh9zdN5jN3CGmU=.9ee00d2d-6115-40a8-800a-5d5bb67ddf4d@github.com>

On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol files to JDK 22 b26.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1760367216

From vromero at openjdk.org  Fri Dec  1 19:15:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Dec 2023 19:15:31 GMT
Subject: RFR: JDK-8320941: Discuss receiver type handling
In-Reply-To: <alakysY-cmYeBt5I4-93bsag2WN5nM9Auv9UEoPcY9A=.071c4c1f-f45a-4de8-a626-3067a9e0e3fd@github.com>
References: <alakysY-cmYeBt5I4-93bsag2WN5nM9Auv9UEoPcY9A=.071c4c1f-f45a-4de8-a626-3067a9e0e3fd@github.com>
Message-ID: <yKmLNkSPzYnsF_qeFtirdpc3S2niWw0FetbCZV3LP2o=.82f560f7-5413-47d2-ad00-de56b5d3e929@github.com>

On Wed, 29 Nov 2023 03:05:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this note to discuss when ExecutableElement returns a non-sentinel object for the receiver type.
> 
> (The PR was accidentally created from the wrong branch; the change to java.lang.Double can be ignored.)

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16874#pullrequestreview-1760421530

From darcy at openjdk.org  Fri Dec  1 20:26:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 1 Dec 2023 20:26:56 GMT
Subject: Integrated: JDK-8320941: Discuss receiver type handling
In-Reply-To: <alakysY-cmYeBt5I4-93bsag2WN5nM9Auv9UEoPcY9A=.071c4c1f-f45a-4de8-a626-3067a9e0e3fd@github.com>
References: <alakysY-cmYeBt5I4-93bsag2WN5nM9Auv9UEoPcY9A=.071c4c1f-f45a-4de8-a626-3067a9e0e3fd@github.com>
Message-ID: <OcjlRIgpBCecJ9QFcQlF2FoJj1Llk5cd-_U1ytrSUFw=.0937eae0-5507-40a1-90c9-1cde4fbec17d@github.com>

On Wed, 29 Nov 2023 03:05:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this note to discuss when ExecutableElement returns a non-sentinel object for the receiver type.
> 
> (The PR was accidentally created from the wrong branch; the change to java.lang.Double can be ignored.)

This pull request has now been integrated.

Changeset: 1839433b
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1839433bff5587f6a9bede3c765100ae4737fd2e
Stats:     11 lines in 1 file changed: 11 ins; 0 del; 0 mod

8320941: Discuss receiver type handling

Reviewed-by: vromero

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

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

From duke at openjdk.org  Fri Dec  1 21:07:34 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 1 Dec 2023 21:07:34 GMT
Subject: RFR: 8321182: SourceExample.SOURCE_14 comment should refer to
 'switch expressions' instead of 'text blocks'
In-Reply-To: <Cl0SyzLPodHknSQJlz527g7oJgzTfDUgBpO5lJwjoDY=.d62c3ded-5f1b-4bdc-affe-4d05d09670ba@github.com>
References: <Cl0SyzLPodHknSQJlz527g7oJgzTfDUgBpO5lJwjoDY=.d62c3ded-5f1b-4bdc-affe-4d05d09670ba@github.com>
Message-ID: <c1M7HpOq3d_Wz7M4493xplaRX9_bL56NBRF2d9m1-yI=.f1bff6ac-5f27-4fc4-b5d8-af6b7f1b8cca@github.com>

On Fri, 1 Dec 2023 15:21:37 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `Versions` test has a comment referring to 'text blocks' when the feature introduced in Java 14 was actually 'switch expressions'. This looks like a simple copy/paste mistake.
> 
> This PR fixes the comment. While touching the code, I also took the liberty to do the following improvements:
> 
> - Fixed a typo in `requirements' in a code comment
> - Removed some unused imports
> - Reduced duplication of `JavaCompiler` option conversion by introducing a separate method `javaCompilerOptions`. (Used the 'extract method' refactoring in IntelliJ IDEA which replaced 3 duplicates)
> 
> If the last fix is considered gratuitous, let me know and I can simplify the PR.

Thanks for the review Joe! I'll integrate now, but will need a sponsor. This is a low-risk change, but no need to rush in case other reviewers want to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/16924#issuecomment-1836774836

From duke at openjdk.org  Fri Dec  1 21:18:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 1 Dec 2023 21:18:43 GMT
Subject: Integrated: 8321182: SourceExample.SOURCE_14 comment should refer to
 'switch expressions' instead of 'text blocks'
In-Reply-To: <Cl0SyzLPodHknSQJlz527g7oJgzTfDUgBpO5lJwjoDY=.d62c3ded-5f1b-4bdc-affe-4d05d09670ba@github.com>
References: <Cl0SyzLPodHknSQJlz527g7oJgzTfDUgBpO5lJwjoDY=.d62c3ded-5f1b-4bdc-affe-4d05d09670ba@github.com>
Message-ID: <3VS3eEInw34DdTIvqh3MEUYiHvV4IHTdst9irkJyRX8=.91d497c1-6da5-41b8-8378-9bc7864bdc40@github.com>

On Fri, 1 Dec 2023 15:21:37 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `Versions` test has a comment referring to 'text blocks' when the feature introduced in Java 14 was actually 'switch expressions'. This looks like a simple copy/paste mistake.
> 
> This PR fixes the comment. While touching the code, I also took the liberty to do the following improvements:
> 
> - Fixed a typo in `requirements' in a code comment
> - Removed some unused imports
> - Reduced duplication of `JavaCompiler` option conversion by introducing a separate method `javaCompilerOptions`. (Used the 'extract method' refactoring in IntelliJ IDEA which replaced 3 duplicates)
> 
> If the last fix is considered gratuitous, let me know and I can simplify the PR.

This pull request has now been integrated.

Changeset: 2f299e4a
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f299e4a732a945175a9d334d69fedafbe0ca25b
Stats:     51 lines in 1 file changed: 19 ins; 28 del; 4 mod

8321182: SourceExample.SOURCE_14 comment should refer to 'switch expressions' instead of 'text blocks'

Reviewed-by: darcy

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

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

From cstein at openjdk.org  Sat Dec  2 09:57:55 2023
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 2 Dec 2023 09:57:55 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v9]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <lFLMw_BnWmUumZnBbjAELxfRAx25t83iwxlW-Px1nYA=.076c98ad-07c9-4a4d-b872-7d49daea0ea4@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
> 
> The following demo programs do not start out of the box:
> 
> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/bcf69dc9..70540efe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=07-08

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

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

From cstein at openjdk.org  Sat Dec  2 09:57:57 2023
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 2 Dec 2023 09:57:57 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v7]
In-Reply-To: <poFL-szCA-a4W-5ZoTfdUx8XikUAPnAkd4kFSCVTxwA=.e00e3b8a-b967-481d-9ae0-6849ca1e9342@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <QFupK20fU3AUEe37HO95ML-aaXVNOxpqWudiuPN38UI=.dd71299d-4c28-4c4a-a03f-4541f10e558d@github.com>
 <poFL-szCA-a4W-5ZoTfdUx8XikUAPnAkd4kFSCVTxwA=.e00e3b8a-b967-481d-9ae0-6849ca1e9342@github.com>
Message-ID: <EwGcay5h17a1IJlIEt1SCGM2-zmWnsau9Br-veH4wMA=.03cbb304-5b47-4fc5-8e42-35ae089ae7e4@github.com>

On Fri, 1 Dec 2023 13:00:12 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test for implicit classes
>>   
>>   Preview notes normally emitted by `javac` are
>>   suppressed now, as they contain hints that
>>   does not apply to the source launcher and will
>>   lead to errors. For example: `-Xlint:preview`
>
> Just nits. Nice work.

@JimLaskey Thanks for the review - addressed all comments via https://github.com/openjdk/jdk/pull/13712/commits/70540efef8d1487ac3a2522e7299716ea3f46bc1

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

PR Comment: https://git.openjdk.org/jdk/pull/13712#issuecomment-1837106820

From cstein at openjdk.org  Sat Dec  2 13:58:55 2023
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 2 Dec 2023 13:58:55 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v10]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <Sq0UJpRLIaXUpoP2y1e7lhiUnbuIQEKl6BZhWiGC5_4=.ad608558-a749-43c4-85e0-d0b6888b3993@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
> 
> The following demo programs do not start out of the box:
> 
> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Delete superseded single-file launcher

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/70540efe..46fdd1cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=08-09

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

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

From darcy at openjdk.org  Sat Dec  2 20:34:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 2 Dec 2023 20:34:36 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <Lx5ZzbGIV584QK73SK4GaA8OF-41M-BECYxzWGmh8Fk=.37a42cf6-50e9-48f4-9d76-b071c2ead567@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
 <Lx5ZzbGIV584QK73SK4GaA8OF-41M-BECYxzWGmh8Fk=.37a42cf6-50e9-48f4-9d76-b071c2ead567@github.com>
Message-ID: <MvHasng-zgZGKUbkeFYM30zb2yO7day8Z3S0JOWSUEU=.a10c86e6-ce86-40a6-af22-b24e784aa243@github.com>

On Fri, 1 Dec 2023 08:54:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Looks good. I assume you'll bump the copyright header on the files that need it before integration, e.g. JavacTestingAbstractProcessor.

Right; I run a script to update the years of modified files.

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

PR Comment: https://git.openjdk.org/jdk/pull/16505#issuecomment-1837247101

From aturbanov at openjdk.org  Sat Dec  2 20:43:39 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 2 Dec 2023 20:43:39 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
Message-ID: <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>

On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol files to JDK 22 b26.

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

> 95:         TWENTY_ONE(false,"65.0", "21"),
> 96:         TWENTY_TWO(false,"66.0", "22"),
> 97:         TWENTY_THREE(false,"67.0", "23"),

As alignment is broken anyway, let's add space
Suggestion:

        TWENTY_THREE(false, "67.0", "23"),

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1412868557

From asotona at openjdk.org  Mon Dec  4 05:38:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Dec 2023 05:38:48 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v34]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <ERznvvOEs71JrKcEoPMt9cLFbuN-TrBQwnv_gAssFsU=.27708813-1833-45e2-bbd3-b3dee338d691@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 372 commits:

 - Merge branch 'master' into JDK-8308753-preview
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - fixed SwitchBootstrapTest
 - fixed SwitchBootstrap and StackMapsTest
 - fixed SwtichBootstrapTest and ModuleVersionTest
 - Merge branch 'master' into JDK-8308753-preview
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java
 - added new package-info snippets and fixed ClassFile::parse throws javadoc description
 - fixed lambda tests
 - ... and 362 more: https://git.openjdk.org/jdk/compare/b9df827a...a908e805

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=33
  Stats: 32362 lines in 787 files changed: 14660 ins; 14113 del; 3589 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

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

From asotona at openjdk.org  Mon Dec  4 07:11:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Dec 2023 07:11:11 GMT
Subject: Integrated: 8308753: Class-File API transition to Preview
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <xmC7Jgr28c-rsclwW-tBVjPo26NDX9amo2Ns2ez1Wtw=.5e1dd353-28ec-4c14-8ad0-4944b93a1216@github.com>

On Wed, 13 Sep 2023 09:48:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 2b00ac0d
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b00ac0d02a110326846c75ea7ea535dccbb1924
Stats:     32362 lines in 787 files changed: 14660 ins; 14113 del; 3589 mod

8308753: Class-File API transition to Preview

Reviewed-by: ihse, mchung, vromero

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

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

From jlahoda at openjdk.org  Mon Dec  4 07:50:57 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Dec 2023 07:50:57 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules
Message-ID: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>

As part of:
https://github.com/openjdk/jdk/pull/16505

there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.

I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.

Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.

The problems (and their solution) I've attempted to tackle here:
 - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
 - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
 - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed classes where finalized in JDK 17), changes are included here, and are the bulk of the changes of this patch.
 - when trying to find an existing class header when processing a new class header, it might have happened that an older existing version was picked up. This then caused repetition of the header in the new version. Proposed fix is to first look at the baseline existing header when searching for existing headers, and also a bit more careful computation of baseline.

As part of testing, I've written a simple program (inside tests), that prints all elements in exported packages using the `PrintingProcessor`, please see `PrintCTSymContent.java`. And printed the content for JDK 17-21 before this patch:
https://cr.openjdk.org/~jlahoda/8321224/diff.00/orig/
after this patch:
https://cr.openjdk.org/~jlahoda/8321224/diff.00/new/
and made a diff:
https://cr.openjdk.org/~jlahoda/8321224/diff.00/diff/

Looking at the diff, it seems that (as expected) it is basically addition of `sealed`&`permits` and addition of package private classes (forced by `permits`).

Symbol files generated for JDK 22 are here:
https://github.com/lahodaj/jdk/commit/06606d544cb63f007b1d4eb5196f3ca6ffd24bed#diff-0029c8ea954c5b329126d760dc307cd3235abbe4e9f0530dc301141e33746d37

There's one quirk in the current historical record files: as the `jdk/internal/foreign/` package existed in the `jdk.incubator.foreign` module, and was moved to `java.base`, the generator still puts the classes in this package into `jdk.incubator.foreign-<version>.sym.txt`. This is a quirk only in the way the `.sym.txt` files are written, when `ct.sym` is written, the `.sig` files are generated into the correct module. I may try to fix this for the future, but it does not seem to be blocker. (We need to include classes in this package due get the correct permitted subclasses handling.)

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

Commit messages:
 - Removing trailing whitespace.
 - Ensuring qualified packages are recorded properly.
 - Fixing tests.
 - Adding a way to dump the API.
 - Adding missing file.
 - 8321224: ct.sym for JDK 22 contains references to internal modules

Changes: https://git.openjdk.org/jdk/pull/16942/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321224
  Stats: 26876 lines in 194 files changed: 6106 ins; 20256 del; 514 mod
  Patch: https://git.openjdk.org/jdk/pull/16942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16942/head:pull/16942

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

From darcy at openjdk.org  Mon Dec  4 07:50:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 4 Dec 2023 07:50:57 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <GMYNmyYZnRpl28-aJ4-WnE8uxmlyuRKx1U3UB494QY0=.bac5302e-2689-4596-8f1b-dd5c047ce629@github.com>

On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As part of:
> https://github.com/openjdk/jdk/pull/16505
> 
> there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.
> 
> I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

Marked as reviewed by darcy (Reviewer).

Thanks for the quick fix @lahodaj ; the changes look plausible, but I think another person should review them too.

We can coordinate with start-of-JDK-23 work depending on exactly when this change goes back.

PS @lahodaj , I think a quick CSR is warranted here to explain the change in behavior in what is (now more correctly) stored in the symbol files.

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

PR Review: https://git.openjdk.org/jdk/pull/16942#pullrequestreview-1761515541
PR Comment: https://git.openjdk.org/jdk/pull/16942#issuecomment-1837756730
PR Comment: https://git.openjdk.org/jdk/pull/16942#issuecomment-1837760204

From cstein at openjdk.org  Mon Dec  4 08:10:30 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 4 Dec 2023 08:10:30 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v11]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <BL9bg3gdGLk2-aLIuEsoPDDRX-Upisqxv-WPu_tHI3A=.b12defed-9c08-472b-8db5-93aa4abbec0b@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
> 
> The following demo programs do not start out of the box:
> 
> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/46fdd1cb..5a063992

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=09-10

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

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

From jlahoda at openjdk.org  Mon Dec  4 08:46:50 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Dec 2023 08:46:50 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v11]
In-Reply-To: <BL9bg3gdGLk2-aLIuEsoPDDRX-Upisqxv-WPu_tHI3A=.b12defed-9c08-472b-8db5-93aa4abbec0b@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <BL9bg3gdGLk2-aLIuEsoPDDRX-Upisqxv-WPu_tHI3A=.b12defed-9c08-472b-8db5-93aa4abbec0b@github.com>
Message-ID: <28YzyXpw17QC6hF3vCqr6Zji-ciBXXaSQ02vP8tH7gI=.40ec86a1-0e34-47bc-aaa6-64216bcd2328@github.com>

On Mon, 4 Dec 2023 08:10:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
>> 
>> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
>> 
>> ### OpenJDK's Demo Programs
>> 
>> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
>> 
>> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
>> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
>> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
>> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
>> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
>> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
>> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
>> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
>> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
>> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
>> 
>> The following demo programs do not start out of the box:
>> 
>> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
>> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
>> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update tests

Overall seems reasonable to me, with two comments inline - one minor, but the other one is the change to the Gatherers tests - sorry, but I don't think it is appropriate to bury that change in this PR/commit.

test/jdk/java/util/stream/GathererTest.java line 352:

> 350:     @MethodSource("configurations")
> 351:     public void testMassivelyComposedGatherers(Config config) {
> 352:         final int ITERATIONS = 128; // Total number of compositions is 1 + (iterations*2)

Sorry, but I think it is not appropriate to do a change like this here. It should have its own PR and discussion.

test/langtools/tools/javac/launcher/src/p/q/CLTest.java line 2:

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

Probably:
Suggestion:

 * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved.

(not sure, but the file existed before, it is just moved, AFAIK.)

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

PR Review: https://git.openjdk.org/jdk/pull/13712#pullrequestreview-1761841707
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1413528478
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1413532003

From cstein at openjdk.org  Mon Dec  4 08:57:41 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 4 Dec 2023 08:57:41 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v12]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <grpMBVh5hM6pbw7EE4S6Qp1lIrtu14e0WWTDeWIumkU=.65cebf25-212a-4105-b412-598c3bc06a6d@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
> 
> The following demo programs do not start out of the box:
> 
> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update test/langtools/tools/javac/launcher/src/p/q/CLTest.java
  
  Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/5a063992..eaeca049

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=10-11

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

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

From cstein at openjdk.org  Mon Dec  4 08:57:47 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 4 Dec 2023 08:57:47 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v11]
In-Reply-To: <28YzyXpw17QC6hF3vCqr6Zji-ciBXXaSQ02vP8tH7gI=.40ec86a1-0e34-47bc-aaa6-64216bcd2328@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <BL9bg3gdGLk2-aLIuEsoPDDRX-Upisqxv-WPu_tHI3A=.b12defed-9c08-472b-8db5-93aa4abbec0b@github.com>
 <28YzyXpw17QC6hF3vCqr6Zji-ciBXXaSQ02vP8tH7gI=.40ec86a1-0e34-47bc-aaa6-64216bcd2328@github.com>
Message-ID: <VG7zAm-aUMs4i8jd-wyWE1HwngVFqdWcicEsxNFfuOY=.89945f69-0a25-481f-8a1f-532d0d5c3da4@github.com>

On Mon, 4 Dec 2023 08:34:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update tests
>
> test/jdk/java/util/stream/GathererTest.java line 352:
> 
>> 350:     @MethodSource("configurations")
>> 351:     public void testMassivelyComposedGatherers(Config config) {
>> 352:         final int ITERATIONS = 128; // Total number of compositions is 1 + (iterations*2)
> 
> Sorry, but I think it is not appropriate to do a change like this here. It should have its own PR and discussion.

Yes, I will revert this change and let @viktorklang-ora fine-tune it in another PR.

> test/langtools/tools/javac/launcher/src/p/q/CLTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Probably:
> Suggestion:
> 
>  * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> (not sure, but the file existed before, it is just moved, AFAIK.)

Yes. It was moved from `.../launcher/src` to `.../launcher/p/q`, thus committing as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1413543215
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1413549502

From cstein at openjdk.org  Mon Dec  4 09:01:44 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 4 Dec 2023 09:01:44 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v13]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <PzUQOsbT08Pk4XAPC_6WPf05BY9BuXaEOOUPbZAQ0pw=.f026b019-8c3b-4502-959e-665ee7bb0412@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
> 
> The following demo programs do not start out of the box:
> 
> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update tests, again

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/eaeca049..2ef19b43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=11-12

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

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

From cstein at openjdk.org  Mon Dec  4 09:09:57 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 4 Dec 2023 09:09:57 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v14]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <7fP2aV-Bb_AnIR7Sqm19twGIVkp3Z1eMBPFnJpdZqYM=.b88d190e-36a3-4e7d-a9e0-84f83fe091d0@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
> 
> The following demo programs do not start out of the box:
> 
> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8306914-javac-multi-file-launcher
   
   # Conflicts:
   #	test/langtools/tools/javac/launcher/GetResourceTest.java
   #	test/langtools/tools/javac/launcher/src/p/q/CLTest.java
 - Update tests, again
 - Update test/langtools/tools/javac/launcher/src/p/q/CLTest.java
   
   Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com>
 - Update tests
 - Delete superseded single-file launcher
 - Address review comments
 - Lower number of composed gatherers
   
   Prevent stack overflows on 32-bit machines
 - Update test for implicit classes
   
   Preview notes normally emitted by `javac` are
   suppressed now, as they contain hints that
   does not apply to the source launcher and will
   lead to errors. For example: `-Xlint:preview`
 - 8306914: Launch Multi-File Source-Code Programs

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

Changes: https://git.openjdk.org/jdk/pull/13712/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=13
  Stats: 3364 lines in 27 files changed: 2504 ins; 841 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13712/head:pull/13712

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

From alanb at openjdk.org  Mon Dec  4 09:12:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Dec 2023 09:12:46 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v11]
In-Reply-To: <VG7zAm-aUMs4i8jd-wyWE1HwngVFqdWcicEsxNFfuOY=.89945f69-0a25-481f-8a1f-532d0d5c3da4@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <BL9bg3gdGLk2-aLIuEsoPDDRX-Upisqxv-WPu_tHI3A=.b12defed-9c08-472b-8db5-93aa4abbec0b@github.com>
 <28YzyXpw17QC6hF3vCqr6Zji-ciBXXaSQ02vP8tH7gI=.40ec86a1-0e34-47bc-aaa6-64216bcd2328@github.com>
 <VG7zAm-aUMs4i8jd-wyWE1HwngVFqdWcicEsxNFfuOY=.89945f69-0a25-481f-8a1f-532d0d5c3da4@github.com>
Message-ID: <nJ3MRVqSdtLDBJlTYOgesJwfXCOXt0_lfFYUalqOS-M=.62e94096-d1b9-4eaf-8953-5f3aa719a6c5@github.com>

On Mon, 4 Dec 2023 08:49:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> test/jdk/java/util/stream/GathererTest.java line 352:
>> 
>>> 350:     @MethodSource("configurations")
>>> 351:     public void testMassivelyComposedGatherers(Config config) {
>>> 352:         final int ITERATIONS = 128; // Total number of compositions is 1 + (iterations*2)
>> 
>> Sorry, but I think it is not appropriate to do a change like this here. It should have its own PR and discussion.
>
> Yes, I will revert this change and let @viktorklang-ora fine-tune it in another PR.

Viktor has the change in JDK-8321124 to dial it down. Right now it requires too much stack on x86_32 systems used in the GHA testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1413568646

From ihse at openjdk.org  Mon Dec  4 11:41:40 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 11:41:40 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <5vLxKqST7AYhrmXhRNKfYhpAK_Z2wAOSSfxKX9L9z9s=.136fcc0d-880a-4e2e-ac2c-82c92d10e0cc@github.com>

On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As part of:
> https://github.com/openjdk/jdk/pull/16505
> 
> there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.
> 
> I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

make/modules/jdk.compiler/Gendata.gmk line 41:

> 39: CT_MODULES := $(filter-out $(MODULES_FILTER), $(DOCS_MODULES))
> 40: CT_EXTRA_MODULES := jdk.unsupported
> 41: CT_TRANSITIVE_MODULES := $(call FindTransitiveIndirectDepsForModules, $(CT_MODULES)) $(CT_MODULES)

Now the CT_TRANSITIVE_MODULES will include all CT_MODULES. I am pretty sure the intention was to keep them separated, for clarity, but to act on both CT_MODULES and CT_TRANSITIVE_MODULES. See e.g. the foreach on line 43. (This change will also make that foreach process CT_MODULES twice.)

Also, just for code readability, can you move the hard-coded list of extra modules to after the programmatic definitions of CT_MODULES and transitive modules, perhaps even with an empty line in between?

I think a better solution is to change your new line to:

$(ECHO) $(CT_MODULES)  $(CT_TRANSITIVE_MODULES)  $(CT_EXTRA_MODULES) >$(SUPPORT_OUTPUTDIR)/symbols/included-modules

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16942#discussion_r1413751161

From cstein at openjdk.org  Mon Dec  4 12:01:06 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 4 Dec 2023 12:01:06 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v15]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <Q1kf_NbfIWkZ90Lo_WHOhO4NH9A6mhxZDayGRtNXIH4=.ef820124-9c4c-42ae-adf9-c7de1b9864e6@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
> 
> The following demo programs do not start out of the box:
> 
> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/b3806670..7bb57d56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=13-14

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

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

From vromero at openjdk.org  Mon Dec  4 19:42:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 4 Dec 2023 19:42:47 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <qjAB5WtEWwoxzU5lkF61Sp0JMnf3yJeYH_7rIiYoZj0=.4ace519b-1cc3-4270-8642-e1174d215a4a@github.com>

On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As part of:
> https://github.com/openjdk/jdk/pull/16505
> 
> there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.
> 
> I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16942#pullrequestreview-1763256790

From jlahoda at openjdk.org  Mon Dec  4 21:27:57 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Dec 2023 21:27:57 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v2]
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>

> As part of:
> https://github.com/openjdk/jdk/pull/16505
> 
> there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.
> 
> I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

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

  Reflecting review feedback - keeping CT_TRANSITIVE_MODULES separate from CT_MODULES.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16942/files
  - new: https://git.openjdk.org/jdk/pull/16942/files/c65eb44b..87927789

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

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

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

From jlahoda at openjdk.org  Mon Dec  4 21:27:59 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Dec 2023 21:27:59 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v2]
In-Reply-To: <5vLxKqST7AYhrmXhRNKfYhpAK_Z2wAOSSfxKX9L9z9s=.136fcc0d-880a-4e2e-ac2c-82c92d10e0cc@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
 <5vLxKqST7AYhrmXhRNKfYhpAK_Z2wAOSSfxKX9L9z9s=.136fcc0d-880a-4e2e-ac2c-82c92d10e0cc@github.com>
Message-ID: <Qi4FyHVWclZ3HkXJ0Ci6LsgvxYD3cJbG7xrKg1JVPQY=.36bfd1c7-3ae7-4f88-9c04-fcc9e8f0d414@github.com>

On Mon, 4 Dec 2023 11:39:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback - keeping CT_TRANSITIVE_MODULES separate from CT_MODULES.
>
> make/modules/jdk.compiler/Gendata.gmk line 41:
> 
>> 39: CT_MODULES := $(filter-out $(MODULES_FILTER), $(DOCS_MODULES))
>> 40: CT_EXTRA_MODULES := jdk.unsupported
>> 41: CT_TRANSITIVE_MODULES := $(call FindTransitiveIndirectDepsForModules, $(CT_MODULES)) $(CT_MODULES)
> 
> Now the CT_TRANSITIVE_MODULES will include all CT_MODULES. I am pretty sure the intention was to keep them separated, for clarity, but to act on both CT_MODULES and CT_TRANSITIVE_MODULES. See e.g. the foreach on line 43. (This change will also make that foreach process CT_MODULES twice.)
> 
> Also, just for code readability, can you move the hard-coded list of extra modules to after the programmatic definitions of CT_MODULES and transitive modules, perhaps even with an empty line in between?
> 
> I think a better solution is to change your new line to:
> 
> $(ECHO) $(CT_MODULES)  $(CT_TRANSITIVE_MODULES)  $(CT_EXTRA_MODULES) >$(SUPPORT_OUTPUTDIR)/symbols/included-modules

Thanks for the comment! I tried to act on it here:
https://github.com/openjdk/jdk/pull/16942/commits/879277891708533b0b56dbe36b20760c62708bbf

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16942#discussion_r1414515956

From darcy at openjdk.org  Tue Dec  5 01:48:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 5 Dec 2023 01:48:14 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v5]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <WT4hwqImuTyuIoTT1l7nJmD7pNjADyuLXYLWrOBK_lU=.11e17f95-9c77-4dc3-a9b4-26bbcfc63141@github.com>

> Time to start making preparations for JDK 23.

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

 - Merge branch 'master' into JDK-8319413
 - Add symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Update symbol files to JDK 22 b26.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Add symbol files for JDK 22 build 25.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/30b5d427...2ee6cb96

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

Changes: https://git.openjdk.org/jdk/pull/16505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=04
  Stats: 12598 lines in 97 files changed: 12560 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/16505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505

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

From vromero at openjdk.org  Tue Dec  5 02:29:03 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Dec 2023 02:29:03 GMT
Subject: RFR: 8321207: javac is not accepting correct code
Message-ID: <va3hiiUbg45MlYB5GhmwSOqedYi37Swk5E0aozXc5FY=.56641f91-d29b-43f6-b59d-f5764448ba98@github.com>

Common code like:


import java.util.*;
import java.util.function.*;

interface Test {
    Object O = new Object() { // but if the implicit static initializer is added here the code is accepted
        IntSupplier x(int m) {
            return () -> m;
        }
    };
}

is failing after fix for [JDK-8194743](https://bugs.openjdk.org/browse/JDK-8194743). The issue here is that method Flow.BaseAnalyzer::forEachInitializer is invoked twice once for static and another once for non-static initializers. The static-ness of the initializer is determined at this method by checking the modifiers in the corresponding AST. The problem with this is that implicit flags are added to symbols at Check::checkFlags but they don't make their way up to the AST's modifiers. The proposed fix is checking for static-ness at both the modifiers and the corresponding symbol

TIA

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

Commit messages:
 - 8321207: javac is not accepting correct code

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

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

From iris at openjdk.org  Tue Dec  5 05:40:40 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 5 Dec 2023 05:40:40 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v5]
In-Reply-To: <WT4hwqImuTyuIoTT1l7nJmD7pNjADyuLXYLWrOBK_lU=.11e17f95-9c77-4dc3-a9b4-26bbcfc63141@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <WT4hwqImuTyuIoTT1l7nJmD7pNjADyuLXYLWrOBK_lU=.11e17f95-9c77-4dc3-a9b4-26bbcfc63141@github.com>
Message-ID: <HioUyYK9DU0tuyxoIMtKjDiwDiOvkC3-89h9aUirlQU=.08a78467-afb7-497f-88b5-cce72a31dcd1@github.com>

On Tue, 5 Dec 2023 01:48:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8319413
>  - Add symbol files.
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Update symbol files to JDK 22 b26.
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Add symbol files for JDK 22 build 25.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/30b5d427...2ee6cb96

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1764000855

From iris at openjdk.org  Tue Dec  5 05:40:44 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 5 Dec 2023 05:40:44 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
 <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>
Message-ID: <uBGC1h1iKx_-qR6p93-OjXCiNnyl8lqV8tTT0AaWjD8=.92e0ed23-2e7d-4ec0-952d-62aa768df14d@github.com>

On Sat, 2 Dec 2023 20:40:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update symbol files to JDK 22 b26.
>
> test/langtools/tools/javac/versions/Versions.java line 97:
> 
>> 95:         TWENTY_ONE(false,"65.0", "21"),
>> 96:         TWENTY_TWO(false,"66.0", "22"),
>> 97:         TWENTY_THREE(false,"67.0", "23"),
> 
> As alignment is broken anyway, let's add space
> Suggestion:
> 
>         TWENTY_THREE(false, "67.0", "23"),

If you're going to add the space, I'd consider establishing new alignment at TWENTY to accommodate the eventual space needed for "THREE", "SEVEN", and "EIGHT".  You wouldn't need to reset alignment for quite some time after that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1414904341

From jlahoda at openjdk.org  Tue Dec  5 07:47:37 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Dec 2023 07:47:37 GMT
Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs [v15]
In-Reply-To: <Q1kf_NbfIWkZ90Lo_WHOhO4NH9A6mhxZDayGRtNXIH4=.ef820124-9c4c-42ae-adf9-c7de1b9864e6@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <Q1kf_NbfIWkZ90Lo_WHOhO4NH9A6mhxZDayGRtNXIH4=.ef820124-9c4c-42ae-adf9-c7de1b9864e6@github.com>
Message-ID: <J6xuulkGiWVvvCGBJo5aGcQ6CU9N0sFF_6cRqLk1kqw=.41c27ee4-ea34-4009-b9fd-7a5bf35b3381@github.com>

On Mon, 4 Dec 2023 12:01:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation (now removed `Main.java` file). It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
>> 
>> ### OpenJDK's Demo Programs
>> 
>> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
>> 
>> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
>> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
>> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
>> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
>> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
>> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
>> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
>> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
>> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
>> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
>> 
>> The following demo programs do not start out of the box:
>> 
>> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
>> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
>> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
>> 
>> Tested tier1-tier5.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright line

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13712#pullrequestreview-1764180949

From cstein at openjdk.org  Tue Dec  5 07:53:47 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 5 Dec 2023 07:53:47 GMT
Subject: Integrated: 8306914: Implement JEP 458: Launch Multi-File Source-Code
 Programs
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <d8JOxaW9SxCBKcFuss6hIjpIVLBQvYMfrtmFM_acIVY=.65484df1-6f32-48fd-904c-9dfd8198e012@github.com>

On Fri, 28 Apr 2023 08:00:36 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation (now removed `Main.java` file). It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
> 
> The following demo programs do not start out of the box:
> 
> - `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
> 
> Tested tier1-tier5.

This pull request has now been integrated.

Changeset: 517b1788
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/517b1788198fc325961df61161f9b365c7b2524e
Stats:     3364 lines in 27 files changed: 2504 ins; 841 del; 19 mod

8306914: Implement JEP 458: Launch Multi-File Source-Code Programs

Reviewed-by: jlahoda, jlaskey

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

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

From asotona at openjdk.org  Tue Dec  5 09:01:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 5 Dec 2023 09:01:38 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v2]
In-Reply-To: <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
 <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>
Message-ID: <L9t3lVyjVYM4fbrb_0KNVfUjK0SH979IflQX2UxobDU=.d3f7771f-f21c-4d46-9e04-e860ff93240a@github.com>

On Mon, 4 Dec 2023 21:27:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> As part of:
>> https://github.com/openjdk/jdk/pull/16505
>> 
>> there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.
>> 
>> I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
>> 
>> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
>> 
>> The problems (and their solution) I've attempted to tackle here:
>>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator ...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - keeping CT_TRANSITIVE_MODULES separate from CT_MODULES.

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16942#pullrequestreview-1764410922

From ihse at openjdk.org  Tue Dec  5 11:25:33 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 11:25:33 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v2]
In-Reply-To: <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
 <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>
Message-ID: <LeCokS4AZOwIhTrphnTRtJwAGZnZP_2OrkRWnN_0IlU=.b5ff6f40-5f38-403e-b20b-2c4bded80ae4@github.com>

On Mon, 4 Dec 2023 21:27:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> As part of:
>> https://github.com/openjdk/jdk/pull/16505
>> 
>> there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.
>> 
>> I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
>> 
>> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
>> 
>> The problems (and their solution) I've attempted to tackle here:
>>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator ...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - keeping CT_TRANSITIVE_MODULES separate from CT_MODULES.

Build changes look fine now.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16942#pullrequestreview-1764783110

From jlahoda at openjdk.org  Tue Dec  5 14:44:35 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Dec 2023 14:44:35 GMT
Subject: RFR: 8321207: javac is not accepting correct code
In-Reply-To: <va3hiiUbg45MlYB5GhmwSOqedYi37Swk5E0aozXc5FY=.56641f91-d29b-43f6-b59d-f5764448ba98@github.com>
References: <va3hiiUbg45MlYB5GhmwSOqedYi37Swk5E0aozXc5FY=.56641f91-d29b-43f6-b59d-f5764448ba98@github.com>
Message-ID: <U5rDbqSo9zaCSVVJE34JdP0C1lcIX9e-cffWB51OHck=.6177dcee-c0ec-46cd-aa31-0ec39663dd5e@github.com>

On Tue, 5 Dec 2023 02:24:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Common code like:
> 
> 
> import java.util.*;
> import java.util.function.*;
> 
> interface Test {
>     Object O = new Object() { // but if the implicit static initializer is added here the code is accepted
>         IntSupplier x(int m) {
>             return () -> m;
>         }
>     };
> }
> 
> is failing after fix for [JDK-8194743](https://bugs.openjdk.org/browse/JDK-8194743). The issue here is that method Flow.BaseAnalyzer::forEachInitializer is invoked twice once for static and another once for non-static initializers. The static-ness of the initializer is determined at this method by checking the modifiers in the corresponding AST. The problem with this is that implicit flags are added to symbols at Check::checkFlags but they don't make their way up to the AST's modifiers. The proposed fix is checking for static-ness at both the modifiers and the corresponding symbol
> 
> TIA

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16963#pullrequestreview-1765271265

From jlahoda at openjdk.org  Tue Dec  5 16:27:30 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Dec 2023 16:27:30 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v3]
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <Wxv9oGOPRzHKZik6LXtbs31p1eI64qaL9fvby4AIyiE=.e5364a2c-59bf-44e1-a846-67c07512d544@github.com>

> As part of:
> https://github.com/openjdk/jdk/pull/16505
> 
> there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.
> 
> I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

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

 - Removing unneeded exports.
 - Merge branch 'master' into JDK-8321224
 - Reflecting review feedback - keeping CT_TRANSITIVE_MODULES separate from CT_MODULES.
 - Removing trailing whitespace.
 - Ensuring qualified packages are recorded properly.
 - Fixing tests.
 - Adding a way to dump the API.
 - Adding missing file.
 - 8321224: ct.sym for JDK 22 contains references to internal modules

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16942/files
  - new: https://git.openjdk.org/jdk/pull/16942/files/87927789..ce981117

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

  Stats: 56068 lines in 1520 files changed: 31819 ins; 18328 del; 5921 mod
  Patch: https://git.openjdk.org/jdk/pull/16942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16942/head:pull/16942

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

From abimpoudis at openjdk.org  Tue Dec  5 16:40:51 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 5 Dec 2023 16:40:51 GMT
Subject: RFR: 8320144: Compilation crashes when a custom annotation with
 invalid default value is used
Message-ID: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>

The erroneous case of:

`public String[] excludeModules() default new String[0];`

was not short-circuited in the compiler and we were getting an NPE in `l.nonEmpty()` for `l`. Now, `getAnnotationArrayValue` returns the error attribute, if that case is detected.

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

Commit messages:
 - 8320144: Compilation crashes when a custom annotation with invalid default value is used

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

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

From jlahoda at openjdk.org  Tue Dec  5 17:27:48 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Dec 2023 17:27:48 GMT
Subject: Integrated: 8321224: ct.sym for JDK 22 contains references to internal
 modules
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <sQ4LcPdHJFMLJlarMFXm2ZUsQvPVUbqF2HOG0nqw3oA=.06c21c44-5f50-44ed-a5a4-6f95a811f0e3@github.com>

On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As part of:
> https://github.com/openjdk/jdk/pull/16505
> 
> there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.
> 
> I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

This pull request has now been integrated.

Changeset: 18c79227
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18c7922781536366be93b2478251e32e261d06bb
Stats:     26870 lines in 194 files changed: 6101 ins; 20256 del; 513 mod

8321224: ct.sym for JDK 22 contains references to internal modules

Reviewed-by: darcy, vromero, asotona, ihse

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

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

From vromero at openjdk.org  Tue Dec  5 21:37:34 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Dec 2023 21:37:34 GMT
Subject: RFR: 8320144: Compilation crashes when a custom annotation with
 invalid default value is used
In-Reply-To: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
References: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
Message-ID: <-e_vTn_GqUzw3dwK28pv53UkmtURMHl4NKQKvem487U=.74bf4a8e-df00-4a32-8e69-c8ccc0d0151f@github.com>

On Tue, 5 Dec 2023 16:34:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The erroneous case of:
> 
> `public String[] excludeModules() default new String[0];`
> 
> was not short-circuited in the compiler and we were getting an NPE in `l.nonEmpty()` for `l`. Now, `getAnnotationArrayValue` returns the error attribute, if that case is detected.

looks sensible to me

test/langtools/tools/javac/T8320144.out line 2:

> 1: T8320144.java:16:54: compiler.err.new.not.allowed.in.annotation
> 2: 1 error

there seems to be an empty new line missing at the end of the file

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16977#pullrequestreview-1766132751
PR Review Comment: https://git.openjdk.org/jdk/pull/16977#discussion_r1416292070

From abimpoudis at openjdk.org  Tue Dec  5 22:04:48 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 5 Dec 2023 22:04:48 GMT
Subject: RFR: 8320144: Compilation crashes when a custom annotation with
 invalid default value is used [v2]
In-Reply-To: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
References: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
Message-ID: <uTXF8kgMdh5-GXhrHAmjl3xRJZ6CoyhLLwb2nw6pniA=.371ed1e7-8839-44fe-a407-60369d74b681@github.com>

> The erroneous case of:
> 
> `public String[] excludeModules() default new String[0];`
> 
> was not short-circuited in the compiler and we were getting an NPE in `l.nonEmpty()` for `l`. Now, `getAnnotationArrayValue` returns the error attribute, if that case is detected.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16977/files
  - new: https://git.openjdk.org/jdk/pull/16977/files/20c3ca05..c746af14

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

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

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

From darcy at openjdk.org  Wed Dec  6 01:10:50 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Dec 2023 01:10:50 GMT
Subject: RFR: JDK-8321073: Defer policy of disabling annotation processing by
 default
Message-ID: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>

To allow more time for build tools to accommodate changes in javac's default annotation processing policy, disabling annotation processing by default will be deferred one release to JDK 23. 

This PR re-enables implicit annotation processing by default _for JDK 22_. It is an anti-delta of  JDK-8306819.

Please also review the CSR to restore the previous behavior for JDK 22:

https://bugs.openjdk.org/browse/JDK-8321321

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

Commit messages:
 - Merge branch 'master' into JDK-8321073
 - JDK-8321073: Defer policy of disabling annotation processing by default

Changes: https://git.openjdk.org/jdk/pull/16988/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16988&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321073
  Stats: 64 lines in 5 files changed: 18 ins; 26 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/16988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16988/head:pull/16988

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

From josiahnoel at gmail.com  Wed Dec  6 01:15:43 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Tue, 5 Dec 2023 20:15:43 -0500
Subject: RFR: JDK-8321073: Defer policy of disabling annotation processing
 by default
In-Reply-To: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
References: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
Message-ID: <CAJ_t5UY4utthnzB8iJQO6rSGLoiYCO20jckeBrygnOeN_6VZkA@mail.gmail.com>

Will a JEP also be created to facilitate discussion and bring greater
awareness?

On Tue, Dec 5, 2023, 8:11?PM Joe Darcy <darcy at openjdk.org> wrote:

> To allow more time for build tools to accommodate changes in javac's
> default annotation processing policy, disabling annotation processing by
> default will be deferred one release to JDK 23.
>
> This PR re-enables implicit annotation processing by default _for JDK 22_.
> It is an anti-delta of  JDK-8306819.
>
> Please also review the CSR to restore the previous behavior for JDK 22:
>
> https://bugs.openjdk.org/browse/JDK-8321321
>
> -------------
>
> Commit messages:
>  - Merge branch 'master' into JDK-8321073
>  - JDK-8321073: Defer policy of disabling annotation processing by default
>
> Changes: https://git.openjdk.org/jdk/pull/16988/files
>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16988&range=00
>   Issue: https://bugs.openjdk.org/browse/JDK-8321073
>   Stats: 64 lines in 5 files changed: 18 ins; 26 del; 20 mod
>   Patch: https://git.openjdk.org/jdk/pull/16988.diff
>   Fetch: git fetch https://git.openjdk.org/jdk.git
> pull/16988/head:pull/16988
>
> PR: https://git.openjdk.org/jdk/pull/16988
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231205/decf54d3/attachment.htm>

From darcy at openjdk.org  Wed Dec  6 01:19:50 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Dec 2023 01:19:50 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <epnNqHl_psXmZlK2gQbRVx9zK4oero1RvARgkhbE6e0=.1c9b8ddf-f8fe-4147-9cac-a4585ed7ff58@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
 <WCqF8rPQnqAJ2GbPIDQXJTTpcnHClOTSXdcG3WlVbkI=.bbea1f2e-ed62-433c-8a20-63de09bafa14@github.com>
 <epnNqHl_psXmZlK2gQbRVx9zK4oero1RvARgkhbE6e0=.1c9b8ddf-f8fe-4147-9cac-a4585ed7ff58@github.com>
Message-ID: <cmzsScFdgTeidEgmNJFNgueO3_jvnirOoQ12y6ZuXMM=.81758d8d-1283-49b0-8782-19d08af5bb7c@github.com>

On Thu, 30 Nov 2023 21:10:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > I have learned very late (about a month ago, and through JMH bug reports!) about this change.
> > Looking at incoming bug reports, I can see this is looking to break significant amount of day-to-day things that rely on annotation processing to work by default. This includes existing JMH benchmarks, existing JCStress tests, and that is only OpenJDK tools so far! The proposed fix, "enable the annotation processing in build" seems to underestimate how many already existing build configs _are there_, and how widespread annotation processing is. So this is a harbinger of a widespread breakage when updating to JDK 22 and beyond.
> > Yet, I see only tiny discussion about this in either here or in the CSR. It mostly just states that disabling annotation processors is the right thing to do to solve the externally reported problematic scenario. Normally, given the impact for changing a policy like this, I would have expected to see a JEP-sized discussion that weighs pros and cons for mitigation strategies, polls what problems real projects would run into, discusses to what extent we want to deal with currently supported JDK releases, etc.
> > After more digging, the only (?) discussions I could find is [Reddit post](https://www.reddit.com/r/java/comments/17f7dha/consider_disabling_the_compilers_default_active/) and this PR comments, which contain some valid questions, concerns, and scenarios the discussion for a change like this should consider.
> > Yes, there was a warning message. This only highlights that hardly anyone reads the warning messages, especially buried somewhere in CI logs. This also does not capture the unfortunate reality that JDK 21 only starts to see major use, so most users did not even had the opportunity to see the warning message! In other words, warning messages are inefficient tools to bring quick attention to the issue that proposes to change the JDK behavior in a considerable way.
> > IMO, JEPs are done for this reason, even for less impactful things. So I suggest we revert [JDK-8306819](https://bugs.openjdk.org/browse/JDK-8306819) from JDK 22, and start over with the JEP targeting JDK 23 or even 24. I believe this would be a right thing to do at this point.
> 
> Thanks for the input @shipilev ; I'm looking into options to amend this change later in JDK 22.

Upon further reflection, we'll be deferring the policy change to disable implicit annotation processing from JDK 22 to JDK 23. The changeset to re-enable the old policy is out for review as https://github.com/openjdk/jdk/pull/16988.

In addition, we plan to backport support for the `-proc:full` option to our update releases: https://bugs.openjdk.org/browse/JDK-8308245

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1841918093

From vromero at openjdk.org  Wed Dec  6 02:38:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Dec 2023 02:38:46 GMT
Subject: Integrated: 8321207: javac is not accepting correct code
In-Reply-To: <va3hiiUbg45MlYB5GhmwSOqedYi37Swk5E0aozXc5FY=.56641f91-d29b-43f6-b59d-f5764448ba98@github.com>
References: <va3hiiUbg45MlYB5GhmwSOqedYi37Swk5E0aozXc5FY=.56641f91-d29b-43f6-b59d-f5764448ba98@github.com>
Message-ID: <OlDGYCD2ldTugeqXH7YBGcudwASWaJZNmPe8u09pzPc=.02d80620-1a99-46dc-9116-939921ee4d62@github.com>

On Tue, 5 Dec 2023 02:24:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Common code like:
> 
> 
> import java.util.*;
> import java.util.function.*;
> 
> interface Test {
>     Object O = new Object() { // but if the implicit static initializer is added here the code is accepted
>         IntSupplier x(int m) {
>             return () -> m;
>         }
>     };
> }
> 
> is failing after fix for [JDK-8194743](https://bugs.openjdk.org/browse/JDK-8194743). The issue here is that method Flow.BaseAnalyzer::forEachInitializer is invoked twice once for static and another once for non-static initializers. The static-ness of the initializer is determined at this method by checking the modifiers in the corresponding AST. The problem with this is that implicit flags are added to symbols at Check::checkFlags but they don't make their way up to the AST's modifiers. The proposed fix is checking for static-ness at both the modifiers and the corresponding symbol
> 
> TIA

This pull request has now been integrated.

Changeset: aaaae3ee
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aaaae3ee3cc966d05f6cf6fa81cecc122a8f9294
Stats:     45 lines in 2 files changed: 44 ins; 0 del; 1 mod

8321207: javac is not accepting correct code

Reviewed-by: jlahoda

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

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

From vromero at openjdk.org  Wed Dec  6 04:02:33 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Dec 2023 04:02:33 GMT
Subject: RFR: JDK-8321073: Defer policy of disabling annotation processing
 by default
In-Reply-To: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
References: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
Message-ID: <z027O2Li8E2qdu8DC20U1bGHpmkO-7d1Wh010r7wY2A=.4fe80c16-bdd1-4de1-a88c-a6f4aa855926@github.com>

On Wed, 6 Dec 2023 01:05:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To allow more time for build tools to accommodate changes in javac's default annotation processing policy, disabling annotation processing by default will be deferred one release to JDK 23. 
> 
> This PR re-enables implicit annotation processing by default _for JDK 22_. It is an anti-delta of  JDK-8306819.
> 
> Please also review the CSR to restore the previous behavior for JDK 22:
> 
> https://bugs.openjdk.org/browse/JDK-8321321

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16988#pullrequestreview-1766590711

From jlahoda at openjdk.org  Wed Dec  6 08:34:36 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Dec 2023 08:34:36 GMT
Subject: RFR: 8320144: Compilation crashes when a custom annotation with
 invalid default value is used [v2]
In-Reply-To: <uTXF8kgMdh5-GXhrHAmjl3xRJZ6CoyhLLwb2nw6pniA=.371ed1e7-8839-44fe-a407-60369d74b681@github.com>
References: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
 <uTXF8kgMdh5-GXhrHAmjl3xRJZ6CoyhLLwb2nw6pniA=.371ed1e7-8839-44fe-a407-60369d74b681@github.com>
Message-ID: <dBRZLrNWKFSo-OFxJbRGUFwcxgw-SgBT_Vb0O3mmXQU=.727805ea-1811-4f4d-b9ba-67a88d9de9d6@github.com>

On Tue, 5 Dec 2023 22:04:48 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> The erroneous case of:
>> 
>> `public String[] excludeModules() default new String[0];`
>> 
>> was not short-circuited in the compiler and we were getting an NPE in `l.nonEmpty()` for `l`. Now, `getAnnotationArrayValue` returns the error attribute, if that case is detected.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java line 716:

> 714:             ListBuffer<Attribute> buf = new ListBuffer<>();
> 715:             for (List<JCExpression> l = na.elems; l.nonEmpty(); l = l.tail) {
> 716:                 buf.append(attributeAnnotationValue(types.elemtype(expectedElementType),

Here, I would be more inclined to attribute the values even in the erroneous case. Like if someone writes:

public String[] value() default new String[0] {Other.CONSTANT}


Attributing even for the erroneous case would mean the AST would have types/symbols filled in, for possible further use.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16977#discussion_r1416915879

From jlahoda at openjdk.org  Wed Dec  6 08:50:38 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Dec 2023 08:50:38 GMT
Subject: RFR: JDK-8321073: Defer policy of disabling annotation processing
 by default
In-Reply-To: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
References: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
Message-ID: <0QjKTbtqNmS-eZLWA2tDDqM9RhN_8g4Kkvn-yJZ9F48=.15a9ae4a-d291-4073-9274-5208d7feb521@github.com>

On Wed, 6 Dec 2023 01:05:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To allow more time for build tools to accommodate changes in javac's default annotation processing policy, disabling annotation processing by default will be deferred one release to JDK 23. 
> 
> This PR re-enables implicit annotation processing by default _for JDK 22_. It is an anti-delta of  JDK-8306819.
> 
> Please also review the CSR to restore the previous behavior for JDK 22:
> 
> https://bugs.openjdk.org/browse/JDK-8321321

LGTM

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16988#pullrequestreview-1767002061

From mcimadamore at openjdk.org  Wed Dec  6 09:21:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 09:21:37 GMT
Subject: RFR: JDK-8321073: Defer policy of disabling annotation processing
 by default
In-Reply-To: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
References: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
Message-ID: <6qXFe9ml8DQQEsx7Z00OupEooo7-OcN40mrTjfHXGJE=.7bb045fd-0d3e-4077-8d6e-8a0d4156f7e9@github.com>

On Wed, 6 Dec 2023 01:05:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To allow more time for build tools to accommodate changes in javac's default annotation processing policy, disabling annotation processing by default will be deferred one release to JDK 23. 
> 
> This PR re-enables implicit annotation processing by default _for JDK 22_. It is an anti-delta of  JDK-8306819.
> 
> Please also review the CSR to restore the previous behavior for JDK 22:
> 
> https://bugs.openjdk.org/browse/JDK-8321321

Looks good

test/langtools/tools/javac/6341866/T6341866.java line 59:

> 57:         NONE(null),                     // don't use implicit compilation
> 58:         OPT_UNSET(null),                // implicit compilation, but no -implicit option
> 59:         OPT_NONE("-implicit:none"),     // implicit compilation wiith -implicit:none

Can we fix the typo?

test/langtools/tools/javac/6341866/T6341866.java line 60:

> 58:         OPT_UNSET(null),                // implicit compilation, but no -implicit option
> 59:         OPT_NONE("-implicit:none"),     // implicit compilation wiith -implicit:none
> 60:         OPT_CLASS("-implicit:class");   // implicit compilation wiith -implicit:class

Here too

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16988#pullrequestreview-1767064126
PR Review Comment: https://git.openjdk.org/jdk/pull/16988#discussion_r1416972088
PR Review Comment: https://git.openjdk.org/jdk/pull/16988#discussion_r1416972263

From mcimadamore at openjdk.org  Wed Dec  6 09:29:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 09:29:37 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API
In-Reply-To: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
Message-ID: <WxYS-yipn_I7LEdNIF0TC-2VZC_f6qGL6c0MFi2j_P8=.647cf914-20c7-4b3f-a011-43350469da24@github.com>

On Mon, 4 Dec 2023 11:12:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
> 
> This patch removes `ClassModel::verify` methods and introduces new top level methods:
> 
> List<VerifyError> ClassFile::verify(ClassModel model);
> List<VerifyError> ClassFile::verify(byte[] bytes);
> List<VerifyError> ClassFile::verify(Path path);
> 
> 
> Impact of the API change is minimal as the API has not been released yet.
> 
> Please review.
> 
> Thanks,
> Adam

test/jdk/jdk/classfile/VerifierSelfTest.java line 62:

> 60: 
> 61:     @Test
> 62:     void testFailedDump() throws IOException {

Why is this removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16947#discussion_r1416985296

From asotona at openjdk.org  Wed Dec  6 09:45:36 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 09:45:36 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API
In-Reply-To: <WxYS-yipn_I7LEdNIF0TC-2VZC_f6qGL6c0MFi2j_P8=.647cf914-20c7-4b3f-a011-43350469da24@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <WxYS-yipn_I7LEdNIF0TC-2VZC_f6qGL6c0MFi2j_P8=.647cf914-20c7-4b3f-a011-43350469da24@github.com>
Message-ID: <PJrqZc52eH1BfKJ1Yh8SZkhzbD28NiWqIXVK7S9P-Jc=.5bedc151-28ce-4502-9b10-f3f6d09c3bcf@github.com>

On Wed, 6 Dec 2023 09:26:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
>> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
>> 
>> This patch removes `ClassModel::verify` methods and introduces new top level methods:
>> 
>> List<VerifyError> ClassFile::verify(ClassModel model);
>> List<VerifyError> ClassFile::verify(byte[] bytes);
>> List<VerifyError> ClassFile::verify(Path path);
>> 
>> 
>> Impact of the API change is minimal as the API has not been released yet.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> test/jdk/jdk/classfile/VerifierSelfTest.java line 62:
> 
>> 60: 
>> 61:     @Test
>> 62:     void testFailedDump() throws IOException {
> 
> Why is this removed?

Dump (print) of the classfile to an optional log (Consumer&lt;String&gt; argument) has been removed from the API.
It was a relic from early phase of the ClassFile API development and it has no use except for this test.
This functionality can be replaced by explicit use of ClassPrinter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16947#discussion_r1417008753

From asotona at openjdk.org  Wed Dec  6 09:49:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 09:49:43 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API
In-Reply-To: <PJrqZc52eH1BfKJ1Yh8SZkhzbD28NiWqIXVK7S9P-Jc=.5bedc151-28ce-4502-9b10-f3f6d09c3bcf@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <WxYS-yipn_I7LEdNIF0TC-2VZC_f6qGL6c0MFi2j_P8=.647cf914-20c7-4b3f-a011-43350469da24@github.com>
 <PJrqZc52eH1BfKJ1Yh8SZkhzbD28NiWqIXVK7S9P-Jc=.5bedc151-28ce-4502-9b10-f3f6d09c3bcf@github.com>
Message-ID: <mNGwG43JKaxUDjwodKDC4fvfOvEtpTX5bDuLf8h8ETU=.96a67af9-ab10-47ca-977c-d3290e27569a@github.com>

On Wed, 6 Dec 2023 09:42:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> test/jdk/jdk/classfile/VerifierSelfTest.java line 62:
>> 
>>> 60: 
>>> 61:     @Test
>>> 62:     void testFailedDump() throws IOException {
>> 
>> Why is this removed?
>
> Dump (print) of the classfile to an optional log (Consumer&lt;String&gt; argument) has been removed from the API.
> It was a relic from early phase of the ClassFile API development and it has no use except for this test.
> This functionality can be replaced by explicit use of ClassPrinter.

I'll rename the test to "testFailed" and keep it without the "dump" part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16947#discussion_r1417013768

From asotona at openjdk.org  Wed Dec  6 10:40:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 10:40:51 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API [v2]
In-Reply-To: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
Message-ID: <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>

> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
> 
> This patch removes `ClassModel::verify` methods and introduces new top level methods:
> 
> List<VerifyError> ClassFile::verify(ClassModel model);
> List<VerifyError> ClassFile::verify(byte[] bytes);
> List<VerifyError> ClassFile::verify(Path path);
> 
> 
> Impact of the API change is minimal as the API has not been released yet.
> 
> Please review.
> 
> Thanks,
> Adam

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

  reverted modified test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16947/files
  - new: https://git.openjdk.org/jdk/pull/16947/files/4485a369..bacdf481

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

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

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

From abimpoudis at openjdk.org  Wed Dec  6 11:02:01 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 6 Dec 2023 11:02:01 GMT
Subject: RFR: 8320144: Compilation crashes when a custom annotation with
 invalid default value is used [v3]
In-Reply-To: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
References: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
Message-ID: <QVpfmKTBsqZEpVKrn-4_9XPAqEYgftZze4MA0-BVPhk=.1046d683-51e7-4008-af3c-fa60732b56e4@github.com>

> The erroneous case of:
> 
> `public String[] excludeModules() default new String[0];`
> 
> was not short-circuited in the compiler and we were getting an NPE in `l.nonEmpty()` for `l`. Now, `getAnnotationArrayValue` returns the error attribute, if that case is detected.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address Jan's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16977/files
  - new: https://git.openjdk.org/jdk/pull/16977/files/c746af14..83340888

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

  Stats: 15 lines in 1 file changed: 4 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16977/head:pull/16977

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

From abimpoudis at openjdk.org  Wed Dec  6 11:40:47 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 6 Dec 2023 11:40:47 GMT
Subject: RFR: 8320144: Compilation crashes when a custom annotation with
 invalid default value is used [v4]
In-Reply-To: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
References: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
Message-ID: <1AUyr2mHtBASXs3ddTq5HxsdBK-C91OOQTIEqGticc0=.8806cce2-2c3a-40b4-b654-1cd88d4f4c36@github.com>

> The erroneous case of:
> 
> `public String[] excludeModules() default new String[0];`
> 
> was not short-circuited in the compiler and we were getting an NPE in `l.nonEmpty()` for `l`. Now, `getAnnotationArrayValue` returns the error attribute, if that case is detected.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Small fix to let attribution for potential elements pass through

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16977/files
  - new: https://git.openjdk.org/jdk/pull/16977/files/83340888..9922d38e

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

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

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

From jlahoda at openjdk.org  Wed Dec  6 11:43:37 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Dec 2023 11:43:37 GMT
Subject: RFR: 8320144: Compilation crashes when a custom annotation with
 invalid default value is used [v4]
In-Reply-To: <1AUyr2mHtBASXs3ddTq5HxsdBK-C91OOQTIEqGticc0=.8806cce2-2c3a-40b4-b654-1cd88d4f4c36@github.com>
References: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
 <1AUyr2mHtBASXs3ddTq5HxsdBK-C91OOQTIEqGticc0=.8806cce2-2c3a-40b4-b654-1cd88d4f4c36@github.com>
Message-ID: <Dvz1TkPfzgNEeDl4ykkohgXceppXIXtXY2cT52-ihb4=.af5fb141-64d8-4069-be27-a7431d718d6a@github.com>

On Wed, 6 Dec 2023 11:40:47 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> The erroneous case of:
>> 
>> `public String[] excludeModules() default new String[0];`
>> 
>> was not short-circuited in the compiler and we were getting an NPE in `l.nonEmpty()` for `l`. Now, `getAnnotationArrayValue` returns the error attribute, if that case is detected.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small fix to let attribution for potential elements pass through

Looks great to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16977#pullrequestreview-1767342443

From abimpoudis at openjdk.org  Wed Dec  6 13:18:11 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 6 Dec 2023 13:18:11 GMT
Subject: RFR: 8320144: Compilation crashes when a custom annotation with
 invalid default value is used [v5]
In-Reply-To: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
References: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
Message-ID: <a3-Slx4lwMmb_czhcL_hP_HcWJVO3RBERLPNB5jQKus=.ad8454ea-7f87-461b-b2e1-e778382f18bb@github.com>

> The erroneous case of:
> 
> `public String[] excludeModules() default new String[0];`
> 
> was not short-circuited in the compiler and we were getting an NPE in `l.nonEmpty()` for `l`. Now, `getAnnotationArrayValue` returns the error attribute, if that case is detected.

Aggelos Biboudis 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 fix-#8320144
 - Small fix to let attribution for potential elements pass through
 - Address Jan's review
 - Address review
 - 8320144: Compilation crashes when a custom annotation with invalid default value is used

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16977/files
  - new: https://git.openjdk.org/jdk/pull/16977/files/9922d38e..a79a8473

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

  Stats: 31044 lines in 295 files changed: 8796 ins; 21258 del; 990 mod
  Patch: https://git.openjdk.org/jdk/pull/16977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16977/head:pull/16977

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

From jlahoda at openjdk.org  Wed Dec  6 14:51:41 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Dec 2023 14:51:41 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API [v2]
In-Reply-To: <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
Message-ID: <ps2A1xR3XSEKSG6FWZfYaygtOfEEifQ4G1w0IQHzlEI=.30280238-43d0-43d5-bae7-ea74b64fca3d@github.com>

On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
>> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
>> 
>> This patch removes `ClassModel::verify` methods and introduces new top level methods:
>> 
>> List<VerifyError> ClassFile::verify(ClassModel model);
>> List<VerifyError> ClassFile::verify(byte[] bytes);
>> List<VerifyError> ClassFile::verify(Path path);
>> 
>> 
>> Impact of the API change is minimal as the API has not been released yet.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted modified test

I guess the tests could be made much more tight. E.g. by not only checking passes/fails verification, but also checking the exact errors reported (for tests that just check that verify "failed", without checking the exact errors, it may happen the verification fails for a wrong reason). And the tests could probably be made much broader.

But I don't think that needs to happen here.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16947#pullrequestreview-1767775716

From mcimadamore at openjdk.org  Wed Dec  6 14:55:38 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 14:55:38 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API [v2]
In-Reply-To: <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
Message-ID: <JwWZV6IFgpnn9CsrHDXjzapJg7dWgaUX0m6guUMpoEk=.b836d2e9-e223-4202-acdb-c492ce9f9950@github.com>

On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
>> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
>> 
>> This patch removes `ClassModel::verify` methods and introduces new top level methods:
>> 
>> List<VerifyError> ClassFile::verify(ClassModel model);
>> List<VerifyError> ClassFile::verify(byte[] bytes);
>> List<VerifyError> ClassFile::verify(Path path);
>> 
>> 
>> Impact of the API change is minimal as the API has not been released yet.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted modified test

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16947#pullrequestreview-1767786746

From asotona at openjdk.org  Wed Dec  6 15:34:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 15:34:46 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API [v2]
In-Reply-To: <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
Message-ID: <iTeId2RAroI-8lgQimKhZluQXhzhtRN0Yv9unkkUWSY=.ff97dd23-3080-456e-8b70-8484c488fa4f@github.com>

On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
>> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
>> 
>> This patch removes `ClassModel::verify` methods and introduces new top level methods:
>> 
>> List<VerifyError> ClassFile::verify(ClassModel model);
>> List<VerifyError> ClassFile::verify(byte[] bytes);
>> List<VerifyError> ClassFile::verify(Path path);
>> 
>> 
>> Impact of the API change is minimal as the API has not been released yet.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted modified test

Thank you for the reviews.

Yes, next step is to improve verifier range and also cover it with negative tests (see https://github.com/openjdk/jdk/pull/16809/files#diff-a23859572e86e946a9ce66361e64e4b7e4473f134bb49a248fccd70d2ac96ea2)

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

PR Comment: https://git.openjdk.org/jdk/pull/16947#issuecomment-1843120837

From asotona at openjdk.org  Wed Dec  6 15:34:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 15:34:48 GMT
Subject: Integrated: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API
In-Reply-To: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
Message-ID: <9Sx8G-RVNRjecpYkIvTBIt4_Y7knwYVeOJeMUyJ9tyA=.bc0716de-0e84-4267-bacf-02eb6b597a14@github.com>

On Mon, 4 Dec 2023 11:12:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
> 
> This patch removes `ClassModel::verify` methods and introduces new top level methods:
> 
> List<VerifyError> ClassFile::verify(ClassModel model);
> List<VerifyError> ClassFile::verify(byte[] bytes);
> List<VerifyError> ClassFile::verify(Path path);
> 
> 
> Impact of the API change is minimal as the API has not been released yet.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 0217b5ac
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0217b5ac8b25db96fce026ac027b18024e25a329
Stats:     94 lines in 11 files changed: 44 ins; 32 del; 18 mod

8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API

Reviewed-by: jlahoda, mcimadamore

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

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

From abimpoudis at openjdk.org  Wed Dec  6 15:37:51 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 6 Dec 2023 15:37:51 GMT
Subject: Integrated: 8320144: Compilation crashes when a custom annotation with
 invalid default value is used
In-Reply-To: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
References: <IeUILr_6M5Jr3Vb71mRO2TMy12ZuUGjNYe_VneTLbRE=.54699cbb-792f-4099-9871-34bbd48120fe@github.com>
Message-ID: <S8F3mrx5b0CAeKdD9TaxLoheqykzPQYX9jOE7ua_-wg=.ad17fafb-f52a-4807-b094-887709df3bbe@github.com>

On Tue, 5 Dec 2023 16:34:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The erroneous case of:
> 
> `public String[] excludeModules() default new String[0];`
> 
> was not short-circuited in the compiler and we were getting an NPE in `l.nonEmpty()` for `l`. Now, `getAnnotationArrayValue` returns the error attribute, if that case is detected.

This pull request has now been integrated.

Changeset: 90e433d7
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90e433d72e73abf3252969f535451b56ecacc952
Stats:     29 lines in 3 files changed: 27 ins; 1 del; 1 mod

8320144: Compilation crashes when a custom annotation with invalid default value is used

Reviewed-by: vromero, jlahoda

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

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

From jlahoda at openjdk.org  Wed Dec  6 16:33:36 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Dec 2023 16:33:36 GMT
Subject: RFR: 8320948: NPE due to unreported compiler error
In-Reply-To: <v4z8go1zox0TA-6Ttl9JSYyAGi8uOwViMMoj-ifOEQo=.6495897e-980b-45b1-98a5-762f8705dd42@github.com>
References: <v4z8go1zox0TA-6Ttl9JSYyAGi8uOwViMMoj-ifOEQo=.6495897e-980b-45b1-98a5-762f8705dd42@github.com>
Message-ID: <t3SmgIB_77ezkcOPE_s4dZHP4oTtBCOxUCRvBqI4vXE=.e1ebcc26-ab9d-4691-baa3-293a4d5110d0@github.com>

On Fri, 1 Dec 2023 14:51:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The compiler is using some heuristics to decide whether or not to report a compiler error while doing recovery on deferred types. For the erroneous code included in the test case, the current heuristics decide not to report the error so ASTs with null types manage to get up to the code generation phase. This fix's proposal is to look into the speculative types of a deferred type and if all the speculative types are erroneous, then use a recovery type as the target type, which later on in the pipeline will imply reporting errors if any
> 
> TIA

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16923#pullrequestreview-1768065065

From vromero at openjdk.org  Wed Dec  6 16:50:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Dec 2023 16:50:53 GMT
Subject: Integrated: 8320948: NPE due to unreported compiler error
In-Reply-To: <v4z8go1zox0TA-6Ttl9JSYyAGi8uOwViMMoj-ifOEQo=.6495897e-980b-45b1-98a5-762f8705dd42@github.com>
References: <v4z8go1zox0TA-6Ttl9JSYyAGi8uOwViMMoj-ifOEQo=.6495897e-980b-45b1-98a5-762f8705dd42@github.com>
Message-ID: <AfWSKoBAotVYXixR8Ni1rh4TIB03SVTgD6jpzlgeexM=.d2d3ff85-5f54-4b1f-b744-d955fcf7ff73@github.com>

On Fri, 1 Dec 2023 14:51:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The compiler is using some heuristics to decide whether or not to report a compiler error while doing recovery on deferred types. For the erroneous code included in the test case, the current heuristics decide not to report the error so ASTs with null types manage to get up to the code generation phase. This fix's proposal is to look into the speculative types of a deferred type and if all the speculative types are erroneous, then use a recovery type as the target type, which later on in the pipeline will imply reporting errors if any
> 
> TIA

This pull request has now been integrated.

Changeset: a9cb120d
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9cb120d03e5b2efa244086e213d3b9e4706558a
Stats:     35 lines in 3 files changed: 34 ins; 0 del; 1 mod

8320948: NPE due to unreported compiler error

Reviewed-by: jlahoda

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

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

From darcy at openjdk.org  Wed Dec  6 17:40:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Dec 2023 17:40:47 GMT
Subject: RFR: JDK-8321073: Defer policy of disabling annotation processing
 by default [v2]
In-Reply-To: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
References: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
Message-ID: <M9fpQBuWbvHnmwcoKPXOOM9jPhhwp4_i1ir7l4vtn4I=.24157832-bb80-4f38-934d-6027270200dd@github.com>

> To allow more time for build tools to accommodate changes in javac's default annotation processing policy, disabling annotation processing by default will be deferred one release to JDK 23. 
> 
> This PR re-enables implicit annotation processing by default _for JDK 22_. It is an anti-delta of  JDK-8306819.
> 
> Please also review the CSR to restore the previous behavior for JDK 22:
> 
> https://bugs.openjdk.org/browse/JDK-8321321

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

  Fix typos found in code review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16988/files
  - new: https://git.openjdk.org/jdk/pull/16988/files/3a6d5abf..f63cb08f

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

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

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

From darcy at openjdk.org  Wed Dec  6 18:39:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Dec 2023 18:39:47 GMT
Subject: Integrated: JDK-8321073: Defer policy of disabling annotation
 processing by default
In-Reply-To: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
References: <JBnqRrAWYUmisiBLY9WRu_rcPjHuLmsG6qffbteA7wY=.4f92464a-9d2a-46c8-b13a-dd3fd44249cd@github.com>
Message-ID: <QXSvSI8ewYFOqIYSt2wscB5jG1eDrik8cFLOiuvORTs=.28feb026-c8e5-46a5-9d2a-d936d5be64b3@github.com>

On Wed, 6 Dec 2023 01:05:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To allow more time for build tools to accommodate changes in javac's default annotation processing policy, disabling annotation processing by default will be deferred one release to JDK 23. 
> 
> This PR re-enables implicit annotation processing by default _for JDK 22_. It is an anti-delta of  JDK-8306819.
> 
> Please also review the CSR to restore the previous behavior for JDK 22:
> 
> https://bugs.openjdk.org/browse/JDK-8321321

This pull request has now been integrated.

Changeset: 3edc24a7
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3edc24a71d29632e0a2166a64fc25ce83f631b47
Stats:     61 lines in 5 files changed: 18 ins; 26 del; 17 mod

8321073: Defer policy of disabling annotation processing by default

Reviewed-by: vromero, jlahoda, mcimadamore

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

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

From darcy at openjdk.org  Wed Dec  6 18:41:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Dec 2023 18:41:57 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v6]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <Mje8eoVfAhXc5K8LoU8YnhAga5PevtfNArYMUHXn6w8=.1cab743b-c1b8-460f-b492-80defdc48745@github.com>

> Time to start making preparations for JDK 23.

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

 - Regenerate JDK 22 symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Add symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Update symbol files to JDK 22 b26.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/db5613af...efe849f6

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

Changes: https://git.openjdk.org/jdk/pull/16505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=05
  Stats: 4866 lines in 98 files changed: 4828 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/16505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505

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

From darcy at openjdk.org  Thu Dec  7 06:33:02 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Dec 2023 06:33:02 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v7]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <gP4NSm10UOuaPUJbDAASnybpKh4T1ds-zvkjHiZH2-U=.03c17fcb-c21c-49f4-8cdd-323db3e0d6a8@github.com>

> Time to start making preparations for JDK 23.

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

 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Regenerate JDK 22 symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Add symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - ... and 11 more: https://git.openjdk.org/jdk/compare/632a3c56...4a871372

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

Changes: https://git.openjdk.org/jdk/pull/16505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=06
  Stats: 4866 lines in 98 files changed: 4828 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/16505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505

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

From darcy at openjdk.org  Thu Dec  7 06:41:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Dec 2023 06:41:09 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v8]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <GYRRAPm9pekioWkc3IaUOzWIYFMGAcc9a2Uvkk5Q-ds=.461d318d-ad9a-45cf-a2a7-6edc17d55302@github.com>

> Time to start making preparations for JDK 23.

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

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16505/files
  - new: https://git.openjdk.org/jdk/pull/16505/files/4a871372..a1aa187c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=06-07

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

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

From jlahoda at openjdk.org  Thu Dec  7 06:46:48 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Dec 2023 06:46:48 GMT
Subject: RFR: 8321164: javac with annotation processor throws AssertionError:
 Filling jrt:/... during JarFileObject[/...]
Message-ID: <wDv_yV358zcNPsSb9uve7lUT0Mr24GhTwJfFUa-KPQk=.e2884510-5fc4-4aa4-931a-19c88d26b078@github.com>

This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4.

The problem (to my understanding) is as follows:
 - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this.
 - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion:
https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401
 - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations:
https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423

The problem is that this method uses `Type.getKind()` which completes.

The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic.

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

Commit messages:
 - Restoring behavior w.r.t. null, removing trailing whitespace.
 - 8321164: javac with annotation processor throws AssertionError: Filling jrt:/... during JarFileObject[/...]

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

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

From vromero at openjdk.org  Thu Dec  7 06:46:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Dec 2023 06:46:49 GMT
Subject: RFR: 8321164: javac with annotation processor throws
 AssertionError: Filling jrt:/... during JarFileObject[/...]
In-Reply-To: <wDv_yV358zcNPsSb9uve7lUT0Mr24GhTwJfFUa-KPQk=.e2884510-5fc4-4aa4-931a-19c88d26b078@github.com>
References: <wDv_yV358zcNPsSb9uve7lUT0Mr24GhTwJfFUa-KPQk=.e2884510-5fc4-4aa4-931a-19c88d26b078@github.com>
Message-ID: <L-XRREwfKFeEkMcWg14a4BEu6y6VWLGp5v2ZApWNo3E=.00cb168d-f5c9-4cef-af06-f3ee491a7d51@github.com>

On Wed, 6 Dec 2023 18:52:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4.
> 
> The problem (to my understanding) is as follows:
>  - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this.
>  - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion:
> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401
>  - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations:
> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423
> 
> The problem is that this method uses `Type.getKind()` which completes.
> 
> The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic.

lgtm, nice test

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17001#pullrequestreview-1768663899

From mcimadamore at openjdk.org  Thu Dec  7 06:46:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Dec 2023 06:46:50 GMT
Subject: RFR: 8321164: javac with annotation processor throws
 AssertionError: Filling jrt:/... during JarFileObject[/...]
In-Reply-To: <wDv_yV358zcNPsSb9uve7lUT0Mr24GhTwJfFUa-KPQk=.e2884510-5fc4-4aa4-931a-19c88d26b078@github.com>
References: <wDv_yV358zcNPsSb9uve7lUT0Mr24GhTwJfFUa-KPQk=.e2884510-5fc4-4aa4-931a-19c88d26b078@github.com>
Message-ID: <FPRbuqIzBOBSJkJLfGIh8SQcaKsc4ojJXtp7hEW3V74=.002a181c-f389-45f6-aea6-d7e672de8dec@github.com>

On Wed, 6 Dec 2023 18:52:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4.
> 
> The problem (to my understanding) is as follows:
>  - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this.
>  - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion:
> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401
>  - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations:
> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423
> 
> The problem is that this method uses `Type.getKind()` which completes.
> 
> The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic.

Marked as reviewed by mcimadamore (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2424:

> 2422:                              ARRAY, MODULE, TYPEVAR, WILDCARD:
> 2423:                             return s.dropMetadata(Annotations.class);
> 2424:                         case VOID, METHOD, PACKAGE, FORALL, DEFERRED, BOT,

Not that it should matter much (as it cannot be annotated) but the `BOT` type seemed to receive a different treatment before (the kind for that is `NULL`). Separately, I'm a bit hazy of the rationale behind the logic here. E.g. is it an optimization to avoid removing metadata that we know isn't there, or is it something else? Anyway, not something to fix now (mostly thinking aloud)

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

PR Review: https://git.openjdk.org/jdk/pull/17001#pullrequestreview-1768703387
PR Review Comment: https://git.openjdk.org/jdk/pull/17001#discussion_r1418028005

From jlahoda at openjdk.org  Thu Dec  7 06:49:34 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Dec 2023 06:49:34 GMT
Subject: RFR: 8321164: javac with annotation processor throws
 AssertionError: Filling jrt:/... during JarFileObject[/...]
In-Reply-To: <FPRbuqIzBOBSJkJLfGIh8SQcaKsc4ojJXtp7hEW3V74=.002a181c-f389-45f6-aea6-d7e672de8dec@github.com>
References: <wDv_yV358zcNPsSb9uve7lUT0Mr24GhTwJfFUa-KPQk=.e2884510-5fc4-4aa4-931a-19c88d26b078@github.com>
 <FPRbuqIzBOBSJkJLfGIh8SQcaKsc4ojJXtp7hEW3V74=.002a181c-f389-45f6-aea6-d7e672de8dec@github.com>
Message-ID: <NvfORRccAnNpMG8_sWAdOU14aMCAyjPbvEBhxNVHh2k=.6da3a573-debf-4f84-8a13-509aa6156244@github.com>

On Wed, 6 Dec 2023 22:03:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4.
>> 
>> The problem (to my understanding) is as follows:
>>  - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this.
>>  - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion:
>> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401
>>  - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations:
>> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423
>> 
>> The problem is that this method uses `Type.getKind()` which completes.
>> 
>> The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2424:
> 
>> 2422:                              ARRAY, MODULE, TYPEVAR, WILDCARD:
>> 2423:                             return s.dropMetadata(Annotations.class);
>> 2424:                         case VOID, METHOD, PACKAGE, FORALL, DEFERRED, BOT,
> 
> Not that it should matter much (as it cannot be annotated) but the `BOT` type seemed to receive a different treatment before (the kind for that is `NULL`). Separately, I'm a bit hazy of the rationale behind the logic here. E.g. is it an optimization to avoid removing metadata that we know isn't there, or is it something else? Anyway, not something to fix now (mostly thinking aloud)

Uh, I somehow missed the `NULL`. Thanks for noticing. My intent here is not to change the behavior if possible, so I restored the `NULL`/`BOT` behavior as it was before.

As for the logic, I agree, I don't know why it is written like this. We could possibly try to cleanup early in a release and test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17001#discussion_r1418465050

From jlahoda at openjdk.org  Thu Dec  7 09:12:51 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Dec 2023 09:12:51 GMT
Subject: Integrated: 8321164: javac with annotation processor throws
 AssertionError: Filling jrt:/... during JarFileObject[/...]
In-Reply-To: <wDv_yV358zcNPsSb9uve7lUT0Mr24GhTwJfFUa-KPQk=.e2884510-5fc4-4aa4-931a-19c88d26b078@github.com>
References: <wDv_yV358zcNPsSb9uve7lUT0Mr24GhTwJfFUa-KPQk=.e2884510-5fc4-4aa4-931a-19c88d26b078@github.com>
Message-ID: <xLVOm887mCca_MQeaE118UwnQozMZ6WCdvuehUYbNIg=.7bf7bc23-d7b1-42b3-9a0d-ad242f8ce711@github.com>

On Wed, 6 Dec 2023 18:52:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4.
> 
> The problem (to my understanding) is as follows:
>  - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this.
>  - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion:
> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401
>  - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations:
> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423
> 
> The problem is that this method uses `Type.getKind()` which completes.
> 
> The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic.

This pull request has now been integrated.

Changeset: 03c45951
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03c4595173d564df97aa4f2b3156adcd4be379fa
Stats:     134 lines in 2 files changed: 124 ins; 0 del; 10 mod

8321164: javac with annotation processor throws AssertionError: Filling jrt:/... during JarFileObject[/...]

Reviewed-by: vromero, mcimadamore

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

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

From darcy at openjdk.org  Thu Dec  7 17:04:41 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Dec 2023 17:04:41 GMT
Subject: Integrated: JDK-8319413: Start of release updates for JDK 23
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <zmVMgvlrXfVNIim6gb1ZSPp2jteSr8-AwHK01zktclc=.fa0c0145-9b1e-42c0-86ca-8b677f55f07b@github.com>

On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start making preparations for JDK 23.

This pull request has now been integrated.

Changeset: 519ecd35
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/519ecd352a66633589f160db7390647d90e36b99
Stats:     4872 lines in 98 files changed: 4828 ins; 0 del; 44 mod

8319413: Start of release updates for JDK 23
8319414: Add SourceVersion.RELEASE_23
8319416: Add source 23 and target 23 to javac

Reviewed-by: iris, erikj, alanb, vromero

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

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

From jlahoda at openjdk.org  Fri Dec  8 16:35:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Dec 2023 16:35:24 GMT
Subject: RFR: 8321582: yield <primitive-type>.class not parsed correctly.
Message-ID: <RXh9m_DUeSinbXeV2e4uBe9CYcDdy-V7a_hVohV51H4=.2fdc35fc-f968-44e6-8a4e-db98708eefda@github.com>

Fixing the parser to accept primitive type after yield.

I didn't want to update the parts of the patch that remain, to not obstruct history, but I used the multi-label case for the new labels.

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

Commit messages:
 - 8321582: yield <primitive-type>.class not parsed correctly.

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

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

From vromero at openjdk.org  Fri Dec  8 17:31:14 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Dec 2023 17:31:14 GMT
Subject: RFR: 8321582: yield <primitive-type>.class not parsed correctly.
In-Reply-To: <RXh9m_DUeSinbXeV2e4uBe9CYcDdy-V7a_hVohV51H4=.2fdc35fc-f968-44e6-8a4e-db98708eefda@github.com>
References: <RXh9m_DUeSinbXeV2e4uBe9CYcDdy-V7a_hVohV51H4=.2fdc35fc-f968-44e6-8a4e-db98708eefda@github.com>
Message-ID: <rurIf_8zgUPqyQOXMnuFvbzXbiz99yiGTDl7pwyXuWQ=.15ea6530-376a-45cb-99a5-19ef8b80c940@github.com>

On Fri, 8 Dec 2023 16:30:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Fixing the parser to accept primitive type after yield.
> 
> I didn't want to update the parts of the patch that remain, to not obstruct history, but I used the multi-label case for the new labels.

looks sensible

do we need a CSR for this one?

test/langtools/tools/javac/switchexpr/ExpressionSwitch.java line 153:

> 151:     }
> 152: 
> 153:     private Class<?> yieldPrimiteDotClass(String s) {

typo: Primite -> Primitive

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17035#pullrequestreview-1772858259
PR Comment: https://git.openjdk.org/jdk/pull/17035#issuecomment-1847564565
PR Review Comment: https://git.openjdk.org/jdk/pull/17035#discussion_r1420815801

From cushon at openjdk.org  Fri Dec  8 18:08:16 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 8 Dec 2023 18:08:16 GMT
Subject: RFR: 8043226: Better diagnostics for non-applicable type
 annotations
In-Reply-To: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
References: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
Message-ID: <ieEZcun0yFtKl8h1-a_vozddPHZoHm2xknhl__Xb39o=.69bd2790-73c4-47bc-b2da-9db406d070ec@github.com>

On Fri, 10 Nov 2023 01:21:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi,
> 
> Please consider this improvement to diagnostics on inadmissable type annotations.
> 
> [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug.
> 
> I have some notes on details of the proposed changes below.
> 
> ---
> 
> Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. 
> 
> As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2.
> 
> This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names.
> 
> Before:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA
>     @TA Outer.SInner osi;
>              ^
> 
> 
> After:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA
>     @TA Outer.SInner osi;
>              ^
>   (to annotate a qualified type, write Outer. at TA SInner)
> 
> 
> ---
> 
> Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`.
> 
> This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location.
> 
> This also improves the ordering of the diagnostic in the output, since attribution errors are report before type annotation validation errors in the l...

Please keep this one open for now

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

PR Comment: https://git.openjdk.org/jdk/pull/16592#issuecomment-1847607054

From darcy at openjdk.org  Fri Dec  8 18:21:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 8 Dec 2023 18:21:36 GMT
Subject: RFR: JDK-8320790: Update --release 22 symbol information for JDK 22
 build 27
Message-ID: <ZdfcFrPnJaOQTt8YlKS3Ogaa6wXab0FVfq7s45jYA-o=.899e8630-2833-4398-9c79-59072f74466b@github.com>

Usual update of the symbol files for a new build.

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

Commit messages:
 - JDK-8320790: Update --release 22 symbol information for JDK 22 build 27

Changes: https://git.openjdk.org/jdk/pull/17036/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17036&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320790
  Stats: 6719 lines in 9 files changed: 6706 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17036.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17036/head:pull/17036

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

From iris at openjdk.org  Fri Dec  8 18:31:17 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 8 Dec 2023 18:31:17 GMT
Subject: RFR: JDK-8320790: Update --release 22 symbol information for JDK
 22 build 27
In-Reply-To: <ZdfcFrPnJaOQTt8YlKS3Ogaa6wXab0FVfq7s45jYA-o=.899e8630-2833-4398-9c79-59072f74466b@github.com>
References: <ZdfcFrPnJaOQTt8YlKS3Ogaa6wXab0FVfq7s45jYA-o=.899e8630-2833-4398-9c79-59072f74466b@github.com>
Message-ID: <DWLv5mfuN1CnUChXxNUkC7bsZt-lsIycLnNp_sglVsU=.3f1210cd-b6a1-4a18-b637-a9c9f7a4f11b@github.com>

On Fri, 8 Dec 2023 18:15:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual update of the symbol files for a new build.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17036#pullrequestreview-1772945723

From jjg at openjdk.org  Fri Dec  8 19:03:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 8 Dec 2023 19:03:14 GMT
Subject: RFR: JDK-8320790: Update --release 22 symbol information for JDK
 22 build 27
In-Reply-To: <ZdfcFrPnJaOQTt8YlKS3Ogaa6wXab0FVfq7s45jYA-o=.899e8630-2833-4398-9c79-59072f74466b@github.com>
References: <ZdfcFrPnJaOQTt8YlKS3Ogaa6wXab0FVfq7s45jYA-o=.899e8630-2833-4398-9c79-59072f74466b@github.com>
Message-ID: <0PUDHhZaWx9aqky6h271aZULeAidaITnvB06wCeEXMY=.17bf68a3-9744-4326-b698-8105adeac823@github.com>

On Fri, 8 Dec 2023 18:15:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual update of the symbol files for a new build.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17036#pullrequestreview-1772995238

From darcy at openjdk.org  Fri Dec  8 19:36:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 8 Dec 2023 19:36:21 GMT
Subject: Integrated: JDK-8320790: Update --release 22 symbol information for
 JDK 22 build 27
In-Reply-To: <ZdfcFrPnJaOQTt8YlKS3Ogaa6wXab0FVfq7s45jYA-o=.899e8630-2833-4398-9c79-59072f74466b@github.com>
References: <ZdfcFrPnJaOQTt8YlKS3Ogaa6wXab0FVfq7s45jYA-o=.899e8630-2833-4398-9c79-59072f74466b@github.com>
Message-ID: <c2fgejocezfh3vYohrAiAF7M8AClo40CrERF_ciyzZU=.a893e1ff-f5cb-45c1-aadd-01ae404b58df@github.com>

On Fri, 8 Dec 2023 18:15:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual update of the symbol files for a new build.

This pull request has now been integrated.

Changeset: 5c12a182
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c12a182e3f9aed8d075bb066cb8a093abab92de
Stats:     6719 lines in 9 files changed: 6706 ins; 1 del; 12 mod

8320790: Update --release 22 symbol information for JDK 22 build 27

Reviewed-by: iris, jjg

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

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

From jlahoda at openjdk.org  Mon Dec 11 09:57:39 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Dec 2023 09:57:39 GMT
Subject: RFR: 8321582: yield <primitive-type>.class not parsed correctly.
 [v2]
In-Reply-To: <RXh9m_DUeSinbXeV2e4uBe9CYcDdy-V7a_hVohV51H4=.2fdc35fc-f968-44e6-8a4e-db98708eefda@github.com>
References: <RXh9m_DUeSinbXeV2e4uBe9CYcDdy-V7a_hVohV51H4=.2fdc35fc-f968-44e6-8a4e-db98708eefda@github.com>
Message-ID: <oUlXI7BXcJMCXlSUfLtrJ5PJrQl7JeWy6HoyVOwflN4=.2dc38d93-91f5-4765-9f7a-e7303f376316@github.com>

> Fixing the parser to accept primitive type after yield.
> 
> I didn't want to update the parts of the patch that remain, to not obstruct history, but I used the multi-label case for the new labels.

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

  Fxing typo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17035/files
  - new: https://git.openjdk.org/jdk/pull/17035/files/48107768..c1d80fde

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

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

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

From jlahoda at openjdk.org  Mon Dec 11 09:57:41 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Dec 2023 09:57:41 GMT
Subject: RFR: 8321582: yield <primitive-type>.class not parsed correctly.
In-Reply-To: <rurIf_8zgUPqyQOXMnuFvbzXbiz99yiGTDl7pwyXuWQ=.15ea6530-376a-45cb-99a5-19ef8b80c940@github.com>
References: <RXh9m_DUeSinbXeV2e4uBe9CYcDdy-V7a_hVohV51H4=.2fdc35fc-f968-44e6-8a4e-db98708eefda@github.com>
 <rurIf_8zgUPqyQOXMnuFvbzXbiz99yiGTDl7pwyXuWQ=.15ea6530-376a-45cb-99a5-19ef8b80c940@github.com>
Message-ID: <IIeemGcQynKcDFR2b6h6AoBnuDZOPLDMFYv9x7qo2aw=.e8169b6f-7e24-4aef-ae5b-81c7d67a3a0d@github.com>

On Fri, 8 Dec 2023 17:28:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> do we need a CSR for this one?

I don't think so - we are enhancing the set of programs that compile, improving adherence to the specification (which is unchanged).

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

PR Comment: https://git.openjdk.org/jdk/pull/17035#issuecomment-1849699173

From jlahoda at openjdk.org  Mon Dec 11 12:23:25 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Dec 2023 12:23:25 GMT
Subject: Integrated: 8321582: yield <primitive-type>.class not parsed
 correctly.
In-Reply-To: <RXh9m_DUeSinbXeV2e4uBe9CYcDdy-V7a_hVohV51H4=.2fdc35fc-f968-44e6-8a4e-db98708eefda@github.com>
References: <RXh9m_DUeSinbXeV2e4uBe9CYcDdy-V7a_hVohV51H4=.2fdc35fc-f968-44e6-8a4e-db98708eefda@github.com>
Message-ID: <Cc-lpKLqHYF5-OQMm-G9CcvosHsnF9s8fG9L2bEKUjE=.8268d7c5-e542-4818-b5aa-c24dd728d02a@github.com>

On Fri, 8 Dec 2023 16:30:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Fixing the parser to accept primitive type after yield.
> 
> I didn't want to update the parts of the patch that remain, to not obstruct history, but I used the multi-label case for the new labels.

This pull request has now been integrated.

Changeset: ce8399fd
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce8399fd6071766114f5f201b6e44a7abdba9f5a
Stats:     29 lines in 2 files changed: 27 ins; 1 del; 1 mod

8321582: yield <primitive-type>.class not parsed correctly.

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Mon Dec 11 12:54:57 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Dec 2023 12:54:57 GMT
Subject: [jdk22] RFR: 8321582: yield <primitive-type>.class not parsed
 correctly.
Message-ID: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com>

Hi all,

This pull request contains a backport of commit [ce8399fd](https://github.com/openjdk/jdk/commit/ce8399fd6071766114f5f201b6e44a7abdba9f5a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 11 Dec 2023 and was reviewed by Vicente Romero.

Thanks!

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

Commit messages:
 - Backport ce8399fd6071766114f5f201b6e44a7abdba9f5a

Changes: https://git.openjdk.org/jdk22/pull/6/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=6&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321582
  Stats: 29 lines in 2 files changed: 27 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk22/pull/6.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/6/head:pull/6

PR: https://git.openjdk.org/jdk22/pull/6

From abimpoudis at openjdk.org  Mon Dec 11 16:08:53 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 11 Dec 2023 16:08:53 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v34]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <5d4KAKHRi3RXoFSlZ6FtQx6OKetrSwnBU8XP1AbAhhY=.e1f9236c-e039-4bc4-838a-38a43caff265@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request incrementally with 11 additional commits since the last revision:

 - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns
 - Fixed switch in the cases of unboxing and widening
 - Merge branch 'JDK-8319220' into primitive-patterns
 - Merge branch 'master' into JDK-8319220
 - reflecting review comment: fixing letter case.
 - Reflecting review feedback.
 - Some more get->orElseThrow
 - Reflecting review feedback.
 - Avoiding generating dead code - review feedback.
 - Cleanup.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/2b2405cc...fac9ca98

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/2b2405cc..fac9ca98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=32-33

  Stats: 689 lines in 5 files changed: 423 ins; 222 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

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

From abimpoudis at openjdk.org  Mon Dec 11 16:16:45 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 11 Dec 2023 16:16:45 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v35]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <YzWv2vncQQYO1qA4ALZd9x-uEVpkgRdAzoKiP9dvSqo=.b750b800-7fd4-4b0e-86bc-eab1813cd571@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove trailing spaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/fac9ca98..4fbdd708

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=33-34

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

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

From abimpoudis at openjdk.org  Mon Dec 11 17:14:02 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 11 Dec 2023 17:14:02 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v36]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <OCO29M0KzQHiTs60MP_uLMtH_w9rbPe0QhVt4R7BNMM=.ba3ae0f4-3c80-45b6-9240-63cc37e6ead6@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

 - Merge branch 'master' into primitive-patterns
 - Remove trailing spaces
 - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns
 - Fixed switch in the cases of unboxing and widening
 - Merge branch 'JDK-8319220' into primitive-patterns
 - Merge branch 'master' into JDK-8319220
 - reflecting review comment: fixing letter case.
 - Reflecting review feedback.
 - Some more get->orElseThrow
 - Reflecting review feedback.
 - ... and 42 more: https://git.openjdk.org/jdk/compare/b270f30d...65457894

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

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=35
  Stats: 3258 lines in 41 files changed: 2995 ins; 109 del; 154 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

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

From abimpoudis at openjdk.org  Mon Dec 11 19:44:01 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 11 Dec 2023 19:44:01 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v37]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <9ldTg1DpAuh8op3uQxpkt_9nXPHbvC8q-re-55L_lsU=.6b4019f2-b5ef-46da-bc9d-dde8308d2f3d@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/65457894..7a71ffa9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=35-36

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

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

From hannesw at openjdk.org  Mon Dec 11 21:23:40 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 11 Dec 2023 21:23:40 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent
 method
Message-ID: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>

Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location).

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

Commit messages:
 - Additional test
 - JDK-8164094: javadoc allows to create a @link to a non-existent method

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

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

From darcy at openjdk.org  Tue Dec 12 02:52:41 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 02:52:41 GMT
Subject: RFR: JDK-8320200: Use Elements predicates for record constructors to
 improve print output
Message-ID: <iSwvKagCls9okzztj_MkU63Uy2lfVSefRLm27rZJljk=.90cf5cff-c53f-4092-82eb-17d6dc37a887@github.com>

Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors.

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

Commit messages:
 - JDK-8320200: Use Elements predicates for record constructors to improve print output

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

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

From darcy at openjdk.org  Tue Dec 12 02:52:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 02:52:42 GMT
Subject: RFR: JDK-8320200: Use Elements predicates for record constructors
 to improve print output
In-Reply-To: <iSwvKagCls9okzztj_MkU63Uy2lfVSefRLm27rZJljk=.90cf5cff-c53f-4092-82eb-17d6dc37a887@github.com>
References: <iSwvKagCls9okzztj_MkU63Uy2lfVSefRLm27rZJljk=.90cf5cff-c53f-4092-82eb-17d6dc37a887@github.com>
Message-ID: <G83wupHZPXJMlwPZu1ojVfOcZAm88qRHpZUW__5gJ6o=.6064669c-277b-4ec1-8bd3-48aeb6893b0f@github.com>

On Tue, 12 Dec 2023 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors.

For a simple record like:


public record ComplexRecord(double real, double imaginary) {
    /**
     * Document the ctor.
     */
   ComplexRecord {
        this.real = real;
        this.imaginary = imaginary;
    }
}


the current printing processor output is


public record ComplexRecord(double real, double imaginary) {
  private final double real;
  private final double imaginary;

  /**
   * Document the ctor.
   */
  ComplexRecord(double real,
    double imaginary);

  public final java.lang.String toString();

  public final int hashCode();

  public final boolean equals(java.lang.Object o);

  public double real();

  public double imaginary();
}


and after this change it will be


public record ComplexRecord(double real, double imaginary) {
  private final double real;
  private final double imaginary;

  /**
   * Document the ctor.
   */
  ComplexRecord {} /* compact constructor */ ;

  public final java.lang.String toString();

  public final int hashCode();

  public final boolean equals(java.lang.Object o);

  public double real();

  public double imaginary();
}


All langtools regression tests pass with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/17073#issuecomment-1851217614

From darcy at openjdk.org  Tue Dec 12 02:55:12 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 02:55:12 GMT
Subject: RFR: JDK-8320200: Use Elements predicates for record constructors
 to improve print output
In-Reply-To: <iSwvKagCls9okzztj_MkU63Uy2lfVSefRLm27rZJljk=.90cf5cff-c53f-4092-82eb-17d6dc37a887@github.com>
References: <iSwvKagCls9okzztj_MkU63Uy2lfVSefRLm27rZJljk=.90cf5cff-c53f-4092-82eb-17d6dc37a887@github.com>
Message-ID: <RD-VHTihbzY4cbWN4ls-5HzqPY89EyON_2XnO9Z834o=.35c313a8-7b7c-4c10-8de9-9d305214d09c@github.com>

On Tue, 12 Dec 2023 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors.

PS It would be possible to add a comment on a record's canonical constructor, but at this junction I didn't think that was worthwhile.

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

PR Comment: https://git.openjdk.org/jdk/pull/17073#issuecomment-1851219868

From darcy at openjdk.org  Tue Dec 12 03:13:50 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 03:13:50 GMT
Subject: RFR: JDK-8321827: Remove unnecessary suppress warnings annotations
 from the printing processor
Message-ID: <zJg_Qxevpgkb6rYUVE_80W3Mw6P49z09NWrsv7mAlXQ=.b1d6de10-d8d8-464c-a339-54f4aa787b52@github.com>

With JEP 463, a utility method like "isUnnamed" is no longer included in javax.lang.model so there is no uses of methods associated with preview features. Therefore, the `@SuppressWarnings` annotations can (and should be) removed.

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

Commit messages:
 - JDK-8321827: Remove unnecessary suppress warnings annotations from the printing processo

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

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

From duke at openjdk.org  Tue Dec 12 07:52:48 2023
From: duke at openjdk.org (phuchau1989)
Date: Tue, 12 Dec 2023 07:52:48 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v12]
In-Reply-To: <dJ_GmL3sg48JA0dRYd8vmmO9BADligcbTu08iWkSJ3Y=.0ebc6510-9272-4177-8f8a-8c4030037f0a@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <dJ_GmL3sg48JA0dRYd8vmmO9BADligcbTu08iWkSJ3Y=.0ebc6510-9272-4177-8f8a-8c4030037f0a@github.com>
Message-ID: <bdQVH9VBBnwQ8ruHs3Q1lDNJhj1LqHaJNDkFiVjnsDQ=.5d57712e-3c64-4992-8e9f-fb98a4a8fb89@github.com>

On Fri, 19 May 2023 12:42:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing obsolette test, as suggested.

Marked as reviewed by phuchau1989 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/13074#pullrequestreview-1776839680

From hannesw at openjdk.org  Tue Dec 12 09:24:35 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Dec 2023 09:24:35 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method
In-Reply-To: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
Message-ID: <jZpP-wYgDSuNqTBLeiYGL4gKg6MR-ExQFznbSk0CMjo=.3be38cc2-0edd-43aa-ac5b-c2c750ffa2f4@github.com>

On Mon, 11 Dec 2023 21:18:57 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location).

There are a few cases of this linking pattern in OpenJDK that need to be fixed before this can be integrated. I filed [JDK-8321889](https://bugs.openjdk.org/browse/JDK-8321889).

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1851612460

From shade at openjdk.org  Tue Dec 12 09:42:53 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 12 Dec 2023 09:42:53 GMT
Subject: [jdk22] RFR: 8321582: yield <primitive-type>.class not parsed
 correctly.
In-Reply-To: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com>
References: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com>
Message-ID: <xdHyb2mJJQsMFCR5267x0jaN1BEmBICFxo-J3JgeAxM=.49fb733d-99fc-438d-8450-c593f30ce46c@github.com>

On Mon, 11 Dec 2023 12:47:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ce8399fd](https://github.com/openjdk/jdk/commit/ce8399fd6071766114f5f201b6e44a7abdba9f5a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 11 Dec 2023 and was reviewed by Vicente Romero.
> 
> Thanks!

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/6#pullrequestreview-1777043990

From hannesw at openjdk.org  Tue Dec 12 09:53:40 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Dec 2023 09:53:40 GMT
Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested) type
Message-ID: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>

Please review a change to fix JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc (with the correct link being created). With [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors.

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

Commit messages:
 - JDK-8321889: JavaDoc method references with wrong (nested) type

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

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

From hannesw at openjdk.org  Tue Dec 12 10:42:32 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Dec 2023 10:42:32 GMT
Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested)
 type [v2]
In-Reply-To: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
References: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
Message-ID: <nIlO1py1sZyxn4mfUUOtbAk7RVMLW1E1_uP4d4r6Vac=.437e6803-3cab-4963-a559-8c09ec794886@github.com>

> Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors.
> 
> I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Restore explicit label and remove duplicate word

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17078/files
  - new: https://git.openjdk.org/jdk/pull/17078/files/53e9cfa0..c7a76b17

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

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

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

From alanb at openjdk.org  Tue Dec 12 11:07:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Dec 2023 11:07:22 GMT
Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested)
 type [v2]
In-Reply-To: <nIlO1py1sZyxn4mfUUOtbAk7RVMLW1E1_uP4d4r6Vac=.437e6803-3cab-4963-a559-8c09ec794886@github.com>
References: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
 <nIlO1py1sZyxn4mfUUOtbAk7RVMLW1E1_uP4d4r6Vac=.437e6803-3cab-4963-a559-8c09ec794886@github.com>
Message-ID: <4dIjqukV52060edEa6j0AiOv5psHgpEFYXOzYqLKNf4=.cede50ce-09da-484e-9b5d-fc185631e419@github.com>

On Tue, 12 Dec 2023 10:42:32 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors.
>> 
>> I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references).
>> 
>> Update: I also fixed two typos in `javax/smartcardio/CardTerminals.java` by removing the duplicate "call" in "... latest call to waitForChange() call".
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore explicit label and remove duplicate word

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17078#pullrequestreview-1777214660

From hannesw at openjdk.org  Tue Dec 12 11:30:32 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Dec 2023 11:30:32 GMT
Subject: Integrated: JDK-8321889: JavaDoc method references with wrong (nested)
 type
In-Reply-To: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
References: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
Message-ID: <wIQscL9sqcYsC8GKpLom4OdGAf7k7bJOuX8V6Y4ZCCw=.3f99cffa-2c24-4e13-b02a-3ca010977c70@github.com>

On Tue, 12 Dec 2023 09:46:29 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors.
> 
> I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references).
> 
> Update: I also fixed two typos in `javax/smartcardio/CardTerminals.java` by removing the duplicate "call" in "... latest call to waitForChange() call".

This pull request has now been integrated.

Changeset: c5168526
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c51685267c7bd5a7cee27ebc2bf0d9899cda9d4c
Stats:     7 lines in 3 files changed: 0 ins; 2 del; 5 mod

8321889: JavaDoc method references with wrong (nested) type

Reviewed-by: alanb

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

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

From hannesw at openjdk.org  Tue Dec 12 12:42:41 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Dec 2023 12:42:41 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
Message-ID: <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>

> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location).

Hannes Walln?fer 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-8164094
 - Additional test
 - JDK-8164094: javadoc allows to create a @link to a non-existent method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17069/files
  - new: https://git.openjdk.org/jdk/pull/17069/files/3816b549..4f08440e

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

  Stats: 248 lines in 16 files changed: 162 ins; 45 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/17069.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17069/head:pull/17069

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

From prappo at openjdk.org  Tue Dec 12 13:49:34 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 12 Dec 2023 13:49:34 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
Message-ID: <Z5a2A6AUkl2qppAvigwuvrgWm7uqOdbiNFyUQsPX45U=.50a42fe0-acbc-43c6-84f3-7a475f8a05f7@github.com>

On Tue, 12 Dec 2023 12:42:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location).
>
> Hannes Walln?fer 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-8164094
>  - Additional test
>  - JDK-8164094: javadoc allows to create a @link to a non-existent method

It's nice to see this issue and its individual sightings being addressed.

While I'm a Reviewer, I'm not a compiler person, so my approval means little here. Wait for a compiler person to approve it. Perhaps they might also suggest a better name for the `explicitType` parameter.

Separately, it was interesting to see that a field is first searched in the enclosing class or interface, and if not found, searched in the superclass or a superinterface. The order in which a method is searched is the opposite: the superclass or a superinterface, then the enclosing class or interface.

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

PR Review: https://git.openjdk.org/jdk/pull/17069#pullrequestreview-1777513670

From prappo at openjdk.org  Tue Dec 12 13:56:22 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 12 Dec 2023 13:56:22 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <Z5a2A6AUkl2qppAvigwuvrgWm7uqOdbiNFyUQsPX45U=.50a42fe0-acbc-43c6-84f3-7a475f8a05f7@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Z5a2A6AUkl2qppAvigwuvrgWm7uqOdbiNFyUQsPX45U=.50a42fe0-acbc-43c6-84f3-7a475f8a05f7@github.com>
Message-ID: <2XjUK3reUMnHKgBUgv4WKHViKp6EGIaW88qeLTPzWE0=.5cdc7588-2ed6-43d7-8125-eca1d6df6092@github.com>

On Tue, 12 Dec 2023 13:46:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> individual sightings being addressed.

I meant in a separate PR #17078.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1852081911

From cstein at openjdk.org  Tue Dec 12 15:17:50 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 12 Dec 2023 15:17:50 GMT
Subject: RFR: 8321739: Source launcher fails with "Not a directory" error
Message-ID: <AFEBTt0A2Mu9HFBdvGLtFEjje_-nqOvMfE82QgXkiKg=.628c9b6b-d7f0-475f-8f1a-c93a9acdfe44@github.com>

Please review this change to allow files sharing names with packages when using the Java source launcher.

The now used `!Files.exists()` returns a boolean value on Unix-based file systems instead of throwing an exception as `Files.notExists()` does when one or more elements of the tested path are files (and not directories), in addition of the the last element.

Tested: tier1

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

Commit messages:
 - Source launcher fails with "Not a directory" error
 - Add failing test for JDK-8321739

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

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

From jlahoda at openjdk.org  Tue Dec 12 15:24:32 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 12 Dec 2023 15:24:32 GMT
Subject: RFR: 8321739: Source launcher fails with "Not a directory" error
In-Reply-To: <AFEBTt0A2Mu9HFBdvGLtFEjje_-nqOvMfE82QgXkiKg=.628c9b6b-d7f0-475f-8f1a-c93a9acdfe44@github.com>
References: <AFEBTt0A2Mu9HFBdvGLtFEjje_-nqOvMfE82QgXkiKg=.628c9b6b-d7f0-475f-8f1a-c93a9acdfe44@github.com>
Message-ID: <9gFsz-TCG0Mao0KStiBrt9ofuw8Ya3wGToIOIA0cpG0=.2dadd6c3-bf2c-443e-97a4-8d1584be0bb6@github.com>

On Tue, 12 Dec 2023 08:56:58 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to allow files sharing names with packages when using the Java source launcher.
> 
> The now used `!Files.exists()` returns a boolean value on Unix-based file systems instead of throwing an exception as `Files.notExists()` does when one or more elements of the tested path are files (and not directories), in addition of the the last element.
> 
> Tested: tier1

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17076#pullrequestreview-1777765474

From cstein at openjdk.org  Tue Dec 12 15:33:34 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 12 Dec 2023 15:33:34 GMT
Subject: Integrated: 8321739: Source launcher fails with "Not a directory"
 error
In-Reply-To: <AFEBTt0A2Mu9HFBdvGLtFEjje_-nqOvMfE82QgXkiKg=.628c9b6b-d7f0-475f-8f1a-c93a9acdfe44@github.com>
References: <AFEBTt0A2Mu9HFBdvGLtFEjje_-nqOvMfE82QgXkiKg=.628c9b6b-d7f0-475f-8f1a-c93a9acdfe44@github.com>
Message-ID: <ixgqlqhO5_vCTnm29EcNFdWtwyVnpE0PKGKTuMjQpco=.27bb8c3b-cdf2-4698-90b9-7a9aad6d252b@github.com>

On Tue, 12 Dec 2023 08:56:58 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to allow files sharing names with packages when using the Java source launcher.
> 
> The now used `!Files.exists()` returns a boolean value on Unix-based file systems instead of throwing an exception as `Files.notExists()` does when one or more elements of the tested path are files (and not directories), in addition of the the last element.
> 
> Tested: tier1

This pull request has now been integrated.

Changeset: df4ed7ef
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df4ed7eff7cc4afb2f0bcfdbb2489715ab209737
Stats:     4 lines in 3 files changed: 1 ins; 0 del; 3 mod

8321739: Source launcher fails with "Not a directory" error

Reviewed-by: jlahoda

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

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

From vromero at openjdk.org  Tue Dec 12 15:39:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Dec 2023 15:39:31 GMT
Subject: [jdk22] RFR: 8321582: yield <primitive-type>.class not parsed
 correctly.
In-Reply-To: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com>
References: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com>
Message-ID: <2lwN4Sd2nMIt2-ogEdQaZu7hSLMezl_yGnGLpK8otzU=.86ec550e-7235-4b69-9860-fc48eb6e753a@github.com>

On Mon, 11 Dec 2023 12:47:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ce8399fd](https://github.com/openjdk/jdk/commit/ce8399fd6071766114f5f201b6e44a7abdba9f5a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 11 Dec 2023 and was reviewed by Vicente Romero.
> 
> Thanks!

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/6#pullrequestreview-1777809760

From cstein at openjdk.org  Tue Dec 12 15:42:44 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 12 Dec 2023 15:42:44 GMT
Subject: [jdk22] RFR: 8321739: Source launcher fails with "Not a directory"
 error
Message-ID: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com>

Hi all,

This pull request contains a backport of commit [df4ed7ef](https://github.com/openjdk/jdk/commit/df4ed7eff7cc4afb2f0bcfdbb2489715ab209737) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Christian Stein on 12 Dec 2023 and was reviewed by Jan Lahoda.

Thanks!

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

Commit messages:
 - Backport df4ed7eff7cc4afb2f0bcfdbb2489715ab209737

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

PR: https://git.openjdk.org/jdk22/pull/10

From jlahoda at openjdk.org  Tue Dec 12 15:42:45 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 12 Dec 2023 15:42:45 GMT
Subject: [jdk22] RFR: 8321739: Source launcher fails with "Not a directory"
 error
In-Reply-To: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com>
References: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com>
Message-ID: <s8ObiktTWGGETAPQQPlSw02o2nXN3_hyNY_f5K7rZmY=.4e045693-4ae3-4e15-9ec7-77108e8c7c7b@github.com>

On Tue, 12 Dec 2023 15:36:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [df4ed7ef](https://github.com/openjdk/jdk/commit/df4ed7eff7cc4afb2f0bcfdbb2489715ab209737) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Christian Stein on 12 Dec 2023 and was reviewed by Jan Lahoda.
> 
> Thanks!

Looks good.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/10#pullrequestreview-1777813669

From jlaskey at openjdk.org  Tue Dec 12 18:37:31 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 12 Dec 2023 18:37:31 GMT
Subject: RFR: JDK-8321827: Remove unnecessary suppress warnings annotations
 from the printing processor
In-Reply-To: <zJg_Qxevpgkb6rYUVE_80W3Mw6P49z09NWrsv7mAlXQ=.b1d6de10-d8d8-464c-a339-54f4aa787b52@github.com>
References: <zJg_Qxevpgkb6rYUVE_80W3Mw6P49z09NWrsv7mAlXQ=.b1d6de10-d8d8-464c-a339-54f4aa787b52@github.com>
Message-ID: <89yf7O3snDy4rmr9kUm5qsHTj5BDQ6KgqOZ-gVjS3vQ=.9541afba-0dae-46ea-b47c-dc51deda3c8b@github.com>

On Tue, 12 Dec 2023 03:08:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With JEP 463, a utility method like "isUnnamed" is no longer included in javax.lang.model so there is no uses of methods associated with preview features. Therefore, the `@SuppressWarnings` annotations can (and should be) removed.

Marked as reviewed by jlaskey (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17074#pullrequestreview-1778207969

From shurailine at openjdk.org  Tue Dec 12 18:46:33 2023
From: shurailine at openjdk.org (Alexandre Iline)
Date: Tue, 12 Dec 2023 18:46:33 GMT
Subject: RFR: 8288989: Make tests not to depend on the source code
In-Reply-To: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
References: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
Message-ID: <BjM3czRmZ0kLceq4xTaa4HzptGl-15n1Le20zUghFm8=.435baa8f-48e8-4cba-ba95-067e9ff31fc1@github.com>

On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Two langtool tests depend on the JDK source tree presence. 
> This patch skips the tests execution in a source-less test environment.
> 
> Please review.
> 
> Thanks,
> Adam

This seems reasonable. LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1852609716

From darcy at openjdk.org  Tue Dec 12 18:47:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 18:47:20 GMT
Subject: Integrated: JDK-8321827: Remove unnecessary suppress warnings
 annotations from the printing processor
In-Reply-To: <zJg_Qxevpgkb6rYUVE_80W3Mw6P49z09NWrsv7mAlXQ=.b1d6de10-d8d8-464c-a339-54f4aa787b52@github.com>
References: <zJg_Qxevpgkb6rYUVE_80W3Mw6P49z09NWrsv7mAlXQ=.b1d6de10-d8d8-464c-a339-54f4aa787b52@github.com>
Message-ID: <GFthWy-iofv9KEJFIh0RwVCeVRHaEnPg68LCB1YcgHM=.691a7949-37c8-4131-9fcb-fd44e36c2a0d@github.com>

On Tue, 12 Dec 2023 03:08:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With JEP 463, a utility method like "isUnnamed" is no longer included in javax.lang.model so there is no uses of methods associated with preview features. Therefore, the `@SuppressWarnings` annotations can (and should be) removed.

This pull request has now been integrated.

Changeset: a3447ec6
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3447ec6562c5b4570da964d08ce8ae4c157c961
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8321827: Remove unnecessary suppress warnings annotations from the printing processor

Reviewed-by: jlaskey

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

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

From vromero at openjdk.org  Tue Dec 12 20:29:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Dec 2023 20:29:32 GMT
Subject: RFR: JDK-8320200: Use Elements predicates for record constructors
 to improve print output
In-Reply-To: <iSwvKagCls9okzztj_MkU63Uy2lfVSefRLm27rZJljk=.90cf5cff-c53f-4092-82eb-17d6dc37a887@github.com>
References: <iSwvKagCls9okzztj_MkU63Uy2lfVSefRLm27rZJljk=.90cf5cff-c53f-4092-82eb-17d6dc37a887@github.com>
Message-ID: <FDv90ctkOEQE7lUH6Q1Ak4Fm25gPtpkEyWsXdc2YP40=.f4cfe7a4-5840-4991-9918-990704e66021@github.com>

On Tue, 12 Dec 2023 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17073#pullrequestreview-1778380198

From darcy at openjdk.org  Tue Dec 12 21:03:38 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 21:03:38 GMT
Subject: Integrated: JDK-8320200: Use Elements predicates for record
 constructors to improve print output
In-Reply-To: <iSwvKagCls9okzztj_MkU63Uy2lfVSefRLm27rZJljk=.90cf5cff-c53f-4092-82eb-17d6dc37a887@github.com>
References: <iSwvKagCls9okzztj_MkU63Uy2lfVSefRLm27rZJljk=.90cf5cff-c53f-4092-82eb-17d6dc37a887@github.com>
Message-ID: <SiIOUKH5HPeCdGU79C7HksjlHQ_mTytakmCDhn0_v9o=.b6d1c5fc-b521-4a41-85ff-13c47399db2c@github.com>

On Tue, 12 Dec 2023 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors.

This pull request has now been integrated.

Changeset: ac07355f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac07355f5507cdb3a741ec1122e5e9983eac3936
Stats:     19 lines in 1 file changed: 11 ins; 0 del; 8 mod

8320200: Use Elements predicates for record constructors to improve print output

Reviewed-by: vromero

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

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

From cstein at openjdk.org  Tue Dec 12 21:11:35 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 12 Dec 2023 21:11:35 GMT
Subject: [jdk22] Integrated: 8321739: Source launcher fails with
 "Not a directory" error
In-Reply-To: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com>
References: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com>
Message-ID: <FHyjMj3SiObkXj_zHdLrqNe1iBXIlud4Jl4-wuGeHPk=.5c94f5a5-e215-492d-af0d-57b75cb83775@github.com>

On Tue, 12 Dec 2023 15:36:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [df4ed7ef](https://github.com/openjdk/jdk/commit/df4ed7eff7cc4afb2f0bcfdbb2489715ab209737) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Christian Stein on 12 Dec 2023 and was reviewed by Jan Lahoda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ae77bd00
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/ae77bd009f9f291c9dea80daee591538ecb887fc
Stats:     4 lines in 3 files changed: 1 ins; 0 del; 3 mod

8321739: Source launcher fails with "Not a directory" error

Reviewed-by: jlahoda
Backport-of: df4ed7eff7cc4afb2f0bcfdbb2489715ab209737

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

PR: https://git.openjdk.org/jdk22/pull/10

From darcy at openjdk.org  Tue Dec 12 21:41:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 21:41:23 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
Message-ID: <Mpqc4k6Kz5M8VFVJIzhTXOeBbyE1RaYdn29t-WIq-Bw=.2ad01fe7-add8-43a2-94d3-3af6f28fb1ce@github.com>

On Tue, 12 Dec 2023 12:42:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location).
>
> Hannes Walln?fer 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-8164094
>  - Additional test
>  - JDK-8164094: javadoc allows to create a @link to a non-existent method

Should this issue have a CSR for the behavioral change?

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1852850124

From jjg at openjdk.org  Tue Dec 12 21:49:31 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 12 Dec 2023 21:49:31 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <Z5a2A6AUkl2qppAvigwuvrgWm7uqOdbiNFyUQsPX45U=.50a42fe0-acbc-43c6-84f3-7a475f8a05f7@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Z5a2A6AUkl2qppAvigwuvrgWm7uqOdbiNFyUQsPX45U=.50a42fe0-acbc-43c6-84f3-7a475f8a05f7@github.com>
Message-ID: <F9VomRGaTbD9zEAhDkAt4EU4b1qYzGILCHKIAloZaGU=.d05f5ed5-db78-4ddf-b2c9-8ebc7594a28f@github.com>

On Tue, 12 Dec 2023 13:46:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> It's nice to see this issue and its individual sightings being addressed.
> 
> While I'm a Reviewer, I'm not a compiler person, so my approval means little here. Wait for a compiler person to approve it. Perhaps they might also suggest a better name for the `explicitType` parameter.
> 
> Separately, it was interesting to see that a field is first searched in the enclosing class or interface, and if not found, searched in the superclass or a superinterface. The order in which a method is searched is the opposite: the superclass or a superinterface, then the enclosing class or interface.

Maybe @lahodaj can help.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1852860126

From hannesw at openjdk.org  Wed Dec 13 10:47:40 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 13 Dec 2023 10:47:40 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <Mpqc4k6Kz5M8VFVJIzhTXOeBbyE1RaYdn29t-WIq-Bw=.2ad01fe7-add8-43a2-94d3-3af6f28fb1ce@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Mpqc4k6Kz5M8VFVJIzhTXOeBbyE1RaYdn29t-WIq-Bw=.2ad01fe7-add8-43a2-94d3-3af6f28fb1ce@github.com>
Message-ID: <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>

On Tue, 12 Dec 2023 21:38:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Should this issue have a CSR for the behavioral change?

My understanding of the issue is that the lookup of explicit-class member references in enclosing classes was an unintended consequence of doing the same for classless references from within nested classes. So I consider this a bug fix, not a feature change (even though it unfortunately changes javadoc to become stricter in what it accepts).

Actually, the feature of extending member reference lookup to enclosing classes is not specified in the taglet spec, which only says this:

> When the reference is to a member of the same class as that containing the documentation comment, all parts of the reference up to and including the # may be omitted, although the '#' may be retained for clarity.

This could be extended to include enclosing classes, but this is existing behaviour, not changed by this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1853676675

From prappo at openjdk.org  Wed Dec 13 13:45:37 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 13 Dec 2023 13:45:37 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <F9VomRGaTbD9zEAhDkAt4EU4b1qYzGILCHKIAloZaGU=.d05f5ed5-db78-4ddf-b2c9-8ebc7594a28f@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Z5a2A6AUkl2qppAvigwuvrgWm7uqOdbiNFyUQsPX45U=.50a42fe0-acbc-43c6-84f3-7a475f8a05f7@github.com>
 <F9VomRGaTbD9zEAhDkAt4EU4b1qYzGILCHKIAloZaGU=.d05f5ed5-db78-4ddf-b2c9-8ebc7594a28f@github.com>
Message-ID: <PCdqQmryCGtZNvEri92X7Ut2klBLIVpqgVGMSSyQQBk=.27c95679-8345-45c5-9815-0763e6c49a4e@github.com>

On Tue, 12 Dec 2023 21:46:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Separately, it was interesting to see that a field is first searched in the enclosing class or interface, and if not found, searched in the superclass or a superinterface. The order in which a method is searched is the opposite: the superclass or a superinterface, then the enclosing class or interface.

As I said before, it's a separate issue. However, I still wonder what the rationale for that difference is; it's not obvious to me. It also doesn't strike me as the right behaviour.

FWIW, as a local experiment I changed code so that both methods and fields were first searched in the superclass and superinterfaces and then in the enclosing class or interface. Out of the above two alternatives, this order seems more correct. All tier1 tests still succeeded.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1853943874

From jlahoda at openjdk.org  Wed Dec 13 13:48:40 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Dec 2023 13:48:40 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
Message-ID: <Ikcjc-3KyZvlfINqLsLwNjhclU-GH0G7uBG3XUoR1_E=.dc1e3a71-045a-4bca-858b-618418a42f97@github.com>

On Tue, 12 Dec 2023 12:42:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location).
>
> Hannes Walln?fer 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-8164094
>  - Additional test
>  - JDK-8164094: javadoc allows to create a @link to a non-existent method

For "normal" field or method (simple-name) lookup, the same-named field or method from the enclosing scope is shadowed by the declaration in the current ("nested") scope (JLS 6.4.1). The "nested" scope includes inherited fields and methods. So, even for fields, it might be preferable to first search supertypes, and only then enclosing scopes.

There is a caveat: the inheritance rules are a bit complex, like for example `private`, inaccessible or hidden(*) fields are not inherited (JLS 8.3); rules for methods are even a bit more complex (JLS 8.4.8). I.e. if we just change the search order, we may end up looking up a private field from a supertype, instead of the more correct field from an enclosing scope.

(*) hidden fields are not really an issue here.

There's also one more specialty for methods: if there's any method of name `m` in a given scope, even if it is not applicable due to parameter types, the search ends in that scope, and does not go to the enclosing scopes (a method named `m` shadows all methods named `m` with any parameters in the enclosing scope). (JLS 6.4.1)

I am not sure how strictly correct javadoc needs to be, but if we want to get closer to the normal "simple-name" lookup, we would probably need to tighten up the code.

I was briefly looking whether we could reuse the standard lookup - might be doable for fields, but not sure about methods. Would need some more investigations, I am afraid.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1853948123

From prappo at openjdk.org  Wed Dec 13 14:56:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 13 Dec 2023 14:56:38 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Mpqc4k6Kz5M8VFVJIzhTXOeBbyE1RaYdn29t-WIq-Bw=.2ad01fe7-add8-43a2-94d3-3af6f28fb1ce@github.com>
 <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>
Message-ID: <81GrAewa5NKD4xg8oTdTzr3X_whVENpiaI-aUbUHMC8=.9c18fc4d-155d-4825-9d72-1fda0c0ff66c@github.com>

On Wed, 13 Dec 2023 10:44:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Should this issue have a CSR for the behavioral change?
>
>> Should this issue have a CSR for the behavioral change?
> 
> My understanding of the issue is that the lookup of explicit-class member references in enclosing classes was an unintended consequence of doing the same for classless references from within nested classes. So I consider this a bug fix, not a feature change (even though it unfortunately changes javadoc to become stricter in what it accepts).
> 
> Actually, the feature of extending member reference lookup to enclosing classes is not specified in the taglet spec, which only says this:
> 
>> When the reference is to a member of the same class as that containing the documentation comment, all parts of the reference up to and including the # may be omitted, although the '#' may be retained for clarity.
> 
> This could be extended to include enclosing classes, but this is existing behaviour, not changed by this issue.

@hns would you be able to create a linked bug to track that lookup order issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1854066147

From vromero at openjdk.org  Wed Dec 13 15:03:43 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Dec 2023 15:03:43 GMT
Subject: RFR: 8288989: Make tests not to depend on the source code
In-Reply-To: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
References: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
Message-ID: <EGnaLQCU8kFHcKQow6G5RCAIxfn-ekZU-HEtRbYe15c=.97bef4db-b7ec-41be-b4ca-495df0db7ee2@github.com>

On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Two langtool tests depend on the JDK source tree presence. 
> This patch skips the tests execution in a source-less test environment.
> 
> Please review.
> 
> Thanks,
> Adam

just curious: in what conditions the tests will be executed in a source-less test environment?

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

PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1854079036

From jjg at openjdk.org  Wed Dec 13 16:57:43 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 13 Dec 2023 16:57:43 GMT
Subject: RFR: 8288989: Make tests not to depend on the source code
In-Reply-To: <EGnaLQCU8kFHcKQow6G5RCAIxfn-ekZU-HEtRbYe15c=.97bef4db-b7ec-41be-b4ca-495df0db7ee2@github.com>
References: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
 <EGnaLQCU8kFHcKQow6G5RCAIxfn-ekZU-HEtRbYe15c=.97bef4db-b7ec-41be-b4ca-495df0db7ee2@github.com>
Message-ID: <px_DX2IWWFk6OEr7ul6XP0wr41CvgQqTF7YZ_b_RU7c=.80d9084a-78ab-4fe9-8980-b6bbbd042cf0@github.com>

On Wed, 13 Dec 2023 15:01:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> just curious: in what conditions the tests will be executed in a source-less test environment? and in any case isn't it preferable to let the test fail so that the user knows that it failed?

Some external users execute tests in a context where the source directory is not available.  Throwing `jtreg.SkippedException` is a mild form of noticeable failure.

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

PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1854341138

From prappo at openjdk.org  Wed Dec 13 17:24:40 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 13 Dec 2023 17:24:40 GMT
Subject: RFR: 8288989: Make tests not to depend on the source code
In-Reply-To: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
References: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
Message-ID: <raXsPRtTS6yhUl1N6BaOmHtfYAkTnqTzslHraTFxqW8=.4e6c066f-d794-4431-afb6-2d84205dee97@github.com>

On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Two langtool tests depend on the JDK source tree presence. 
> This patch skips the tests execution in a source-less test environment.
> 
> Please review.
> 
> Thanks,
> Adam

Firstly, I agree with Jon on `jtreg.SkippedException`, which we also plan to use for a similar issue, JDK-8310277. Secondly, may I suggest retitling the issue so that it wouldn't mislead people into thinking that the affected tests no longer need access to source code to do useful work?

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

PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1854404680

From duke at openjdk.org  Wed Dec 13 18:21:49 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 13 Dec 2023 18:21:49 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool Processing of @File
Message-ID: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>

Better Error Handling for Jar Tool Processing of "@File" <br>

This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.

Thank you.

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

Commit messages:
 - 8318971 : Better Error Handling for Jar Tool Processing of @File

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

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

From achung at openjdk.org  Wed Dec 13 22:26:45 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 13 Dec 2023 22:26:45 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
Message-ID: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>

Translation drop for JDK22 RDP1

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

Commit messages:
 - translated files

Changes: https://git.openjdk.org/jdk/pull/17096/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17096&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322041
  Stats: 290 lines in 36 files changed: 166 ins; 15 del; 109 mod
  Patch: https://git.openjdk.org/jdk/pull/17096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17096/head:pull/17096

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

From cushon at openjdk.org  Wed Dec 13 23:02:52 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 13 Dec 2023 23:02:52 GMT
Subject: RFR: 8322040: Missing array bounds check in ClassReader.parameter
Message-ID: <j1pLAalQjb6He4W3RyxwH3aQcpGS1Qd1wE5xNdIllnE=.d79cf96b-e967-4a73-8154-23a234a7bf8d@github.com>

Hello,

Please consider this fix which adds a missing array bounds check in `ClassReader.parameter`.

I found this while investigating the crash described in [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040).

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

Commit messages:
 - 8322040: Missing array bounds check in ClassReader.parameter

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

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

From vdyakov at openjdk.org  Wed Dec 13 23:25:37 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Wed, 13 Dec 2023 23:25:37 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <0oGMQEYflrpIHgrQQ60XHXx1jR1fEbqjmZZAD4B8YXk=.dc1a7f14-1d24-4f8d-8471-6846e65863df@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

@alexeysemenyukoracle please review jpackage part

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

PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1854847266

From achung at openjdk.org  Wed Dec 13 23:34:37 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 13 Dec 2023 23:34:37 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <03lwg8mSWD_UyU_XMYspZO9EzplluKXuLnsIYbtVCw8=.99fca7b7-98d3-4643-be9c-01983a3b2772@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

@JoeWang-Java can u review the xml changes?

@jonathan-gibbons can u review the compiler changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1854853944
PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1854854368

From almatvee at openjdk.org  Thu Dec 14 00:39:39 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 14 Dec 2023 00:39:39 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <vaylowtWRfhbYxAQD5dvyZLrtomUTsW3v5IcUjnULRE=.d2a5e01d-b2e8-49e0-b9b5-b79bcea89603@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

jpackage part looks fine.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1780705685

From dholmes at openjdk.org  Thu Dec 14 05:51:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 05:51:45 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
Message-ID: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>

Updated the version to 23-ea and year to 2024.

This initial generation also picks up the unpublished changes from:

- [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
- [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
- [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc)


In addition this includes the updates for

- [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23

Thanks

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

Commit messages:
 - 8322065: Initial nroff manpage generation for JDK 23
 - 8309981: Remove expired flags in JDK 23

Changes: https://git.openjdk.org/jdk/pull/17101/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322065
  Stats: 216 lines in 29 files changed: 47 ins; 61 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/17101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17101/head:pull/17101

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

From alanb at openjdk.org  Thu Dec 14 09:03:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Dec 2023 09:03:38 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
Message-ID: <TXQNeaff7Jd_CyhpTkq-o_TBH27cU01p8G0Thq7E5F0=.46bddd4a-9baa-4d4e-ad01-0f48b4d836e1@github.com>

On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 
> - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
> - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
> - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc)
> 
> 
> In addition this includes the updates for
> 
> - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23
> 
> Thanks

Initially I wondered if JDK-8309981 should be separated but include keeps things in sync so I think okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17101#pullrequestreview-1781343785

From prappo at openjdk.org  Thu Dec 14 09:19:37 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 14 Dec 2023 09:19:37 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
Message-ID: <wc-9qyyMKcPQDfB2BQmDNHfSXFlPo1-X7RlNVr3BoA8=.5771d53d-9553-4747-99a7-e51f1a22260d@github.com>

On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 
> - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
> - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
> - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc)
> 
> 
> In addition this includes the updates for
> 
> - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23
> 
> Thanks

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 

> * [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc)

Thanks for doing this, David. I only note that the changes for JDK-8321384 were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), which was integrated in the mainline before JDK 22 RDP 1. So they are already present in the mainline.

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

PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855467435

From abimpoudis at openjdk.org  Thu Dec 14 11:04:09 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 14 Dec 2023 11:04:09 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v38]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <3JvLQvkIPnCIy1JtnD6hKyVg2GvDUDvUqog8R7gbGJc=.21d55c1c-1476-4eea-8720-5424eda66678@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

 - Merge branch 'master' into primitive-patterns
 - Cleanup
 - Merge branch 'master' into primitive-patterns
 - Remove trailing spaces
 - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns
 - Fixed switch in the cases of unboxing and widening
 - Merge branch 'JDK-8319220' into primitive-patterns
 - Merge branch 'master' into JDK-8319220
 - reflecting review comment: fixing letter case.
 - Reflecting review feedback.
 - ... and 44 more: https://git.openjdk.org/jdk/compare/d2ba3b1e...a03fea7c

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

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=37
  Stats: 3248 lines in 41 files changed: 2985 ins; 110 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

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

From mcimadamore at openjdk.org  Thu Dec 14 11:07:38 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Dec 2023 11:07:38 GMT
Subject: RFR: 8288989: Make tests not to depend on the source code
In-Reply-To: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
References: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
Message-ID: <WGi1LD_PlJJyHV6e1rQ-ypoHJFSy4LAFLWR9sPsnZDs=.7fcf74df-55c4-45c8-8a18-5a215b906e17@github.com>

On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Two langtool tests depend on the JDK source tree presence. 
> This patch skips the tests execution in a source-less test environment.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16470#pullrequestreview-1781575868

From cstein at openjdk.org  Thu Dec 14 11:26:39 2023
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 14 Dec 2023 11:26:39 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <y2kS17FHng7x9R8XzK_l2IeOTUw3f3AhjgEfKUqw-EY=.5a963a5a-4188-449e-be61-387e2f03badb@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

Marked as reviewed by cstein (Committer).

German translations read OK.

Nit: some layouts get lost in translated files - it would be great to have similar usage of `\n` and `` in the translated files.

For example, the English file `src/java.base/share/classes/sun/launcher/resources/launcher.properties` has good (easy to compare) layout:

java.launcher.opt.header  =   Usage: {0} [options] <mainclass> [args...]\n\
\           (to execute a class)\n\
\   or  {0} [options] -jar <jarfile> [args...]\n\
\           (to execute a jar file)\n\
\   or  {0} [options] -m <module>[/<mainclass>] [args...]\n\
\       {0} [options] --module <module>[/<mainclass>] [args...]\n\
\           (to execute the main class in a module)\n\
\   or  {0} [options] <sourcefile> [args]\n\
\           (to execute a source-file program)\n\n\
[...]

The German translation in `src/java.base/share/classes/sun/launcher/resources/launcher_de.properties` uses only a single line in its properties file:

java.launcher.opt.header  =   Verwendung: {0} [Optionen] <Hauptklasse> [args...]\n           (zur Ausf?hrung einer Klasse)\n   oder  {0} [Optionen] -jar <JAR-Datei> [args...]\n           (zur Ausf?hrung einer JAR-Datei)\n   oder  {0} [Optionen] -m <Modul>[/<Hauptklasse>] [args...]\n       {0} [Optionen] --module <Modul>[/<Hauptklasse>] [args...]\n            (zur Ausf?hrung der Hauptklasse in einem Modul)\n   oder  {0} [Optionen] <Quelldatei> [args]\n           (zur Ausf?hrung eines Programms mit einer Quelldatei)\n\n[...]

Changes in the latter are not easy to spot and review.

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

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1781603832
PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1855667603

From asotona at openjdk.org  Thu Dec 14 11:39:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Dec 2023 11:39:49 GMT
Subject: RFR: 8288989: Make tests not depend on the source code
In-Reply-To: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
References: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
Message-ID: <Um7IJNawcATClrKMGXb5-Ew5IeMQGME_glFRgg5uigA=.3ce60ac3-7daa-4afe-89fd-2443fc3dbe41@github.com>

On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Two langtool tests depend on the JDK source tree presence. 
> This patch skips the tests execution in a source-less test environment.
> 
> Please review.
> 
> Thanks,
> Adam

retitled as suggested

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

PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1855685435

From asotona at openjdk.org  Thu Dec 14 11:39:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Dec 2023 11:39:51 GMT
Subject: Integrated: 8288989: Make tests not depend on the source code
In-Reply-To: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
References: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
Message-ID: <ahvkjFlG1xNM9hBwVZzvZjE8Vv_eBnp3ot1nBkplm2Y=.db39fadc-d42c-4200-9885-9cc631fedd98@github.com>

On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Two langtool tests depend on the JDK source tree presence. 
> This patch skips the tests execution in a source-less test environment.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 2838a916
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2838a916ab98cb0152f8b1e3f96eccca198af5e9
Stats:     11 lines in 2 files changed: 8 ins; 0 del; 3 mod

8288989: Make tests not depend on the source code

Reviewed-by: mcimadamore

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

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

From asotona at openjdk.org  Thu Dec 14 11:45:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Dec 2023 11:45:48 GMT
Subject: RFR: 8288989: Make tests not depend on the source code
In-Reply-To: <px_DX2IWWFk6OEr7ul6XP0wr41CvgQqTF7YZ_b_RU7c=.80d9084a-78ab-4fe9-8980-b6bbbd042cf0@github.com>
References: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
 <EGnaLQCU8kFHcKQow6G5RCAIxfn-ekZU-HEtRbYe15c=.97bef4db-b7ec-41be-b4ca-495df0db7ee2@github.com>
 <px_DX2IWWFk6OEr7ul6XP0wr41CvgQqTF7YZ_b_RU7c=.80d9084a-78ab-4fe9-8980-b6bbbd042cf0@github.com>
Message-ID: <DT-jKjF0IKU7IpQ4e5E6WyYq6bFluXhA1h6CzkjVaZg=.4062e265-c361-43ea-9836-e23e48931f23@github.com>

On Wed, 13 Dec 2023 16:54:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> > just curious: in what conditions the tests will be executed in a source-less test environment? and in any case isn't it preferable to let the test fail so that the user knows that it failed?
> 
> Some external users execute tests in a context where the source directory is not available. Throwing `jtreg.SkippedException` is a mild form of noticeable failure.

I don't have an access to any environment to test it, so I prefer the same solution as already applied in several similar situations across the JDK tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1855694559

From asotona at openjdk.org  Thu Dec 14 11:57:15 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Dec 2023 11:57:15 GMT
Subject: [jdk22] RFR: 8288989: Make tests not depend on the source code
Message-ID: <wO9J-09LSt_Y5E-k61I-y5yV8YM66zkhdXAumfKFpF4=.5ee5a321-e91d-4371-9322-97f6bf8b3236@github.com>

8288989: Make tests not depend on the source code

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

Commit messages:
 - Backport 2838a916ab98cb0152f8b1e3f96eccca198af5e9

Changes: https://git.openjdk.org/jdk22/pull/13/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=13&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288989
  Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk22/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/13/head:pull/13

PR: https://git.openjdk.org/jdk22/pull/13

From dholmes at openjdk.org  Thu Dec 14 12:26:40 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 12:26:40 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <wc-9qyyMKcPQDfB2BQmDNHfSXFlPo1-X7RlNVr3BoA8=.5771d53d-9553-4747-99a7-e51f1a22260d@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
 <wc-9qyyMKcPQDfB2BQmDNHfSXFlPo1-X7RlNVr3BoA8=.5771d53d-9553-4747-99a7-e51f1a22260d@github.com>
Message-ID: <KGeNu7eyXiV1Xdi4G3O5pRd8-wLGYRLHLnvSOl0RJBk=.4cb49fb9-01f0-46c2-846d-be194ab1abaa@github.com>

On Thu, 14 Dec 2023 09:17:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Thanks for doing this, David. I only note that the changes for JDK-8321384 were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), which was integrated in the mainline before JDK 22 RDP 1. So they are already present in the mainline.

Ah I see. Thanks for correcting that, I will update the PR and JBS issue.

And thanks for looking at this @pavelrappo .

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

PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855755042

From dholmes at openjdk.org  Thu Dec 14 12:30:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 12:30:38 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <TXQNeaff7Jd_CyhpTkq-o_TBH27cU01p8G0Thq7E5F0=.46bddd4a-9baa-4d4e-ad01-0f48b4d836e1@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
 <TXQNeaff7Jd_CyhpTkq-o_TBH27cU01p8G0Thq7E5F0=.46bddd4a-9baa-4d4e-ad01-0f48b4d836e1@github.com>
Message-ID: <mVw4r96UaGCiseQ8hJip4ForRXp8x4LSA6nx7lELxNo=.fc11214c-7229-4f2e-9667-0bcf42b26751@github.com>

On Thu, 14 Dec 2023 09:01:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Initially I wondered if JDK-8309981 should be separated but include keeps things in sync so I think okay.

Thanks for the review @AlanBateman .

Yeah I was in two minds there myself. I started fixing [JDK-8309981](https://bugs.openjdk.org/browse/JDK-8309981) only to discover that the start of release updates had not been done as part of the start of release, so I figured I may as well fix it all together given I'd generated all the updated files anyway. But I'm still a little unsure ... in fact I think I will remove it in the morning.

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

PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855761906

From dholmes at openjdk.org  Thu Dec 14 12:35:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 12:35:52 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 [v2]
In-Reply-To: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
Message-ID: <cLrnXzE4mmuGODVy7DfA7Zzq1ot2aquVTBG9PPGPwJQ=.e0f4b2b4-d567-462b-9ecd-5be70e461aa6@github.com>

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 
> - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
> - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Revert "8309981: Remove expired flags in JDK 23"
  
  This reverts commit 0324a90e936ae01e42ae099e7235156326cc318a.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17101/files
  - new: https://git.openjdk.org/jdk/pull/17101/files/65a8c9ed..8b052141

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

  Stats: 23 lines in 2 files changed: 10 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17101/head:pull/17101

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

From jjg at openjdk.org  Thu Dec 14 16:49:48 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 14 Dec 2023 16:49:48 GMT
Subject: RFR: 8288989: Make tests not depend on the source code
In-Reply-To: <DT-jKjF0IKU7IpQ4e5E6WyYq6bFluXhA1h6CzkjVaZg=.4062e265-c361-43ea-9836-e23e48931f23@github.com>
References: <tZmNkxjWU_fJGsj_yetUUiC2BT0Tffs7n8xtZA6I8po=.3c1d99d5-ba7f-4a34-82d3-a28265ae632a@github.com>
 <EGnaLQCU8kFHcKQow6G5RCAIxfn-ekZU-HEtRbYe15c=.97bef4db-b7ec-41be-b4ca-495df0db7ee2@github.com>
 <px_DX2IWWFk6OEr7ul6XP0wr41CvgQqTF7YZ_b_RU7c=.80d9084a-78ab-4fe9-8980-b6bbbd042cf0@github.com>
 <DT-jKjF0IKU7IpQ4e5E6WyYq6bFluXhA1h6CzkjVaZg=.4062e265-c361-43ea-9836-e23e48931f23@github.com>
Message-ID: <kpWNt-sKbxS_PkmfiDj0rsCQNuhM7-B17uZbMEvQwqM=.45000be4-f08d-43ab-bf5a-c75c65ff71e3@github.com>

On Thu, 14 Dec 2023 11:42:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> I don't have an access to any environment to test it, so I prefer the same solution as already applied in several similar situations across the JDK tests.

If you really wanted, you could test it locally, running `jtreg` directly (not through `make test`) and temporarily rename the `src` directory to something else, for the duration of your test run.

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

PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1856192601

From joehw at openjdk.org  Thu Dec 14 19:04:41 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 14 Dec 2023 19:04:41 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <dsMlRFjnSPD-o6ihRbzbBI93HYkNtbUONmZPxew9DfM=.3fbc999c-ec8e-454a-92f3-41ee4adbfb2a@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 331:

> 329: 
> 330: # Implementation Property DTD
> 331:         JDK_DTD_DENY = JAXP00010008: DOCTYPE ist nicht zul?ssig, wenn die DTD-Eigenschaft auf "Ablehnen" gesetzt wurde. Weitere Informationen: Eigenschaft jdk.xml.dtd.support in java.xml/module-summary.

This version quoted "Ablehnen" while the other two (ja - "??" and zh_CN - "??") didn't. If we want to be consistent, "deny" would be better since that's the literal value. The English version should have quoted "deny".

The previous translations in these files have not been consistent. Some of the key words were translated. If we want to keep this translation as is, it's probably better to remove the quote in the "de" file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427152545

From naoto at openjdk.org  Thu Dec 14 19:25:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Dec 2023 19:25:41 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <L7ojiF0-qtrRJ6kgXJuFd3aHcUafKYpaQTMEc3hKnwg=.60825019-a8b5-4ff6-a74c-94bb7005bced@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties line 111:

> 109: doclet.Factory=?????:
> 110: doclet.UnknownTag=??????????????????
> 111: doclet.UnknownTagWithHint=?????????????@{0}???????????????

Simply appending a question mark may read a bit odd, although it is a straightforward translation from English.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties line 88:

> 86: dc.tag.start.unmatched = ??????????: </{0}>
> 87: dc.unknown.javadoc.tag = ??????????????????
> 88: dc.unknown.javadoc.tag.with.hint = ?????????????@{0}???????????????

same here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427170568
PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427171135

From jlu at openjdk.org  Thu Dec 14 19:46:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 14 Dec 2023 19:46:41 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <H5RoLt8IbybQX6PGHDO1nCQMyPO_UpftllwuKLp20E8=.21c243f7-03bf-4667-ba18-d0751fa15b1a@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

All around LGTM. From a skim I don't see any of the typical l10n related file mode issues, line ending issues, or values that should not be changed (like _WixLocalization Culture_). Might be worth filing a bug against the translation tool to see if it could support multi line translations for localized versions as @sormuras pointed out.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 2293:

> 2291: compiler.err.underscore.as.identifier=Ab Release 9 ist "_" ein Schl?sselwort und kann nicht als ID verwendet werden
> 2292: 
> 2293: compiler.err.use.of.underscore.not.allowed=Unterstrich ist hier nicht zul?ssig\nAb Release 9 ist ''_'' ein Schl?sselwort und kann nicht als ID verwendet werden\nAb Release 22 kann ''_'' als Name in der Deklaration unbenannter Muster, lokaler Variablen, Ausnahmeparameter oder Lambda-Parameter verwendet werden

Just an observation, but the double quotes were converted to (two) single quotes. Previously, localized de files represented '' '' as " ", as different languages have different l10n rules (according to the translation contact). And this is seen with the other values on this file using "" instead of '' ''.

But here it looks like they updated the value to match the quotes in of the value in the original .properties files. Not sure if they updated the rules and this is intentional, or unintentional.

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

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1782404582
PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427080553

From asemenyuk at openjdk.org  Thu Dec 14 20:40:44 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 14 Dec 2023 20:40:44 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <1b8hGFdrVVjDalOWt2pkTGQ_jmudlYiXAeptlQfmbZM=.a08ed560-9472-4a75-ae4d-afab8e93799c@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good

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

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1782697421
PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1856551939

From dholmes at openjdk.org  Thu Dec 14 21:28:47 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 21:28:47 GMT
Subject: Integrated: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
Message-ID: <PburUtgTlWWQUu8FrbTb5opRR6eanF3CGgdcCPJ6sEw=.d9807c9b-f763-4f69-8327-d5e3feb0877d@github.com>

On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 
> - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
> - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
> 
> Thanks

This pull request has now been integrated.

Changeset: 692be577
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/692be577385844bf00a01ff10e390e014191569f
Stats:     193 lines in 27 files changed: 36 ins; 51 del; 106 mod

8322065: Initial nroff manpage generation for JDK 23

Reviewed-by: alanb

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

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

From achung at openjdk.org  Thu Dec 14 22:01:40 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 14 Dec 2023 22:01:40 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <KURZGxIoW_SgiStcTHzOW8IqokPAPVIYJb7MTvzFWuM=.c274f868-2473-459b-bd3e-290d5fb51324@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

mach5 looks green

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

PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1856733375

From achung at openjdk.org  Thu Dec 14 22:17:54 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 14 Dec 2023 22:17:54 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2]
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>

> Translation drop for JDK22 RDP1

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed quotes around Ablehnen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17096/files
  - new: https://git.openjdk.org/jdk/pull/17096/files/3c8e871d..0e964a06

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

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

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

From achung at openjdk.org  Fri Dec 15 00:11:46 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 15 Dec 2023 00:11:46 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2]
In-Reply-To: <dsMlRFjnSPD-o6ihRbzbBI93HYkNtbUONmZPxew9DfM=.3fbc999c-ec8e-454a-92f3-41ee4adbfb2a@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
 <dsMlRFjnSPD-o6ihRbzbBI93HYkNtbUONmZPxew9DfM=.3fbc999c-ec8e-454a-92f3-41ee4adbfb2a@github.com>
Message-ID: <k3S_M-N-0pmpxnPUpba28kfX9zKVGiZdVkDJdyMOsiM=.e6ceb77e-3fb8-4243-9435-50bf9e306243@github.com>

On Thu, 14 Dec 2023 19:01:22 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed quotes around Ablehnen
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 331:
> 
>> 329: 
>> 330: # Implementation Property DTD
>> 331:         JDK_DTD_DENY = JAXP00010008: DOCTYPE ist nicht zul?ssig, wenn die DTD-Eigenschaft auf "Ablehnen" gesetzt wurde. Weitere Informationen: Eigenschaft jdk.xml.dtd.support in java.xml/module-summary.
> 
> This version quoted "Ablehnen" while the other two (ja - "??" and zh_CN - "??") didn't. If we want to be consistent, "deny" would be better since that's the literal value. The English version should have quoted "deny".
> 
> The previous translations in these files have not been consistent. Some of the key words were translated. If we want to keep this translation as is, it's probably better to remove the quote in the "de" file.

removed quotes around Ablehnen

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427423629

From vromero at openjdk.org  Fri Dec 15 02:53:38 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Dec 2023 02:53:38 GMT
Subject: RFR: 8322040: Missing array bounds check in ClassReader.parameter
In-Reply-To: <j1pLAalQjb6He4W3RyxwH3aQcpGS1Qd1wE5xNdIllnE=.d79cf96b-e967-4a73-8154-23a234a7bf8d@github.com>
References: <j1pLAalQjb6He4W3RyxwH3aQcpGS1Qd1wE5xNdIllnE=.d79cf96b-e967-4a73-8154-23a234a7bf8d@github.com>
Message-ID: <Th3KNqlpy06p1xhvg2Pmpoew3pYDT6YGk7-1AnDU-x8=.15baa3c8-c7fa-4424-a51f-6889b94ca564@github.com>

On Wed, 13 Dec 2023 22:57:04 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hello,
> 
> Please consider this fix which adds a missing array bounds check in `ClassReader.parameter`.
> 
> I found this while investigating the crash described in [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040).

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17097#pullrequestreview-1783049320

From joehw at openjdk.org  Fri Dec 15 05:26:41 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 15 Dec 2023 05:26:41 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2]
In-Reply-To: <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
 <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>
Message-ID: <z8aKUf41rLHle3HwH5xn7EiUtS_iKARKC6S_zujxzAQ=.657eb893-0fa3-4aca-9393-a47e6f0fcc1c@github.com>

On Thu, 14 Dec 2023 22:17:54 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Translation drop for JDK22 RDP1
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed quotes around Ablehnen

The java.xml changes look good.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1783142189

From jlahoda at openjdk.org  Fri Dec 15 08:16:59 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 15 Dec 2023 08:16:59 GMT
Subject: RFR: 8322159: ThisEscapeAnalyzer crashes for erroneous code
Message-ID: <jst9pel7lJIEd8c8-v5hnw5KwPN65_Vutrfim0xD7VM=.1a2d0f6d-26e2-4168-a167-1bc3a402f9e1@github.com>

When an unresolvable method is used in the code, the model is a bit strange (and not very easy to fix) - for method invocations, the symbol used is actually a `ClassSymbol` instead of `MethodSymbol`, and method references have fields like `kind` unfilled.

This is causing issues in ThisEscapeAnalyzer when there were unresolvable methods, and the analyzer is called (i.e. in practice when running with `-Xlint:this-escape -XDshould-stop.at=FLOW`, or similar):
 - `visitApply` has a hardcoded cast to `MethodSymbol`. Seems the case in not really necessary, so the proposal is to remove it.
 - `visitReference` crashes on an access to `JCMemberReference.kind`, as it is unfilled. The proposal is to skip the check if the method reference's type is errneous.

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

Commit messages:
 - 8322159: ThisEscapeAnalyzer crashes for erroneous code

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

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

From antoine.dessaigne at gmail.com  Fri Dec 15 10:12:15 2023
From: antoine.dessaigne at gmail.com (Antoine DESSAIGNE)
Date: Fri, 15 Dec 2023 11:12:15 +0100
Subject: Invalid code generated by C2 compiler in OpenJDK 21
Message-ID: <CAFkOUcXCXQ+jQkAPJOA5DSph5ces9z4U4-W0B8LZ=0Z4DMPw+Q@mail.gmail.com>

Hello everyone,

I've found an issue while migrating to OpenJDK 21. A valued local variable
(effectively final) has its value removed and it throws a
NullPointerException. Unfortunately, I cannot provide the source code and
the data to reproduce the issue, and I couldn't create a smaller code
snippet to show the issue. That said, I'll happily show the code and
perform many tests during calls.

Here's what I did so far to diagnose the issue.

I bisected the repository to find where the regression comes from. I found
this commit 3696711efa5 [1] but it's a merge so I bisected the branch and
found 10737e168c9 [2]. Looking at this commit, I have no idea how it could
introduce this kind of regression.

Then, thanks to the guidance from Aleksey Shipil?v, I tested many things
* Issue does *not* happen with the following
flags: -Xint, -XX:-TieredCompilation, -XX:TieredStopAtLevel=1,
-XX:TieredStopAtLevel=2, -XX:TieredStopAtLevel=3
* Issue also happens with fastdebug builds of OpenJDK, without crashing due
to assertions
* Issue still happens in the latest version of the code (commit b31454e3623)
* Issue happens no matter which GC is used, I tried SerialGC, ParallelGC,
G1GC, and ShenandoahGC

The tests were performed in Docker containers running on 4 different hosts.

Therefore it looks like C2 is generating an invalid assembly code.
Unfortunately, I'm not great with assembly and the generated assembly is
quite big (main code is around 20k).

Do you have an idea of why this is happening? Do you know what test I can
run? If one of you is available, we can schedule calls for me to show you
the code and my tests. Thank you very much for your assistance.

Have a nice day,

Antoine DESSAIGNE

[1]
https://github.com/openjdk/jdk/commit/3696711efa566fb776d6923da86e17b0e1e22964
[2]
https://github.com/openjdk/jdk/commit/10737e168c967a08e257927251861bf2c14795ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231215/c4ade287/attachment-0001.htm>

From cushon at openjdk.org  Fri Dec 15 10:19:51 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 15 Dec 2023 10:19:51 GMT
Subject: Integrated: 8322040: Missing array bounds check in
 ClassReader.parameter
In-Reply-To: <j1pLAalQjb6He4W3RyxwH3aQcpGS1Qd1wE5xNdIllnE=.d79cf96b-e967-4a73-8154-23a234a7bf8d@github.com>
References: <j1pLAalQjb6He4W3RyxwH3aQcpGS1Qd1wE5xNdIllnE=.d79cf96b-e967-4a73-8154-23a234a7bf8d@github.com>
Message-ID: <IeBZPbi76HHi0DQhLO1gn7DYWak1y0TDA_7UDiNmYXY=.43ed60bf-1501-4b00-b2e9-d102aa0ae4a8@github.com>

On Wed, 13 Dec 2023 22:57:04 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hello,
> 
> Please consider this fix which adds a missing array bounds check in `ClassReader.parameter`.
> 
> I found this while investigating the crash described in [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040).

This pull request has now been integrated.

Changeset: 20de541b
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20de541b1304b4dc3a385f8a78f1215da237e4aa
Stats:     154 lines in 2 files changed: 153 ins; 0 del; 1 mod

8322040: Missing array bounds check in ClassReader.parameter

Reviewed-by: vromero

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

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

From alanb at openjdk.org  Fri Dec 15 11:23:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Dec 2023 11:23:49 GMT
Subject: RFR: 8322040: Missing array bounds check in ClassReader.parameter
In-Reply-To: <j1pLAalQjb6He4W3RyxwH3aQcpGS1Qd1wE5xNdIllnE=.d79cf96b-e967-4a73-8154-23a234a7bf8d@github.com>
References: <j1pLAalQjb6He4W3RyxwH3aQcpGS1Qd1wE5xNdIllnE=.d79cf96b-e967-4a73-8154-23a234a7bf8d@github.com>
Message-ID: <jSnq0mwXZwUPuT-KOrCKdaCsS1Qszd2bFcQJgwmpKVo=.0ba49bd4-b1b9-4c74-ba58-7f435c7eec1f@github.com>

On Wed, 13 Dec 2023 22:57:04 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hello,
> 
> Please consider this fix which adds a missing array bounds check in `ClassReader.parameter`.
> 
> I found this while investigating the crash described in [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040).

test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile

<dir>/test/langtools/tools/javac/classreader/BadMethodParameter.java:38: error: package jdk.internal.classfile does not exist
import jdk.internal.classfile.ClassModel;

Maybe it was created before the class file API before a preview API? In any case it is failing in tier1 now, needs to be fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17097#issuecomment-1857714054

From cushon at openjdk.org  Fri Dec 15 11:30:51 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 15 Dec 2023 11:30:51 GMT
Subject: RFR: 8322040: Missing array bounds check in ClassReader.parameter
In-Reply-To: <jSnq0mwXZwUPuT-KOrCKdaCsS1Qszd2bFcQJgwmpKVo=.0ba49bd4-b1b9-4c74-ba58-7f435c7eec1f@github.com>
References: <j1pLAalQjb6He4W3RyxwH3aQcpGS1Qd1wE5xNdIllnE=.d79cf96b-e967-4a73-8154-23a234a7bf8d@github.com>
 <jSnq0mwXZwUPuT-KOrCKdaCsS1Qszd2bFcQJgwmpKVo=.0ba49bd4-b1b9-4c74-ba58-7f435c7eec1f@github.com>
Message-ID: <t104rfDymbGoleOh-NMmoKC1idWdxYIyVqNt-AXEHVk=.3e6ebfb2-65a9-41f7-808a-d0515ee6c5f6@github.com>

On Fri, 15 Dec 2023 11:21:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Maybe it was created before the class file API before a preview API?

I think that is what happened, I had failed to notice this branch was stale. Sorry for the mistake!

I am preparing a fix: https://bugs.openjdk.org/browse/JDK-8322175

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

PR Comment: https://git.openjdk.org/jdk/pull/17097#issuecomment-1857723838

From cushon at openjdk.org  Fri Dec 15 12:04:46 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 15 Dec 2023 12:04:46 GMT
Subject: RFR: 8322175:
 test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile
Message-ID: <HMYvtuMlYyL4pwYR4tdiKntvp57mtYnsbXi2mRfgoIg=.4ab11592-a172-44ea-a7f4-909198372f84@github.com>

Hello, please consider this fix for a compilation error in a test introduced by [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040).

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

Commit messages:
 - Fix trailing whitespace
 - 8322175: test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile

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

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

From jlahoda at openjdk.org  Fri Dec 15 12:16:37 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 15 Dec 2023 12:16:37 GMT
Subject: RFR: 8322175:
 test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile
In-Reply-To: <HMYvtuMlYyL4pwYR4tdiKntvp57mtYnsbXi2mRfgoIg=.4ab11592-a172-44ea-a7f4-909198372f84@github.com>
References: <HMYvtuMlYyL4pwYR4tdiKntvp57mtYnsbXi2mRfgoIg=.4ab11592-a172-44ea-a7f4-909198372f84@github.com>
Message-ID: <WtjmG8Bw_3QUSuFSTn-oNLXt73ysEl3-7BAdvP8Qzis=.bc61aa78-0445-42ff-a593-242fdb7ee5ae@github.com>

On Fri, 15 Dec 2023 11:51:48 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hello, please consider this fix for a compilation error in a test introduced by [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040).

Looks good to me!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17120#pullrequestreview-1783798942

From alanb at openjdk.org  Fri Dec 15 12:20:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Dec 2023 12:20:49 GMT
Subject: RFR: 8322175:
 test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile
In-Reply-To: <HMYvtuMlYyL4pwYR4tdiKntvp57mtYnsbXi2mRfgoIg=.4ab11592-a172-44ea-a7f4-909198372f84@github.com>
References: <HMYvtuMlYyL4pwYR4tdiKntvp57mtYnsbXi2mRfgoIg=.4ab11592-a172-44ea-a7f4-909198372f84@github.com>
Message-ID: <egaY38kpWxjvy-KLfvSvTS9jm7mE6KHo08laYEh_dA4=.22b0ef61-5885-4c8e-b6c3-af99c15f5176@github.com>

On Fri, 15 Dec 2023 11:51:48 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hello, please consider this fix for a compilation error in a test introduced by [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040).

Thanks for jumping on this.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17120#pullrequestreview-1783810434

From cushon at openjdk.org  Fri Dec 15 12:20:50 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 15 Dec 2023 12:20:50 GMT
Subject: Integrated: 8322175:
 test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile
In-Reply-To: <HMYvtuMlYyL4pwYR4tdiKntvp57mtYnsbXi2mRfgoIg=.4ab11592-a172-44ea-a7f4-909198372f84@github.com>
References: <HMYvtuMlYyL4pwYR4tdiKntvp57mtYnsbXi2mRfgoIg=.4ab11592-a172-44ea-a7f4-909198372f84@github.com>
Message-ID: <CJEPVuR7y3orBr96fFYiWXW8b8VP6st63tIr_wZXQLk=.61f77508-f16e-43fe-a46b-3dbe75c34383@github.com>

On Fri, 15 Dec 2023 11:51:48 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hello, please consider this fix for a compilation error in a test introduced by [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040).

This pull request has now been integrated.

Changeset: bdebf198
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bdebf198bb0f4c3347ae9539d02ce0476e1176ce
Stats:     12 lines in 1 file changed: 3 ins; 2 del; 7 mod

8322175: test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile

Reviewed-by: jlahoda

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

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

From acobbs at openjdk.org  Fri Dec 15 15:45:37 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 15 Dec 2023 15:45:37 GMT
Subject: RFR: 8322159: ThisEscapeAnalyzer crashes for erroneous code
In-Reply-To: <jst9pel7lJIEd8c8-v5hnw5KwPN65_Vutrfim0xD7VM=.1a2d0f6d-26e2-4168-a167-1bc3a402f9e1@github.com>
References: <jst9pel7lJIEd8c8-v5hnw5KwPN65_Vutrfim0xD7VM=.1a2d0f6d-26e2-4168-a167-1bc3a402f9e1@github.com>
Message-ID: <Ungtkb3ISpOCPp4PDuYX0mY5A_-t8QLfdKrynE6vJ8k=.b80f3cde-1727-4931-917c-6cb6ad2ca7af@github.com>

On Fri, 15 Dec 2023 08:10:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When an unresolvable method is used in the code, the model is a bit strange (and not very easy to fix) - for method invocations, the symbol used is actually a `ClassSymbol` instead of `MethodSymbol`, and method references have fields like `kind` unfilled.
> 
> This is causing issues in ThisEscapeAnalyzer when there were unresolvable methods, and the analyzer is called (i.e. in practice when running with `-Xlint:this-escape -XDshould-stop.at=FLOW`, or similar):
>  - `visitApply` has a hardcoded cast to `MethodSymbol`. Seems the case in not really necessary, so the proposal is to remove it.
>  - `visitReference` crashes on an access to `JCMemberReference.kind`, as it is unfilled. The proposal is to skip the check if the method reference's type is errneous.

Hi @lahodaj,

Looks good to me - thanks for fixing.

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

PR Comment: https://git.openjdk.org/jdk/pull/17118#issuecomment-1858083342

From vromero at openjdk.org  Fri Dec 15 16:31:37 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Dec 2023 16:31:37 GMT
Subject: RFR: 8322159: ThisEscapeAnalyzer crashes for erroneous code
In-Reply-To: <jst9pel7lJIEd8c8-v5hnw5KwPN65_Vutrfim0xD7VM=.1a2d0f6d-26e2-4168-a167-1bc3a402f9e1@github.com>
References: <jst9pel7lJIEd8c8-v5hnw5KwPN65_Vutrfim0xD7VM=.1a2d0f6d-26e2-4168-a167-1bc3a402f9e1@github.com>
Message-ID: <VAdjtJpqwPb0ZlnkzESM8EAV9Nxvdg8NNeGI5Tu4kHk=.211aa52b-2718-4662-be3f-884056a8f346@github.com>

On Fri, 15 Dec 2023 08:10:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When an unresolvable method is used in the code, the model is a bit strange (and not very easy to fix) - for method invocations, the symbol used is actually a `ClassSymbol` instead of `MethodSymbol`, and method references have fields like `kind` unfilled.
> 
> This is causing issues in ThisEscapeAnalyzer when there were unresolvable methods, and the analyzer is called (i.e. in practice when running with `-Xlint:this-escape -XDshould-stop.at=FLOW`, or similar):
>  - `visitApply` has a hardcoded cast to `MethodSymbol`. Seems the case in not really necessary, so the proposal is to remove it.
>  - `visitReference` crashes on an access to `JCMemberReference.kind`, as it is unfilled. The proposal is to skip the check if the method reference's type is errneous.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17118#pullrequestreview-1784486330

From jjg at openjdk.org  Sat Dec 16 00:30:43 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 16 Dec 2023 00:30:43 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2]
In-Reply-To: <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
 <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>
Message-ID: <vui2bQ07IKPZlxU0kxYYremw50nCWrLQg4_aLtOkqyA=.2f07249e-dc8b-4578-93ce-7c4ed32c4a1b@github.com>

On Thu, 14 Dec 2023 22:17:54 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Translation drop for JDK22 RDP1
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed quotes around Ablehnen

The diffs are more conveniently available here:
https://cr.openjdk.org/~jjg/jdk-l10n-diffs--15dec23/

The compiler and javadoc diffs look "ok" but I cannot read most other languages, and cannot comment on the quality of the translations. I do see that there are places where a translation has been edited where the English original has not. I also see issues with some of the English messages, but that is not for here. 

My "approval" is just for `jdk.compiler` and `jdk.javadoc` files.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1785076089

From achung at openjdk.org  Sat Dec 16 01:05:46 2023
From: achung at openjdk.org (Alisen Chung)
Date: Sat, 16 Dec 2023 01:05:46 GMT
Subject: Integrated: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <NFpfs0qdRUOnXNf5GJOgxCzucmZQK0fg1Vwia3ZOwKU=.281411ad-914c-471c-835a-f99a1f9e2d06@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

This pull request has now been integrated.

Changeset: b061b667
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b061b6678fde891974d5b58cec963b3481099a8d
Stats:     290 lines in 36 files changed: 166 ins; 15 del; 109 mod

8322041: JDK 22 RDP1 L10n resource files update

Reviewed-by: almatvee, cstein, asemenyuk, joehw, jjg

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

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

From alanb at openjdk.org  Sun Dec 17 09:32:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Dec 2023 09:32:36 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool Processing of
 @File
In-Reply-To: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
Message-ID: <URBh2Fx0GcLS7pRbkcThSOzfHPc6LKWufgbX1VOuBLs=.be0b4b46-daf1-4001-9099-85b9f866eee7@github.com>

On Wed, 13 Dec 2023 18:16:56 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> Better Error Handling for Jar Tool Processing of "@File" <br>
> 
> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
> 
> Thank you.

The implementation change looks okay, I think we mostly agreed that in the previous PR.

I don't have cycles to look at the test right now so I hope you can get another reviewer for the test update.

The other part to this is the man page. I chatted briefly with Ryan about this a few weeks ago as something that needs to updated (not this PR of course).

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17088#pullrequestreview-1785407802

From javalists at cbfiddle.com  Sun Dec 17 16:48:15 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 17 Dec 2023 08:48:15 -0800
Subject: a change in javac behavior
Message-ID: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com>

I?m experiencing a change in behavior compiling a particular file.

The compiler is trying to match an invocation to one of two constructors for a static class defined in the same file.

The second constructor has a parameter of type Builder. In the past, this was interpreted as my Builder class, which is imported into this file.
That matches the invocation.

Now, however, the constructor parameter type is interpreted as java.lang.Thread.Builder, presumably because the static class extends Thread.
That causes a mismatch to be reported.

This interpretation appears to be limited to the resolution of the constructor invocation. Within the constructor, I do not get an error when the parameter
is used as an instance of my Builder class.

This happens in JDK 20, JDK 21, and the latest build of JDK 22.
It does not happen in JDK 17.

The error message:

    [javac]     constructor Worker.Worker(@org.jetbrains.annotations.NotNull String, at org.jetbrains.annotations.NotNull SeverityLevel, at org.jetbrains.annotations.NotNull java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable TaskStatusListener, at org.jetbrains.annotations.NotNull SimpleTaskReceiver<BuildResult>) is not applicable
    [javac]       (argument mismatch; @org.jetbrains.annotations.NotNull com.cbfiddle.releases.Builder cannot be converted to @org.jetbrains.annotations.NotNull java.lang.Thread.Builder)


The constructor:

public Worker(@NotNull String taskName,
              @NotNull SeverityLevel level,
              @NotNull Builder builder,
              @Nullable TaskStatusListener tsl,
              @NotNull SimpleTaskReceiver<BuildResult> r)
{
    this.taskName = taskName;
    this.level = level;
    this.r = r;
    this.bl = createBuildListener(tsl);
    this.op = () -> builder.perform(bl);

    setPriority(Thread.MIN_PRIORITY);
}

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

From forax at univ-mlv.fr  Sun Dec 17 17:56:34 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 17 Dec 2023 18:56:34 +0100 (CET)
Subject: a change in javac behavior
In-Reply-To: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com>
References: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com>
Message-ID: <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr>

> From: "Alan Snyder" <javalists at cbfiddle.com>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, December 17, 2023 5:48:15 PM
> Subject: a change in javac behavior

> I?m experiencing a change in behavior compiling a particular file.
> The compiler is trying to match an invocation to one of two constructors for a
> static class defined in the same file.

> The second constructor has a parameter of type Builder. In the past, this was
> interpreted as my Builder class, which is imported into this file.
> That matches the invocation.

> Now, however, the constructor parameter type is interpreted as
> java.lang.Thread.Builder, presumably because the static class extends Thread.
> That causes a mismatch to be reported.

> This interpretation appears to be limited to the resolution of the constructor
> invocation. Within the constructor, I do not get an error when the parameter
> is used as an instance of my Builder class.

> This happens in JDK 20, JDK 21, and the latest build of JDK 22.
> It does not happen in JDK 17.

I believe this is not a behavior change, you are experiencing the "comb" behavior, where javac will first start to match members declared inside the class hierarchy before trying to match other members. 
Here is the classical example 
class Foo { 
String name; 

void setName(String name) { 
this.name = name; 
} 

public void execute() { 
new Thread() { 
public void run() { 
setName("foo"); 
} 
}.start(); 
} 
} 

where the method setName() inside execute() calls Thread.setName() instead of Foo.setName(). 

You code compiles with JDK 17 because Thread.Builder was introduced in 21 (19 as preview). 

If you want to avoid those kind of issues, prefer delegation to inheritance. 

> The error message:

> [javac] constructor Worker.Worker(@org.jetbrains.annotations.NotNull
> String, at org.jetbrains.annotations.NotNull
> SeverityLevel, at org.jetbrains.annotations.NotNull
> java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable
> TaskStatusListener, at org.jetbrains.annotations.NotNull
> SimpleTaskReceiver<BuildResult>) is not applicable
> [javac] (argument mismatch; @org.jetbrains.annotations.NotNull
> com.cbfiddle.releases.Builder cannot be converted to
> @org.jetbrains.annotations.NotNull java.lang.Thread.Builder)

> The constructor:

> public Worker ( @NotNull String taskName ,
> @NotNull SeverityLevel level ,
> @NotNull Builder builder ,
> @Nullable TaskStatusListener tsl ,
> @NotNull SimpleTaskReceiver < BuildResult > r )
> {
> this . taskName = taskName ;
> this . level = level ;
> this . r = r ;
> this . bl = createBuildListener( tsl ) ;
> this . op = () -> builder .perform( bl ) ;

> setPriority( Thread . MIN_PRIORITY ) ;
> }

regards, 
R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231217/01b5e94a/attachment.htm>

From javalists at cbfiddle.com  Sun Dec 17 20:03:14 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 17 Dec 2023 12:03:14 -0800
Subject: a change in javac behavior
In-Reply-To: <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr>
References: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com>
 <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <502E2D50-61B8-4677-A2AF-F9FD6A199716@cbfiddle.com>

So, that is how things are supposed to work?

Also, can you explain why javac does not complain about the builder.perform() invocation?
That variable is declared using the disputed parameter declaration.
If the parameter type is taken to be Thread.Builder, the call to perform should be rejected.


> On Dec 17, 2023, at 9:56?AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 
> 
> From: "Alan Snyder" <javalists at cbfiddle.com>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, December 17, 2023 5:48:15 PM
> Subject: a change in javac behavior
> I?m experiencing a change in behavior compiling a particular file.
> The compiler is trying to match an invocation to one of two constructors for a static class defined in the same file.
> 
> The second constructor has a parameter of type Builder. In the past, this was interpreted as my Builder class, which is imported into this file.
> That matches the invocation.
> 
> Now, however, the constructor parameter type is interpreted as java.lang.Thread.Builder, presumably because the static class extends Thread.
> That causes a mismatch to be reported.
> 
> This interpretation appears to be limited to the resolution of the constructor invocation. Within the constructor, I do not get an error when the parameter
> is used as an instance of my Builder class.
> 
> This happens in JDK 20, JDK 21, and the latest build of JDK 22.
> It does not happen in JDK 17.
> 
> I believe this is not a behavior change, you are experiencing the "comb" behavior, where javac will first start to match members declared inside the class hierarchy before trying to match other members.
> Here is the classical example
> class Foo {
>   String name;
> 
>   void setName(String name) {
>     this.name = name;
>   }
> 
>   public void execute() {
>     new Thread() {
>       public void run() {
>         setName("foo");
>       }
>     }.start();
>   } 
> }
> 
> where the method setName() inside execute() calls Thread.setName() instead of Foo.setName().
> 
> You code compiles with JDK 17 because Thread.Builder was introduced in 21 (19 as preview).
> 
> If you want to avoid those kind of issues, prefer delegation to inheritance.
> 
> 
> The error message:
> 
>     [javac]     constructor Worker.Worker(@org.jetbrains.annotations.NotNull String, at org.jetbrains.annotations.NotNull SeverityLevel, at org.jetbrains.annotations.NotNull java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable TaskStatusListener, at org.jetbrains.annotations.NotNull SimpleTaskReceiver<BuildResult>) is not applicable
>     [javac]       (argument mismatch; @org.jetbrains.annotations.NotNull com.cbfiddle.releases.Builder cannot be converted to @org.jetbrains.annotations.NotNull java.lang.Thread.Builder)
> 
> 
> The constructor:
> 
> public Worker(@NotNull String taskName,
> @NotNull SeverityLevel level,
> @NotNull Builder builder,
> @Nullable TaskStatusListener tsl,
> @NotNull SimpleTaskReceiver<BuildResult> r)
> {
>     this.taskName = taskName;
> this.level = level;
> this.r = r;
> this.bl = createBuildListener(tsl);
> this.op = () -> builder.perform(bl);
> 
> setPriority(Thread.MIN_PRIORITY);
> }
> 
> regards,
> R?mi
> 

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

From forax at univ-mlv.fr  Mon Dec 18 06:39:45 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 18 Dec 2023 07:39:45 +0100 (CET)
Subject: a change in javac behavior
In-Reply-To: <502E2D50-61B8-4677-A2AF-F9FD6A199716@cbfiddle.com>
References: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com>
 <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr>
 <502E2D50-61B8-4677-A2AF-F9FD6A199716@cbfiddle.com>
Message-ID: <867073994.84357316.1702881585077.JavaMail.zimbra@univ-eiffel.fr>

> From: "Alan Snyder" <javalists at cbfiddle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, December 17, 2023 9:03:14 PM
> Subject: Re: a change in javac behavior

> So, that is how things are supposed to work?

Yes, 

> Also, can you explain why javac does not complain about the builder.perform()
> invocation?
> That variable is declared using the disputed parameter declaration.
> If the parameter type is taken to be Thread.Builder, the call to perform should
> be rejected.

Hard to say without the whole code but if your original error comes from the same file, it may mask the error at builder.perform(), javac does several passes on the same code. 

regards, 
R?mi 

>> On Dec 17, 2023, at 9:56 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>>> From: "Alan Snyder" <javalists at cbfiddle.com>
>>> To: "compiler-dev" <compiler-dev at openjdk.org>
>>> Sent: Sunday, December 17, 2023 5:48:15 PM
>>> Subject: a change in javac behavior

>>> I?m experiencing a change in behavior compiling a particular file.
>>> The compiler is trying to match an invocation to one of two constructors for a
>>> static class defined in the same file.

>>> The second constructor has a parameter of type Builder. In the past, this was
>>> interpreted as my Builder class, which is imported into this file.
>>> That matches the invocation.

>>> Now, however, the constructor parameter type is interpreted as
>>> java.lang.Thread.Builder, presumably because the static class extends Thread.
>>> That causes a mismatch to be reported.

>>> This interpretation appears to be limited to the resolution of the constructor
>>> invocation. Within the constructor, I do not get an error when the parameter
>>> is used as an instance of my Builder class.

>>> This happens in JDK 20, JDK 21, and the latest build of JDK 22.
>>> It does not happen in JDK 17.

>> I believe this is not a behavior change, you are experiencing the "comb"
>> behavior, where javac will first start to match members declared inside the
>> class hierarchy before trying to match other members.
>> Here is the classical example
>> class Foo {
>> String name;

>> void setName(String name) {
>> this.name = name;
>> }

>> public void execute() {
>> new Thread() {
>> public void run() {
>> setName("foo");
>> }
>> }.start();
>> }
>> }

>> where the method setName() inside execute() calls Thread.setName() instead of
>> Foo.setName().

>> You code compiles with JDK 17 because Thread.Builder was introduced in 21 (19 as
>> preview).

>> If you want to avoid those kind of issues, prefer delegation to inheritance.

>>> The error message:

>>> [javac] constructor Worker.Worker(@org.jetbrains.annotations.NotNull
>>> String, at org.jetbrains.annotations.NotNull
>>> SeverityLevel, at org.jetbrains.annotations.NotNull
>>> java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable
>>> TaskStatusListener, at org.jetbrains.annotations.NotNull
>>> SimpleTaskReceiver<BuildResult>) is not applicable
>>> [javac] (argument mismatch; @org.jetbrains.annotations.NotNull
>>> com.cbfiddle.releases.Builder cannot be converted to
>>> @org.jetbrains.annotations.NotNull java.lang.Thread.Builder)

>>> The constructor:

>>> public Worker ( @NotNull String taskName ,
>>> @NotNull SeverityLevel level ,
>>> @NotNull Builder builder ,
>>> @Nullable TaskStatusListener tsl ,
>>> @NotNull SimpleTaskReceiver < BuildResult > r )
>>> {
>>> this . taskName = taskName ;
>>> this . level = level ;
>>> this . r = r ;
>>> this . bl = createBuildListener( tsl ) ;
>>> this . op = () -> builder .perform( bl ) ;

>>> setPriority( Thread . MIN_PRIORITY ) ;
>>> }

>> regards,
>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231218/246fd990/attachment.htm>

From pbielicki at gmail.com  Mon Dec 18 08:50:48 2023
From: pbielicki at gmail.com (Przemek Bielicki)
Date: Mon, 18 Dec 2023 09:50:48 +0100
Subject: [Bug] javac gives non-deterministic output (for sealed interface with
 records)
Message-ID: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>

Hey Folks,

I'm not 100% sure it's the best idea to post it here but I have no access
to the JDK JIRA (yet?) ?

Last week I had a huge headache because of a bug I discovered in the Java
compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 (mixed mode,
sharing). I'm pretty certain it's a bug because my expectation is that the
compiler MUST produce deterministic output of the compiled classes - at
least when the JDK version is the same.

*## Expected behavior*

Java compiler produces deterministic output i.e compiled byte code is
exactly the same (SHA-wise) and is independent of the operating system
type, version and other variables.

*## Bug description*

When compiling 1700+ classes in one of our modules on different CI agents
(with exact same JDK version) I noticed intermittent SHA differences (of
the compiled classes) that originated from a single class (the
attached GradleExecGraphNodeExecutionInfo.java file.) It's a
sealed interface and it uses records - I have an impression that using
these two in conjunction plays a role here.

I also attach the compiled bytecode coming from two different CI agents.
If you compare the bytecode you will notice this:
[image: image.png]
The only difference (if the image is not displayed correctly) is that two
same bytes (at the 0x440 position) switch the order depending on where the
class is compiled. I didn't check the meaning of those bytes - I hope you
can help here.

"javap -c -l -private" shows that the output is exactly the same (but it
isn't).

The only difference between the CI nodes is the Linux kernel version (Linux
5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-generic (amd64). I was
able to reproduce this behavior consistently when I compiled this module on
different CI agents with the same difference in the Linux kernel.
Here's the screen from Develocity showing the diff in the infrastructure.
[image: image.png]

I tried to reproduce this problem with the minimal reproducer (by
extracting the sealed interface outside of the big module) but I failed
here. The produced byte code was the same.

Please let me know if you need to check sources of the other classes
referenced by this sealed interface. I'd need to get an approval before
sharing them publicly.

Cheers,
Przemek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231218/29d01f71/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9238 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231218/29d01f71/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 165378 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231218/29d01f71/image-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GradleExecGraphNodeExecutionInfo.java
Type: application/octet-stream
Size: 2017 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231218/29d01f71/GradleExecGraphNodeExecutionInfo-0001.java>

From vicente.romero at oracle.com  Mon Dec 18 21:19:26 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 18 Dec 2023 16:19:26 -0500
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
Message-ID: <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>

I think that having deterministic output is a very desirable property of 
a compiler but not a guarantee. If such non-determinism was provoking a 
compiler error this would be a higher priority error. Also as you 
determined yourself it is not possible to reproduce the issue with the 
test case you sent. We have made efforts in the past to remove sources 
of non-determinism in the compiler and I would say that the ones 
remaining are harder to remove. We could dive deeper with a reproductor 
but without that, it could be a futile effort,

Vicente

On 12/18/23 03:50, Przemek Bielicki wrote:
> Hey Folks,
>
> I'm not 100% sure it's the best idea to post it here but I have no 
> access to the JDK JIRA (yet?) ?
>
> Last week I had a huge headache because of a bug I discovered in the 
> Java compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 
> (mixed mode, sharing). I'm pretty certain it's a bug because my 
> expectation is that the compiler MUST produce deterministic output of 
> the compiled?classes - at least when the JDK version is the same.
>
> *## Expected behavior*
>
> Java compiler produces deterministic output i.e compiled byte code is 
> exactly the same (SHA-wise) and is independent?of the operating system 
> type, version and other variables.
>
> *## Bug description*
>
> When compiling 1700+ classes in one of our modules on different CI 
> agents (with exact same JDK version) I noticed intermittent?SHA 
> differences (of the compiled classes) that originated from a single 
> class (the attached?GradleExecGraphNodeExecutionInfo.java file.) It's 
> a sealed?interface and it uses records - I have an impression that 
> using these two in conjunction plays a role here.
>
> I also attach the compiled bytecode coming from two different CI agents.
> If you compare the bytecode you will notice this:
> image.png
> The only difference (if the image is not displayed correctly) is that 
> two same bytes (at the 0x440 position) switch?the order depending on 
> where the class is compiled. I didn't check the meaning of those bytes 
> - I hope?you can help here.
>
> "javap -c -l -private" shows that the output?is exactly the same (but 
> it isn't).
>
> The only difference between the CI nodes is the Linux kernel version 
> (Linux 5.4.0-*166*-generic (amd64)?vs?Linux 5.4.0-*167*-generic 
> (amd64). I was able to reproduce this behavior consistently when I 
> compiled this module on different CI agents with the same difference 
> in the Linux kernel.
> Here's the screen from Develocity showing the diff in the infrastructure.
> image.png
>
> I tried to reproduce this problem with the minimal reproducer (by 
> extracting the sealed interface outside of the big module) but I 
> failed here. The produced byte code was the same.
>
> Please let me know if you need to check sources of the other classes 
> referenced by this sealed interface. I'd need to get an approval 
> before sharing them publicly.
>
> Cheers,
> Przemek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231218/2098a169/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9238 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231218/2098a169/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 165378 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231218/2098a169/image-0003.png>

From javalists at cbfiddle.com  Mon Dec 18 22:55:13 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 18 Dec 2023 14:55:13 -0800
Subject: a change in javac behavior
In-Reply-To: <867073994.84357316.1702881585077.JavaMail.zimbra@univ-eiffel.fr>
References: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com>
 <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr>
 <502E2D50-61B8-4677-A2AF-F9FD6A199716@cbfiddle.com>
 <867073994.84357316.1702881585077.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <0FBBED07-C865-40FA-AD24-1331890FAD83@cbfiddle.com>

Thank you, Remi, for the explanation.

I?m sure there are good reasons why Java works this way and it is cast in concrete, but I have to say that from
a usability point of view, I find it undesirable that an explicit import can fail to apply to some uses of the
identifier because of some factor that is not visible in the source file.

  Alan



> On Dec 17, 2023, at 10:39?PM, forax at univ-mlv.fr wrote:
> 
> 
> 
> From: "Alan Snyder" <javalists at cbfiddle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, December 17, 2023 9:03:14 PM
> Subject: Re: a change in javac behavior
> So, that is how things are supposed to work?
> 
> Yes,
> 
> 
> Also, can you explain why javac does not complain about the builder.perform() invocation?
> That variable is declared using the disputed parameter declaration.
> If the parameter type is taken to be Thread.Builder, the call to perform should be rejected.
> 
> Hard to say without the whole code but if your original error comes from the same file, it may mask the error at builder.perform(), javac does several passes on the same code.
> 
> regards,
> R?mi
> 
> 
> 
> On Dec 17, 2023, at 9:56?AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 
> 
> From: "Alan Snyder" <javalists at cbfiddle.com>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, December 17, 2023 5:48:15 PM
> Subject: a change in javac behavior
> I?m experiencing a change in behavior compiling a particular file.
> The compiler is trying to match an invocation to one of two constructors for a static class defined in the same file.
> 
> The second constructor has a parameter of type Builder. In the past, this was interpreted as my Builder class, which is imported into this file.
> That matches the invocation.
> 
> Now, however, the constructor parameter type is interpreted as java.lang.Thread.Builder, presumably because the static class extends Thread.
> That causes a mismatch to be reported.
> 
> This interpretation appears to be limited to the resolution of the constructor invocation. Within the constructor, I do not get an error when the parameter
> is used as an instance of my Builder class.
> 
> This happens in JDK 20, JDK 21, and the latest build of JDK 22.
> It does not happen in JDK 17.
> 
> I believe this is not a behavior change, you are experiencing the "comb" behavior, where javac will first start to match members declared inside the class hierarchy before trying to match other members.
> Here is the classical example
> class Foo {
>   String name;
> 
>   void setName(String name) {
>     this.name = name;
>   }
> 
>   public void execute() {
>     new Thread() {
>       public void run() {
>         setName("foo");
>       }
>     }.start();
>   } 
> }
> 
> where the method setName() inside execute() calls Thread.setName() instead of Foo.setName().
> 
> You code compiles with JDK 17 because Thread.Builder was introduced in 21 (19 as preview).
> 
> If you want to avoid those kind of issues, prefer delegation to inheritance.
> 
> 
> The error message:
> 
>     [javac]     constructor Worker.Worker(@org.jetbrains.annotations.NotNull String, at org.jetbrains.annotations.NotNull SeverityLevel, at org.jetbrains.annotations.NotNull java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable TaskStatusListener, at org.jetbrains.annotations.NotNull SimpleTaskReceiver<BuildResult>) is not applicable
>     [javac]       (argument mismatch; @org.jetbrains.annotations.NotNull com.cbfiddle.releases.Builder cannot be converted to @org.jetbrains.annotations.NotNull java.lang.Thread.Builder)
> 
> 
> The constructor:
> 
> public Worker(@NotNull String taskName,
> @NotNull SeverityLevel level,
> @NotNull Builder builder,
> @Nullable TaskStatusListener tsl,
> @NotNull SimpleTaskReceiver<BuildResult> r)
> {
>     this.taskName = taskName;
> this.level = level;
> this.r = r;
> this.bl = createBuildListener(tsl);
> this.op = () -> builder.perform(bl);
> 
> setPriority(Thread.MIN_PRIORITY);
> }
> 
> regards,
> R?mi
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231218/9553b223/attachment.htm>

From vromero at openjdk.org  Mon Dec 18 23:44:00 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 18 Dec 2023 23:44:00 GMT
Subject: RFR: 8305007: Within-lambda subclass of local class using method param
 causes compiler crash
Message-ID: <k2fPgixMUYsKFz9SHC0PBkmwvWiOQwa6D33-XPuEH88=.4182054f-e102-4bfe-83d8-33bcb46ed06b@github.com>

javac is crashing while compiling code like:


public abstract class CompilerCrashLambdaPlusLocalClass {
    public abstract void consume(Runnable r);

    public void doThing(String parameter) {
        class LocalClass {
            @Override
            public String toString() {
                return parameter;
            }
        }
        consume(() -> {
            class LambdaLocalClass extends LocalClass {}
            new LocalClass();
        });
    }
}

the reason for the issue is that the mappings for captured variables created by LambdaToMethod are not copying the `adr`, local address, field of the original VarSymbol it is mapping. Later on during code generation an assertion was being triggered due to a variable with an `adr < 0` this patch fixes this issue.

Thanks,
Vicente

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

Commit messages:
 - keeping address of original VarSymbol
 - Merge branch 'master' into JDK-8305007
 - 8305007: Within-lambda subclass of local class using method param causes compiler crash

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

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

From pbielicki at gmail.com  Tue Dec 19 07:44:48 2023
From: pbielicki at gmail.com (Przemek Bielicki)
Date: Tue, 19 Dec 2023 08:44:48 +0100
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
Message-ID: <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>

I understand your point. I will work on the reproducer then. When I'm
successful I will just share a link to github with you - I hope that's OK?

In the meantime, can someone please explain to me the meaning of those two
bytes that switch order?
I'm sending the classes again, this time in a ZIP file as I guess .class
extension may be considered as malware by the filters (?).

Przemek

On Mon, Dec 18, 2023 at 10:24?PM Vicente Romero <vicente.romero at oracle.com>
wrote:

> I think that having deterministic output is a very desirable property of a
> compiler but not a guarantee. If such non-determinism was provoking a
> compiler error this would be a higher priority error. Also as you
> determined yourself it is not possible to reproduce the issue with the test
> case you sent. We have made efforts in the past to remove sources of
> non-determinism in the compiler and I would say that the ones remaining are
> harder to remove. We could dive deeper with a reproductor but without that,
> it could be a futile effort,
>
> Vicente
>
> On 12/18/23 03:50, Przemek Bielicki wrote:
>
> Hey Folks,
>
> I'm not 100% sure it's the best idea to post it here but I have no access
> to the JDK JIRA (yet?) ?
>
> Last week I had a huge headache because of a bug I discovered in the Java
> compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 (mixed mode,
> sharing). I'm pretty certain it's a bug because my expectation is that the
> compiler MUST produce deterministic output of the compiled classes - at
> least when the JDK version is the same.
>
> *## Expected behavior*
>
> Java compiler produces deterministic output i.e compiled byte code is
> exactly the same (SHA-wise) and is independent of the operating system
> type, version and other variables.
>
> *## Bug description*
>
> When compiling 1700+ classes in one of our modules on different CI agents
> (with exact same JDK version) I noticed intermittent SHA differences (of
> the compiled classes) that originated from a single class (the
> attached GradleExecGraphNodeExecutionInfo.java file.) It's a
> sealed interface and it uses records - I have an impression that using
> these two in conjunction plays a role here.
>
> I also attach the compiled bytecode coming from two different CI agents.
> If you compare the bytecode you will notice this:
> [image: image.png]
> The only difference (if the image is not displayed correctly) is that two
> same bytes (at the 0x440 position) switch the order depending on where the
> class is compiled. I didn't check the meaning of those bytes - I hope you
> can help here.
>
> "javap -c -l -private" shows that the output is exactly the same (but it
> isn't).
>
> The only difference between the CI nodes is the Linux kernel version
> (Linux 5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-generic (amd64).
> I was able to reproduce this behavior consistently when I compiled this
> module on different CI agents with the same difference in the Linux kernel.
> Here's the screen from Develocity showing the diff in the infrastructure.
> [image: image.png]
>
> I tried to reproduce this problem with the minimal reproducer (by
> extracting the sealed interface outside of the big module) but I failed
> here. The produced byte code was the same.
>
> Please let me know if you need to check sources of the other classes
> referenced by this sealed interface. I'd need to get an approval before
> sharing them publicly.
>
> Cheers,
> Przemek
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/be634d65/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9238 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/be634d65/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 165378 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/be634d65/image-0003.png>

From pbielicki at gmail.com  Tue Dec 19 08:28:07 2023
From: pbielicki at gmail.com (Przemek Bielicki)
Date: Tue, 19 Dec 2023 09:28:07 +0100
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
Message-ID: <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>

As pointed out by a friendly member of this mailing group (not mentioning
the name for privacy) I'm sharing the ZIP file using GDrive:
https://drive.google.com/file/d/1SMuh71IxtUmZXcE5uvG1ppA0PKQjCOE1/view?usp=sharing

Cheers,
Przemek

On Tue, Dec 19, 2023 at 8:44?AM Przemek Bielicki <pbielicki at gmail.com>
wrote:

> I understand your point. I will work on the reproducer then. When I'm
> successful I will just share a link to github with you - I hope that's OK?
>
> In the meantime, can someone please explain to me the meaning of those two
> bytes that switch order?
> I'm sending the classes again, this time in a ZIP file as I guess .class
> extension may be considered as malware by the filters (?).
>
> Przemek
>
> On Mon, Dec 18, 2023 at 10:24?PM Vicente Romero <vicente.romero at oracle.com>
> wrote:
>
>> I think that having deterministic output is a very desirable property of
>> a compiler but not a guarantee. If such non-determinism was provoking a
>> compiler error this would be a higher priority error. Also as you
>> determined yourself it is not possible to reproduce the issue with the test
>> case you sent. We have made efforts in the past to remove sources of
>> non-determinism in the compiler and I would say that the ones remaining are
>> harder to remove. We could dive deeper with a reproductor but without that,
>> it could be a futile effort,
>>
>> Vicente
>>
>> On 12/18/23 03:50, Przemek Bielicki wrote:
>>
>> Hey Folks,
>>
>> I'm not 100% sure it's the best idea to post it here but I have no access
>> to the JDK JIRA (yet?) ?
>>
>> Last week I had a huge headache because of a bug I discovered in the Java
>> compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 (mixed mode,
>> sharing). I'm pretty certain it's a bug because my expectation is that the
>> compiler MUST produce deterministic output of the compiled classes - at
>> least when the JDK version is the same.
>>
>> *## Expected behavior*
>>
>> Java compiler produces deterministic output i.e compiled byte code is
>> exactly the same (SHA-wise) and is independent of the operating system
>> type, version and other variables.
>>
>> *## Bug description*
>>
>> When compiling 1700+ classes in one of our modules on different CI agents
>> (with exact same JDK version) I noticed intermittent SHA differences (of
>> the compiled classes) that originated from a single class (the
>> attached GradleExecGraphNodeExecutionInfo.java file.) It's a
>> sealed interface and it uses records - I have an impression that using
>> these two in conjunction plays a role here.
>>
>> I also attach the compiled bytecode coming from two different CI agents.
>> If you compare the bytecode you will notice this:
>> [image: image.png]
>> The only difference (if the image is not displayed correctly) is that two
>> same bytes (at the 0x440 position) switch the order depending on where the
>> class is compiled. I didn't check the meaning of those bytes - I hope you
>> can help here.
>>
>> "javap -c -l -private" shows that the output is exactly the same (but it
>> isn't).
>>
>> The only difference between the CI nodes is the Linux kernel version
>> (Linux 5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-generic (amd64).
>> I was able to reproduce this behavior consistently when I compiled this
>> module on different CI agents with the same difference in the Linux kernel.
>> Here's the screen from Develocity showing the diff in the infrastructure.
>> [image: image.png]
>>
>> I tried to reproduce this problem with the minimal reproducer (by
>> extracting the sealed interface outside of the big module) but I failed
>> here. The produced byte code was the same.
>>
>> Please let me know if you need to check sources of the other classes
>> referenced by this sealed interface. I'd need to get an approval before
>> sharing them publicly.
>>
>> Cheers,
>> Przemek
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/dc3d719a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9238 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/dc3d719a/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 165378 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/dc3d719a/image-0003.png>

From pbielicki at gmail.com  Tue Dec 19 08:48:05 2023
From: pbielicki at gmail.com (Przemek Bielicki)
Date: Tue, 19 Dec 2023 09:48:05 +0100
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
 <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>
 <CAMvdueDg5peX+Wc-=4VirJKYGVZqTXF3ZLTOt=X+u4SacwTiVA@mail.gmail.com>
 <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
Message-ID: <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>

Oh damn! I think IDEA's decompiler helped a little with the explanation of
the meaning of the order.
As you can see from the attached screenshot the order of permits differ:

permits GradleExecGraphNodeExecutionInfo.Task,
GradleExecGraphNodeExecutionInfo.Transform {
vs.
permits GradleExecGraphNodeExecutionInfo.Transform,
GradleExecGraphNodeExecutionInfo.Task {

I guess this structure (collection of permits?) is handled by the compiler
using some sort of Set instead of a List thus we get a
non-deterministic order.
My fellow Gradle colleagues told me that they discovered such
non-determinisms in the past and the reasons were very similar.

I hope it's helpful and can unblock you from digging deeper? ??

What's interesting is that javap isn't showing this difference. ?

Cheers,
Przemek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/7c78e4f0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idea_decompiled.png
Type: image/png
Size: 166235 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/7c78e4f0/idea_decompiled-0001.png>

From james.laskey at oracle.com  Tue Dec 19 08:56:10 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 19 Dec 2023 08:56:10 +0000
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
 <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>
 <CAMvdueDg5peX+Wc-=4VirJKYGVZqTXF3ZLTOt=X+u4SacwTiVA@mail.gmail.com>
 <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
 <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
Message-ID: <C732ED2F-FACA-415C-8EB1-91AF0F23AEF1@oracle.com>

This is very good. Thanks for isolating. This is the sort of thing that is easily missed because of the subtlety and could lead to days of searching.

On 19 Dec 2023, at 04:48, Przemek Bielicki <pbielicki at gmail.com> wrote:

Oh damn! I think IDEA's decompiler helped a little with the explanation of the meaning of the order.
As you can see from the attached screenshot the order of permits differ:

permits GradleExecGraphNodeExecutionInfo.Task, GradleExecGraphNodeExecutionInfo.Transform {
vs.
permits GradleExecGraphNodeExecutionInfo.Transform, GradleExecGraphNodeExecutionInfo.Task {

I guess this structure (collection of permits?) is handled by the compiler using some sort of Set instead of a List thus we get a non-deterministic order.
My fellow Gradle colleagues told me that they discovered such non-determinisms in the past and the reasons were very similar.

I hope it's helpful and can unblock you from digging deeper? ??

What's interesting is that javap isn't showing this difference. ?

Cheers,
Przemek
[idea_decompiled.png]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/33db0824/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idea_decompiled.png
Type: image/png
Size: 166235 bytes
Desc: idea_decompiled.png
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/33db0824/idea_decompiled-0001.png>

From jpai at openjdk.org  Tue Dec 19 14:23:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 14:23:37 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool Processing of
 "@File"
In-Reply-To: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
Message-ID: <npJJHMmh-skT-OJE_GimMDhb7VsVfxb4GJT64RqeVug=.1bf86e21-e67d-4a14-a3ac-41c6eb014735@github.com>

On Wed, 13 Dec 2023 18:16:56 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> Better Error Handling for Jar Tool Processing of "@File" <br>
> 
> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
> 
> Thank you.

Hello Weibing, I had another look at this today. The implementation change looks OK. But I think the JBS issue summary and the JBS issue description will need to be updated.

The real issue here isn't specific to the use of `@file` by the `jar` tool. Instead the issue is about an internal detail of the `jar` tool implementation. When the `jar` tool is launched either to create (`-c`) or to update (`-u`) a jar file, it gets passed a list of files to include/update the jar file with. One way to pass those options is literally as part of the command. The other way is to include those files path in a separate file and pass that file to the `jar` tool as the `@that-other-file`. The issue here affects both those variants.

The internal implementation of the `jar` tool in `sun/tools/jar/Main.java`, uses a flag called `ok` to keep track of whether there was any error during the `jar` tool action processing. This `ok` flagged is marked by various methods that get invoked during the `jar` processing. 

When `-c` or `-u` options are passed to the `jar` tool, the `sun/tools/jar/Main.java` calls an internal method `expand()`. This method is responsible for finalizing the files that need to be included in the jar that gets created or updated. This expand method is also responsible for marking that `ok` flag if there are any errors (like any file that was specified to be included/updated in the jar, is missing).  Once the `expand()` method returns, the internal implementation detail of the `jar` tool will go ahead and create a temporary file. Content will be written out to this temporary files. The more entries to create in the final jar being created/updated, the more time and more disk space this temporary file will consume. Finally, when writing out to the temporary file is done, the `ok` flag is checked to see if it was flagged as failed. If `ok` says no errors were noticed, then the temporary file that was created will be moved as the final jar that had to be created/updated. If `o
 k` said that there were failures, then the temporary file is deleted and the final jar to be created won't get created (rightly so) nor will the final jar get updated, in case of `-u` option (rightly so).

The issue here is that if the `expand()` method noticed that there was an error with the provided file paths (like 1 out of the 5 files specified is missing), then it marks the `ok` flag to indicate that, but the current implementation of the `jar` tool (before the change in this PR) just doesn't check the flag and goes on to do the expensive work of creating a temporary file (which will have the rest of the 4 files) and that temporary file will then finally get discarded at the end. This entire process of creating the temporary file can be avoided by checking the `ok` flag after the `expand()` method returns. That is what the proposal in the PR does and I think it looks good.

Given that, I think the JBS issue summary and the description doesn't match what we are doing here. Would you be able to update those accordingly? If you want me to do that, do let me know and you can then update this PR title.

As for the new test method introduced in this PR, in the existing `InputFilesTest`, it took me a while to understand what exactly this was doing. One part of it is due to a bit misleading method names - for example, `println()` method which going by that name, I thought was printing a new line (I didn't understand why) but turns out that method actually prints out the output that has been captured in a `ByteArrayOutputStream` by a  previous invocation of the `jar` tool from within the test method. That `println()` method has been that way even before the changes in this PR, so I think that is OK (unless you won't mind updating the name to something better?).

This existing `InputFilesTest` runs various tests for the `jar` tool by passing it file paths to be included/updated in the jar. It currently doesn't have any coverage for `@file` usages, so this new test method is adding that. However, this new test method isn't exercising the case where one or more file paths specified in the passed `@file` are missing. So it isn't exactly exercising the issue that is being fixed. I think the test you added is OK as a positive test (where all passed file paths are present), but I think we would also need one for missing files and then assert in that test that the final jar isn't created or updated and the `jar` tool returns a non-zero exit code. Please also add some comments to the newly introduced test methods to make it easier to understand what they are testing.

While at it, could you also please check if the `@file` usage has test coverage from some other existing test class? I am bit surprised that this `InputFilesTest` doesn't have any, so maybe it's tested elsewhere?

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

PR Comment: https://git.openjdk.org/jdk/pull/17088#issuecomment-1862849864

From vicente.romero at oracle.com  Tue Dec 19 14:39:51 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 19 Dec 2023 09:39:51 -0500
Subject: [External] : Re: [Bug] javac gives non-deterministic output (for
 sealed interface with records)
In-Reply-To: <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
Message-ID: <37623827-772d-48f7-83c1-e34358d5617f@oracle.com>



On 12/19/23 02:44, Przemek Bielicki wrote:
> I understand?your?point. I will work on the reproducer then. When I'm 
> successful?I will just share a link to github?with you - I hope that's OK?

yep that's fine,

>
> In the meantime, can someone please explain to me the meaning of those 
> two bytes that switch?order?
> I'm sending the classes again, this time in a ZIP file as I guess 
> .class extension may be considered as malware by the filters (?).

yes I think that .class are not allowed

>
> Przemek

Thanks,
Vicente

>
> On Mon, Dec 18, 2023 at 10:24?PM Vicente Romero 
> <vicente.romero at oracle.com> wrote:
>
>     I think that having deterministic output is a very desirable
>     property of a compiler but not a guarantee. If such
>     non-determinism was provoking a compiler error this would be a
>     higher priority error. Also as you determined yourself it is not
>     possible to reproduce the issue with the test case you sent. We
>     have made efforts in the past to remove sources of non-determinism
>     in the compiler and I would say that the ones remaining are harder
>     to remove. We could dive deeper with a reproductor but without
>     that, it could be a futile effort,
>
>     Vicente
>
>     On 12/18/23 03:50, Przemek Bielicki wrote:
>>     Hey Folks,
>>
>>     I'm not 100% sure it's the best idea to post it here but I have
>>     no access to the JDK JIRA (yet?) ?
>>
>>     Last week I had a huge headache because of a bug I discovered in
>>     the Java compiler - Eclipse Temurin OpenJDK 64-Bit Server VM
>>     17.0.9+9 (mixed mode, sharing). I'm pretty certain it's a bug
>>     because my expectation is that the compiler MUST produce
>>     deterministic output of the compiled?classes - at least when the
>>     JDK version is the same.
>>
>>     *## Expected behavior*
>>
>>     Java compiler produces deterministic output i.e compiled byte
>>     code is exactly the same (SHA-wise) and is independent?of the
>>     operating system type, version and other variables.
>>
>>     *## Bug description*
>>
>>     When compiling 1700+ classes in one of our modules on different
>>     CI agents (with exact same JDK version) I noticed
>>     intermittent?SHA differences (of the compiled classes) that
>>     originated from a single class (the
>>     attached?GradleExecGraphNodeExecutionInfo.java file.) It's a
>>     sealed?interface and it uses records - I have an impression that
>>     using these two in conjunction plays a role here.
>>
>>     I also attach the compiled bytecode coming from two different CI
>>     agents.
>>     If you compare the bytecode you will notice this:
>>     image.png
>>     The only difference (if the image is not displayed correctly) is
>>     that two same bytes (at the 0x440 position) switch?the order
>>     depending on where the class is compiled. I didn't check the
>>     meaning of those bytes - I hope?you can help here.
>>
>>     "javap -c -l -private" shows that the output?is exactly the same
>>     (but it isn't).
>>
>>     The only difference between the CI nodes is the Linux kernel
>>     version (Linux 5.4.0-*166*-generic (amd64)?vs?Linux
>>     5.4.0-*167*-generic (amd64). I was able to reproduce this
>>     behavior consistently when I compiled this module on different CI
>>     agents with the same difference in the Linux kernel.
>>     Here's the screen from Develocity showing the diff in the
>>     infrastructure.
>>     image.png
>>
>>     I tried to reproduce this problem with the minimal reproducer (by
>>     extracting the sealed interface outside of the big module) but I
>>     failed here. The produced byte code was the same.
>>
>>     Please let me know if you need to check sources of the other
>>     classes referenced by this sealed interface. I'd need to get an
>>     approval before sharing them publicly.
>>
>>     Cheers,
>>     Przemek
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/cb996f53/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9238 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/cb996f53/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 165378 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/cb996f53/image-0003.png>

From vicente.romero at oracle.com  Tue Dec 19 16:45:47 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 19 Dec 2023 11:45:47 -0500
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
 <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>
 <CAMvdueDg5peX+Wc-=4VirJKYGVZqTXF3ZLTOt=X+u4SacwTiVA@mail.gmail.com>
 <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
 <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
Message-ID: <a16c29c9-f290-4da2-8715-afa20c6101db@oracle.com>

Hi Przemek,

Thanks again for the report and the additional info provided. I have 
created [1] and assigned it to myself,

Vicente

[1] https://bugs.openjdk.org/browse/JDK-8322477

On 12/19/23 03:48, Przemek Bielicki wrote:
> Oh damn! I think IDEA's decompiler helped a little with the 
> explanation of the meaning of the order.
> As you can see from the attached screenshot the order of permits differ:
>
> permits GradleExecGraphNodeExecutionInfo.Task, 
> GradleExecGraphNodeExecutionInfo.Transform {
> vs.
> permits GradleExecGraphNodeExecutionInfo.Transform, 
> GradleExecGraphNodeExecutionInfo.Task {
>
> I guess this structure (collection of permits?) is handled by the 
> compiler using some sort of Set instead of a List thus we get a 
> non-deterministic?order.
> My fellow Gradle colleagues told me that they discovered such 
> non-determinisms in the past and the reasons were very similar.
>
> I hope it's helpful and can unblock you from digging deeper????
>
> What's interesting is that javap isn't showing this difference.??
>
> Cheers,
> Przemek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/989e4a8f/attachment.htm>

From pbielicki at gmail.com  Tue Dec 19 16:46:21 2023
From: pbielicki at gmail.com (Przemek Bielicki)
Date: Tue, 19 Dec 2023 17:46:21 +0100
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <a16c29c9-f290-4da2-8715-afa20c6101db@oracle.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
 <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>
 <CAMvdueDg5peX+Wc-=4VirJKYGVZqTXF3ZLTOt=X+u4SacwTiVA@mail.gmail.com>
 <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
 <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
 <a16c29c9-f290-4da2-8715-afa20c6101db@oracle.com>
Message-ID: <CAMvdueBptk+UL_=G9tgAHAx+VkMDstrgZRebPq16VNZjyw0e1A@mail.gmail.com>

Awesome, thanks!

W dniu wt., 19.12.2023 o 17:45 Vicente Romero <vicente.romero at oracle.com>
napisa?(a):

> Hi Przemek,
>
> Thanks again for the report and the additional info provided. I have
> created [1] and assigned it to myself,
>
> Vicente
>
> [1] https://bugs.openjdk.org/browse/JDK-8322477
>
>
> On 12/19/23 03:48, Przemek Bielicki wrote:
>
> Oh damn! I think IDEA's decompiler helped a little with the explanation of
> the meaning of the order.
> As you can see from the attached screenshot the order of permits differ:
>
> permits GradleExecGraphNodeExecutionInfo.Task,
> GradleExecGraphNodeExecutionInfo.Transform {
> vs.
> permits GradleExecGraphNodeExecutionInfo.Transform,
> GradleExecGraphNodeExecutionInfo.Task {
>
> I guess this structure (collection of permits?) is handled by the compiler
> using some sort of Set instead of a List thus we get a
> non-deterministic order.
> My fellow Gradle colleagues told me that they discovered such
> non-determinisms in the past and the reasons were very similar.
>
> I hope it's helpful and can unblock you from digging deeper? ??
>
> What's interesting is that javap isn't showing this difference. ?
>
> Cheers,
> Przemek
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/1cfb8f0b/attachment.htm>

From vicente.romero at oracle.com  Tue Dec 19 16:52:06 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 19 Dec 2023 11:52:06 -0500
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
 <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>
 <CAMvdueDg5peX+Wc-=4VirJKYGVZqTXF3ZLTOt=X+u4SacwTiVA@mail.gmail.com>
 <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
 <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
Message-ID: <2607ee7b-86dc-478c-bf9e-6d6ebb02ed1b@oracle.com>



On 12/19/23 03:48, Przemek Bielicki wrote:
> Oh damn! I think IDEA's decompiler helped a little with the 
> explanation of the meaning of the order.
> As you can see from the attached screenshot the order of permits differ:
>
> permits GradleExecGraphNodeExecutionInfo.Task, 
> GradleExecGraphNodeExecutionInfo.Transform {
> vs.
> permits GradleExecGraphNodeExecutionInfo.Transform, 
> GradleExecGraphNodeExecutionInfo.Task {
>
> I guess this structure (collection of permits?) is handled by the 
> compiler using some sort of Set instead of a List thus we get a 
> non-deterministic?order.
> My fellow Gradle colleagues told me that they discovered such 
> non-determinisms in the past and the reasons were very similar.
>
> I hope it's helpful and can unblock you from digging deeper????
yep I think this is good enough to dig deeper,
>
> What's interesting is that javap isn't showing this difference.??
>
> Cheers,
> Przemek

Thanks
Vicente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/34dcb479/attachment-0001.htm>

From vicente.romero at oracle.com  Tue Dec 19 16:55:52 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 19 Dec 2023 11:55:52 -0500
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
 <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>
 <CAMvdueDg5peX+Wc-=4VirJKYGVZqTXF3ZLTOt=X+u4SacwTiVA@mail.gmail.com>
 <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
 <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
Message-ID: <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com>

Hi Przemek,

can you patch JDK sources, rebuild them and try if a given patch fixes 
your issue or do you need a customized JDK?

Thanks,
Vicente

On 12/19/23 03:48, Przemek Bielicki wrote:
> Oh damn! I think IDEA's decompiler helped a little with the 
> explanation of the meaning of the order.
> As you can see from the attached screenshot the order of permits differ:
>
> permits GradleExecGraphNodeExecutionInfo.Task, 
> GradleExecGraphNodeExecutionInfo.Transform {
> vs.
> permits GradleExecGraphNodeExecutionInfo.Transform, 
> GradleExecGraphNodeExecutionInfo.Task {
>
> I guess this structure (collection of permits?) is handled by the 
> compiler using some sort of Set instead of a List thus we get a 
> non-deterministic?order.
> My fellow Gradle colleagues told me that they discovered such 
> non-determinisms in the past and the reasons were very similar.
>
> I hope it's helpful and can unblock you from digging deeper????
>
> What's interesting is that javap isn't showing this difference.??
>
> Cheers,
> Przemek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/b04723e0/attachment.htm>

From pbielicki at gmail.com  Tue Dec 19 17:01:48 2023
From: pbielicki at gmail.com (Przemek Bielicki)
Date: Tue, 19 Dec 2023 18:01:48 +0100
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
 <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>
 <CAMvdueDg5peX+Wc-=4VirJKYGVZqTXF3ZLTOt=X+u4SacwTiVA@mail.gmail.com>
 <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
 <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
 <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com>
Message-ID: <CAMvdueA74ORzWbgr=FLp9OeE_ROUbDVQZKNzqb2N37sBTO0MYQ@mail.gmail.com>

Probably - I don?t have the environment and I also never built the JDK from
sources it I have a technical skills to eventually do it ?

Can you pls point me to some docs on how to build the JDK from scratch?

Cheers,
Przemek

W dniu wt., 19.12.2023 o 17:56 Vicente Romero <vicente.romero at oracle.com>
napisa?(a):

> Hi Przemek,
>
> can you patch JDK sources, rebuild them and try if a given patch fixes
> your issue or do you need a customized JDK?
>
> Thanks,
> Vicente
>
>
> On 12/19/23 03:48, Przemek Bielicki wrote:
>
> Oh damn! I think IDEA's decompiler helped a little with the explanation of
> the meaning of the order.
> As you can see from the attached screenshot the order of permits differ:
>
> permits GradleExecGraphNodeExecutionInfo.Task,
> GradleExecGraphNodeExecutionInfo.Transform {
> vs.
> permits GradleExecGraphNodeExecutionInfo.Transform,
> GradleExecGraphNodeExecutionInfo.Task {
>
> I guess this structure (collection of permits?) is handled by the compiler
> using some sort of Set instead of a List thus we get a
> non-deterministic order.
> My fellow Gradle colleagues told me that they discovered such
> non-determinisms in the past and the reasons were very similar.
>
> I hope it's helpful and can unblock you from digging deeper? ??
>
> What's interesting is that javap isn't showing this difference. ?
>
> Cheers,
> Przemek
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/69427861/attachment.htm>

From vicente.romero at oracle.com  Tue Dec 19 18:11:09 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 19 Dec 2023 13:11:09 -0500
Subject: [External] : Re: [Bug] javac gives non-deterministic output (for
 sealed interface with records)
In-Reply-To: <CAMvdueA74ORzWbgr=FLp9OeE_ROUbDVQZKNzqb2N37sBTO0MYQ@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
 <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>
 <CAMvdueDg5peX+Wc-=4VirJKYGVZqTXF3ZLTOt=X+u4SacwTiVA@mail.gmail.com>
 <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
 <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
 <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com>
 <CAMvdueA74ORzWbgr=FLp9OeE_ROUbDVQZKNzqb2N37sBTO0MYQ@mail.gmail.com>
Message-ID: <98b41452-12e3-457f-9128-afec5f033a45@oracle.com>

no worries I can publish a JDK you can play with,

Thanks,
Vicente

On 12/19/23 12:01, Przemek Bielicki wrote:
> Probably - I don?t have the environment and I also never built the JDK 
> from sources it I have a technical skills to eventually do it ?
>
> Can you pls point me to some docs on how to build the JDK from scratch?
>
> Cheers,
> Przemek
>
> W dniu wt., 19.12.2023 o 17:56 Vicente Romero 
> <vicente.romero at oracle.com> napisa?(a):
>
>     Hi Przemek,
>
>     can you patch JDK sources, rebuild them and try if a given patch
>     fixes your issue or do you need a customized JDK?
>
>     Thanks,
>     Vicente
>
>
>     On 12/19/23 03:48, Przemek Bielicki wrote:
>>     Oh damn! I think IDEA's decompiler helped a little with the
>>     explanation of the meaning of the order.
>>     As you can see from the attached screenshot the order of permits
>>     differ:
>>
>>     permits GradleExecGraphNodeExecutionInfo.Task,
>>     GradleExecGraphNodeExecutionInfo.Transform {
>>     vs.
>>     permits GradleExecGraphNodeExecutionInfo.Transform,
>>     GradleExecGraphNodeExecutionInfo.Task {
>>
>>     I guess this structure (collection of permits?) is handled by the
>>     compiler using some sort of Set instead of a List thus we get a
>>     non-deterministic?order.
>>     My fellow Gradle colleagues told me that they discovered such
>>     non-determinisms in the past and the reasons were very similar.
>>
>>     I hope it's helpful and can unblock you from digging deeper????
>>
>>     What's interesting is that javap isn't showing this difference.??
>>
>>     Cheers,
>>     Przemek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/ba9b3af9/attachment-0001.htm>

From acobbs at openjdk.org  Tue Dec 19 22:53:16 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 19 Dec 2023 22:53:16 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
Message-ID: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>

Please review several fixes and improvements to the `this-escape` lint warning analyzer.

The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.

Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.

The changes are summarized here:

#### 1. Generalize how we categorize references

The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".

Previously the `Ref` categories were:
* `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
* `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
* `VarRef` - A local variable or method parameter currently in scope
* `ExprRef` - An object reference sitting on top of the Java execution stack
* `YieldRef` - The current switch expression's yield value(s)
* `ReturnRef` - The current method's return value(s)

For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).

The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.

In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".

As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.

#### 2. Track the types of all references

By keeping track of the actual type of each reference (as opposed to just looking at its compile-time type), we can make more precise calculations. We weren't doing this before.

For example consider this class:

public class Leaker {

    public Leaker() {
        Runnable r = new Runnable() {
            public void run() {
                Leaker.this.mightLeak();
            }
        };
        r.run();   // there is a leak here
    }

    protected void mightLeak() {
        // a subclass could override this method
    }
}

Previously we would not have detected a 'this' escape because we wouldn't have known that variable `r` is a `Leaker$1`, which allows us to deduce that `r.run()` is actually `Leaker$1.run()` (which we can analyze) instead of just `Runnable.run()` (which we can't).

Because of this change, some `Ref` types that were previously singletons are no longer singletons. For example, now there can be more than one `ReturnRef` in scope at any time, representing different possible types for the method's return value.

#### 3. Handling of non-public outer instances

To eliminate some false positives, we no longer warn if a leak happens solely due to a "non-public" outer instance.

For example, consider this code:

public class Test {

    public Test() {
        System.out.println(new Inner());
    }   

    private class Inner {
        Object getMyOuter() {
            return Test.this;
        }
    }
}

The outer `Test` instance associated with objects of type `Test.Inner` is considered "non-public" because it's not directly accessible to the outside world (because `Test.Inner` is a private class). So while it's true that instances of `Test.Inner` retain a reference to their enclosing instance, an unrelated method like `System.out.println()` wouldn't know how to access them. The only way a `Test.Inner` could leak its outer instance to such a method is if it did so (perhaps indirectly) through some entr?e that the method "knows about". Of course, that's possible, but absent any further analysis (which could be added in the future), the cost/reward trade-off doesn't seem worth generating a warning here.

This is an area for future research. In other words: when a `Ref` is passed to unknown code, when is it worth complaining about a leak, and when should we just be silent? Previously we always complained, but now that we have more information about references (namely, their types) we can be a little more discriminating.

In any case, this decision is encapsulated in a new method `triggersUnknownInvokeLeak()`.

#### 4. Fix tracking of new instances

Previously we were not tracking references from a constructor's "return value", i.e., the new instance. We fix this by pretending that constructors end with `return this`.

#### 5. Fix tracking of enhanced `for()` loops

Previously we were not tracking the implicit invocations of `iterator()`, `hasNext()`, and `next()` associated with enhanced `for()` loops. This patch adds that tracking.

#### 6. Fix leaks via return values from lambdas and method references

Leaks inside lambdas and methods referred-to by method reference were being detected properly, but leaks from the _return values_ of those things were not.

So for example, this code would escape notice:

import java.util.function.Supplier;
public class Test {

    public Test() {
        ((Supplier<Test>)this::self).get().mightLeak();
    }   

    public final Test self() {
        return this;
    }

    protected void mightLeak() {
        // a subclass could override this method
    }
}

This patch fixes this omission.

#### 7. Some minor refactoring to make the code clearer

* Some methods were renamed
* Some bits of code were extracted into separate methods
* Added `Ref`  methods `toDirect()`, `toIndirect()`, `toOuter()`, and `fromOuter()`

#### 8. Remove some unnecessary suppression

Several `*.gmk` build files were suppressing `this-escape` warnings unnecessarily. These have been updated.

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

Commit messages:
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Javadoc++
 - Merge branch 'master' into JDK-8317376
 - Several improvements to the 'this' escape analyzer.

Changes: https://git.openjdk.org/jdk/pull/16208/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16208&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317376
  Stats: 870 lines in 20 files changed: 512 ins; 148 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/16208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16208/head:pull/16208

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

From davidalayachew at gmail.com  Wed Dec 20 04:10:49 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 19 Dec 2023 23:10:49 -0500
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CAMvdueA74ORzWbgr=FLp9OeE_ROUbDVQZKNzqb2N37sBTO0MYQ@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <dc0dc11d-b9a9-4060-bc53-54b730b6fcf1@oracle.com>
 <CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com>
 <CAMvdueAx9F70NRn-8Km8sxkxmVWLa5Cj257Y9NvjZNnhJoEDtA@mail.gmail.com>
 <CAMvdueDg5peX+Wc-=4VirJKYGVZqTXF3ZLTOt=X+u4SacwTiVA@mail.gmail.com>
 <CAMvdueBrVB_A0bi6+OMtxHvzxq08EaYXG2QcTbuivUyQfKvMdQ@mail.gmail.com>
 <CAMvdueC0twx3OGnahV--m6_Ytagvz8+-W=s7CciVJFiNRrQO4g@mail.gmail.com>
 <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com>
 <CAMvdueA74ORzWbgr=FLp9OeE_ROUbDVQZKNzqb2N37sBTO0MYQ@mail.gmail.com>
Message-ID: <CAA9v-_O_c6h29Y5-E8E9kogf9Lmo6nsW_8RTfXEC00DT09jtAg@mail.gmail.com>

I'm not Vicente, but I'm 99% sure this is the link that would have been
sent.

https://openjdk.org/groups/build/doc/building.html

On Tue, Dec 19, 2023 at 12:02?PM Przemek Bielicki <pbielicki at gmail.com>
wrote:

> Probably - I don?t have the environment and I also never built the JDK
> from sources it I have a technical skills to eventually do it ?
>
> Can you pls point me to some docs on how to build the JDK from scratch?
>
> Cheers,
> Przemek
>
> W dniu wt., 19.12.2023 o 17:56 Vicente Romero <vicente.romero at oracle.com>
> napisa?(a):
>
>> Hi Przemek,
>>
>> can you patch JDK sources, rebuild them and try if a given patch fixes
>> your issue or do you need a customized JDK?
>>
>> Thanks,
>> Vicente
>>
>>
>> On 12/19/23 03:48, Przemek Bielicki wrote:
>>
>> Oh damn! I think IDEA's decompiler helped a little with the explanation
>> of the meaning of the order.
>> As you can see from the attached screenshot the order of permits differ:
>>
>> permits GradleExecGraphNodeExecutionInfo.Task,
>> GradleExecGraphNodeExecutionInfo.Transform {
>> vs.
>> permits GradleExecGraphNodeExecutionInfo.Transform,
>> GradleExecGraphNodeExecutionInfo.Task {
>>
>> I guess this structure (collection of permits?) is handled by the
>> compiler using some sort of Set instead of a List thus we get a
>> non-deterministic order.
>> My fellow Gradle colleagues told me that they discovered such
>> non-determinisms in the past and the reasons were very similar.
>>
>> I hope it's helpful and can unblock you from digging deeper? ??
>>
>> What's interesting is that javap isn't showing this difference. ?
>>
>> Cheers,
>> Przemek
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/90a3ec2f/attachment.htm>

From dfuchs at openjdk.org  Wed Dec 20 09:06:37 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Dec 2023 09:06:37 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <i2dqrXTLtVjEDs2ZwOEz_DxZfYlq_hDUZAtTM_ucni8=.580b80a6-8465-423a-809f-09cdba6a2552@github.com>

On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

Hummm... I know a few (two) places in `java.net.http` where we deliberately let `this` escape. One place is where we set up the double final link between an `HttpClientImpl` instance and its facade (set at construction time where the facade has a final field pointing at its implementation and the implementation has a final `WeakRefeference` pointing at its facade, all set up within their constructors). Another place is with the `SSLflowDelegate` where `connect`, a protected method implemented on the `SSLTube.SSLTubeFlowDelegate` subclass is called from within the super class constructor. I assume these were the reason why `this-escape` analysis had been disabled on `java.net.http`, and I expect the reason why the analysis can be reenabled by default is because of point 3 above?

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

PR Comment: https://git.openjdk.org/jdk/pull/16208#issuecomment-1864102081

From acobbs at openjdk.org  Wed Dec 20 15:37:48 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 20 Dec 2023 15:37:48 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
In-Reply-To: <i2dqrXTLtVjEDs2ZwOEz_DxZfYlq_hDUZAtTM_ucni8=.580b80a6-8465-423a-809f-09cdba6a2552@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
 <i2dqrXTLtVjEDs2ZwOEz_DxZfYlq_hDUZAtTM_ucni8=.580b80a6-8465-423a-809f-09cdba6a2552@github.com>
Message-ID: <K4lrwBuwborx3maPYe0tOC_G-YzeO4O_EhHt4hn_Z3o=.d8a69ee0-c797-4df6-86fe-8a0f25bda7d4@github.com>

On Wed, 20 Dec 2023 09:03:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I assume these were the reason why this-escape analysis had been disabled on java.net.http, and I expect the reason why the analysis can be reenabled by default is because of point 3 above?

No, the goal here is simply to remove unnecessary build flags. All Java code is compiled with `-Werror` so if the build still succeeds with the build flag removed then (in theory at least) the flag is no longer needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16208#issuecomment-1864689891

From achung at openjdk.org  Wed Dec 20 19:06:58 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 20 Dec 2023 19:06:58 GMT
Subject: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update
Message-ID: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>

Backport of JDK-8322041

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

Commit messages:
 - Backport b061b6678fde891974d5b58cec963b3481099a8d

Changes: https://git.openjdk.org/jdk22/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=22&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322041
  Stats: 290 lines in 36 files changed: 166 ins; 15 del; 109 mod
  Patch: https://git.openjdk.org/jdk22/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/22/head:pull/22

PR: https://git.openjdk.org/jdk22/pull/22

From kcr at openjdk.org  Wed Dec 20 19:18:50 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 20 Dec 2023 19:18:50 GMT
Subject: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
References: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
Message-ID: <0PwfnK4xd97FHzIR9ChcGQXtE1EExZ-YgFSRY6T2oDQ=.899d8f7b-9807-4d6d-b63a-12bf207c68d7@github.com>

On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Backport of JDK-8322041

The patch looks good. Additionally, I confirmed that the files in question are identical to those in jdk mainline after this patch is applied.

It will need a "R"eviewer to approve.

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk22/pull/22#pullrequestreview-1791515826

From naoto at openjdk.org  Wed Dec 20 20:46:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Dec 2023 20:46:51 GMT
Subject: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
References: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
Message-ID: <iYq79_yXwnDH-tNdASBaMjtOOMzLdC263z8BOa0sLCc=.693f7bbe-9a1b-4916-98bd-ca89acf5acc0@github.com>

On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Backport of JDK-8322041

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/22#pullrequestreview-1791633961

From achung at openjdk.org  Wed Dec 20 21:44:48 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 20 Dec 2023 21:44:48 GMT
Subject: [jdk22] Integrated: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
References: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
Message-ID: <yCyGyO_7UOEIfk5gKLcCBlk8BCsqOlMFX4IWvaSylG4=.da243501-12cc-4ee5-ab6f-7c2e64b202a3@github.com>

On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Backport of JDK-8322041

This pull request has now been integrated.

Changeset: a05f3d10
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/a05f3d10cc374297fd9b0fa27305c9b26f8081d2
Stats:     290 lines in 36 files changed: 166 ins; 15 del; 109 mod

8322041: JDK 22 RDP1 L10n resource files update

Reviewed-by: kcr, naoto
Backport-of: b061b6678fde891974d5b58cec963b3481099a8d

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

PR: https://git.openjdk.org/jdk22/pull/22

From erikj at openjdk.org  Thu Dec 21 14:21:46 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 21 Dec 2023 14:21:46 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <5tfqJ0axChFrBuu-YP6qxuVp6w98q26qBt-jusjSPuM=.a81fb73b-49cf-4391-99c0-f31a53f8d431@github.com>

On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

The build changes look ok.

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

PR Review: https://git.openjdk.org/jdk/pull/16208#pullrequestreview-1793061991

From mail2akash97 at gmail.com  Sun Dec 24 08:57:45 2023
From: mail2akash97 at gmail.com (Keerthivasan Raghavan)
Date: Sun, 24 Dec 2023 14:27:45 +0530
Subject: Programmatic creation of class files and self modifying code
Message-ID: <CAK2J2tR4qBZ6rdECoHEPp7ft2bY43oP_Dn-Heyo06u1LnP5JUg@mail.gmail.com>

Hi All,

I am a newbie to java. How do I programmatically create "*.class" files
using the compiler API? I do not want to parse "*.java" files , but
generate "*.class" files. This brings me to the next question of how to
execute dynamically generated byte code: just like JRE jas JIT I would like
to programmatically JIT java byte code and execute it. This is inline with
the concept of self modifying code:

https://en.wikipedia.org/wiki/Self-modifying_code

Any pointers/code-snippets to the compiler API that I can use would be
helpful.

Thank you,
Keerthivasan Raghavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231224/ae9efedf/attachment.htm>

From liangchenblue at gmail.com  Sun Dec 24 12:10:42 2023
From: liangchenblue at gmail.com (-)
Date: Sun, 24 Dec 2023 06:10:42 -0600
Subject: Programmatic creation of class files and self modifying code
In-Reply-To: <CAK2J2tR4qBZ6rdECoHEPp7ft2bY43oP_Dn-Heyo06u1LnP5JUg@mail.gmail.com>
References: <CAK2J2tR4qBZ6rdECoHEPp7ft2bY43oP_Dn-Heyo06u1LnP5JUg@mail.gmail.com>
Message-ID: <CABe8uE1_afNJb8r=26LeCXrHBCU0RR_TWVSruDgzq3Tpp=3MxQ@mail.gmail.com>

Hello Keerthivasan,
Currently, most Java applications parse and create Class Files with ASM
(short for "assembly") library, available at https://asm.ow2.io. It
requires Java 6 and above.
Given Java 6 is really old, Java Core Libraries is introducing the
Class-File API https://openjdk.org/jeps/457, allowing the Class File
handling to evolve with Java itself for better forward compatibility, as
existing ASM fails every time Java rolls out a new version.
In addition, javac uses an internal library in com.sun.tools, which is
planned to be replaced by Class-File API in the long run, though it might
be only after everything else has migrated due to javac having high
compatibility requirements.

For executing defined bytecode, there are 2 main ways:
1. You will define a custom ClassLoader with an accessible
defineClass(String, byte[], int, int), which works for all Java versions,
but is chunky (as you need to define a class to access defineClass)
2. You will use MethodHandles.Lookup.defineClass and
MethodHandles.Lookup.defineHiddenClass, available in Java 12 and 16
respectively. They are much more convenient, but can only define classes in
the same package. In addition, defineHiddenClass is the only way to define
"hidden classes", which unlike regular classes, can be unloaded when it's
no longer needed. (Previously, it was done by custom ClassLoaders that are
discarded explicitly)

P.S. The compiler-dev list is focused around development around javac, and
your question seems a bit off-topic. But I don't know which list is proper
for this question either.

Best

On Sun, Dec 24, 2023 at 2:58?AM Keerthivasan Raghavan <
mail2akash97 at gmail.com> wrote:

> Hi All,
>
> I am a newbie to java. How do I programmatically create "*.class" files
> using the compiler API? I do not want to parse "*.java" files , but
> generate "*.class" files. This brings me to the next question of how to
> execute dynamically generated byte code: just like JRE jas JIT I would like
> to programmatically JIT java byte code and execute it. This is inline with
> the concept of self modifying code:
>
> https://en.wikipedia.org/wiki/Self-modifying_code
>
> Any pointers/code-snippets to the compiler API that I can use would be
> helpful.
>
> Thank you,
> Keerthivasan Raghavan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231224/4974af86/attachment.htm>

From liangchenblue at gmail.com  Sun Dec 24 15:07:46 2023
From: liangchenblue at gmail.com (-)
Date: Sun, 24 Dec 2023 09:07:46 -0600
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
Message-ID: <CABe8uE2uGN2MXLReXL3dBEDXFsVcURSAbGF3X6W839TGDVu7ww@mail.gmail.com>

Hi Przemek,
Since you say this happens "intermittently", like how often does it happen
(like 50% of the time or way less frequent)? And does it happen with Java
21 as well? I have tried to create minimal cases to reproduce on Java 21,
but to no avail.
I think the class 222 you've attached in the emails should be the correct
one, while class 80 seems to be wrong, as the PermittedSubclasses should be
declared in class file in the order they are present in the source file.

A preliminary examination shows that other 2 attributes NestMembers and
InnerClasses are solely handled by ClassWriter while the implicit
PermittedSubclasses depends on TypeEnter's processing order. That might be
a clue if we can confirm that this happens on Java 21.

Chen

On Mon, Dec 18, 2023 at 2:51?AM Przemek Bielicki <pbielicki at gmail.com>
wrote:

> Hey Folks,
>
> I'm not 100% sure it's the best idea to post it here but I have no access
> to the JDK JIRA (yet?) ?
>
> Last week I had a huge headache because of a bug I discovered in the Java
> compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 (mixed mode,
> sharing). I'm pretty certain it's a bug because my expectation is that the
> compiler MUST produce deterministic output of the compiled classes - at
> least when the JDK version is the same.
>
> *## Expected behavior*
>
> Java compiler produces deterministic output i.e compiled byte code is
> exactly the same (SHA-wise) and is independent of the operating system
> type, version and other variables.
>
> *## Bug description*
>
> When compiling 1700+ classes in one of our modules on different CI agents
> (with exact same JDK version) I noticed intermittent SHA differences (of
> the compiled classes) that originated from a single class (the
> attached GradleExecGraphNodeExecutionInfo.java file.) It's a
> sealed interface and it uses records - I have an impression that using
> these two in conjunction plays a role here.
>
> I also attach the compiled bytecode coming from two different CI agents.
> If you compare the bytecode you will notice this:
> [image: image.png]
> The only difference (if the image is not displayed correctly) is that two
> same bytes (at the 0x440 position) switch the order depending on where the
> class is compiled. I didn't check the meaning of those bytes - I hope you
> can help here.
>
> "javap -c -l -private" shows that the output is exactly the same (but it
> isn't).
>
> The only difference between the CI nodes is the Linux kernel version
> (Linux 5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-generic (amd64).
> I was able to reproduce this behavior consistently when I compiled this
> module on different CI agents with the same difference in the Linux kernel.
> Here's the screen from Develocity showing the diff in the infrastructure.
> [image: image.png]
>
> I tried to reproduce this problem with the minimal reproducer (by
> extracting the sealed interface outside of the big module) but I failed
> here. The produced byte code was the same.
>
> Please let me know if you need to check sources of the other classes
> referenced by this sealed interface. I'd need to get an approval before
> sharing them publicly.
>
> Cheers,
> Przemek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231224/ceee21f3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9238 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231224/ceee21f3/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 165378 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231224/ceee21f3/image-0003.png>

From pbielicki at gmail.com  Thu Dec 28 14:44:43 2023
From: pbielicki at gmail.com (Przemek Bielicki)
Date: Thu, 28 Dec 2023 15:44:43 +0100
Subject: [Bug] javac gives non-deterministic output (for sealed interface
 with records)
In-Reply-To: <CABe8uE2uGN2MXLReXL3dBEDXFsVcURSAbGF3X6W839TGDVu7ww@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <CABe8uE2uGN2MXLReXL3dBEDXFsVcURSAbGF3X6W839TGDVu7ww@mail.gmail.com>
Message-ID: <CAMvdueAzx-YhDzQf2FU7b6T3Ywx8GfwiP+mic4d=N3mkbAqhpQ@mail.gmail.com>

Hi Chen,

I have two classes that use the same syntax. I can always reproduce this
"issue". There is a caveat though. Once the problem appears in the first
compiled class, another time in the second and yet another time in both
classes. It is reproducible in JDK 23 - Vicente sent me a patched JDK 23
with extra logging and I was able to catch the different order of
processing the permits depending on where those classes were compiled:

:scans-server:compileJava
[javac-log]: adding Task to GradleExecGraphNodeExecutionInfo
[javac-log]: permitted list is now: Task,
[javac-log]: adding Transform to GradleExecGraphNodeExecutionInfo
[javac-log]: permitted list is now: Task, Transform,

vs.

 :scans-server:compileJava
[javac-log]: adding Transform to GradleExecGraphNodeExecutionInfo
[javac-log]: permitted list is now: Transform,
[javac-log]: adding Task to GradleExecGraphNodeExecutionInfo
[javac-log]: permitted list is now: Transform, Task,

We'll continue our investigations in January (I hope).

If you think that the class 80 is wrong then it's coming from the node with
"Linux 5.4.0-*166*-generic" kernel (Ubuntu 20.04.6 LTS).
I am able to reproduce this issue with the same frequency on any node that
is using the same kernel version. This is super weird but this minor kernel
version difference is the only indicator that I was able to catch.

I hope that helps.

Cheers,
Przemek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231228/ff7da312/attachment.htm>