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:
References:
Message-ID:
On Thu, 30 Nov 2023 11:03:09 GMT, Aggelos Biboudis 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
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:
References:
Message-ID:
On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy 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:
References:
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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Thu, 30 Nov 2023 16:11:01 GMT, Jim Laskey 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:
References:
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 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:
References:
Message-ID:
On Thu, 30 Nov 2023 15:00:00 GMT, Pavel Rappo 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
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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Fri, 1 Dec 2023 12:41:16 GMT, Christian Stein 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: * 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.
< 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.
< 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.
> 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 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.
> 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:
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>
Message-ID:
On Wed, 29 Nov 2023 08:46:46 GMT, Per Minborg 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` 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:
> 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:
On Mon, 20 Nov 2023 17:24:03 GMT, Aggelos Biboudis 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 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
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:
References:
Message-ID:
> 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:
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:
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:
References:
Message-ID:
On Fri, 1 Dec 2023 15:21:37 GMT, Eirik Bjorsnos 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:
References:
Message-ID:
On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy 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:
References:
Message-ID:
On Wed, 29 Nov 2023 03:05:19 GMT, Joe Darcy 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:
References:
Message-ID:
On Wed, 29 Nov 2023 03:05:19 GMT, Joe Darcy 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
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:
References:
Message-ID:
On Fri, 1 Dec 2023 15:21:37 GMT, Eirik Bjorsnos 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:
References:
Message-ID: <3VS3eEInw34DdTIvqh3MEUYiHvV4IHTdst9irkJyRX8=.91d497c1-6da5-41b8-8378-9bc7864bdc40@github.com>
On Fri, 1 Dec 2023 15:21:37 GMT, Eirik Bjorsnos 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
Committer: Joe Darcy
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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Fri, 1 Dec 2023 13:00:12 GMT, Jim Laskey 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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Fri, 1 Dec 2023 08:54:06 GMT, Alan Bateman 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:
References:
Message-ID: <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>
On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy 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:
> 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:
On Wed, 13 Sep 2023 09:48:00 GMT, Adam Sotona 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
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:
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-.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:
References:
Message-ID:
On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda 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:
References:
Message-ID:
> 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:
References:
Message-ID: <28YzyXpw17QC6hF3vCqr6Zji-ciBXXaSQ02vP8tH7gI=.40ec86a1-0e34-47bc-aaa6-64216bcd2328@github.com>
On Mon, 4 Dec 2023 08:10:30 GMT, Christian Stein 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:
References:
Message-ID:
> 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:
<28YzyXpw17QC6hF3vCqr6Zji-ciBXXaSQ02vP8tH7gI=.40ec86a1-0e34-47bc-aaa6-64216bcd2328@github.com>
Message-ID:
On Mon, 4 Dec 2023 08:34:29 GMT, Jan Lahoda 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:
References:
Message-ID:
> 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:
References:
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:
References:
<28YzyXpw17QC6hF3vCqr6Zji-ciBXXaSQ02vP8tH7gI=.40ec86a1-0e34-47bc-aaa6-64216bcd2328@github.com>
Message-ID:
On Mon, 4 Dec 2023 08:49:06 GMT, Christian Stein 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:
References:
Message-ID: <5vLxKqST7AYhrmXhRNKfYhpAK_Z2wAOSSfxKX9L9z9s=.136fcc0d-880a-4e2e-ac2c-82c92d10e0cc@github.com>
On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda 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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda 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:
References:
Message-ID:
> 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:
<5vLxKqST7AYhrmXhRNKfYhpAK_Z2wAOSSfxKX9L9z9s=.136fcc0d-880a-4e2e-ac2c-82c92d10e0cc@github.com>
Message-ID:
On Mon, 4 Dec 2023 11:39:04 GMT, Magnus Ihse Bursie 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:
References:
Message-ID:
> 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:
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:
References:
Message-ID:
On Tue, 5 Dec 2023 01:48:14 GMT, Joe Darcy 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:
<8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>
Message-ID:
On Sat, 2 Dec 2023 20:40:57 GMT, Andrey Turbanov 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:
References:
Message-ID:
On Mon, 4 Dec 2023 12:01:06 GMT, Christian Stein 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:
References:
Message-ID:
On Fri, 28 Apr 2023 08:00:36 GMT, Christian Stein 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
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:
References:
Message-ID:
On Mon, 4 Dec 2023 21:27:57 GMT, Jan Lahoda 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:
References:
Message-ID:
On Mon, 4 Dec 2023 21:27:57 GMT, Jan Lahoda 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:
References:
Message-ID:
On Tue, 5 Dec 2023 02:24:19 GMT, Vicente Romero 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:
References:
Message-ID:
> 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:
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:
References:
Message-ID:
On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda 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
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:
References:
Message-ID: <-e_vTn_GqUzw3dwK28pv53UkmtURMHl4NKQKvem487U=.74bf4a8e-df00-4a32-8e69-c8ccc0d0151f@github.com>
On Tue, 5 Dec 2023 16:34:03 GMT, Aggelos Biboudis 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:
References:
Message-ID:
> 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:
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:
References:
Message-ID:
Will a JEP also be created to facilitate discussion and bring greater
awareness?
On Tue, Dec 5, 2023, 8:11?PM Joe Darcy 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:
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:
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID:
On Thu, 30 Nov 2023 21:10:45 GMT, Joe Darcy 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:
References:
Message-ID:
On Tue, 5 Dec 2023 02:24:19 GMT, Vicente Romero 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
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:
References:
Message-ID:
On Wed, 6 Dec 2023 01:05:19 GMT, Joe Darcy 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:
References:
Message-ID:
On Tue, 5 Dec 2023 22:04:48 GMT, Aggelos Biboudis 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 buf = new ListBuffer<>();
> 715: for (List 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:
References:
Message-ID: <0QjKTbtqNmS-eZLWA2tDDqM9RhN_8g4Kkvn-yJZ9F48=.15a9ae4a-d291-4073-9274-5208d7feb521@github.com>
On Wed, 6 Dec 2023 01:05:19 GMT, Joe Darcy 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:
References:
Message-ID: <6qXFe9ml8DQQEsx7Z00OupEooo7-OcN40mrTjfHXGJE=.7bb045fd-0d3e-4077-8d6e-8a0d4156f7e9@github.com>
On Wed, 6 Dec 2023 01:05:19 GMT, Joe Darcy 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:
References:
Message-ID:
On Mon, 4 Dec 2023 11:12:37 GMT, Adam Sotona 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 ClassFile::verify(ClassModel model);
> List ClassFile::verify(byte[] bytes);
> List 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:
References:
Message-ID:
On Wed, 6 Dec 2023 09:26:29 GMT, Maurizio Cimadamore 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 ClassFile::verify(ClassModel model);
>> List ClassFile::verify(byte[] bytes);
>> List 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<String> 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:
References:
Message-ID:
On Wed, 6 Dec 2023 09:42:49 GMT, Adam Sotona 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<String> 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:
References:
Message-ID:
> 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 ClassFile::verify(ClassModel model);
> List ClassFile::verify(byte[] bytes);
> List 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:
References:
Message-ID:
> 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:
References:
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:
<1AUyr2mHtBASXs3ddTq5HxsdBK-C91OOQTIEqGticc0=.8806cce2-2c3a-40b4-b654-1cd88d4f4c36@github.com>
Message-ID:
On Wed, 6 Dec 2023 11:40:47 GMT, Aggelos Biboudis 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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona 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 ClassFile::verify(ClassModel model);
>> List ClassFile::verify(byte[] bytes);
>> List 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:
References:
Message-ID:
On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona