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 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 Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16947#pullrequestreview-1767786746 From asotona at openjdk.org Wed Dec 6 15:34:46 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 6 Dec 2023 15:34:46 GMT Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API [v2] In-Reply-To: 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 Thank you for the reviews. Yes, next step is to improve verifier range and also cover it with negative tests (see https://github.com/openjdk/jdk/pull/16809/files#diff-a23859572e86e946a9ce66361e64e4b7e4473f134bb49a248fccd70d2ac96ea2) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16947#issuecomment-1843120837 From asotona at openjdk.org Wed Dec 6 15:34:48 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 6 Dec 2023 15:34:48 GMT Subject: Integrated: 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API In-Reply-To: References: Message-ID: <9Sx8G-RVNRjecpYkIvTBIt4_Y7knwYVeOJeMUyJ9tyA=.bc0716de-0e84-4267-bacf-02eb6b597a14@github.com> 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 This pull request has now been integrated. Changeset: 0217b5ac Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/0217b5ac8b25db96fce026ac027b18024e25a329 Stats: 94 lines in 11 files changed: 44 ins; 32 del; 18 mod 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API Reviewed-by: jlahoda, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16947 From abimpoudis at openjdk.org Wed Dec 6 15:37:51 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 6 Dec 2023 15:37:51 GMT Subject: Integrated: 8320144: Compilation crashes when a custom annotation with invalid default value is used In-Reply-To: References: Message-ID: 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. This pull request has now been integrated. Changeset: 90e433d7 Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/90e433d72e73abf3252969f535451b56ecacc952 Stats: 29 lines in 3 files changed: 27 ins; 1 del; 1 mod 8320144: Compilation crashes when a custom annotation with invalid default value is used Reviewed-by: vromero, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/16977 From jlahoda at openjdk.org Wed Dec 6 16:33:36 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 6 Dec 2023 16:33:36 GMT Subject: RFR: 8320948: NPE due to unreported compiler error In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 14:51:15 GMT, Vicente Romero wrote: > The compiler is using some heuristics to decide whether or not to report a compiler error while doing recovery on deferred types. For the erroneous code included in the test case, the current heuristics decide not to report the error so ASTs with null types manage to get up to the code generation phase. This fix's proposal is to look into the speculative types of a deferred type and if all the speculative types are erroneous, then use a recovery type as the target type, which later on in the pipeline will imply reporting errors if any > > TIA Looks reasonable to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16923#pullrequestreview-1768065065 From vromero at openjdk.org Wed Dec 6 16:50:53 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 6 Dec 2023 16:50:53 GMT Subject: Integrated: 8320948: NPE due to unreported compiler error In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 14:51:15 GMT, Vicente Romero wrote: > The compiler is using some heuristics to decide whether or not to report a compiler error while doing recovery on deferred types. For the erroneous code included in the test case, the current heuristics decide not to report the error so ASTs with null types manage to get up to the code generation phase. This fix's proposal is to look into the speculative types of a deferred type and if all the speculative types are erroneous, then use a recovery type as the target type, which later on in the pipeline will imply reporting errors if any > > TIA This pull request has now been integrated. Changeset: a9cb120d Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/a9cb120d03e5b2efa244086e213d3b9e4706558a Stats: 35 lines in 3 files changed: 34 ins; 0 del; 1 mod 8320948: NPE due to unreported compiler error Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/16923 From darcy at openjdk.org Wed Dec 6 17:40:47 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 6 Dec 2023 17:40:47 GMT Subject: RFR: JDK-8321073: Defer policy of disabling annotation processing by default [v2] In-Reply-To: References: 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 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typos found in code review. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16988/files - new: https://git.openjdk.org/jdk/pull/16988/files/3a6d5abf..f63cb08f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16988&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16988&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16988.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16988/head:pull/16988 PR: https://git.openjdk.org/jdk/pull/16988 From darcy at openjdk.org Wed Dec 6 18:39:47 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 6 Dec 2023 18:39:47 GMT Subject: Integrated: JDK-8321073: Defer policy of disabling annotation processing by default In-Reply-To: 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 This pull request has now been integrated. Changeset: 3edc24a7 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/3edc24a71d29632e0a2166a64fc25ce83f631b47 Stats: 61 lines in 5 files changed: 18 ins; 26 del; 17 mod 8321073: Defer policy of disabling annotation processing by default Reviewed-by: vromero, jlahoda, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16988 From darcy at openjdk.org Wed Dec 6 18:41:57 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 6 Dec 2023 18:41:57 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v6] In-Reply-To: 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 18 commits: - Regenerate JDK 22 symbol files. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Add symbol files. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Update symbol files to JDK 22 b26. - ... and 8 more: https://git.openjdk.org/jdk/compare/db5613af...efe849f6 ------------- Changes: https://git.openjdk.org/jdk/pull/16505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=05 Stats: 4866 lines in 98 files changed: 4828 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/16505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505 PR: https://git.openjdk.org/jdk/pull/16505 From darcy at openjdk.org Thu Dec 7 06:33:02 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 7 Dec 2023 06:33:02 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v7] In-Reply-To: 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 21 commits: - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Regenerate JDK 22 symbol files. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Add symbol files. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - ... and 11 more: https://git.openjdk.org/jdk/compare/632a3c56...4a871372 ------------- Changes: https://git.openjdk.org/jdk/pull/16505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=06 Stats: 4866 lines in 98 files changed: 4828 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/16505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505 PR: https://git.openjdk.org/jdk/pull/16505 From darcy at openjdk.org Thu Dec 7 06:41:09 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 7 Dec 2023 06:41:09 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v8] In-Reply-To: References: Message-ID: > Time to start making preparations for JDK 23. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyright year. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16505/files - new: https://git.openjdk.org/jdk/pull/16505/files/4a871372..a1aa187c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=06-07 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505 PR: https://git.openjdk.org/jdk/pull/16505 From jlahoda at openjdk.org Thu Dec 7 06:46:48 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 7 Dec 2023 06:46:48 GMT Subject: RFR: 8321164: javac with annotation processor throws AssertionError: Filling jrt:/... during JarFileObject[/...] Message-ID: This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4. The problem (to my understanding) is as follows: - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this. - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion: https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401 - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations: https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423 The problem is that this method uses `Type.getKind()` which completes. The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic. ------------- Commit messages: - Restoring behavior w.r.t. null, removing trailing whitespace. - 8321164: javac with annotation processor throws AssertionError: Filling jrt:/... during JarFileObject[/...] Changes: https://git.openjdk.org/jdk/pull/17001/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17001&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321164 Stats: 134 lines in 2 files changed: 124 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17001.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17001/head:pull/17001 PR: https://git.openjdk.org/jdk/pull/17001 From vromero at openjdk.org Thu Dec 7 06:46:49 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 7 Dec 2023 06:46:49 GMT Subject: RFR: 8321164: javac with annotation processor throws AssertionError: Filling jrt:/... during JarFileObject[/...] In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 18:52:48 GMT, Jan Lahoda wrote: > This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4. > > The problem (to my understanding) is as follows: > - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this. > - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion: > https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401 > - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations: > https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423 > > The problem is that this method uses `Type.getKind()` which completes. > > The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic. lgtm, nice test ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17001#pullrequestreview-1768663899 From mcimadamore at openjdk.org Thu Dec 7 06:46:50 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 7 Dec 2023 06:46:50 GMT Subject: RFR: 8321164: javac with annotation processor throws AssertionError: Filling jrt:/... during JarFileObject[/...] In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 18:52:48 GMT, Jan Lahoda wrote: > This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4. > > The problem (to my understanding) is as follows: > - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this. > - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion: > https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401 > - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations: > https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423 > > The problem is that this method uses `Type.getKind()` which completes. > > The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic. Marked as reviewed by mcimadamore (Reviewer). src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2424: > 2422: ARRAY, MODULE, TYPEVAR, WILDCARD: > 2423: return s.dropMetadata(Annotations.class); > 2424: case VOID, METHOD, PACKAGE, FORALL, DEFERRED, BOT, Not that it should matter much (as it cannot be annotated) but the `BOT` type seemed to receive a different treatment before (the kind for that is `NULL`). Separately, I'm a bit hazy of the rationale behind the logic here. E.g. is it an optimization to avoid removing metadata that we know isn't there, or is it something else? Anyway, not something to fix now (mostly thinking aloud) ------------- PR Review: https://git.openjdk.org/jdk/pull/17001#pullrequestreview-1768703387 PR Review Comment: https://git.openjdk.org/jdk/pull/17001#discussion_r1418028005 From jlahoda at openjdk.org Thu Dec 7 06:49:34 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 7 Dec 2023 06:49:34 GMT Subject: RFR: 8321164: javac with annotation processor throws AssertionError: Filling jrt:/... during JarFileObject[/...] In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 22:03:29 GMT, Maurizio Cimadamore wrote: >> This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4. >> >> The problem (to my understanding) is as follows: >> - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this. >> - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion: >> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401 >> - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations: >> https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423 >> >> The problem is that this method uses `Type.getKind()` which completes. >> >> The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic. > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2424: > >> 2422: ARRAY, MODULE, TYPEVAR, WILDCARD: >> 2423: return s.dropMetadata(Annotations.class); >> 2424: case VOID, METHOD, PACKAGE, FORALL, DEFERRED, BOT, > > Not that it should matter much (as it cannot be annotated) but the `BOT` type seemed to receive a different treatment before (the kind for that is `NULL`). Separately, I'm a bit hazy of the rationale behind the logic here. E.g. is it an optimization to avoid removing metadata that we know isn't there, or is it something else? Anyway, not something to fix now (mostly thinking aloud) Uh, I somehow missed the `NULL`. Thanks for noticing. My intent here is not to change the behavior if possible, so I restored the `NULL`/`BOT` behavior as it was before. As for the logic, I agree, I don't know why it is written like this. We could possibly try to cleanup early in a release and test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17001#discussion_r1418465050 From jlahoda at openjdk.org Thu Dec 7 09:12:51 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 7 Dec 2023 09:12:51 GMT Subject: Integrated: 8321164: javac with annotation processor throws AssertionError: Filling jrt:/... during JarFileObject[/...] In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 18:52:48 GMT, Jan Lahoda wrote: > This is a latent bug revealed by the recent JDK-8225377/https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4. > > The problem (to my understanding) is as follows: > - `ClassReader` cannot be used recursively, i.e. while completing one class from a classfile, we cannot complete another one. `ClassReader` carefully avoids situations like this. > - when reading an anonymous class, the `EnclosingMethod` attribute is read, and the enclosing method must be found. `ClassReader` uses a special `ClassReader. isSameBinaryType` method, that is supposed to avoid completion: > https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1401 > - the `isSameBinaryType` method uses erasure, and if the given type has type annotations, the erasure will try to remove the annotations: > https://github.com/openjdk/jdk/blob/3edc24a71d29632e0a2166a64fc25ce83f631b47/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L2423 > > The problem is that this method uses `Type.getKind()` which completes. > > The proposal in this patch is to avoid the completion by not using `getKind`, but rather `getTag`. While I am not completely sure why the code avoids doing `dropMetadata` for some types, I tried to replicate the existing behavior. One caveat is that certain types may have `getTag() == CLASS`, but `getKind() == ERROR` (e.g. if the class is not found). The new code is not replicating this aspect, as we cannot reliably determine whether a `ClassType` is erroneous or not without completing it. But, it is not clear to me why dropping annotations from an erroneous `ClassType` should be problematic. This pull request has now been integrated. Changeset: 03c45951 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/03c4595173d564df97aa4f2b3156adcd4be379fa Stats: 134 lines in 2 files changed: 124 ins; 0 del; 10 mod 8321164: javac with annotation processor throws AssertionError: Filling jrt:/... during JarFileObject[/...] Reviewed-by: vromero, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/17001 From darcy at openjdk.org Thu Dec 7 17:04:41 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 7 Dec 2023 17:04:41 GMT Subject: Integrated: JDK-8319413: Start of release updates for JDK 23 In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote: > Time to start making preparations for JDK 23. This pull request has now been integrated. Changeset: 519ecd35 Author: Joe Darcy Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/519ecd352a66633589f160db7390647d90e36b99 Stats: 4872 lines in 98 files changed: 4828 ins; 0 del; 44 mod 8319413: Start of release updates for JDK 23 8319414: Add SourceVersion.RELEASE_23 8319416: Add source 23 and target 23 to javac Reviewed-by: iris, erikj, alanb, vromero ------------- PR: https://git.openjdk.org/jdk/pull/16505 From jlahoda at openjdk.org Fri Dec 8 16:35:24 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 8 Dec 2023 16:35:24 GMT Subject: RFR: 8321582: yield .class not parsed correctly. Message-ID: Fixing the parser to accept primitive type after yield. I didn't want to update the parts of the patch that remain, to not obstruct history, but I used the multi-label case for the new labels. ------------- Commit messages: - 8321582: yield .class not parsed correctly. Changes: https://git.openjdk.org/jdk/pull/17035/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17035&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321582 Stats: 29 lines in 2 files changed: 27 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17035.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17035/head:pull/17035 PR: https://git.openjdk.org/jdk/pull/17035 From vromero at openjdk.org Fri Dec 8 17:31:14 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 8 Dec 2023 17:31:14 GMT Subject: RFR: 8321582: yield .class not parsed correctly. In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 16:30:21 GMT, Jan Lahoda wrote: > Fixing the parser to accept primitive type after yield. > > I didn't want to update the parts of the patch that remain, to not obstruct history, but I used the multi-label case for the new labels. looks sensible do we need a CSR for this one? test/langtools/tools/javac/switchexpr/ExpressionSwitch.java line 153: > 151: } > 152: > 153: private Class yieldPrimiteDotClass(String s) { typo: Primite -> Primitive ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17035#pullrequestreview-1772858259 PR Comment: https://git.openjdk.org/jdk/pull/17035#issuecomment-1847564565 PR Review Comment: https://git.openjdk.org/jdk/pull/17035#discussion_r1420815801 From cushon at openjdk.org Fri Dec 8 18:08:16 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 8 Dec 2023 18:08:16 GMT Subject: RFR: 8043226: Better diagnostics for non-applicable type annotations In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 01:21:28 GMT, Liam Miller-Cushon wrote: > Hi, > > Please consider this improvement to diagnostics on inadmissable type annotations. > > [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug. > > I have some notes on details of the proposed changes below. > > --- > > Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. > > As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2. > > This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names. > > Before: > > > test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA > @TA Outer.SInner osi; > ^ > > > After: > > > test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA > @TA Outer.SInner osi; > ^ > (to annotate a qualified type, write Outer. at TA SInner) > > > --- > > Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`. > > This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location. > > This also improves the ordering of the diagnostic in the output, since attribution errors are report before type annotation validation errors in the l... Please keep this one open for now ------------- PR Comment: https://git.openjdk.org/jdk/pull/16592#issuecomment-1847607054 From darcy at openjdk.org Fri Dec 8 18:21:36 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 8 Dec 2023 18:21:36 GMT Subject: RFR: JDK-8320790: Update --release 22 symbol information for JDK 22 build 27 Message-ID: Usual update of the symbol files for a new build. ------------- Commit messages: - JDK-8320790: Update --release 22 symbol information for JDK 22 build 27 Changes: https://git.openjdk.org/jdk/pull/17036/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17036&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320790 Stats: 6719 lines in 9 files changed: 6706 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/17036.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17036/head:pull/17036 PR: https://git.openjdk.org/jdk/pull/17036 From iris at openjdk.org Fri Dec 8 18:31:17 2023 From: iris at openjdk.org (Iris Clark) Date: Fri, 8 Dec 2023 18:31:17 GMT Subject: RFR: JDK-8320790: Update --release 22 symbol information for JDK 22 build 27 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 18:15:08 GMT, Joe Darcy wrote: > Usual update of the symbol files for a new build. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17036#pullrequestreview-1772945723 From jjg at openjdk.org Fri Dec 8 19:03:14 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 8 Dec 2023 19:03:14 GMT Subject: RFR: JDK-8320790: Update --release 22 symbol information for JDK 22 build 27 In-Reply-To: References: Message-ID: <0PUDHhZaWx9aqky6h271aZULeAidaITnvB06wCeEXMY=.17bf68a3-9744-4326-b698-8105adeac823@github.com> On Fri, 8 Dec 2023 18:15:08 GMT, Joe Darcy wrote: > Usual update of the symbol files for a new build. Marked as reviewed by jjg (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17036#pullrequestreview-1772995238 From darcy at openjdk.org Fri Dec 8 19:36:21 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 8 Dec 2023 19:36:21 GMT Subject: Integrated: JDK-8320790: Update --release 22 symbol information for JDK 22 build 27 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 18:15:08 GMT, Joe Darcy wrote: > Usual update of the symbol files for a new build. This pull request has now been integrated. Changeset: 5c12a182 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/5c12a182e3f9aed8d075bb066cb8a093abab92de Stats: 6719 lines in 9 files changed: 6706 ins; 1 del; 12 mod 8320790: Update --release 22 symbol information for JDK 22 build 27 Reviewed-by: iris, jjg ------------- PR: https://git.openjdk.org/jdk/pull/17036 From jlahoda at openjdk.org Mon Dec 11 09:57:39 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 11 Dec 2023 09:57:39 GMT Subject: RFR: 8321582: yield .class not parsed correctly. [v2] In-Reply-To: References: Message-ID: > Fixing the parser to accept primitive type after yield. > > I didn't want to update the parts of the patch that remain, to not obstruct history, but I used the multi-label case for the new labels. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fxing typo. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17035/files - new: https://git.openjdk.org/jdk/pull/17035/files/48107768..c1d80fde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17035&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17035&range=00-01 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/17035.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17035/head:pull/17035 PR: https://git.openjdk.org/jdk/pull/17035 From jlahoda at openjdk.org Mon Dec 11 09:57:41 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 11 Dec 2023 09:57:41 GMT Subject: RFR: 8321582: yield .class not parsed correctly. In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 17:28:54 GMT, Vicente Romero wrote: > do we need a CSR for this one? I don't think so - we are enhancing the set of programs that compile, improving adherence to the specification (which is unchanged). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17035#issuecomment-1849699173 From jlahoda at openjdk.org Mon Dec 11 12:23:25 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 11 Dec 2023 12:23:25 GMT Subject: Integrated: 8321582: yield .class not parsed correctly. In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 16:30:21 GMT, Jan Lahoda wrote: > Fixing the parser to accept primitive type after yield. > > I didn't want to update the parts of the patch that remain, to not obstruct history, but I used the multi-label case for the new labels. This pull request has now been integrated. Changeset: ce8399fd Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/ce8399fd6071766114f5f201b6e44a7abdba9f5a Stats: 29 lines in 2 files changed: 27 ins; 1 del; 1 mod 8321582: yield .class not parsed correctly. Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/17035 From jlahoda at openjdk.org Mon Dec 11 12:54:57 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 11 Dec 2023 12:54:57 GMT Subject: [jdk22] RFR: 8321582: yield .class not parsed correctly. Message-ID: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com> Hi all, This pull request contains a backport of commit [ce8399fd](https://github.com/openjdk/jdk/commit/ce8399fd6071766114f5f201b6e44a7abdba9f5a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Jan Lahoda on 11 Dec 2023 and was reviewed by Vicente Romero. Thanks! ------------- Commit messages: - Backport ce8399fd6071766114f5f201b6e44a7abdba9f5a Changes: https://git.openjdk.org/jdk22/pull/6/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=6&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321582 Stats: 29 lines in 2 files changed: 27 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk22/pull/6.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/6/head:pull/6 PR: https://git.openjdk.org/jdk22/pull/6 From abimpoudis at openjdk.org Mon Dec 11 16:08:53 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 11 Dec 2023 16:08:53 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v34] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: <5d4KAKHRi3RXoFSlZ6FtQx6OKetrSwnBU8XP1AbAhhY=.e1f9236c-e039-4bc4-838a-38a43caff265@github.com> > This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/ Aggelos Biboudis has updated the pull request incrementally with 11 additional commits since the last revision: - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns - Fixed switch in the cases of unboxing and widening - Merge branch 'JDK-8319220' into primitive-patterns - Merge branch 'master' into JDK-8319220 - reflecting review comment: fixing letter case. - Reflecting review feedback. - Some more get->orElseThrow - Reflecting review feedback. - Avoiding generating dead code - review feedback. - Cleanup. - ... and 1 more: https://git.openjdk.org/jdk/compare/2b2405cc...fac9ca98 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15638/files - new: https://git.openjdk.org/jdk/pull/15638/files/2b2405cc..fac9ca98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=32-33 Stats: 689 lines in 5 files changed: 423 ins; 222 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From abimpoudis at openjdk.org Mon Dec 11 16:16:45 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 11 Dec 2023 16:16:45 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v35] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: > This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/ Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Remove trailing spaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15638/files - new: https://git.openjdk.org/jdk/pull/15638/files/fac9ca98..4fbdd708 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=33-34 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From abimpoudis at openjdk.org Mon Dec 11 17:14:02 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 11 Dec 2023 17:14:02 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v36] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: > This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/ Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits: - Merge branch 'master' into primitive-patterns - Remove trailing spaces - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns - Fixed switch in the cases of unboxing and widening - Merge branch 'JDK-8319220' into primitive-patterns - Merge branch 'master' into JDK-8319220 - reflecting review comment: fixing letter case. - Reflecting review feedback. - Some more get->orElseThrow - Reflecting review feedback. - ... and 42 more: https://git.openjdk.org/jdk/compare/b270f30d...65457894 ------------- Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=35 Stats: 3258 lines in 41 files changed: 2995 ins; 109 del; 154 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From abimpoudis at openjdk.org Mon Dec 11 19:44:01 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 11 Dec 2023 19:44:01 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v37] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: <9ldTg1DpAuh8op3uQxpkt_9nXPHbvC8q-re-55L_lsU=.6b4019f2-b5ef-46da-bc9d-dde8308d2f3d@github.com> > This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/ Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15638/files - new: https://git.openjdk.org/jdk/pull/15638/files/65457894..7a71ffa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=36 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=35-36 Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From hannesw at openjdk.org Mon Dec 11 21:23:40 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 11 Dec 2023 21:23:40 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method Message-ID: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location). ------------- Commit messages: - Additional test - JDK-8164094: javadoc allows to create a @link to a non-existent method Changes: https://git.openjdk.org/jdk/pull/17069/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17069&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8164094 Stats: 56 lines in 2 files changed: 29 ins; 1 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/17069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17069/head:pull/17069 PR: https://git.openjdk.org/jdk/pull/17069 From darcy at openjdk.org Tue Dec 12 02:52:41 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 12 Dec 2023 02:52:41 GMT Subject: RFR: JDK-8320200: Use Elements predicates for record constructors to improve print output Message-ID: Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors. ------------- Commit messages: - JDK-8320200: Use Elements predicates for record constructors to improve print output Changes: https://git.openjdk.org/jdk/pull/17073/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17073&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320200 Stats: 19 lines in 1 file changed: 11 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17073.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17073/head:pull/17073 PR: https://git.openjdk.org/jdk/pull/17073 From darcy at openjdk.org Tue Dec 12 02:52:42 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 12 Dec 2023 02:52:42 GMT Subject: RFR: JDK-8320200: Use Elements predicates for record constructors to improve print output In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 02:47:18 GMT, Joe Darcy wrote: > Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors. For a simple record like: public record ComplexRecord(double real, double imaginary) { /** * Document the ctor. */ ComplexRecord { this.real = real; this.imaginary = imaginary; } } the current printing processor output is public record ComplexRecord(double real, double imaginary) { private final double real; private final double imaginary; /** * Document the ctor. */ ComplexRecord(double real, double imaginary); public final java.lang.String toString(); public final int hashCode(); public final boolean equals(java.lang.Object o); public double real(); public double imaginary(); } and after this change it will be public record ComplexRecord(double real, double imaginary) { private final double real; private final double imaginary; /** * Document the ctor. */ ComplexRecord {} /* compact constructor */ ; public final java.lang.String toString(); public final int hashCode(); public final boolean equals(java.lang.Object o); public double real(); public double imaginary(); } All langtools regression tests pass with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17073#issuecomment-1851217614 From darcy at openjdk.org Tue Dec 12 02:55:12 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 12 Dec 2023 02:55:12 GMT Subject: RFR: JDK-8320200: Use Elements predicates for record constructors to improve print output In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 02:47:18 GMT, Joe Darcy wrote: > Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors. PS It would be possible to add a comment on a record's canonical constructor, but at this junction I didn't think that was worthwhile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17073#issuecomment-1851219868 From darcy at openjdk.org Tue Dec 12 03:13:50 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 12 Dec 2023 03:13:50 GMT Subject: RFR: JDK-8321827: Remove unnecessary suppress warnings annotations from the printing processor Message-ID: With JEP 463, a utility method like "isUnnamed" is no longer included in javax.lang.model so there is no uses of methods associated with preview features. Therefore, the `@SuppressWarnings` annotations can (and should be) removed. ------------- Commit messages: - JDK-8321827: Remove unnecessary suppress warnings annotations from the printing processo Changes: https://git.openjdk.org/jdk/pull/17074/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17074&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321827 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17074/head:pull/17074 PR: https://git.openjdk.org/jdk/pull/17074 From duke at openjdk.org Tue Dec 12 07:52:48 2023 From: duke at openjdk.org (phuchau1989) Date: Tue, 12 Dec 2023 07:52:48 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v12] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 12:42:22 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Removing obsolette test, as suggested. Marked as reviewed by phuchau1989 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/13074#pullrequestreview-1776839680 From hannesw at openjdk.org Tue Dec 12 09:24:35 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Dec 2023 09:24:35 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method In-Reply-To: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Message-ID: On Mon, 11 Dec 2023 21:18:57 GMT, Hannes Walln?fer wrote: > Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location). There are a few cases of this linking pattern in OpenJDK that need to be fixed before this can be integrated. I filed [JDK-8321889](https://bugs.openjdk.org/browse/JDK-8321889). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1851612460 From shade at openjdk.org Tue Dec 12 09:42:53 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 12 Dec 2023 09:42:53 GMT Subject: [jdk22] RFR: 8321582: yield .class not parsed correctly. In-Reply-To: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com> References: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com> Message-ID: On Mon, 11 Dec 2023 12:47:10 GMT, Jan Lahoda wrote: > Hi all, > > This pull request contains a backport of commit [ce8399fd](https://github.com/openjdk/jdk/commit/ce8399fd6071766114f5f201b6e44a7abdba9f5a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jan Lahoda on 11 Dec 2023 and was reviewed by Vicente Romero. > > Thanks! Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk22/pull/6#pullrequestreview-1777043990 From hannesw at openjdk.org Tue Dec 12 09:53:40 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Dec 2023 09:53:40 GMT Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested) type Message-ID: Please review a change to fix JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc (with the correct link being created). With [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors. ------------- Commit messages: - JDK-8321889: JavaDoc method references with wrong (nested) type Changes: https://git.openjdk.org/jdk/pull/17078/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17078&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321889 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17078.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17078/head:pull/17078 PR: https://git.openjdk.org/jdk/pull/17078 From hannesw at openjdk.org Tue Dec 12 10:42:32 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Dec 2023 10:42:32 GMT Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested) type [v2] In-Reply-To: References: Message-ID: > Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors. > > I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references). Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Restore explicit label and remove duplicate word ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17078/files - new: https://git.openjdk.org/jdk/pull/17078/files/53e9cfa0..c7a76b17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17078&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17078&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17078.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17078/head:pull/17078 PR: https://git.openjdk.org/jdk/pull/17078 From alanb at openjdk.org Tue Dec 12 11:07:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 12 Dec 2023 11:07:22 GMT Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested) type [v2] In-Reply-To: References: Message-ID: <4dIjqukV52060edEa6j0AiOv5psHgpEFYXOzYqLKNf4=.cede50ce-09da-484e-9b5d-fc185631e419@github.com> On Tue, 12 Dec 2023 10:42:32 GMT, Hannes Walln?fer wrote: >> Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors. >> >> I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references). >> >> Update: I also fixed two typos in `javax/smartcardio/CardTerminals.java` by removing the duplicate "call" in "... latest call to waitForChange() call". > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Restore explicit label and remove duplicate word Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17078#pullrequestreview-1777214660 From hannesw at openjdk.org Tue Dec 12 11:30:32 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Dec 2023 11:30:32 GMT Subject: Integrated: JDK-8321889: JavaDoc method references with wrong (nested) type In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 09:46:29 GMT, Hannes Walln?fer wrote: > Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors. > > I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references). > > Update: I also fixed two typos in `javax/smartcardio/CardTerminals.java` by removing the duplicate "call" in "... latest call to waitForChange() call". This pull request has now been integrated. Changeset: c5168526 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/c51685267c7bd5a7cee27ebc2bf0d9899cda9d4c Stats: 7 lines in 3 files changed: 0 ins; 2 del; 5 mod 8321889: JavaDoc method references with wrong (nested) type Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17078 From hannesw at openjdk.org Tue Dec 12 12:42:41 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Dec 2023 12:42:41 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method [v2] In-Reply-To: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Message-ID: > Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location). Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8164094 - Additional test - JDK-8164094: javadoc allows to create a @link to a non-existent method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17069/files - new: https://git.openjdk.org/jdk/pull/17069/files/3816b549..4f08440e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17069&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17069&range=00-01 Stats: 248 lines in 16 files changed: 162 ins; 45 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/17069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17069/head:pull/17069 PR: https://git.openjdk.org/jdk/pull/17069 From prappo at openjdk.org Tue Dec 12 13:49:34 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 12 Dec 2023 13:49:34 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method [v2] In-Reply-To: References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Message-ID: On Tue, 12 Dec 2023 12:42:41 GMT, Hannes Walln?fer wrote: >> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location). > > Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8164094 > - Additional test > - JDK-8164094: javadoc allows to create a @link to a non-existent method It's nice to see this issue and its individual sightings being addressed. While I'm a Reviewer, I'm not a compiler person, so my approval means little here. Wait for a compiler person to approve it. Perhaps they might also suggest a better name for the `explicitType` parameter. Separately, it was interesting to see that a field is first searched in the enclosing class or interface, and if not found, searched in the superclass or a superinterface. The order in which a method is searched is the opposite: the superclass or a superinterface, then the enclosing class or interface. ------------- PR Review: https://git.openjdk.org/jdk/pull/17069#pullrequestreview-1777513670 From prappo at openjdk.org Tue Dec 12 13:56:22 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 12 Dec 2023 13:56:22 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method [v2] In-Reply-To: References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Message-ID: <2XjUK3reUMnHKgBUgv4WKHViKp6EGIaW88qeLTPzWE0=.5cdc7588-2ed6-43d7-8125-eca1d6df6092@github.com> On Tue, 12 Dec 2023 13:46:59 GMT, Pavel Rappo wrote: > individual sightings being addressed. I meant in a separate PR #17078. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1852081911 From cstein at openjdk.org Tue Dec 12 15:17:50 2023 From: cstein at openjdk.org (Christian Stein) Date: Tue, 12 Dec 2023 15:17:50 GMT Subject: RFR: 8321739: Source launcher fails with "Not a directory" error Message-ID: Please review this change to allow files sharing names with packages when using the Java source launcher. The now used `!Files.exists()` returns a boolean value on Unix-based file systems instead of throwing an exception as `Files.notExists()` does when one or more elements of the tested path are files (and not directories), in addition of the the last element. Tested: tier1 ------------- Commit messages: - Source launcher fails with "Not a directory" error - Add failing test for JDK-8321739 Changes: https://git.openjdk.org/jdk/pull/17076/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17076&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321739 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17076/head:pull/17076 PR: https://git.openjdk.org/jdk/pull/17076 From jlahoda at openjdk.org Tue Dec 12 15:24:32 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 12 Dec 2023 15:24:32 GMT Subject: RFR: 8321739: Source launcher fails with "Not a directory" error In-Reply-To: References: Message-ID: <9gFsz-TCG0Mao0KStiBrt9ofuw8Ya3wGToIOIA0cpG0=.2dadd6c3-bf2c-443e-97a4-8d1584be0bb6@github.com> On Tue, 12 Dec 2023 08:56:58 GMT, Christian Stein wrote: > Please review this change to allow files sharing names with packages when using the Java source launcher. > > The now used `!Files.exists()` returns a boolean value on Unix-based file systems instead of throwing an exception as `Files.notExists()` does when one or more elements of the tested path are files (and not directories), in addition of the the last element. > > Tested: tier1 Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17076#pullrequestreview-1777765474 From cstein at openjdk.org Tue Dec 12 15:33:34 2023 From: cstein at openjdk.org (Christian Stein) Date: Tue, 12 Dec 2023 15:33:34 GMT Subject: Integrated: 8321739: Source launcher fails with "Not a directory" error In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 08:56:58 GMT, Christian Stein wrote: > Please review this change to allow files sharing names with packages when using the Java source launcher. > > The now used `!Files.exists()` returns a boolean value on Unix-based file systems instead of throwing an exception as `Files.notExists()` does when one or more elements of the tested path are files (and not directories), in addition of the the last element. > > Tested: tier1 This pull request has now been integrated. Changeset: df4ed7ef Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/df4ed7eff7cc4afb2f0bcfdbb2489715ab209737 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod 8321739: Source launcher fails with "Not a directory" error Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/17076 From vromero at openjdk.org Tue Dec 12 15:39:31 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 12 Dec 2023 15:39:31 GMT Subject: [jdk22] RFR: 8321582: yield .class not parsed correctly. In-Reply-To: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com> References: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com> Message-ID: <2lwN4Sd2nMIt2-ogEdQaZu7hSLMezl_yGnGLpK8otzU=.86ec550e-7235-4b69-9860-fc48eb6e753a@github.com> On Mon, 11 Dec 2023 12:47:10 GMT, Jan Lahoda wrote: > Hi all, > > This pull request contains a backport of commit [ce8399fd](https://github.com/openjdk/jdk/commit/ce8399fd6071766114f5f201b6e44a7abdba9f5a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jan Lahoda on 11 Dec 2023 and was reviewed by Vicente Romero. > > Thanks! lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk22/pull/6#pullrequestreview-1777809760 From cstein at openjdk.org Tue Dec 12 15:42:44 2023 From: cstein at openjdk.org (Christian Stein) Date: Tue, 12 Dec 2023 15:42:44 GMT Subject: [jdk22] RFR: 8321739: Source launcher fails with "Not a directory" error Message-ID: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com> Hi all, This pull request contains a backport of commit [df4ed7ef](https://github.com/openjdk/jdk/commit/df4ed7eff7cc4afb2f0bcfdbb2489715ab209737) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Christian Stein on 12 Dec 2023 and was reviewed by Jan Lahoda. Thanks! ------------- Commit messages: - Backport df4ed7eff7cc4afb2f0bcfdbb2489715ab209737 Changes: https://git.openjdk.org/jdk22/pull/10/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=10&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321739 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk22/pull/10.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/10/head:pull/10 PR: https://git.openjdk.org/jdk22/pull/10 From jlahoda at openjdk.org Tue Dec 12 15:42:45 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 12 Dec 2023 15:42:45 GMT Subject: [jdk22] RFR: 8321739: Source launcher fails with "Not a directory" error In-Reply-To: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com> References: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com> Message-ID: On Tue, 12 Dec 2023 15:36:06 GMT, Christian Stein wrote: > Hi all, > > This pull request contains a backport of commit [df4ed7ef](https://github.com/openjdk/jdk/commit/df4ed7eff7cc4afb2f0bcfdbb2489715ab209737) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Christian Stein on 12 Dec 2023 and was reviewed by Jan Lahoda. > > Thanks! Looks good. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk22/pull/10#pullrequestreview-1777813669 From jlaskey at openjdk.org Tue Dec 12 18:37:31 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 12 Dec 2023 18:37:31 GMT Subject: RFR: JDK-8321827: Remove unnecessary suppress warnings annotations from the printing processor In-Reply-To: References: Message-ID: <89yf7O3snDy4rmr9kUm5qsHTj5BDQ6KgqOZ-gVjS3vQ=.9541afba-0dae-46ea-b47c-dc51deda3c8b@github.com> On Tue, 12 Dec 2023 03:08:15 GMT, Joe Darcy wrote: > With JEP 463, a utility method like "isUnnamed" is no longer included in javax.lang.model so there is no uses of methods associated with preview features. Therefore, the `@SuppressWarnings` annotations can (and should be) removed. Marked as reviewed by jlaskey (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17074#pullrequestreview-1778207969 From shurailine at openjdk.org Tue Dec 12 18:46:33 2023 From: shurailine at openjdk.org (Alexandre Iline) Date: Tue, 12 Dec 2023 18:46:33 GMT Subject: RFR: 8288989: Make tests not to depend on the source code In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona wrote: > Two langtool tests depend on the JDK source tree presence. > This patch skips the tests execution in a source-less test environment. > > Please review. > > Thanks, > Adam This seems reasonable. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1852609716 From darcy at openjdk.org Tue Dec 12 18:47:20 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 12 Dec 2023 18:47:20 GMT Subject: Integrated: JDK-8321827: Remove unnecessary suppress warnings annotations from the printing processor In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 03:08:15 GMT, Joe Darcy wrote: > With JEP 463, a utility method like "isUnnamed" is no longer included in javax.lang.model so there is no uses of methods associated with preview features. Therefore, the `@SuppressWarnings` annotations can (and should be) removed. This pull request has now been integrated. Changeset: a3447ec6 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/a3447ec6562c5b4570da964d08ce8ae4c157c961 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8321827: Remove unnecessary suppress warnings annotations from the printing processor Reviewed-by: jlaskey ------------- PR: https://git.openjdk.org/jdk/pull/17074 From vromero at openjdk.org Tue Dec 12 20:29:32 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 12 Dec 2023 20:29:32 GMT Subject: RFR: JDK-8320200: Use Elements predicates for record constructors to improve print output In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 02:47:18 GMT, Joe Darcy wrote: > Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17073#pullrequestreview-1778380198 From darcy at openjdk.org Tue Dec 12 21:03:38 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 12 Dec 2023 21:03:38 GMT Subject: Integrated: JDK-8320200: Use Elements predicates for record constructors to improve print output In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 02:47:18 GMT, Joe Darcy wrote: > Please review this small increase for source fidelity by customizing the printing processor output for record compact constructors. This pull request has now been integrated. Changeset: ac07355f Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/ac07355f5507cdb3a741ec1122e5e9983eac3936 Stats: 19 lines in 1 file changed: 11 ins; 0 del; 8 mod 8320200: Use Elements predicates for record constructors to improve print output Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/17073 From cstein at openjdk.org Tue Dec 12 21:11:35 2023 From: cstein at openjdk.org (Christian Stein) Date: Tue, 12 Dec 2023 21:11:35 GMT Subject: [jdk22] Integrated: 8321739: Source launcher fails with "Not a directory" error In-Reply-To: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com> References: <95o38eD9qSnf8CS5ZoxF6dEJ5_DYef0_VhexVX-MLjE=.11e46ed6-6506-475d-895b-ae2bc0093e24@github.com> Message-ID: On Tue, 12 Dec 2023 15:36:06 GMT, Christian Stein wrote: > Hi all, > > This pull request contains a backport of commit [df4ed7ef](https://github.com/openjdk/jdk/commit/df4ed7eff7cc4afb2f0bcfdbb2489715ab209737) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Christian Stein on 12 Dec 2023 and was reviewed by Jan Lahoda. > > Thanks! This pull request has now been integrated. Changeset: ae77bd00 Author: Christian Stein URL: https://git.openjdk.org/jdk22/commit/ae77bd009f9f291c9dea80daee591538ecb887fc Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod 8321739: Source launcher fails with "Not a directory" error Reviewed-by: jlahoda Backport-of: df4ed7eff7cc4afb2f0bcfdbb2489715ab209737 ------------- PR: https://git.openjdk.org/jdk22/pull/10 From darcy at openjdk.org Tue Dec 12 21:41:23 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 12 Dec 2023 21:41:23 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method [v2] In-Reply-To: References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Message-ID: On Tue, 12 Dec 2023 12:42:41 GMT, Hannes Walln?fer wrote: >> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location). > > Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8164094 > - Additional test > - JDK-8164094: javadoc allows to create a @link to a non-existent method Should this issue have a CSR for the behavioral change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1852850124 From jjg at openjdk.org Tue Dec 12 21:49:31 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 12 Dec 2023 21:49:31 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method [v2] In-Reply-To: References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Message-ID: On Tue, 12 Dec 2023 13:46:59 GMT, Pavel Rappo wrote: > It's nice to see this issue and its individual sightings being addressed. > > While I'm a Reviewer, I'm not a compiler person, so my approval means little here. Wait for a compiler person to approve it. Perhaps they might also suggest a better name for the `explicitType` parameter. > > Separately, it was interesting to see that a field is first searched in the enclosing class or interface, and if not found, searched in the superclass or a superinterface. The order in which a method is searched is the opposite: the superclass or a superinterface, then the enclosing class or interface. Maybe @lahodaj can help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1852860126 From hannesw at openjdk.org Wed Dec 13 10:47:40 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 13 Dec 2023 10:47:40 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method [v2] In-Reply-To: References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Message-ID: <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com> On Tue, 12 Dec 2023 21:38:33 GMT, Joe Darcy wrote: > Should this issue have a CSR for the behavioral change? My understanding of the issue is that the lookup of explicit-class member references in enclosing classes was an unintended consequence of doing the same for classless references from within nested classes. So I consider this a bug fix, not a feature change (even though it unfortunately changes javadoc to become stricter in what it accepts). Actually, the feature of extending member reference lookup to enclosing classes is not specified in the taglet spec, which only says this: > When the reference is to a member of the same class as that containing the documentation comment, all parts of the reference up to and including the # may be omitted, although the '#' may be retained for clarity. This could be extended to include enclosing classes, but this is existing behaviour, not changed by this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1853676675 From prappo at openjdk.org Wed Dec 13 13:45:37 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 13 Dec 2023 13:45:37 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method [v2] In-Reply-To: References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Message-ID: On Tue, 12 Dec 2023 21:46:33 GMT, Jonathan Gibbons wrote: > Separately, it was interesting to see that a field is first searched in the enclosing class or interface, and if not found, searched in the superclass or a superinterface. The order in which a method is searched is the opposite: the superclass or a superinterface, then the enclosing class or interface. As I said before, it's a separate issue. However, I still wonder what the rationale for that difference is; it's not obvious to me. It also doesn't strike me as the right behaviour. FWIW, as a local experiment I changed code so that both methods and fields were first searched in the superclass and superinterfaces and then in the enclosing class or interface. Out of the above two alternatives, this order seems more correct. All tier1 tests still succeeded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1853943874 From jlahoda at openjdk.org Wed Dec 13 13:48:40 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 13 Dec 2023 13:48:40 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method [v2] In-Reply-To: References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> Message-ID: On Tue, 12 Dec 2023 12:42:41 GMT, Hannes Walln?fer wrote: >> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location). > > Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8164094 > - Additional test > - JDK-8164094: javadoc allows to create a @link to a non-existent method For "normal" field or method (simple-name) lookup, the same-named field or method from the enclosing scope is shadowed by the declaration in the current ("nested") scope (JLS 6.4.1). The "nested" scope includes inherited fields and methods. So, even for fields, it might be preferable to first search supertypes, and only then enclosing scopes. There is a caveat: the inheritance rules are a bit complex, like for example `private`, inaccessible or hidden(*) fields are not inherited (JLS 8.3); rules for methods are even a bit more complex (JLS 8.4.8). I.e. if we just change the search order, we may end up looking up a private field from a supertype, instead of the more correct field from an enclosing scope. (*) hidden fields are not really an issue here. There's also one more specialty for methods: if there's any method of name `m` in a given scope, even if it is not applicable due to parameter types, the search ends in that scope, and does not go to the enclosing scopes (a method named `m` shadows all methods named `m` with any parameters in the enclosing scope). (JLS 6.4.1) I am not sure how strictly correct javadoc needs to be, but if we want to get closer to the normal "simple-name" lookup, we would probably need to tighten up the code. I was briefly looking whether we could reuse the standard lookup - might be doable for fields, but not sure about methods. Would need some more investigations, I am afraid. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1853948123 From prappo at openjdk.org Wed Dec 13 14:56:38 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 13 Dec 2023 14:56:38 GMT Subject: RFR: JDK-8164094: javadoc allows to create a @link to a non-existent method [v2] In-Reply-To: <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com> References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com> <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com> Message-ID: <81GrAewa5NKD4xg8oTdTzr3X_whVENpiaI-aUbUHMC8=.9c18fc4d-155d-4825-9d72-1fda0c0ff66c@github.com> On Wed, 13 Dec 2023 10:44:43 GMT, Hannes Walln?fer wrote: >> Should this issue have a CSR for the behavioral change? > >> Should this issue have a CSR for the behavioral change? > > My understanding of the issue is that the lookup of explicit-class member references in enclosing classes was an unintended consequence of doing the same for classless references from within nested classes. So I consider this a bug fix, not a feature change (even though it unfortunately changes javadoc to become stricter in what it accepts). > > Actually, the feature of extending member reference lookup to enclosing classes is not specified in the taglet spec, which only says this: > >> When the reference is to a member of the same class as that containing the documentation comment, all parts of the reference up to and including the # may be omitted, although the '#' may be retained for clarity. > > This could be extended to include enclosing classes, but this is existing behaviour, not changed by this issue. @hns would you be able to create a linked bug to track that lookup order issue? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1854066147 From vromero at openjdk.org Wed Dec 13 15:03:43 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 13 Dec 2023 15:03:43 GMT Subject: RFR: 8288989: Make tests not to depend on the source code In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona wrote: > Two langtool tests depend on the JDK source tree presence. > This patch skips the tests execution in a source-less test environment. > > Please review. > > Thanks, > Adam just curious: in what conditions the tests will be executed in a source-less test environment? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1854079036 From jjg at openjdk.org Wed Dec 13 16:57:43 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 13 Dec 2023 16:57:43 GMT Subject: RFR: 8288989: Make tests not to depend on the source code In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 15:01:08 GMT, Vicente Romero wrote: > just curious: in what conditions the tests will be executed in a source-less test environment? and in any case isn't it preferable to let the test fail so that the user knows that it failed? Some external users execute tests in a context where the source directory is not available. Throwing `jtreg.SkippedException` is a mild form of noticeable failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1854341138 From prappo at openjdk.org Wed Dec 13 17:24:40 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 13 Dec 2023 17:24:40 GMT Subject: RFR: 8288989: Make tests not to depend on the source code In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona wrote: > Two langtool tests depend on the JDK source tree presence. > This patch skips the tests execution in a source-less test environment. > > Please review. > > Thanks, > Adam Firstly, I agree with Jon on `jtreg.SkippedException`, which we also plan to use for a similar issue, JDK-8310277. Secondly, may I suggest retitling the issue so that it wouldn't mislead people into thinking that the affected tests no longer need access to source code to do useful work? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1854404680 From duke at openjdk.org Wed Dec 13 18:21:49 2023 From: duke at openjdk.org (Weibing Xiao) Date: Wed, 13 Dec 2023 18:21:49 GMT Subject: RFR: 8318971 : Better Error Handling for Jar Tool Processing of @File Message-ID: Better Error Handling for Jar Tool Processing of "@File"
This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423. Thank you. ------------- Commit messages: - 8318971 : Better Error Handling for Jar Tool Processing of @File Changes: https://git.openjdk.org/jdk/pull/17088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17088&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318971 Stats: 56 lines in 2 files changed: 54 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17088/head:pull/17088 PR: https://git.openjdk.org/jdk/pull/17088 From achung at openjdk.org Wed Dec 13 22:26:45 2023 From: achung at openjdk.org (Alisen Chung) Date: Wed, 13 Dec 2023 22:26:45 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update Message-ID: Translation drop for JDK22 RDP1 ------------- Commit messages: - translated files Changes: https://git.openjdk.org/jdk/pull/17096/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17096&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322041 Stats: 290 lines in 36 files changed: 166 ins; 15 del; 109 mod Patch: https://git.openjdk.org/jdk/pull/17096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17096/head:pull/17096 PR: https://git.openjdk.org/jdk/pull/17096 From cushon at openjdk.org Wed Dec 13 23:02:52 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 13 Dec 2023 23:02:52 GMT Subject: RFR: 8322040: Missing array bounds check in ClassReader.parameter Message-ID: Hello, Please consider this fix which adds a missing array bounds check in `ClassReader.parameter`. I found this while investigating the crash described in [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040). ------------- Commit messages: - 8322040: Missing array bounds check in ClassReader.parameter Changes: https://git.openjdk.org/jdk/pull/17097/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17097&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322040 Stats: 154 lines in 2 files changed: 153 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17097.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17097/head:pull/17097 PR: https://git.openjdk.org/jdk/pull/17097 From vdyakov at openjdk.org Wed Dec 13 23:25:37 2023 From: vdyakov at openjdk.org (Victor Dyakov) Date: Wed, 13 Dec 2023 23:25:37 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <0oGMQEYflrpIHgrQQ60XHXx1jR1fEbqjmZZAD4B8YXk=.dc1a7f14-1d24-4f8d-8471-6846e65863df@github.com> On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 @alexeysemenyukoracle please review jpackage part ------------- PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1854847266 From achung at openjdk.org Wed Dec 13 23:34:37 2023 From: achung at openjdk.org (Alisen Chung) Date: Wed, 13 Dec 2023 23:34:37 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <03lwg8mSWD_UyU_XMYspZO9EzplluKXuLnsIYbtVCw8=.99fca7b7-98d3-4643-be9c-01983a3b2772@github.com> On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 @JoeWang-Java can u review the xml changes? @jonathan-gibbons can u review the compiler changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1854853944 PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1854854368 From almatvee at openjdk.org Thu Dec 14 00:39:39 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 14 Dec 2023 00:39:39 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 jpackage part looks fine. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1780705685 From dholmes at openjdk.org Thu Dec 14 05:51:45 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 05:51:45 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 Message-ID: Updated the version to 23-ea and year to 2024. This initial generation also picks up the unpublished changes from: - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) In addition this includes the updates for - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23 Thanks ------------- Commit messages: - 8322065: Initial nroff manpage generation for JDK 23 - 8309981: Remove expired flags in JDK 23 Changes: https://git.openjdk.org/jdk/pull/17101/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322065 Stats: 216 lines in 29 files changed: 47 ins; 61 del; 108 mod Patch: https://git.openjdk.org/jdk/pull/17101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17101/head:pull/17101 PR: https://git.openjdk.org/jdk/pull/17101 From alanb at openjdk.org Thu Dec 14 09:03:38 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Dec 2023 09:03:38 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) > - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) > - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) > > > In addition this includes the updates for > > - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23 > > Thanks Initially I wondered if JDK-8309981 should be separated but include keeps things in sync so I think okay. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17101#pullrequestreview-1781343785 From prappo at openjdk.org Thu Dec 14 09:19:37 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 14 Dec 2023 09:19:37 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) > - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) > - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) > > > In addition this includes the updates for > > - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23 > > Thanks > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > * [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) Thanks for doing this, David. I only note that the changes for JDK-8321384 were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), which was integrated in the mainline before JDK 22 RDP 1. So they are already present in the mainline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855467435 From abimpoudis at openjdk.org Thu Dec 14 11:04:09 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 14 Dec 2023 11:04:09 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v38] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: <3JvLQvkIPnCIy1JtnD6hKyVg2GvDUDvUqog8R7gbGJc=.21d55c1c-1476-4eea-8720-5424eda66678@github.com> > This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/ Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits: - Merge branch 'master' into primitive-patterns - Cleanup - Merge branch 'master' into primitive-patterns - Remove trailing spaces - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns - Fixed switch in the cases of unboxing and widening - Merge branch 'JDK-8319220' into primitive-patterns - Merge branch 'master' into JDK-8319220 - reflecting review comment: fixing letter case. - Reflecting review feedback. - ... and 44 more: https://git.openjdk.org/jdk/compare/d2ba3b1e...a03fea7c ------------- Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=37 Stats: 3248 lines in 41 files changed: 2985 ins; 110 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From mcimadamore at openjdk.org Thu Dec 14 11:07:38 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 14 Dec 2023 11:07:38 GMT Subject: RFR: 8288989: Make tests not to depend on the source code In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona wrote: > Two langtool tests depend on the JDK source tree presence. > This patch skips the tests execution in a source-less test environment. > > Please review. > > Thanks, > Adam Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16470#pullrequestreview-1781575868 From cstein at openjdk.org Thu Dec 14 11:26:39 2023 From: cstein at openjdk.org (Christian Stein) Date: Thu, 14 Dec 2023 11:26:39 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 Marked as reviewed by cstein (Committer). German translations read OK. Nit: some layouts get lost in translated files - it would be great to have similar usage of `\n` and `` in the translated files. For example, the English file `src/java.base/share/classes/sun/launcher/resources/launcher.properties` has good (easy to compare) layout: java.launcher.opt.header = Usage: {0} [options] [args...]\n\ \ (to execute a class)\n\ \ or {0} [options] -jar [args...]\n\ \ (to execute a jar file)\n\ \ or {0} [options] -m [/] [args...]\n\ \ {0} [options] --module [/] [args...]\n\ \ (to execute the main class in a module)\n\ \ or {0} [options] [args]\n\ \ (to execute a source-file program)\n\n\ [...] The German translation in `src/java.base/share/classes/sun/launcher/resources/launcher_de.properties` uses only a single line in its properties file: java.launcher.opt.header = Verwendung: {0} [Optionen] [args...]\n (zur Ausf?hrung einer Klasse)\n oder {0} [Optionen] -jar [args...]\n (zur Ausf?hrung einer JAR-Datei)\n oder {0} [Optionen] -m [/] [args...]\n {0} [Optionen] --module [/] [args...]\n (zur Ausf?hrung der Hauptklasse in einem Modul)\n oder {0} [Optionen] [args]\n (zur Ausf?hrung eines Programms mit einer Quelldatei)\n\n[...] Changes in the latter are not easy to spot and review. ------------- PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1781603832 PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1855667603 From asotona at openjdk.org Thu Dec 14 11:39:49 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 14 Dec 2023 11:39:49 GMT Subject: RFR: 8288989: Make tests not depend on the source code In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona wrote: > Two langtool tests depend on the JDK source tree presence. > This patch skips the tests execution in a source-less test environment. > > Please review. > > Thanks, > Adam retitled as suggested ------------- PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1855685435 From asotona at openjdk.org Thu Dec 14 11:39:51 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 14 Dec 2023 11:39:51 GMT Subject: Integrated: 8288989: Make tests not depend on the source code In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 09:02:43 GMT, Adam Sotona wrote: > Two langtool tests depend on the JDK source tree presence. > This patch skips the tests execution in a source-less test environment. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 2838a916 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/2838a916ab98cb0152f8b1e3f96eccca198af5e9 Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod 8288989: Make tests not depend on the source code Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16470 From asotona at openjdk.org Thu Dec 14 11:45:48 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 14 Dec 2023 11:45:48 GMT Subject: RFR: 8288989: Make tests not depend on the source code In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 16:54:33 GMT, Jonathan Gibbons wrote: > > just curious: in what conditions the tests will be executed in a source-less test environment? and in any case isn't it preferable to let the test fail so that the user knows that it failed? > > Some external users execute tests in a context where the source directory is not available. Throwing `jtreg.SkippedException` is a mild form of noticeable failure. I don't have an access to any environment to test it, so I prefer the same solution as already applied in several similar situations across the JDK tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1855694559 From asotona at openjdk.org Thu Dec 14 11:57:15 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 14 Dec 2023 11:57:15 GMT Subject: [jdk22] RFR: 8288989: Make tests not depend on the source code Message-ID: 8288989: Make tests not depend on the source code ------------- Commit messages: - Backport 2838a916ab98cb0152f8b1e3f96eccca198af5e9 Changes: https://git.openjdk.org/jdk22/pull/13/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=13&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288989 Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk22/pull/13.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/13/head:pull/13 PR: https://git.openjdk.org/jdk22/pull/13 From dholmes at openjdk.org Thu Dec 14 12:26:40 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 12:26:40 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 09:17:05 GMT, Pavel Rappo wrote: > Thanks for doing this, David. I only note that the changes for JDK-8321384 were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), which was integrated in the mainline before JDK 22 RDP 1. So they are already present in the mainline. Ah I see. Thanks for correcting that, I will update the PR and JBS issue. And thanks for looking at this @pavelrappo . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855755042 From dholmes at openjdk.org Thu Dec 14 12:30:38 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 12:30:38 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 09:01:17 GMT, Alan Bateman wrote: > Initially I wondered if JDK-8309981 should be separated but include keeps things in sync so I think okay. Thanks for the review @AlanBateman . Yeah I was in two minds there myself. I started fixing [JDK-8309981](https://bugs.openjdk.org/browse/JDK-8309981) only to discover that the start of release updates had not been done as part of the start of release, so I figured I may as well fix it all together given I'd generated all the updated files anyway. But I'm still a little unsure ... in fact I think I will remove it in the morning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855761906 From dholmes at openjdk.org Thu Dec 14 12:35:52 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 12:35:52 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 [v2] In-Reply-To: References: Message-ID: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) > - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Revert "8309981: Remove expired flags in JDK 23" This reverts commit 0324a90e936ae01e42ae099e7235156326cc318a. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17101/files - new: https://git.openjdk.org/jdk/pull/17101/files/65a8c9ed..8b052141 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=00-01 Stats: 23 lines in 2 files changed: 10 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17101/head:pull/17101 PR: https://git.openjdk.org/jdk/pull/17101 From jjg at openjdk.org Thu Dec 14 16:49:48 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 14 Dec 2023 16:49:48 GMT Subject: RFR: 8288989: Make tests not depend on the source code In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 11:42:39 GMT, Adam Sotona wrote: > I don't have an access to any environment to test it, so I prefer the same solution as already applied in several similar situations across the JDK tests. If you really wanted, you could test it locally, running `jtreg` directly (not through `make test`) and temporarily rename the `src` directory to something else, for the duration of your test run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16470#issuecomment-1856192601 From joehw at openjdk.org Thu Dec 14 19:04:41 2023 From: joehw at openjdk.org (Joe Wang) Date: Thu, 14 Dec 2023 19:04:41 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 331: > 329: > 330: # Implementation Property DTD > 331: JDK_DTD_DENY = JAXP00010008: DOCTYPE ist nicht zul?ssig, wenn die DTD-Eigenschaft auf "Ablehnen" gesetzt wurde. Weitere Informationen: Eigenschaft jdk.xml.dtd.support in java.xml/module-summary. This version quoted "Ablehnen" while the other two (ja - "??" and zh_CN - "??") didn't. If we want to be consistent, "deny" would be better since that's the literal value. The English version should have quoted "deny". The previous translations in these files have not been consistent. Some of the key words were translated. If we want to keep this translation as is, it's probably better to remove the quote in the "de" file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427152545 From naoto at openjdk.org Thu Dec 14 19:25:41 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 14 Dec 2023 19:25:41 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties line 111: > 109: doclet.Factory=?????: > 110: doclet.UnknownTag=?????????????????? > 111: doclet.UnknownTagWithHint=?????????????@{0}??????????????? Simply appending a question mark may read a bit odd, although it is a straightforward translation from English. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties line 88: > 86: dc.tag.start.unmatched = ??????????: > 87: dc.unknown.javadoc.tag = ?????????????????? > 88: dc.unknown.javadoc.tag.with.hint = ?????????????@{0}??????????????? same here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427170568 PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427171135 From jlu at openjdk.org Thu Dec 14 19:46:41 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 14 Dec 2023 19:46:41 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 All around LGTM. From a skim I don't see any of the typical l10n related file mode issues, line ending issues, or values that should not be changed (like _WixLocalization Culture_). Might be worth filing a bug against the translation tool to see if it could support multi line translations for localized versions as @sormuras pointed out. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 2293: > 2291: compiler.err.underscore.as.identifier=Ab Release 9 ist "_" ein Schl?sselwort und kann nicht als ID verwendet werden > 2292: > 2293: compiler.err.use.of.underscore.not.allowed=Unterstrich ist hier nicht zul?ssig\nAb Release 9 ist ''_'' ein Schl?sselwort und kann nicht als ID verwendet werden\nAb Release 22 kann ''_'' als Name in der Deklaration unbenannter Muster, lokaler Variablen, Ausnahmeparameter oder Lambda-Parameter verwendet werden Just an observation, but the double quotes were converted to (two) single quotes. Previously, localized de files represented '' '' as " ", as different languages have different l10n rules (according to the translation contact). And this is seen with the other values on this file using "" instead of '' ''. But here it looks like they updated the value to match the quotes in of the value in the original .properties files. Not sure if they updated the rules and this is intentional, or unintentional. ------------- PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1782404582 PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427080553 From asemenyuk at openjdk.org Thu Dec 14 20:40:44 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 14 Dec 2023 20:40:44 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <1b8hGFdrVVjDalOWt2pkTGQ_jmudlYiXAeptlQfmbZM=.a08ed560-9472-4a75-ae4d-afab8e93799c@github.com> On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 Marked as reviewed by asemenyuk (Reviewer). jpackage changes look good ------------- PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1782697421 PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1856551939 From dholmes at openjdk.org Thu Dec 14 21:28:47 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 21:28:47 GMT Subject: Integrated: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) > - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) > > Thanks This pull request has now been integrated. Changeset: 692be577 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/692be577385844bf00a01ff10e390e014191569f Stats: 193 lines in 27 files changed: 36 ins; 51 del; 106 mod 8322065: Initial nroff manpage generation for JDK 23 Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17101 From achung at openjdk.org Thu Dec 14 22:01:40 2023 From: achung at openjdk.org (Alisen Chung) Date: Thu, 14 Dec 2023 22:01:40 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 mach5 looks green ------------- PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1856733375 From achung at openjdk.org Thu Dec 14 22:17:54 2023 From: achung at openjdk.org (Alisen Chung) Date: Thu, 14 Dec 2023 22:17:54 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: > Translation drop for JDK22 RDP1 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed quotes around Ablehnen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17096/files - new: https://git.openjdk.org/jdk/pull/17096/files/3c8e871d..0e964a06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17096&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17096&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17096/head:pull/17096 PR: https://git.openjdk.org/jdk/pull/17096 From achung at openjdk.org Fri Dec 15 00:11:46 2023 From: achung at openjdk.org (Alisen Chung) Date: Fri, 15 Dec 2023 00:11:46 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 19:01:22 GMT, Joe Wang wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> removed quotes around Ablehnen > > src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 331: > >> 329: >> 330: # Implementation Property DTD >> 331: JDK_DTD_DENY = JAXP00010008: DOCTYPE ist nicht zul?ssig, wenn die DTD-Eigenschaft auf "Ablehnen" gesetzt wurde. Weitere Informationen: Eigenschaft jdk.xml.dtd.support in java.xml/module-summary. > > This version quoted "Ablehnen" while the other two (ja - "??" and zh_CN - "??") didn't. If we want to be consistent, "deny" would be better since that's the literal value. The English version should have quoted "deny". > > The previous translations in these files have not been consistent. Some of the key words were translated. If we want to keep this translation as is, it's probably better to remove the quote in the "de" file. removed quotes around Ablehnen ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427423629 From vromero at openjdk.org Fri Dec 15 02:53:38 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 15 Dec 2023 02:53:38 GMT Subject: RFR: 8322040: Missing array bounds check in ClassReader.parameter In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:57:04 GMT, Liam Miller-Cushon wrote: > Hello, > > Please consider this fix which adds a missing array bounds check in `ClassReader.parameter`. > > I found this while investigating the crash described in [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040). looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17097#pullrequestreview-1783049320 From joehw at openjdk.org Fri Dec 15 05:26:41 2023 From: joehw at openjdk.org (Joe Wang) Date: Fri, 15 Dec 2023 05:26:41 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 22:17:54 GMT, Alisen Chung wrote: >> Translation drop for JDK22 RDP1 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > removed quotes around Ablehnen The java.xml changes look good. ------------- Marked as reviewed by joehw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1783142189 From jlahoda at openjdk.org Fri Dec 15 08:16:59 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 15 Dec 2023 08:16:59 GMT Subject: RFR: 8322159: ThisEscapeAnalyzer crashes for erroneous code Message-ID: When an unresolvable method is used in the code, the model is a bit strange (and not very easy to fix) - for method invocations, the symbol used is actually a `ClassSymbol` instead of `MethodSymbol`, and method references have fields like `kind` unfilled. This is causing issues in ThisEscapeAnalyzer when there were unresolvable methods, and the analyzer is called (i.e. in practice when running with `-Xlint:this-escape -XDshould-stop.at=FLOW`, or similar): - `visitApply` has a hardcoded cast to `MethodSymbol`. Seems the case in not really necessary, so the proposal is to remove it. - `visitReference` crashes on an access to `JCMemberReference.kind`, as it is unfilled. The proposal is to skip the check if the method reference's type is errneous. ------------- Commit messages: - 8322159: ThisEscapeAnalyzer crashes for erroneous code Changes: https://git.openjdk.org/jdk/pull/17118/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17118&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322159 Stats: 44 lines in 2 files changed: 41 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17118.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17118/head:pull/17118 PR: https://git.openjdk.org/jdk/pull/17118 From antoine.dessaigne at gmail.com Fri Dec 15 10:12:15 2023 From: antoine.dessaigne at gmail.com (Antoine DESSAIGNE) Date: Fri, 15 Dec 2023 11:12:15 +0100 Subject: Invalid code generated by C2 compiler in OpenJDK 21 Message-ID: Hello everyone, I've found an issue while migrating to OpenJDK 21. A valued local variable (effectively final) has its value removed and it throws a NullPointerException. Unfortunately, I cannot provide the source code and the data to reproduce the issue, and I couldn't create a smaller code snippet to show the issue. That said, I'll happily show the code and perform many tests during calls. Here's what I did so far to diagnose the issue. I bisected the repository to find where the regression comes from. I found this commit 3696711efa5 [1] but it's a merge so I bisected the branch and found 10737e168c9 [2]. Looking at this commit, I have no idea how it could introduce this kind of regression. Then, thanks to the guidance from Aleksey Shipil?v, I tested many things * Issue does *not* happen with the following flags: -Xint, -XX:-TieredCompilation, -XX:TieredStopAtLevel=1, -XX:TieredStopAtLevel=2, -XX:TieredStopAtLevel=3 * Issue also happens with fastdebug builds of OpenJDK, without crashing due to assertions * Issue still happens in the latest version of the code (commit b31454e3623) * Issue happens no matter which GC is used, I tried SerialGC, ParallelGC, G1GC, and ShenandoahGC The tests were performed in Docker containers running on 4 different hosts. Therefore it looks like C2 is generating an invalid assembly code. Unfortunately, I'm not great with assembly and the generated assembly is quite big (main code is around 20k). Do you have an idea of why this is happening? Do you know what test I can run? If one of you is available, we can schedule calls for me to show you the code and my tests. Thank you very much for your assistance. Have a nice day, Antoine DESSAIGNE [1] https://github.com/openjdk/jdk/commit/3696711efa566fb776d6923da86e17b0e1e22964 [2] https://github.com/openjdk/jdk/commit/10737e168c967a08e257927251861bf2c14795ab -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at openjdk.org Fri Dec 15 10:19:51 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 15 Dec 2023 10:19:51 GMT Subject: Integrated: 8322040: Missing array bounds check in ClassReader.parameter In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:57:04 GMT, Liam Miller-Cushon wrote: > Hello, > > Please consider this fix which adds a missing array bounds check in `ClassReader.parameter`. > > I found this while investigating the crash described in [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040). This pull request has now been integrated. Changeset: 20de541b Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/20de541b1304b4dc3a385f8a78f1215da237e4aa Stats: 154 lines in 2 files changed: 153 ins; 0 del; 1 mod 8322040: Missing array bounds check in ClassReader.parameter Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/17097 From alanb at openjdk.org Fri Dec 15 11:23:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Dec 2023 11:23:49 GMT Subject: RFR: 8322040: Missing array bounds check in ClassReader.parameter In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:57:04 GMT, Liam Miller-Cushon wrote: > Hello, > > Please consider this fix which adds a missing array bounds check in `ClassReader.parameter`. > > I found this while investigating the crash described in [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040). test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile /test/langtools/tools/javac/classreader/BadMethodParameter.java:38: error: package jdk.internal.classfile does not exist import jdk.internal.classfile.ClassModel; Maybe it was created before the class file API before a preview API? In any case it is failing in tier1 now, needs to be fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17097#issuecomment-1857714054 From cushon at openjdk.org Fri Dec 15 11:30:51 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 15 Dec 2023 11:30:51 GMT Subject: RFR: 8322040: Missing array bounds check in ClassReader.parameter In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 11:21:12 GMT, Alan Bateman wrote: > Maybe it was created before the class file API before a preview API? I think that is what happened, I had failed to notice this branch was stale. Sorry for the mistake! I am preparing a fix: https://bugs.openjdk.org/browse/JDK-8322175 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17097#issuecomment-1857723838 From cushon at openjdk.org Fri Dec 15 12:04:46 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 15 Dec 2023 12:04:46 GMT Subject: RFR: 8322175: test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile Message-ID: Hello, please consider this fix for a compilation error in a test introduced by [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040). ------------- Commit messages: - Fix trailing whitespace - 8322175: test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile Changes: https://git.openjdk.org/jdk/pull/17120/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17120&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322175 Stats: 12 lines in 1 file changed: 3 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17120.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17120/head:pull/17120 PR: https://git.openjdk.org/jdk/pull/17120 From jlahoda at openjdk.org Fri Dec 15 12:16:37 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 15 Dec 2023 12:16:37 GMT Subject: RFR: 8322175: test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 11:51:48 GMT, Liam Miller-Cushon wrote: > Hello, please consider this fix for a compilation error in a test introduced by [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040). Looks good to me! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17120#pullrequestreview-1783798942 From alanb at openjdk.org Fri Dec 15 12:20:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Dec 2023 12:20:49 GMT Subject: RFR: 8322175: test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 11:51:48 GMT, Liam Miller-Cushon wrote: > Hello, please consider this fix for a compilation error in a test introduced by [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040). Thanks for jumping on this. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17120#pullrequestreview-1783810434 From cushon at openjdk.org Fri Dec 15 12:20:50 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 15 Dec 2023 12:20:50 GMT Subject: Integrated: 8322175: test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 11:51:48 GMT, Liam Miller-Cushon wrote: > Hello, please consider this fix for a compilation error in a test introduced by [JDK-8322040](https://bugs.openjdk.org/browse/JDK-8322040). This pull request has now been integrated. Changeset: bdebf198 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/bdebf198bb0f4c3347ae9539d02ce0476e1176ce Stats: 12 lines in 1 file changed: 3 ins; 2 del; 7 mod 8322175: test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/17120 From acobbs at openjdk.org Fri Dec 15 15:45:37 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 15 Dec 2023 15:45:37 GMT Subject: RFR: 8322159: ThisEscapeAnalyzer crashes for erroneous code In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 08:10:42 GMT, Jan Lahoda wrote: > When an unresolvable method is used in the code, the model is a bit strange (and not very easy to fix) - for method invocations, the symbol used is actually a `ClassSymbol` instead of `MethodSymbol`, and method references have fields like `kind` unfilled. > > This is causing issues in ThisEscapeAnalyzer when there were unresolvable methods, and the analyzer is called (i.e. in practice when running with `-Xlint:this-escape -XDshould-stop.at=FLOW`, or similar): > - `visitApply` has a hardcoded cast to `MethodSymbol`. Seems the case in not really necessary, so the proposal is to remove it. > - `visitReference` crashes on an access to `JCMemberReference.kind`, as it is unfilled. The proposal is to skip the check if the method reference's type is errneous. Hi @lahodaj, Looks good to me - thanks for fixing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17118#issuecomment-1858083342 From vromero at openjdk.org Fri Dec 15 16:31:37 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 15 Dec 2023 16:31:37 GMT Subject: RFR: 8322159: ThisEscapeAnalyzer crashes for erroneous code In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 08:10:42 GMT, Jan Lahoda wrote: > When an unresolvable method is used in the code, the model is a bit strange (and not very easy to fix) - for method invocations, the symbol used is actually a `ClassSymbol` instead of `MethodSymbol`, and method references have fields like `kind` unfilled. > > This is causing issues in ThisEscapeAnalyzer when there were unresolvable methods, and the analyzer is called (i.e. in practice when running with `-Xlint:this-escape -XDshould-stop.at=FLOW`, or similar): > - `visitApply` has a hardcoded cast to `MethodSymbol`. Seems the case in not really necessary, so the proposal is to remove it. > - `visitReference` crashes on an access to `JCMemberReference.kind`, as it is unfilled. The proposal is to skip the check if the method reference's type is errneous. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17118#pullrequestreview-1784486330 From jjg at openjdk.org Sat Dec 16 00:30:43 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Sat, 16 Dec 2023 00:30:43 GMT Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 22:17:54 GMT, Alisen Chung wrote: >> Translation drop for JDK22 RDP1 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > removed quotes around Ablehnen The diffs are more conveniently available here: https://cr.openjdk.org/~jjg/jdk-l10n-diffs--15dec23/ The compiler and javadoc diffs look "ok" but I cannot read most other languages, and cannot comment on the quality of the translations. I do see that there are places where a translation has been edited where the English original has not. I also see issues with some of the English messages, but that is not for here. My "approval" is just for `jdk.compiler` and `jdk.javadoc` files. ------------- Marked as reviewed by jjg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1785076089 From achung at openjdk.org Sat Dec 16 01:05:46 2023 From: achung at openjdk.org (Alisen Chung) Date: Sat, 16 Dec 2023 01:05:46 GMT Subject: Integrated: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote: > Translation drop for JDK22 RDP1 This pull request has now been integrated. Changeset: b061b667 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/b061b6678fde891974d5b58cec963b3481099a8d Stats: 290 lines in 36 files changed: 166 ins; 15 del; 109 mod 8322041: JDK 22 RDP1 L10n resource files update Reviewed-by: almatvee, cstein, asemenyuk, joehw, jjg ------------- PR: https://git.openjdk.org/jdk/pull/17096 From alanb at openjdk.org Sun Dec 17 09:32:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 17 Dec 2023 09:32:36 GMT Subject: RFR: 8318971 : Better Error Handling for Jar Tool Processing of @File In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 18:16:56 GMT, Weibing Xiao wrote: > Better Error Handling for Jar Tool Processing of "@File"
> > This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423. > > Thank you. The implementation change looks okay, I think we mostly agreed that in the previous PR. I don't have cycles to look at the test right now so I hope you can get another reviewer for the test update. The other part to this is the man page. I chatted briefly with Ryan about this a few weeks ago as something that needs to updated (not this PR of course). ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17088#pullrequestreview-1785407802 From javalists at cbfiddle.com Sun Dec 17 16:48:15 2023 From: javalists at cbfiddle.com (Alan Snyder) Date: Sun, 17 Dec 2023 08:48:15 -0800 Subject: a change in javac behavior Message-ID: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com> I?m experiencing a change in behavior compiling a particular file. The compiler is trying to match an invocation to one of two constructors for a static class defined in the same file. The second constructor has a parameter of type Builder. In the past, this was interpreted as my Builder class, which is imported into this file. That matches the invocation. Now, however, the constructor parameter type is interpreted as java.lang.Thread.Builder, presumably because the static class extends Thread. That causes a mismatch to be reported. This interpretation appears to be limited to the resolution of the constructor invocation. Within the constructor, I do not get an error when the parameter is used as an instance of my Builder class. This happens in JDK 20, JDK 21, and the latest build of JDK 22. It does not happen in JDK 17. The error message: [javac] constructor Worker.Worker(@org.jetbrains.annotations.NotNull String, at org.jetbrains.annotations.NotNull SeverityLevel, at org.jetbrains.annotations.NotNull java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable TaskStatusListener, at org.jetbrains.annotations.NotNull SimpleTaskReceiver) is not applicable [javac] (argument mismatch; @org.jetbrains.annotations.NotNull com.cbfiddle.releases.Builder cannot be converted to @org.jetbrains.annotations.NotNull java.lang.Thread.Builder) The constructor: public Worker(@NotNull String taskName, @NotNull SeverityLevel level, @NotNull Builder builder, @Nullable TaskStatusListener tsl, @NotNull SimpleTaskReceiver r) { this.taskName = taskName; this.level = level; this.r = r; this.bl = createBuildListener(tsl); this.op = () -> builder.perform(bl); setPriority(Thread.MIN_PRIORITY); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Dec 17 17:56:34 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 17 Dec 2023 18:56:34 +0100 (CET) Subject: a change in javac behavior In-Reply-To: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com> References: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com> Message-ID: <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr> > From: "Alan Snyder" > To: "compiler-dev" > Sent: Sunday, December 17, 2023 5:48:15 PM > Subject: a change in javac behavior > I?m experiencing a change in behavior compiling a particular file. > The compiler is trying to match an invocation to one of two constructors for a > static class defined in the same file. > The second constructor has a parameter of type Builder. In the past, this was > interpreted as my Builder class, which is imported into this file. > That matches the invocation. > Now, however, the constructor parameter type is interpreted as > java.lang.Thread.Builder, presumably because the static class extends Thread. > That causes a mismatch to be reported. > This interpretation appears to be limited to the resolution of the constructor > invocation. Within the constructor, I do not get an error when the parameter > is used as an instance of my Builder class. > This happens in JDK 20, JDK 21, and the latest build of JDK 22. > It does not happen in JDK 17. I believe this is not a behavior change, you are experiencing the "comb" behavior, where javac will first start to match members declared inside the class hierarchy before trying to match other members. Here is the classical example class Foo { String name; void setName(String name) { this.name = name; } public void execute() { new Thread() { public void run() { setName("foo"); } }.start(); } } where the method setName() inside execute() calls Thread.setName() instead of Foo.setName(). You code compiles with JDK 17 because Thread.Builder was introduced in 21 (19 as preview). If you want to avoid those kind of issues, prefer delegation to inheritance. > The error message: > [javac] constructor Worker.Worker(@org.jetbrains.annotations.NotNull > String, at org.jetbrains.annotations.NotNull > SeverityLevel, at org.jetbrains.annotations.NotNull > java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable > TaskStatusListener, at org.jetbrains.annotations.NotNull > SimpleTaskReceiver) is not applicable > [javac] (argument mismatch; @org.jetbrains.annotations.NotNull > com.cbfiddle.releases.Builder cannot be converted to > @org.jetbrains.annotations.NotNull java.lang.Thread.Builder) > The constructor: > public Worker ( @NotNull String taskName , > @NotNull SeverityLevel level , > @NotNull Builder builder , > @Nullable TaskStatusListener tsl , > @NotNull SimpleTaskReceiver < BuildResult > r ) > { > this . taskName = taskName ; > this . level = level ; > this . r = r ; > this . bl = createBuildListener( tsl ) ; > this . op = () -> builder .perform( bl ) ; > setPriority( Thread . MIN_PRIORITY ) ; > } regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From javalists at cbfiddle.com Sun Dec 17 20:03:14 2023 From: javalists at cbfiddle.com (Alan Snyder) Date: Sun, 17 Dec 2023 12:03:14 -0800 Subject: a change in javac behavior In-Reply-To: <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr> References: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com> <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <502E2D50-61B8-4677-A2AF-F9FD6A199716@cbfiddle.com> So, that is how things are supposed to work? Also, can you explain why javac does not complain about the builder.perform() invocation? That variable is declared using the disputed parameter declaration. If the parameter type is taken to be Thread.Builder, the call to perform should be rejected. > On Dec 17, 2023, at 9:56?AM, Remi Forax wrote: > > > > From: "Alan Snyder" > To: "compiler-dev" > Sent: Sunday, December 17, 2023 5:48:15 PM > Subject: a change in javac behavior > I?m experiencing a change in behavior compiling a particular file. > The compiler is trying to match an invocation to one of two constructors for a static class defined in the same file. > > The second constructor has a parameter of type Builder. In the past, this was interpreted as my Builder class, which is imported into this file. > That matches the invocation. > > Now, however, the constructor parameter type is interpreted as java.lang.Thread.Builder, presumably because the static class extends Thread. > That causes a mismatch to be reported. > > This interpretation appears to be limited to the resolution of the constructor invocation. Within the constructor, I do not get an error when the parameter > is used as an instance of my Builder class. > > This happens in JDK 20, JDK 21, and the latest build of JDK 22. > It does not happen in JDK 17. > > I believe this is not a behavior change, you are experiencing the "comb" behavior, where javac will first start to match members declared inside the class hierarchy before trying to match other members. > Here is the classical example > class Foo { > String name; > > void setName(String name) { > this.name = name; > } > > public void execute() { > new Thread() { > public void run() { > setName("foo"); > } > }.start(); > } > } > > where the method setName() inside execute() calls Thread.setName() instead of Foo.setName(). > > You code compiles with JDK 17 because Thread.Builder was introduced in 21 (19 as preview). > > If you want to avoid those kind of issues, prefer delegation to inheritance. > > > The error message: > > [javac] constructor Worker.Worker(@org.jetbrains.annotations.NotNull String, at org.jetbrains.annotations.NotNull SeverityLevel, at org.jetbrains.annotations.NotNull java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable TaskStatusListener, at org.jetbrains.annotations.NotNull SimpleTaskReceiver) is not applicable > [javac] (argument mismatch; @org.jetbrains.annotations.NotNull com.cbfiddle.releases.Builder cannot be converted to @org.jetbrains.annotations.NotNull java.lang.Thread.Builder) > > > The constructor: > > public Worker(@NotNull String taskName, > @NotNull SeverityLevel level, > @NotNull Builder builder, > @Nullable TaskStatusListener tsl, > @NotNull SimpleTaskReceiver r) > { > this.taskName = taskName; > this.level = level; > this.r = r; > this.bl = createBuildListener(tsl); > this.op = () -> builder.perform(bl); > > setPriority(Thread.MIN_PRIORITY); > } > > regards, > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Dec 18 06:39:45 2023 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 18 Dec 2023 07:39:45 +0100 (CET) Subject: a change in javac behavior In-Reply-To: <502E2D50-61B8-4677-A2AF-F9FD6A199716@cbfiddle.com> References: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com> <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr> <502E2D50-61B8-4677-A2AF-F9FD6A199716@cbfiddle.com> Message-ID: <867073994.84357316.1702881585077.JavaMail.zimbra@univ-eiffel.fr> > From: "Alan Snyder" > To: "Remi Forax" > Cc: "compiler-dev" > Sent: Sunday, December 17, 2023 9:03:14 PM > Subject: Re: a change in javac behavior > So, that is how things are supposed to work? Yes, > Also, can you explain why javac does not complain about the builder.perform() > invocation? > That variable is declared using the disputed parameter declaration. > If the parameter type is taken to be Thread.Builder, the call to perform should > be rejected. Hard to say without the whole code but if your original error comes from the same file, it may mask the error at builder.perform(), javac does several passes on the same code. regards, R?mi >> On Dec 17, 2023, at 9:56 AM, Remi Forax wrote: >>> From: "Alan Snyder" >>> To: "compiler-dev" >>> Sent: Sunday, December 17, 2023 5:48:15 PM >>> Subject: a change in javac behavior >>> I?m experiencing a change in behavior compiling a particular file. >>> The compiler is trying to match an invocation to one of two constructors for a >>> static class defined in the same file. >>> The second constructor has a parameter of type Builder. In the past, this was >>> interpreted as my Builder class, which is imported into this file. >>> That matches the invocation. >>> Now, however, the constructor parameter type is interpreted as >>> java.lang.Thread.Builder, presumably because the static class extends Thread. >>> That causes a mismatch to be reported. >>> This interpretation appears to be limited to the resolution of the constructor >>> invocation. Within the constructor, I do not get an error when the parameter >>> is used as an instance of my Builder class. >>> This happens in JDK 20, JDK 21, and the latest build of JDK 22. >>> It does not happen in JDK 17. >> I believe this is not a behavior change, you are experiencing the "comb" >> behavior, where javac will first start to match members declared inside the >> class hierarchy before trying to match other members. >> Here is the classical example >> class Foo { >> String name; >> void setName(String name) { >> this.name = name; >> } >> public void execute() { >> new Thread() { >> public void run() { >> setName("foo"); >> } >> }.start(); >> } >> } >> where the method setName() inside execute() calls Thread.setName() instead of >> Foo.setName(). >> You code compiles with JDK 17 because Thread.Builder was introduced in 21 (19 as >> preview). >> If you want to avoid those kind of issues, prefer delegation to inheritance. >>> The error message: >>> [javac] constructor Worker.Worker(@org.jetbrains.annotations.NotNull >>> String, at org.jetbrains.annotations.NotNull >>> SeverityLevel, at org.jetbrains.annotations.NotNull >>> java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable >>> TaskStatusListener, at org.jetbrains.annotations.NotNull >>> SimpleTaskReceiver) is not applicable >>> [javac] (argument mismatch; @org.jetbrains.annotations.NotNull >>> com.cbfiddle.releases.Builder cannot be converted to >>> @org.jetbrains.annotations.NotNull java.lang.Thread.Builder) >>> The constructor: >>> public Worker ( @NotNull String taskName , >>> @NotNull SeverityLevel level , >>> @NotNull Builder builder , >>> @Nullable TaskStatusListener tsl , >>> @NotNull SimpleTaskReceiver < BuildResult > r ) >>> { >>> this . taskName = taskName ; >>> this . level = level ; >>> this . r = r ; >>> this . bl = createBuildListener( tsl ) ; >>> this . op = () -> builder .perform( bl ) ; >>> setPriority( Thread . MIN_PRIORITY ) ; >>> } >> regards, >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbielicki at gmail.com Mon Dec 18 08:50:48 2023 From: pbielicki at gmail.com (Przemek Bielicki) Date: Mon, 18 Dec 2023 09:50:48 +0100 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) Message-ID: Hey Folks, I'm not 100% sure it's the best idea to post it here but I have no access to the JDK JIRA (yet?) ? Last week I had a huge headache because of a bug I discovered in the Java compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 (mixed mode, sharing). I'm pretty certain it's a bug because my expectation is that the compiler MUST produce deterministic output of the compiled classes - at least when the JDK version is the same. *## Expected behavior* Java compiler produces deterministic output i.e compiled byte code is exactly the same (SHA-wise) and is independent of the operating system type, version and other variables. *## Bug description* When compiling 1700+ classes in one of our modules on different CI agents (with exact same JDK version) I noticed intermittent SHA differences (of the compiled classes) that originated from a single class (the attached GradleExecGraphNodeExecutionInfo.java file.) It's a sealed interface and it uses records - I have an impression that using these two in conjunction plays a role here. I also attach the compiled bytecode coming from two different CI agents. If you compare the bytecode you will notice this: [image: image.png] The only difference (if the image is not displayed correctly) is that two same bytes (at the 0x440 position) switch the order depending on where the class is compiled. I didn't check the meaning of those bytes - I hope you can help here. "javap -c -l -private" shows that the output is exactly the same (but it isn't). The only difference between the CI nodes is the Linux kernel version (Linux 5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-generic (amd64). I was able to reproduce this behavior consistently when I compiled this module on different CI agents with the same difference in the Linux kernel. Here's the screen from Develocity showing the diff in the infrastructure. [image: image.png] I tried to reproduce this problem with the minimal reproducer (by extracting the sealed interface outside of the big module) but I failed here. The produced byte code was the same. Please let me know if you need to check sources of the other classes referenced by this sealed interface. I'd need to get an approval before sharing them publicly. Cheers, Przemek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 9238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165378 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GradleExecGraphNodeExecutionInfo.java Type: application/octet-stream Size: 2017 bytes Desc: not available URL: From vicente.romero at oracle.com Mon Dec 18 21:19:26 2023 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 18 Dec 2023 16:19:26 -0500 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: I think that having deterministic output is a very desirable property of a compiler but not a guarantee. If such non-determinism was provoking a compiler error this would be a higher priority error. Also as you determined yourself it is not possible to reproduce the issue with the test case you sent. We have made efforts in the past to remove sources of non-determinism in the compiler and I would say that the ones remaining are harder to remove. We could dive deeper with a reproductor but without that, it could be a futile effort, Vicente On 12/18/23 03:50, Przemek Bielicki wrote: > Hey Folks, > > I'm not 100% sure it's the best idea to post it here but I have no > access to the JDK JIRA (yet?) ? > > Last week I had a huge headache because of a bug I discovered in the > Java compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 > (mixed mode, sharing). I'm pretty certain it's a bug because my > expectation is that the compiler MUST produce deterministic output of > the compiled?classes - at least when the JDK version is the same. > > *## Expected behavior* > > Java compiler produces deterministic output i.e compiled byte code is > exactly the same (SHA-wise) and is independent?of the operating system > type, version and other variables. > > *## Bug description* > > When compiling 1700+ classes in one of our modules on different CI > agents (with exact same JDK version) I noticed intermittent?SHA > differences (of the compiled classes) that originated from a single > class (the attached?GradleExecGraphNodeExecutionInfo.java file.) It's > a sealed?interface and it uses records - I have an impression that > using these two in conjunction plays a role here. > > I also attach the compiled bytecode coming from two different CI agents. > If you compare the bytecode you will notice this: > image.png > The only difference (if the image is not displayed correctly) is that > two same bytes (at the 0x440 position) switch?the order depending on > where the class is compiled. I didn't check the meaning of those bytes > - I hope?you can help here. > > "javap -c -l -private" shows that the output?is exactly the same (but > it isn't). > > The only difference between the CI nodes is the Linux kernel version > (Linux 5.4.0-*166*-generic (amd64)?vs?Linux 5.4.0-*167*-generic > (amd64). I was able to reproduce this behavior consistently when I > compiled this module on different CI agents with the same difference > in the Linux kernel. > Here's the screen from Develocity showing the diff in the infrastructure. > image.png > > I tried to reproduce this problem with the minimal reproducer (by > extracting the sealed interface outside of the big module) but I > failed here. The produced byte code was the same. > > Please let me know if you need to check sources of the other classes > referenced by this sealed interface. I'd need to get an approval > before sharing them publicly. > > Cheers, > Przemek > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 9238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165378 bytes Desc: not available URL: From javalists at cbfiddle.com Mon Dec 18 22:55:13 2023 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 18 Dec 2023 14:55:13 -0800 Subject: a change in javac behavior In-Reply-To: <867073994.84357316.1702881585077.JavaMail.zimbra@univ-eiffel.fr> References: <9A03AF11-459F-4BF7-B561-39F982B0B95C@cbfiddle.com> <1096482159.84292091.1702835794187.JavaMail.zimbra@univ-eiffel.fr> <502E2D50-61B8-4677-A2AF-F9FD6A199716@cbfiddle.com> <867073994.84357316.1702881585077.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <0FBBED07-C865-40FA-AD24-1331890FAD83@cbfiddle.com> Thank you, Remi, for the explanation. I?m sure there are good reasons why Java works this way and it is cast in concrete, but I have to say that from a usability point of view, I find it undesirable that an explicit import can fail to apply to some uses of the identifier because of some factor that is not visible in the source file. Alan > On Dec 17, 2023, at 10:39?PM, forax at univ-mlv.fr wrote: > > > > From: "Alan Snyder" > To: "Remi Forax" > Cc: "compiler-dev" > Sent: Sunday, December 17, 2023 9:03:14 PM > Subject: Re: a change in javac behavior > So, that is how things are supposed to work? > > Yes, > > > Also, can you explain why javac does not complain about the builder.perform() invocation? > That variable is declared using the disputed parameter declaration. > If the parameter type is taken to be Thread.Builder, the call to perform should be rejected. > > Hard to say without the whole code but if your original error comes from the same file, it may mask the error at builder.perform(), javac does several passes on the same code. > > regards, > R?mi > > > > On Dec 17, 2023, at 9:56?AM, Remi Forax wrote: > > > > From: "Alan Snyder" > To: "compiler-dev" > Sent: Sunday, December 17, 2023 5:48:15 PM > Subject: a change in javac behavior > I?m experiencing a change in behavior compiling a particular file. > The compiler is trying to match an invocation to one of two constructors for a static class defined in the same file. > > The second constructor has a parameter of type Builder. In the past, this was interpreted as my Builder class, which is imported into this file. > That matches the invocation. > > Now, however, the constructor parameter type is interpreted as java.lang.Thread.Builder, presumably because the static class extends Thread. > That causes a mismatch to be reported. > > This interpretation appears to be limited to the resolution of the constructor invocation. Within the constructor, I do not get an error when the parameter > is used as an instance of my Builder class. > > This happens in JDK 20, JDK 21, and the latest build of JDK 22. > It does not happen in JDK 17. > > I believe this is not a behavior change, you are experiencing the "comb" behavior, where javac will first start to match members declared inside the class hierarchy before trying to match other members. > Here is the classical example > class Foo { > String name; > > void setName(String name) { > this.name = name; > } > > public void execute() { > new Thread() { > public void run() { > setName("foo"); > } > }.start(); > } > } > > where the method setName() inside execute() calls Thread.setName() instead of Foo.setName(). > > You code compiles with JDK 17 because Thread.Builder was introduced in 21 (19 as preview). > > If you want to avoid those kind of issues, prefer delegation to inheritance. > > > The error message: > > [javac] constructor Worker.Worker(@org.jetbrains.annotations.NotNull String, at org.jetbrains.annotations.NotNull SeverityLevel, at org.jetbrains.annotations.NotNull java.lang.Thread.Builder, at org.jetbrains.annotations.Nullable TaskStatusListener, at org.jetbrains.annotations.NotNull SimpleTaskReceiver) is not applicable > [javac] (argument mismatch; @org.jetbrains.annotations.NotNull com.cbfiddle.releases.Builder cannot be converted to @org.jetbrains.annotations.NotNull java.lang.Thread.Builder) > > > The constructor: > > public Worker(@NotNull String taskName, > @NotNull SeverityLevel level, > @NotNull Builder builder, > @Nullable TaskStatusListener tsl, > @NotNull SimpleTaskReceiver r) > { > this.taskName = taskName; > this.level = level; > this.r = r; > this.bl = createBuildListener(tsl); > this.op = () -> builder.perform(bl); > > setPriority(Thread.MIN_PRIORITY); > } > > regards, > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vromero at openjdk.org Mon Dec 18 23:44:00 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 18 Dec 2023 23:44:00 GMT Subject: RFR: 8305007: Within-lambda subclass of local class using method param causes compiler crash Message-ID: javac is crashing while compiling code like: public abstract class CompilerCrashLambdaPlusLocalClass { public abstract void consume(Runnable r); public void doThing(String parameter) { class LocalClass { @Override public String toString() { return parameter; } } consume(() -> { class LambdaLocalClass extends LocalClass {} new LocalClass(); }); } } the reason for the issue is that the mappings for captured variables created by LambdaToMethod are not copying the `adr`, local address, field of the original VarSymbol it is mapping. Later on during code generation an assertion was being triggered due to a variable with an `adr < 0` this patch fixes this issue. Thanks, Vicente ------------- Commit messages: - keeping address of original VarSymbol - Merge branch 'master' into JDK-8305007 - 8305007: Within-lambda subclass of local class using method param causes compiler crash Changes: https://git.openjdk.org/jdk/pull/17151/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305007 Stats: 48 lines in 2 files changed: 48 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17151/head:pull/17151 PR: https://git.openjdk.org/jdk/pull/17151 From pbielicki at gmail.com Tue Dec 19 07:44:48 2023 From: pbielicki at gmail.com (Przemek Bielicki) Date: Tue, 19 Dec 2023 08:44:48 +0100 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: I understand your point. I will work on the reproducer then. When I'm successful I will just share a link to github with you - I hope that's OK? In the meantime, can someone please explain to me the meaning of those two bytes that switch order? I'm sending the classes again, this time in a ZIP file as I guess .class extension may be considered as malware by the filters (?). Przemek On Mon, Dec 18, 2023 at 10:24?PM Vicente Romero wrote: > I think that having deterministic output is a very desirable property of a > compiler but not a guarantee. If such non-determinism was provoking a > compiler error this would be a higher priority error. Also as you > determined yourself it is not possible to reproduce the issue with the test > case you sent. We have made efforts in the past to remove sources of > non-determinism in the compiler and I would say that the ones remaining are > harder to remove. We could dive deeper with a reproductor but without that, > it could be a futile effort, > > Vicente > > On 12/18/23 03:50, Przemek Bielicki wrote: > > Hey Folks, > > I'm not 100% sure it's the best idea to post it here but I have no access > to the JDK JIRA (yet?) ? > > Last week I had a huge headache because of a bug I discovered in the Java > compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 (mixed mode, > sharing). I'm pretty certain it's a bug because my expectation is that the > compiler MUST produce deterministic output of the compiled classes - at > least when the JDK version is the same. > > *## Expected behavior* > > Java compiler produces deterministic output i.e compiled byte code is > exactly the same (SHA-wise) and is independent of the operating system > type, version and other variables. > > *## Bug description* > > When compiling 1700+ classes in one of our modules on different CI agents > (with exact same JDK version) I noticed intermittent SHA differences (of > the compiled classes) that originated from a single class (the > attached GradleExecGraphNodeExecutionInfo.java file.) It's a > sealed interface and it uses records - I have an impression that using > these two in conjunction plays a role here. > > I also attach the compiled bytecode coming from two different CI agents. > If you compare the bytecode you will notice this: > [image: image.png] > The only difference (if the image is not displayed correctly) is that two > same bytes (at the 0x440 position) switch the order depending on where the > class is compiled. I didn't check the meaning of those bytes - I hope you > can help here. > > "javap -c -l -private" shows that the output is exactly the same (but it > isn't). > > The only difference between the CI nodes is the Linux kernel version > (Linux 5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-generic (amd64). > I was able to reproduce this behavior consistently when I compiled this > module on different CI agents with the same difference in the Linux kernel. > Here's the screen from Develocity showing the diff in the infrastructure. > [image: image.png] > > I tried to reproduce this problem with the minimal reproducer (by > extracting the sealed interface outside of the big module) but I failed > here. The produced byte code was the same. > > Please let me know if you need to check sources of the other classes > referenced by this sealed interface. I'd need to get an approval before > sharing them publicly. > > Cheers, > Przemek > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 9238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165378 bytes Desc: not available URL: From pbielicki at gmail.com Tue Dec 19 08:28:07 2023 From: pbielicki at gmail.com (Przemek Bielicki) Date: Tue, 19 Dec 2023 09:28:07 +0100 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: As pointed out by a friendly member of this mailing group (not mentioning the name for privacy) I'm sharing the ZIP file using GDrive: https://drive.google.com/file/d/1SMuh71IxtUmZXcE5uvG1ppA0PKQjCOE1/view?usp=sharing Cheers, Przemek On Tue, Dec 19, 2023 at 8:44?AM Przemek Bielicki wrote: > I understand your point. I will work on the reproducer then. When I'm > successful I will just share a link to github with you - I hope that's OK? > > In the meantime, can someone please explain to me the meaning of those two > bytes that switch order? > I'm sending the classes again, this time in a ZIP file as I guess .class > extension may be considered as malware by the filters (?). > > Przemek > > On Mon, Dec 18, 2023 at 10:24?PM Vicente Romero > wrote: > >> I think that having deterministic output is a very desirable property of >> a compiler but not a guarantee. If such non-determinism was provoking a >> compiler error this would be a higher priority error. Also as you >> determined yourself it is not possible to reproduce the issue with the test >> case you sent. We have made efforts in the past to remove sources of >> non-determinism in the compiler and I would say that the ones remaining are >> harder to remove. We could dive deeper with a reproductor but without that, >> it could be a futile effort, >> >> Vicente >> >> On 12/18/23 03:50, Przemek Bielicki wrote: >> >> Hey Folks, >> >> I'm not 100% sure it's the best idea to post it here but I have no access >> to the JDK JIRA (yet?) ? >> >> Last week I had a huge headache because of a bug I discovered in the Java >> compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 (mixed mode, >> sharing). I'm pretty certain it's a bug because my expectation is that the >> compiler MUST produce deterministic output of the compiled classes - at >> least when the JDK version is the same. >> >> *## Expected behavior* >> >> Java compiler produces deterministic output i.e compiled byte code is >> exactly the same (SHA-wise) and is independent of the operating system >> type, version and other variables. >> >> *## Bug description* >> >> When compiling 1700+ classes in one of our modules on different CI agents >> (with exact same JDK version) I noticed intermittent SHA differences (of >> the compiled classes) that originated from a single class (the >> attached GradleExecGraphNodeExecutionInfo.java file.) It's a >> sealed interface and it uses records - I have an impression that using >> these two in conjunction plays a role here. >> >> I also attach the compiled bytecode coming from two different CI agents. >> If you compare the bytecode you will notice this: >> [image: image.png] >> The only difference (if the image is not displayed correctly) is that two >> same bytes (at the 0x440 position) switch the order depending on where the >> class is compiled. I didn't check the meaning of those bytes - I hope you >> can help here. >> >> "javap -c -l -private" shows that the output is exactly the same (but it >> isn't). >> >> The only difference between the CI nodes is the Linux kernel version >> (Linux 5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-generic (amd64). >> I was able to reproduce this behavior consistently when I compiled this >> module on different CI agents with the same difference in the Linux kernel. >> Here's the screen from Develocity showing the diff in the infrastructure. >> [image: image.png] >> >> I tried to reproduce this problem with the minimal reproducer (by >> extracting the sealed interface outside of the big module) but I failed >> here. The produced byte code was the same. >> >> Please let me know if you need to check sources of the other classes >> referenced by this sealed interface. I'd need to get an approval before >> sharing them publicly. >> >> Cheers, >> Przemek >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 9238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165378 bytes Desc: not available URL: From pbielicki at gmail.com Tue Dec 19 08:48:05 2023 From: pbielicki at gmail.com (Przemek Bielicki) Date: Tue, 19 Dec 2023 09:48:05 +0100 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: Oh damn! I think IDEA's decompiler helped a little with the explanation of the meaning of the order. As you can see from the attached screenshot the order of permits differ: permits GradleExecGraphNodeExecutionInfo.Task, GradleExecGraphNodeExecutionInfo.Transform { vs. permits GradleExecGraphNodeExecutionInfo.Transform, GradleExecGraphNodeExecutionInfo.Task { I guess this structure (collection of permits?) is handled by the compiler using some sort of Set instead of a List thus we get a non-deterministic order. My fellow Gradle colleagues told me that they discovered such non-determinisms in the past and the reasons were very similar. I hope it's helpful and can unblock you from digging deeper? ?? What's interesting is that javap isn't showing this difference. ? Cheers, Przemek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: idea_decompiled.png Type: image/png Size: 166235 bytes Desc: not available URL: From james.laskey at oracle.com Tue Dec 19 08:56:10 2023 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 19 Dec 2023 08:56:10 +0000 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: This is very good. Thanks for isolating. This is the sort of thing that is easily missed because of the subtlety and could lead to days of searching. On 19 Dec 2023, at 04:48, Przemek Bielicki wrote: Oh damn! I think IDEA's decompiler helped a little with the explanation of the meaning of the order. As you can see from the attached screenshot the order of permits differ: permits GradleExecGraphNodeExecutionInfo.Task, GradleExecGraphNodeExecutionInfo.Transform { vs. permits GradleExecGraphNodeExecutionInfo.Transform, GradleExecGraphNodeExecutionInfo.Task { I guess this structure (collection of permits?) is handled by the compiler using some sort of Set instead of a List thus we get a non-deterministic order. My fellow Gradle colleagues told me that they discovered such non-determinisms in the past and the reasons were very similar. I hope it's helpful and can unblock you from digging deeper? ?? What's interesting is that javap isn't showing this difference. ? Cheers, Przemek [idea_decompiled.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: idea_decompiled.png Type: image/png Size: 166235 bytes Desc: idea_decompiled.png URL: From jpai at openjdk.org Tue Dec 19 14:23:37 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Dec 2023 14:23:37 GMT Subject: RFR: 8318971 : Better Error Handling for Jar Tool Processing of "@File" In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 18:16:56 GMT, Weibing Xiao wrote: > Better Error Handling for Jar Tool Processing of "@File"
> > This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423. > > Thank you. Hello Weibing, I had another look at this today. The implementation change looks OK. But I think the JBS issue summary and the JBS issue description will need to be updated. The real issue here isn't specific to the use of `@file` by the `jar` tool. Instead the issue is about an internal detail of the `jar` tool implementation. When the `jar` tool is launched either to create (`-c`) or to update (`-u`) a jar file, it gets passed a list of files to include/update the jar file with. One way to pass those options is literally as part of the command. The other way is to include those files path in a separate file and pass that file to the `jar` tool as the `@that-other-file`. The issue here affects both those variants. The internal implementation of the `jar` tool in `sun/tools/jar/Main.java`, uses a flag called `ok` to keep track of whether there was any error during the `jar` tool action processing. This `ok` flagged is marked by various methods that get invoked during the `jar` processing. When `-c` or `-u` options are passed to the `jar` tool, the `sun/tools/jar/Main.java` calls an internal method `expand()`. This method is responsible for finalizing the files that need to be included in the jar that gets created or updated. This expand method is also responsible for marking that `ok` flag if there are any errors (like any file that was specified to be included/updated in the jar, is missing). Once the `expand()` method returns, the internal implementation detail of the `jar` tool will go ahead and create a temporary file. Content will be written out to this temporary files. The more entries to create in the final jar being created/updated, the more time and more disk space this temporary file will consume. Finally, when writing out to the temporary file is done, the `ok` flag is checked to see if it was flagged as failed. If `ok` says no errors were noticed, then the temporary file that was created will be moved as the final jar that had to be created/updated. If `o k` said that there were failures, then the temporary file is deleted and the final jar to be created won't get created (rightly so) nor will the final jar get updated, in case of `-u` option (rightly so). The issue here is that if the `expand()` method noticed that there was an error with the provided file paths (like 1 out of the 5 files specified is missing), then it marks the `ok` flag to indicate that, but the current implementation of the `jar` tool (before the change in this PR) just doesn't check the flag and goes on to do the expensive work of creating a temporary file (which will have the rest of the 4 files) and that temporary file will then finally get discarded at the end. This entire process of creating the temporary file can be avoided by checking the `ok` flag after the `expand()` method returns. That is what the proposal in the PR does and I think it looks good. Given that, I think the JBS issue summary and the description doesn't match what we are doing here. Would you be able to update those accordingly? If you want me to do that, do let me know and you can then update this PR title. As for the new test method introduced in this PR, in the existing `InputFilesTest`, it took me a while to understand what exactly this was doing. One part of it is due to a bit misleading method names - for example, `println()` method which going by that name, I thought was printing a new line (I didn't understand why) but turns out that method actually prints out the output that has been captured in a `ByteArrayOutputStream` by a previous invocation of the `jar` tool from within the test method. That `println()` method has been that way even before the changes in this PR, so I think that is OK (unless you won't mind updating the name to something better?). This existing `InputFilesTest` runs various tests for the `jar` tool by passing it file paths to be included/updated in the jar. It currently doesn't have any coverage for `@file` usages, so this new test method is adding that. However, this new test method isn't exercising the case where one or more file paths specified in the passed `@file` are missing. So it isn't exactly exercising the issue that is being fixed. I think the test you added is OK as a positive test (where all passed file paths are present), but I think we would also need one for missing files and then assert in that test that the final jar isn't created or updated and the `jar` tool returns a non-zero exit code. Please also add some comments to the newly introduced test methods to make it easier to understand what they are testing. While at it, could you also please check if the `@file` usage has test coverage from some other existing test class? I am bit surprised that this `InputFilesTest` doesn't have any, so maybe it's tested elsewhere? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17088#issuecomment-1862849864 From vicente.romero at oracle.com Tue Dec 19 14:39:51 2023 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 19 Dec 2023 09:39:51 -0500 Subject: [External] : Re: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: <37623827-772d-48f7-83c1-e34358d5617f@oracle.com> On 12/19/23 02:44, Przemek Bielicki wrote: > I understand?your?point. I will work on the reproducer then. When I'm > successful?I will just share a link to github?with you - I hope that's OK? yep that's fine, > > In the meantime, can someone please explain to me the meaning of those > two bytes that switch?order? > I'm sending the classes again, this time in a ZIP file as I guess > .class extension may be considered as malware by the filters (?). yes I think that .class are not allowed > > Przemek Thanks, Vicente > > On Mon, Dec 18, 2023 at 10:24?PM Vicente Romero > wrote: > > I think that having deterministic output is a very desirable > property of a compiler but not a guarantee. If such > non-determinism was provoking a compiler error this would be a > higher priority error. Also as you determined yourself it is not > possible to reproduce the issue with the test case you sent. We > have made efforts in the past to remove sources of non-determinism > in the compiler and I would say that the ones remaining are harder > to remove. We could dive deeper with a reproductor but without > that, it could be a futile effort, > > Vicente > > On 12/18/23 03:50, Przemek Bielicki wrote: >> Hey Folks, >> >> I'm not 100% sure it's the best idea to post it here but I have >> no access to the JDK JIRA (yet?) ? >> >> Last week I had a huge headache because of a bug I discovered in >> the Java compiler - Eclipse Temurin OpenJDK 64-Bit Server VM >> 17.0.9+9 (mixed mode, sharing). I'm pretty certain it's a bug >> because my expectation is that the compiler MUST produce >> deterministic output of the compiled?classes - at least when the >> JDK version is the same. >> >> *## Expected behavior* >> >> Java compiler produces deterministic output i.e compiled byte >> code is exactly the same (SHA-wise) and is independent?of the >> operating system type, version and other variables. >> >> *## Bug description* >> >> When compiling 1700+ classes in one of our modules on different >> CI agents (with exact same JDK version) I noticed >> intermittent?SHA differences (of the compiled classes) that >> originated from a single class (the >> attached?GradleExecGraphNodeExecutionInfo.java file.) It's a >> sealed?interface and it uses records - I have an impression that >> using these two in conjunction plays a role here. >> >> I also attach the compiled bytecode coming from two different CI >> agents. >> If you compare the bytecode you will notice this: >> image.png >> The only difference (if the image is not displayed correctly) is >> that two same bytes (at the 0x440 position) switch?the order >> depending on where the class is compiled. I didn't check the >> meaning of those bytes - I hope?you can help here. >> >> "javap -c -l -private" shows that the output?is exactly the same >> (but it isn't). >> >> The only difference between the CI nodes is the Linux kernel >> version (Linux 5.4.0-*166*-generic (amd64)?vs?Linux >> 5.4.0-*167*-generic (amd64). I was able to reproduce this >> behavior consistently when I compiled this module on different CI >> agents with the same difference in the Linux kernel. >> Here's the screen from Develocity showing the diff in the >> infrastructure. >> image.png >> >> I tried to reproduce this problem with the minimal reproducer (by >> extracting the sealed interface outside of the big module) but I >> failed here. The produced byte code was the same. >> >> Please let me know if you need to check sources of the other >> classes referenced by this sealed interface. I'd need to get an >> approval before sharing them publicly. >> >> Cheers, >> Przemek >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 9238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165378 bytes Desc: not available URL: From vicente.romero at oracle.com Tue Dec 19 16:45:47 2023 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 19 Dec 2023 11:45:47 -0500 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: Hi Przemek, Thanks again for the report and the additional info provided. I have created [1] and assigned it to myself, Vicente [1] https://bugs.openjdk.org/browse/JDK-8322477 On 12/19/23 03:48, Przemek Bielicki wrote: > Oh damn! I think IDEA's decompiler helped a little with the > explanation of the meaning of the order. > As you can see from the attached screenshot the order of permits differ: > > permits GradleExecGraphNodeExecutionInfo.Task, > GradleExecGraphNodeExecutionInfo.Transform { > vs. > permits GradleExecGraphNodeExecutionInfo.Transform, > GradleExecGraphNodeExecutionInfo.Task { > > I guess this structure (collection of permits?) is handled by the > compiler using some sort of Set instead of a List thus we get a > non-deterministic?order. > My fellow Gradle colleagues told me that they discovered such > non-determinisms in the past and the reasons were very similar. > > I hope it's helpful and can unblock you from digging deeper???? > > What's interesting is that javap isn't showing this difference.?? > > Cheers, > Przemek -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbielicki at gmail.com Tue Dec 19 16:46:21 2023 From: pbielicki at gmail.com (Przemek Bielicki) Date: Tue, 19 Dec 2023 17:46:21 +0100 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: Awesome, thanks! W dniu wt., 19.12.2023 o 17:45 Vicente Romero napisa?(a): > Hi Przemek, > > Thanks again for the report and the additional info provided. I have > created [1] and assigned it to myself, > > Vicente > > [1] https://bugs.openjdk.org/browse/JDK-8322477 > > > On 12/19/23 03:48, Przemek Bielicki wrote: > > Oh damn! I think IDEA's decompiler helped a little with the explanation of > the meaning of the order. > As you can see from the attached screenshot the order of permits differ: > > permits GradleExecGraphNodeExecutionInfo.Task, > GradleExecGraphNodeExecutionInfo.Transform { > vs. > permits GradleExecGraphNodeExecutionInfo.Transform, > GradleExecGraphNodeExecutionInfo.Task { > > I guess this structure (collection of permits?) is handled by the compiler > using some sort of Set instead of a List thus we get a > non-deterministic order. > My fellow Gradle colleagues told me that they discovered such > non-determinisms in the past and the reasons were very similar. > > I hope it's helpful and can unblock you from digging deeper? ?? > > What's interesting is that javap isn't showing this difference. ? > > Cheers, > Przemek > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Dec 19 16:52:06 2023 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 19 Dec 2023 11:52:06 -0500 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: <2607ee7b-86dc-478c-bf9e-6d6ebb02ed1b@oracle.com> On 12/19/23 03:48, Przemek Bielicki wrote: > Oh damn! I think IDEA's decompiler helped a little with the > explanation of the meaning of the order. > As you can see from the attached screenshot the order of permits differ: > > permits GradleExecGraphNodeExecutionInfo.Task, > GradleExecGraphNodeExecutionInfo.Transform { > vs. > permits GradleExecGraphNodeExecutionInfo.Transform, > GradleExecGraphNodeExecutionInfo.Task { > > I guess this structure (collection of permits?) is handled by the > compiler using some sort of Set instead of a List thus we get a > non-deterministic?order. > My fellow Gradle colleagues told me that they discovered such > non-determinisms in the past and the reasons were very similar. > > I hope it's helpful and can unblock you from digging deeper???? yep I think this is good enough to dig deeper, > > What's interesting is that javap isn't showing this difference.?? > > Cheers, > Przemek Thanks Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Dec 19 16:55:52 2023 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 19 Dec 2023 11:55:52 -0500 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com> Hi Przemek, can you patch JDK sources, rebuild them and try if a given patch fixes your issue or do you need a customized JDK? Thanks, Vicente On 12/19/23 03:48, Przemek Bielicki wrote: > Oh damn! I think IDEA's decompiler helped a little with the > explanation of the meaning of the order. > As you can see from the attached screenshot the order of permits differ: > > permits GradleExecGraphNodeExecutionInfo.Task, > GradleExecGraphNodeExecutionInfo.Transform { > vs. > permits GradleExecGraphNodeExecutionInfo.Transform, > GradleExecGraphNodeExecutionInfo.Task { > > I guess this structure (collection of permits?) is handled by the > compiler using some sort of Set instead of a List thus we get a > non-deterministic?order. > My fellow Gradle colleagues told me that they discovered such > non-determinisms in the past and the reasons were very similar. > > I hope it's helpful and can unblock you from digging deeper???? > > What's interesting is that javap isn't showing this difference.?? > > Cheers, > Przemek -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbielicki at gmail.com Tue Dec 19 17:01:48 2023 From: pbielicki at gmail.com (Przemek Bielicki) Date: Tue, 19 Dec 2023 18:01:48 +0100 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com> References: <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com> Message-ID: Probably - I don?t have the environment and I also never built the JDK from sources it I have a technical skills to eventually do it ? Can you pls point me to some docs on how to build the JDK from scratch? Cheers, Przemek W dniu wt., 19.12.2023 o 17:56 Vicente Romero napisa?(a): > Hi Przemek, > > can you patch JDK sources, rebuild them and try if a given patch fixes > your issue or do you need a customized JDK? > > Thanks, > Vicente > > > On 12/19/23 03:48, Przemek Bielicki wrote: > > Oh damn! I think IDEA's decompiler helped a little with the explanation of > the meaning of the order. > As you can see from the attached screenshot the order of permits differ: > > permits GradleExecGraphNodeExecutionInfo.Task, > GradleExecGraphNodeExecutionInfo.Transform { > vs. > permits GradleExecGraphNodeExecutionInfo.Transform, > GradleExecGraphNodeExecutionInfo.Task { > > I guess this structure (collection of permits?) is handled by the compiler > using some sort of Set instead of a List thus we get a > non-deterministic order. > My fellow Gradle colleagues told me that they discovered such > non-determinisms in the past and the reasons were very similar. > > I hope it's helpful and can unblock you from digging deeper? ?? > > What's interesting is that javap isn't showing this difference. ? > > Cheers, > Przemek > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Dec 19 18:11:09 2023 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 19 Dec 2023 13:11:09 -0500 Subject: [External] : Re: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com> Message-ID: <98b41452-12e3-457f-9128-afec5f033a45@oracle.com> no worries I can publish a JDK you can play with, Thanks, Vicente On 12/19/23 12:01, Przemek Bielicki wrote: > Probably - I don?t have the environment and I also never built the JDK > from sources it I have a technical skills to eventually do it ? > > Can you pls point me to some docs on how to build the JDK from scratch? > > Cheers, > Przemek > > W dniu wt., 19.12.2023 o 17:56 Vicente Romero > napisa?(a): > > Hi Przemek, > > can you patch JDK sources, rebuild them and try if a given patch > fixes your issue or do you need a customized JDK? > > Thanks, > Vicente > > > On 12/19/23 03:48, Przemek Bielicki wrote: >> Oh damn! I think IDEA's decompiler helped a little with the >> explanation of the meaning of the order. >> As you can see from the attached screenshot the order of permits >> differ: >> >> permits GradleExecGraphNodeExecutionInfo.Task, >> GradleExecGraphNodeExecutionInfo.Transform { >> vs. >> permits GradleExecGraphNodeExecutionInfo.Transform, >> GradleExecGraphNodeExecutionInfo.Task { >> >> I guess this structure (collection of permits?) is handled by the >> compiler using some sort of Set instead of a List thus we get a >> non-deterministic?order. >> My fellow Gradle colleagues told me that they discovered such >> non-determinisms in the past and the reasons were very similar. >> >> I hope it's helpful and can unblock you from digging deeper???? >> >> What's interesting is that javap isn't showing this difference.?? >> >> Cheers, >> Przemek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acobbs at openjdk.org Tue Dec 19 22:53:16 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 19 Dec 2023 22:53:16 GMT Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer Message-ID: Please review several fixes and improvements to the `this-escape` lint warning analyzer. The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design. Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below. The changes are summarized here: #### 1. Generalize how we categorize references The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape". Previously the `Ref` categories were: * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed * `VarRef` - A local variable or method parameter currently in scope * `ExprRef` - An object reference sitting on top of the Java execution stack * `YieldRef` - The current switch expression's yield value(s) * `ReturnRef` - The current method's return value(s) For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced). The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference. In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect". As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`. #### 2. Track the types of all references By keeping track of the actual type of each reference (as opposed to just looking at its compile-time type), we can make more precise calculations. We weren't doing this before. For example consider this class: public class Leaker { public Leaker() { Runnable r = new Runnable() { public void run() { Leaker.this.mightLeak(); } }; r.run(); // there is a leak here } protected void mightLeak() { // a subclass could override this method } } Previously we would not have detected a 'this' escape because we wouldn't have known that variable `r` is a `Leaker$1`, which allows us to deduce that `r.run()` is actually `Leaker$1.run()` (which we can analyze) instead of just `Runnable.run()` (which we can't). Because of this change, some `Ref` types that were previously singletons are no longer singletons. For example, now there can be more than one `ReturnRef` in scope at any time, representing different possible types for the method's return value. #### 3. Handling of non-public outer instances To eliminate some false positives, we no longer warn if a leak happens solely due to a "non-public" outer instance. For example, consider this code: public class Test { public Test() { System.out.println(new Inner()); } private class Inner { Object getMyOuter() { return Test.this; } } } The outer `Test` instance associated with objects of type `Test.Inner` is considered "non-public" because it's not directly accessible to the outside world (because `Test.Inner` is a private class). So while it's true that instances of `Test.Inner` retain a reference to their enclosing instance, an unrelated method like `System.out.println()` wouldn't know how to access them. The only way a `Test.Inner` could leak its outer instance to such a method is if it did so (perhaps indirectly) through some entr?e that the method "knows about". Of course, that's possible, but absent any further analysis (which could be added in the future), the cost/reward trade-off doesn't seem worth generating a warning here. This is an area for future research. In other words: when a `Ref` is passed to unknown code, when is it worth complaining about a leak, and when should we just be silent? Previously we always complained, but now that we have more information about references (namely, their types) we can be a little more discriminating. In any case, this decision is encapsulated in a new method `triggersUnknownInvokeLeak()`. #### 4. Fix tracking of new instances Previously we were not tracking references from a constructor's "return value", i.e., the new instance. We fix this by pretending that constructors end with `return this`. #### 5. Fix tracking of enhanced `for()` loops Previously we were not tracking the implicit invocations of `iterator()`, `hasNext()`, and `next()` associated with enhanced `for()` loops. This patch adds that tracking. #### 6. Fix leaks via return values from lambdas and method references Leaks inside lambdas and methods referred-to by method reference were being detected properly, but leaks from the _return values_ of those things were not. So for example, this code would escape notice: import java.util.function.Supplier; public class Test { public Test() { ((Supplier)this::self).get().mightLeak(); } public final Test self() { return this; } protected void mightLeak() { // a subclass could override this method } } This patch fixes this omission. #### 7. Some minor refactoring to make the code clearer * Some methods were renamed * Some bits of code were extracted into separate methods * Added `Ref` methods `toDirect()`, `toIndirect()`, `toOuter()`, and `fromOuter()` #### 8. Remove some unnecessary suppression Several `*.gmk` build files were suppressing `this-escape` warnings unnecessarily. These have been updated. ------------- Commit messages: - Merge branch 'master' into JDK-8317376 - Merge branch 'master' into JDK-8317376 - Javadoc++ - Merge branch 'master' into JDK-8317376 - Several improvements to the 'this' escape analyzer. Changes: https://git.openjdk.org/jdk/pull/16208/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16208&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317376 Stats: 870 lines in 20 files changed: 512 ins; 148 del; 210 mod Patch: https://git.openjdk.org/jdk/pull/16208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16208/head:pull/16208 PR: https://git.openjdk.org/jdk/pull/16208 From davidalayachew at gmail.com Wed Dec 20 04:10:49 2023 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 19 Dec 2023 23:10:49 -0500 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: <2ccac985-e57e-4a7b-ae98-dc1802a5ee4d@oracle.com> Message-ID: I'm not Vicente, but I'm 99% sure this is the link that would have been sent. https://openjdk.org/groups/build/doc/building.html On Tue, Dec 19, 2023 at 12:02?PM Przemek Bielicki wrote: > Probably - I don?t have the environment and I also never built the JDK > from sources it I have a technical skills to eventually do it ? > > Can you pls point me to some docs on how to build the JDK from scratch? > > Cheers, > Przemek > > W dniu wt., 19.12.2023 o 17:56 Vicente Romero > napisa?(a): > >> Hi Przemek, >> >> can you patch JDK sources, rebuild them and try if a given patch fixes >> your issue or do you need a customized JDK? >> >> Thanks, >> Vicente >> >> >> On 12/19/23 03:48, Przemek Bielicki wrote: >> >> Oh damn! I think IDEA's decompiler helped a little with the explanation >> of the meaning of the order. >> As you can see from the attached screenshot the order of permits differ: >> >> permits GradleExecGraphNodeExecutionInfo.Task, >> GradleExecGraphNodeExecutionInfo.Transform { >> vs. >> permits GradleExecGraphNodeExecutionInfo.Transform, >> GradleExecGraphNodeExecutionInfo.Task { >> >> I guess this structure (collection of permits?) is handled by the >> compiler using some sort of Set instead of a List thus we get a >> non-deterministic order. >> My fellow Gradle colleagues told me that they discovered such >> non-determinisms in the past and the reasons were very similar. >> >> I hope it's helpful and can unblock you from digging deeper? ?? >> >> What's interesting is that javap isn't showing this difference. ? >> >> Cheers, >> Przemek >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.org Wed Dec 20 09:06:37 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 20 Dec 2023 09:06:37 GMT Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs wrote: > Please review several fixes and improvements to the `this-escape` lint warning analyzer. > > The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design. > > Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below. > > The changes are summarized here: > > #### 1. Generalize how we categorize references > > The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape". > > Previously the `Ref` categories were: > * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed > * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed > * `VarRef` - A local variable or method parameter currently in scope > * `ExprRef` - An object reference sitting on top of the Java execution stack > * `YieldRef` - The current switch expression's yield value(s) > * `ReturnRef` - The current method's return value(s) > > For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced). > > The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference. > > In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect". > > As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`. > > #### 2. Track the types of all references > > By keeping track of the actual type of... Hummm... I know a few (two) places in `java.net.http` where we deliberately let `this` escape. One place is where we set up the double final link between an `HttpClientImpl` instance and its facade (set at construction time where the facade has a final field pointing at its implementation and the implementation has a final `WeakRefeference` pointing at its facade, all set up within their constructors). Another place is with the `SSLflowDelegate` where `connect`, a protected method implemented on the `SSLTube.SSLTubeFlowDelegate` subclass is called from within the super class constructor. I assume these were the reason why `this-escape` analysis had been disabled on `java.net.http`, and I expect the reason why the analysis can be reenabled by default is because of point 3 above? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16208#issuecomment-1864102081 From acobbs at openjdk.org Wed Dec 20 15:37:48 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 20 Dec 2023 15:37:48 GMT Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 09:03:34 GMT, Daniel Fuchs wrote: > I assume these were the reason why this-escape analysis had been disabled on java.net.http, and I expect the reason why the analysis can be reenabled by default is because of point 3 above? No, the goal here is simply to remove unnecessary build flags. All Java code is compiled with `-Werror` so if the build still succeeds with the build flag removed then (in theory at least) the flag is no longer needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16208#issuecomment-1864689891 From achung at openjdk.org Wed Dec 20 19:06:58 2023 From: achung at openjdk.org (Alisen Chung) Date: Wed, 20 Dec 2023 19:06:58 GMT Subject: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update Message-ID: Backport of JDK-8322041 ------------- Commit messages: - Backport b061b6678fde891974d5b58cec963b3481099a8d Changes: https://git.openjdk.org/jdk22/pull/22/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=22&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322041 Stats: 290 lines in 36 files changed: 166 ins; 15 del; 109 mod Patch: https://git.openjdk.org/jdk22/pull/22.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/22/head:pull/22 PR: https://git.openjdk.org/jdk22/pull/22 From kcr at openjdk.org Wed Dec 20 19:18:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 20 Dec 2023 19:18:50 GMT Subject: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <0PwfnK4xd97FHzIR9ChcGQXtE1EExZ-YgFSRY6T2oDQ=.899d8f7b-9807-4d6d-b63a-12bf207c68d7@github.com> On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung wrote: > Backport of JDK-8322041 The patch looks good. Additionally, I confirmed that the files in question are identical to those in jdk mainline after this patch is applied. It will need a "R"eviewer to approve. ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk22/pull/22#pullrequestreview-1791515826 From naoto at openjdk.org Wed Dec 20 20:46:51 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 20 Dec 2023 20:46:51 GMT Subject: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung wrote: > Backport of JDK-8322041 Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk22/pull/22#pullrequestreview-1791633961 From achung at openjdk.org Wed Dec 20 21:44:48 2023 From: achung at openjdk.org (Alisen Chung) Date: Wed, 20 Dec 2023 21:44:48 GMT Subject: [jdk22] Integrated: 8322041: JDK 22 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung wrote: > Backport of JDK-8322041 This pull request has now been integrated. Changeset: a05f3d10 Author: Alisen Chung URL: https://git.openjdk.org/jdk22/commit/a05f3d10cc374297fd9b0fa27305c9b26f8081d2 Stats: 290 lines in 36 files changed: 166 ins; 15 del; 109 mod 8322041: JDK 22 RDP1 L10n resource files update Reviewed-by: kcr, naoto Backport-of: b061b6678fde891974d5b58cec963b3481099a8d ------------- PR: https://git.openjdk.org/jdk22/pull/22 From erikj at openjdk.org Thu Dec 21 14:21:46 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 21 Dec 2023 14:21:46 GMT Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer In-Reply-To: References: Message-ID: <5tfqJ0axChFrBuu-YP6qxuVp6w98q26qBt-jusjSPuM=.a81fb73b-49cf-4391-99c0-f31a53f8d431@github.com> On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs wrote: > Please review several fixes and improvements to the `this-escape` lint warning analyzer. > > The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design. > > Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below. > > The changes are summarized here: > > #### 1. Generalize how we categorize references > > The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape". > > Previously the `Ref` categories were: > * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed > * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed > * `VarRef` - A local variable or method parameter currently in scope > * `ExprRef` - An object reference sitting on top of the Java execution stack > * `YieldRef` - The current switch expression's yield value(s) > * `ReturnRef` - The current method's return value(s) > > For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced). > > The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference. > > In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect". > > As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`. > > #### 2. Track the types of all references > > By keeping track of the actual type of... The build changes look ok. ------------- PR Review: https://git.openjdk.org/jdk/pull/16208#pullrequestreview-1793061991 From mail2akash97 at gmail.com Sun Dec 24 08:57:45 2023 From: mail2akash97 at gmail.com (Keerthivasan Raghavan) Date: Sun, 24 Dec 2023 14:27:45 +0530 Subject: Programmatic creation of class files and self modifying code Message-ID: Hi All, I am a newbie to java. How do I programmatically create "*.class" files using the compiler API? I do not want to parse "*.java" files , but generate "*.class" files. This brings me to the next question of how to execute dynamically generated byte code: just like JRE jas JIT I would like to programmatically JIT java byte code and execute it. This is inline with the concept of self modifying code: https://en.wikipedia.org/wiki/Self-modifying_code Any pointers/code-snippets to the compiler API that I can use would be helpful. Thank you, Keerthivasan Raghavan -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Sun Dec 24 12:10:42 2023 From: liangchenblue at gmail.com (-) Date: Sun, 24 Dec 2023 06:10:42 -0600 Subject: Programmatic creation of class files and self modifying code In-Reply-To: References: Message-ID: Hello Keerthivasan, Currently, most Java applications parse and create Class Files with ASM (short for "assembly") library, available at https://asm.ow2.io. It requires Java 6 and above. Given Java 6 is really old, Java Core Libraries is introducing the Class-File API https://openjdk.org/jeps/457, allowing the Class File handling to evolve with Java itself for better forward compatibility, as existing ASM fails every time Java rolls out a new version. In addition, javac uses an internal library in com.sun.tools, which is planned to be replaced by Class-File API in the long run, though it might be only after everything else has migrated due to javac having high compatibility requirements. For executing defined bytecode, there are 2 main ways: 1. You will define a custom ClassLoader with an accessible defineClass(String, byte[], int, int), which works for all Java versions, but is chunky (as you need to define a class to access defineClass) 2. You will use MethodHandles.Lookup.defineClass and MethodHandles.Lookup.defineHiddenClass, available in Java 12 and 16 respectively. They are much more convenient, but can only define classes in the same package. In addition, defineHiddenClass is the only way to define "hidden classes", which unlike regular classes, can be unloaded when it's no longer needed. (Previously, it was done by custom ClassLoaders that are discarded explicitly) P.S. The compiler-dev list is focused around development around javac, and your question seems a bit off-topic. But I don't know which list is proper for this question either. Best On Sun, Dec 24, 2023 at 2:58?AM Keerthivasan Raghavan < mail2akash97 at gmail.com> wrote: > Hi All, > > I am a newbie to java. How do I programmatically create "*.class" files > using the compiler API? I do not want to parse "*.java" files , but > generate "*.class" files. This brings me to the next question of how to > execute dynamically generated byte code: just like JRE jas JIT I would like > to programmatically JIT java byte code and execute it. This is inline with > the concept of self modifying code: > > https://en.wikipedia.org/wiki/Self-modifying_code > > Any pointers/code-snippets to the compiler API that I can use would be > helpful. > > Thank you, > Keerthivasan Raghavan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Sun Dec 24 15:07:46 2023 From: liangchenblue at gmail.com (-) Date: Sun, 24 Dec 2023 09:07:46 -0600 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: Hi Przemek, Since you say this happens "intermittently", like how often does it happen (like 50% of the time or way less frequent)? And does it happen with Java 21 as well? I have tried to create minimal cases to reproduce on Java 21, but to no avail. I think the class 222 you've attached in the emails should be the correct one, while class 80 seems to be wrong, as the PermittedSubclasses should be declared in class file in the order they are present in the source file. A preliminary examination shows that other 2 attributes NestMembers and InnerClasses are solely handled by ClassWriter while the implicit PermittedSubclasses depends on TypeEnter's processing order. That might be a clue if we can confirm that this happens on Java 21. Chen On Mon, Dec 18, 2023 at 2:51?AM Przemek Bielicki wrote: > Hey Folks, > > I'm not 100% sure it's the best idea to post it here but I have no access > to the JDK JIRA (yet?) ? > > Last week I had a huge headache because of a bug I discovered in the Java > compiler - Eclipse Temurin OpenJDK 64-Bit Server VM 17.0.9+9 (mixed mode, > sharing). I'm pretty certain it's a bug because my expectation is that the > compiler MUST produce deterministic output of the compiled classes - at > least when the JDK version is the same. > > *## Expected behavior* > > Java compiler produces deterministic output i.e compiled byte code is > exactly the same (SHA-wise) and is independent of the operating system > type, version and other variables. > > *## Bug description* > > When compiling 1700+ classes in one of our modules on different CI agents > (with exact same JDK version) I noticed intermittent SHA differences (of > the compiled classes) that originated from a single class (the > attached GradleExecGraphNodeExecutionInfo.java file.) It's a > sealed interface and it uses records - I have an impression that using > these two in conjunction plays a role here. > > I also attach the compiled bytecode coming from two different CI agents. > If you compare the bytecode you will notice this: > [image: image.png] > The only difference (if the image is not displayed correctly) is that two > same bytes (at the 0x440 position) switch the order depending on where the > class is compiled. I didn't check the meaning of those bytes - I hope you > can help here. > > "javap -c -l -private" shows that the output is exactly the same (but it > isn't). > > The only difference between the CI nodes is the Linux kernel version > (Linux 5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-generic (amd64). > I was able to reproduce this behavior consistently when I compiled this > module on different CI agents with the same difference in the Linux kernel. > Here's the screen from Develocity showing the diff in the infrastructure. > [image: image.png] > > I tried to reproduce this problem with the minimal reproducer (by > extracting the sealed interface outside of the big module) but I failed > here. The produced byte code was the same. > > Please let me know if you need to check sources of the other classes > referenced by this sealed interface. I'd need to get an approval before > sharing them publicly. > > Cheers, > Przemek > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 9238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165378 bytes Desc: not available URL: From pbielicki at gmail.com Thu Dec 28 14:44:43 2023 From: pbielicki at gmail.com (Przemek Bielicki) Date: Thu, 28 Dec 2023 15:44:43 +0100 Subject: [Bug] javac gives non-deterministic output (for sealed interface with records) In-Reply-To: References: Message-ID: Hi Chen, I have two classes that use the same syntax. I can always reproduce this "issue". There is a caveat though. Once the problem appears in the first compiled class, another time in the second and yet another time in both classes. It is reproducible in JDK 23 - Vicente sent me a patched JDK 23 with extra logging and I was able to catch the different order of processing the permits depending on where those classes were compiled: :scans-server:compileJava [javac-log]: adding Task to GradleExecGraphNodeExecutionInfo [javac-log]: permitted list is now: Task, [javac-log]: adding Transform to GradleExecGraphNodeExecutionInfo [javac-log]: permitted list is now: Task, Transform, vs. :scans-server:compileJava [javac-log]: adding Transform to GradleExecGraphNodeExecutionInfo [javac-log]: permitted list is now: Transform, [javac-log]: adding Task to GradleExecGraphNodeExecutionInfo [javac-log]: permitted list is now: Transform, Task, We'll continue our investigations in January (I hope). If you think that the class 80 is wrong then it's coming from the node with "Linux 5.4.0-*166*-generic" kernel (Ubuntu 20.04.6 LTS). I am able to reproduce this issue with the same frequency on any node that is using the same kernel version. This is super weird but this minor kernel version difference is the only indicator that I was able to catch. I hope that helps. Cheers, Przemek -------------- next part -------------- An HTML attachment was scrubbed... URL: