From vromero at openjdk.org Wed Nov 1 04:53:34 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 1 Nov 2023 04:53:34 GMT Subject: RFR: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled Message-ID: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion was being thrown for code that was erroneous in the first place. Basically having: ------------- Commit messages: - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled Changes: https://git.openjdk.org/jdk/pull/16443/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8191460 Stats: 170 lines in 2 files changed: 162 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16443/head:pull/16443 PR: https://git.openjdk.org/jdk/pull/16443 From jlahoda at openjdk.org Wed Nov 1 12:13:00 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 1 Nov 2023 12:13:00 GMT Subject: RFR: 8317048: VerifyError with unnamed pattern variable and more than one components In-Reply-To: References: Message-ID: On Fri, 29 Sep 2023 10:20:10 GMT, Aggelos Biboudis wrote: > There were situations when javac optimizes switch structures (by merging the head of cases recursively) when two neighboring cases have a mix of named and unnamed patterns. This resulted translation is like the following: > > From this: > > > static int compareTo(Tuple, R> o) { > return switch (o) { > case Tuple, R>(R1 _, R1 _) -> -1; > case Tuple, R>(R1 _, R2 _) -> -1; > case Tuple, R>(R2 _, R1 _) -> -1; > case Tuple, R>(R2 fst, R2 snd) -> fst.value().compareTo(snd.value()); > }; > } > > > to code like this from the deeper nested switch (sample taken from `translateTopLevelClass`): > > > ... > case 1: > if (!(let snd = (T8317048.R2)selector10$temp; in true)) { > index$11 = 2; > continue; > } > yield .value().compareTo(snd.value()); // boom, fst is missing > break; > ... > > > The reason is that in the `resolveAccumulator` we peek the first of the two to replace both, in this case the `R2 _`. > > > JCPatternCaseLabel leadingTest = > (JCPatternCaseLabel) accummulator.first().labels.head; > > > One way to solve this is to not merge two successive type patterns that have different namings (either both named or both unnamed). Looks OK. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15983#pullrequestreview-1708082084 From abimpoudis at openjdk.org Wed Nov 1 13:41:16 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 1 Nov 2023 13:41:16 GMT Subject: Integrated: 8317048: VerifyError with unnamed pattern variable and more than one components In-Reply-To: References: Message-ID: On Fri, 29 Sep 2023 10:20:10 GMT, Aggelos Biboudis wrote: > There were situations when javac optimizes switch structures (by merging the head of cases recursively) when two neighboring cases have a mix of named and unnamed patterns. This resulted translation is like the following: > > From this: > > > static int compareTo(Tuple, R> o) { > return switch (o) { > case Tuple, R>(R1 _, R1 _) -> -1; > case Tuple, R>(R1 _, R2 _) -> -1; > case Tuple, R>(R2 _, R1 _) -> -1; > case Tuple, R>(R2 fst, R2 snd) -> fst.value().compareTo(snd.value()); > }; > } > > > to code like this from the deeper nested switch (sample taken from `translateTopLevelClass`): > > > ... > case 1: > if (!(let snd = (T8317048.R2)selector10$temp; in true)) { > index$11 = 2; > continue; > } > yield .value().compareTo(snd.value()); // boom, fst is missing > break; > ... > > > The reason is that in the `resolveAccumulator` we peek the first of the two to replace both, in this case the `R2 _`. > > > JCPatternCaseLabel leadingTest = > (JCPatternCaseLabel) accummulator.first().labels.head; > > > One way to solve this is to not merge two successive type patterns that have different namings (either both named or both unnamed). This pull request has now been integrated. Changeset: 36de19d4 Author: Aggelos Biboudis Committer: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/36de19d4622e38b6c00644b0035521808574e255 Stats: 89 lines in 2 files changed: 89 ins; 0 del; 0 mod 8317048: VerifyError with unnamed pattern variable and more than one components Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/15983 From asotona at openjdk.org Wed Nov 1 15:49:12 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Nov 2023 15:49:12 GMT Subject: RFR: 8187591: -Werror turns incubator module warning to an error Message-ID: -Werror turns incubator module warning to an error This patch disables incubating module warning at compile time when "preview" lint category is disabled. It also adds a test, adjusts "preview" lint category description and updates javac man pages. Please review. Thanks, Adam ------------- Commit messages: - updated man page - added test - 8187591: -Werror turns incubator module warning to an error Changes: https://git.openjdk.org/jdk/pull/16454/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16454&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8187591 Stats: 26 lines in 5 files changed: 16 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/16454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16454/head:pull/16454 PR: https://git.openjdk.org/jdk/pull/16454 From abimpoudis at openjdk.org Wed Nov 1 15:55:44 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 1 Nov 2023 15:55:44 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v28] 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/jep455-20231030/specs/instanceof-jls.html Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Add test for instanceof as a pattern on with record patterns ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15638/files - new: https://git.openjdk.org/jdk/pull/15638/files/b437373b..a7f778ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=26-27 Stats: 192 lines in 4 files changed: 162 ins; 18 del; 12 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 cushon at openjdk.org Wed Nov 1 17:42:14 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 1 Nov 2023 17:42:14 GMT Subject: RFR: 8225377: type annotations are not visible to javac plugins across compilation boundaries [v5] In-Reply-To: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> Message-ID: > Hello, > > Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377). > > --- > > To provide some background context and motivation for the bug fix, consider an example like: > > > class B { > @Nullable int f(int x) { > return x; > } > } > > > If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file. > > If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file. > > This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future. > > --- > > javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol. > > Some notes on the approach: > > * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types. > > * For initial test coverage, I have enabled test coverage for annotation processing of type annotations to also run t... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Fix a typo in a comment - s/it's/its ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16407/files - new: https://git.openjdk.org/jdk/pull/16407/files/14b6bbd9..0568df80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16407/head:pull/16407 PR: https://git.openjdk.org/jdk/pull/16407 From aturbanov at openjdk.org Wed Nov 1 19:00:06 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 1 Nov 2023 19:00:06 GMT Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code Programs [v4] In-Reply-To: <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com> References: <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com> Message-ID: On Wed, 25 Oct 2023 11:02:41 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 ?: Implicitly Declared Classes and Instance Main Method (2nd 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: > > Main method determines the main class now src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramFileObject.java line 87: > 85: char[] buf = new char[1024]; > 86: int n; > 87: while ((n = r.read(buf, 0, buf.length)) != -1) { Suggestion: while ((n = r.read(buf, 0, buf.length)) != -1) { src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 220: > 218: try { > 219: nextClass = Class.forName(name, true, firstClass.getClassLoader()); > 220: } catch (ClassNotFoundException ignore) { Suggestion: } catch (ClassNotFoundException ignore) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1379190096 PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1379190354 From jlaskey at openjdk.org Wed Nov 1 19:02:18 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 1 Nov 2023 19:02:18 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) Message-ID: Address changes from JEP 445 to JEP 463. - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. - Don't mark class on read. - Remove reflection and annotation processing related to unnamed classes. - Simplify main method search. ------------- Commit messages: - Implicit classes and instance main methods Changes: https://git.openjdk.org/jdk/pull/16461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315458 Stats: 344 lines in 36 files changed: 12 ins; 231 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Wed Nov 1 19:14:22 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 1 Nov 2023 19:14:22 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove obsolete tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/4a34a4e8..a07b8d29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=00-01 Stats: 320 lines in 3 files changed: 0 ins; 320 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From vromero at openjdk.org Wed Nov 1 19:19:15 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 1 Nov 2023 19:19:15 GMT Subject: RFR: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled [v2] In-Reply-To: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> Message-ID: > This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion is being thrown for a special, corner-ish, case. Basically having: > > package p; > @Deprecated class T {} // see that class T is annotated > > and: > > package p; > class Y { > @interface A {} > @interface A {} // error: class A is already defined > T t; > } > > class `Y` has a duplicate definition of annotation `A`. Now if class `T` is compiled first as in: > > `javac -d out/ p/T.java` > > and then we do: > `javac -processor P -cp p:out/:. p/Y.java p/T.java` > > where P is the simplest possible annotation processor, basically doing nothing. IMO what is happening here is that during the second compilation, once the compiler find type `T` in class `Y`, given that T.class is in the classpath, it is loaded and the `@Deprecated` annotation is attached to symbol for type `T`. Then when the source for `T.java` is being compiled and its annotations are being processed we get to the code where the assertion is. Here the symbol for `T` is not a package but its metadata is not empty and so the assertion is thrown. The fix here is just removing the assertion as as shown by this example it is not an invariant. > > TIA Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - merge with remote branch - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16443/files - new: https://git.openjdk.org/jdk/pull/16443/files/7a75f038..39a9bfb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16443/head:pull/16443 PR: https://git.openjdk.org/jdk/pull/16443 From cushon at openjdk.org Wed Nov 1 19:28:15 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 1 Nov 2023 19:28:15 GMT Subject: RFR: 8225377: type annotations are not visible to javac plugins across compilation boundaries [v6] In-Reply-To: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> Message-ID: > Hello, > > Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377). > > --- > > To provide some background context and motivation for the bug fix, consider an example like: > > > class B { > @Nullable int f(int x) { > return x; > } > } > > > If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file. > > If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file. > > This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future. > > --- > > javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol. > > Some notes on the approach: > > * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types. > > * For initial test coverage, I have enabled test coverage for annotation processing of type annotations to also run t... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Initialize method receiver types if they have type annotations Receiver types are not otherwise initialized for classes, see also https://bugs.openjdk.org/browse/JDK-8319196 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16407/files - new: https://git.openjdk.org/jdk/pull/16407/files/0568df80..70712266 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=04-05 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16407/head:pull/16407 PR: https://git.openjdk.org/jdk/pull/16407 From cushon at openjdk.org Wed Nov 1 19:28:16 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 1 Nov 2023 19:28:16 GMT Subject: RFR: 8225377: type annotations are not visible to javac plugins across compilation boundaries [v4] In-Reply-To: References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> Message-ID: On Mon, 30 Oct 2023 23:46:40 GMT, Vicente Romero wrote: > looks good to me Thanks for the review! I did some more validation of the change on Google's codebase, and everything looks good on that side. I made one more small update for receiver parameters and added an additional test case. Receiver parameters are not currently filled in for classes loaded from the classpath. (That is potentially an issue even without type annotations being present, I filed [JDK-8319196](https://bugs.openjdk.org/browse/JDK-8319196).) I updated the logic here to fill in the receiver parameter type if `METHOD_RECEIVER` annotations are present: diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java index f86a95e501c..d15d5ca2526 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java @@ -2333,8 +2333,9 @@ public Void visitMethodSymbol(Symbol.MethodSymbol s, Void unused) { } mt.thrown = thrown.toList(); mt.restype = addTypeAnnotations(mt.restype, TargetType.METHOD_RETURN); - if (mt.recvtype != null) { - mt.recvtype = addTypeAnnotations(mt.recvtype, TargetType.METHOD_RECEIVER); + if (attributes.stream().anyMatch(a -> a.position.type == TargetType.METHOD_RECEIVER)) { + Assert.checkNull(mt.recvtype); + mt.recvtype = addTypeAnnotations(s.owner.type, TargetType.METHOD_RECEIVER); } return null; } diff --git a/test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java b/test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java index af63575052c..18b41b4a80c 100644 --- a/test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java +++ b/test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java @@ -573,4 +573,10 @@ class Inner90<@TA(90) T> { @Test(posn=4, annoType = TB.class, expect = "100") class Inner100> { } + + // receiver parameters + class Inner110 { + @Test(posn=2, annoType = TA.class, expect = "110") + void f(@TA(110) Inner110 this) {} + } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/16407#issuecomment-1789525288 From alanb at openjdk.org Thu Nov 2 07:48:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 07:48:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete tests There's a number of .orig files that seem to have been checked in by mistake. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1790224015 From asotona at openjdk.org Thu Nov 2 09:09:23 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Nov 2023 09:09:23 GMT Subject: RFR: 8288989: Make tests not to depend on the source code Message-ID: 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 ------------- Commit messages: - 8288989: Make tests not to depend on the source code Changes: https://git.openjdk.org/jdk/pull/16470/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16470&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/jdk/pull/16470.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16470/head:pull/16470 PR: https://git.openjdk.org/jdk/pull/16470 From mcimadamore at openjdk.org Thu Nov 2 11:04:06 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 11:04:06 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete tests src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4057: > 4055: Name name = names.fromString(simplename); > 4056: JCModifiers implicitMods = F.at(Position.NOPOS) > 4057: .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.IMPLICIT_CLASS, List.nil()); I don't think the JVMS allows for a flag to have ACC_MANDATED flags? It is a limitation of the class file format that only formal parameters and modules can be flagged as ACC_MANDATED ([?4.7.24](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.24), [?4.7.25](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.25)) to indicate that, despite being compiler-generated, they are not considered implementation artifacts. There is no way to flag other compiler-generated constructs so that they too are not considered implementation artifacts (JLS ?13.1). This limitation means that reflective APIs of the Java SE Platform may not accurately indicate the "mandated" status of such constructs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379931703 From mcimadamore at openjdk.org Thu Nov 2 11:15:04 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 11:15:04 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete tests src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 249: > 247: STRING_TEMPLATES(JDK21, Fragments.FeatureStringTemplates, DiagKind.PLURAL), > 248: UNNAMED_CLASSES(JDK21, Fragments.FeatureUnnamedClasses, DiagKind.PLURAL), > 249: IMPLICIT_CLASSES(JDK21, Fragments.FeatureImplicitClasses, DiagKind.PLURAL), Should this be JDK22? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 442: > 440: Errors.ClassPublicShouldBeInFile(topElement, tree.name)); > 441: } > 442: if ((tree.mods.flags & IMPLICIT_CLASS) != 0) { I'm not 100% sure about this. Another option would be to tweak Resolve::findType and make sure that `typeNotFound` (or some more specific message!) is returned when an implicit class is referred to by name. If you look at the first few lines in that method you will see: if (name == names.empty) return typeNotFound; // do not allow inadvertent "lookup" of anonymous types So, there's already some logic there for skipping some types. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379942927 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379940717 From mcimadamore at openjdk.org Thu Nov 2 11:21:08 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 11:21:08 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete tests test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 1: > 1: /* Is the implicit class no longer discoverable through annotation processing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379949276 From jlaskey at openjdk.org Thu Nov 2 11:39:19 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 11:39:19 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove .orig files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/a07b8d29..b98e40f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=01-02 Stats: 720 lines in 3 files changed: 0 ins; 720 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 12:01:13 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:01:13 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:12:14 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove obsolete tests > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 249: > >> 247: STRING_TEMPLATES(JDK21, Fragments.FeatureStringTemplates, DiagKind.PLURAL), >> 248: UNNAMED_CLASSES(JDK21, Fragments.FeatureUnnamedClasses, DiagKind.PLURAL), >> 249: IMPLICIT_CLASSES(JDK21, Fragments.FeatureImplicitClasses, DiagKind.PLURAL), > > Should this be JDK22? No. It should be left at the first preview level. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 442: > >> 440: Errors.ClassPublicShouldBeInFile(topElement, tree.name)); >> 441: } >> 442: if ((tree.mods.flags & IMPLICIT_CLASS) != 0) { > > I'm not 100% sure about this. Another option would be to tweak Resolve::findType and make sure that `typeNotFound` (or some more specific message!) is returned when an implicit class is referred to by name. If you look at the first few lines in that method you will see: > > > if (name == names.empty) > return typeNotFound; // do not allow inadvertent "lookup" of anonymous types > > > So, there's already some logic there for skipping some types. The main thing here is that it is done once at the source instead of every look up. The symbol should not exist in the compilation unit. > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4057: > >> 4055: Name name = names.fromString(simplename); >> 4056: JCModifiers implicitMods = F.at(Position.NOPOS) >> 4057: .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.IMPLICIT_CLASS, List.nil()); > > I don't think the JVMS allows for a flag to have ACC_MANDATED flags? > > > It is a limitation of the class file format that only formal parameters and modules can be flagged as ACC_MANDATED ([?4.7.24](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.24), [?4.7.25](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.25)) to indicate that, despite being compiler-generated, they are not considered implementation artifacts. There is no way to flag other compiler-generated constructs so that they too are not considered implementation artifacts (JLS ?13.1). This limitation means that reflective APIs of the Java SE Platform may not accurately indicate the "mandated" status of such constructs. The spec has been updated to include implicit classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379993631 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379993078 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379990952 From jlaskey at openjdk.org Thu Nov 2 12:01:05 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:01:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:39:19 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove .orig files Re .orig. Thank you Alan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1790596666 From jlaskey at openjdk.org Thu Nov 2 12:01:16 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:01:16 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 11:18:19 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove .orig files > > test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 1: > >> 1: /* > > Is the implicit class no longer discoverable through annotation processing? The class is discoverable but only as a regular class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379994884 From mcimadamore at openjdk.org Thu Nov 2 12:09:05 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 12:09:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: <9g7BSn0mYpRLBVI_MNp0tpHI_DggkE_rs1KPrTBRGm0=.50c46c99-8257-4c32-8a44-f3f6a77d463b@github.com> On Thu, 2 Nov 2023 11:55:17 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 442: >> >>> 440: Errors.ClassPublicShouldBeInFile(topElement, tree.name)); >>> 441: } >>> 442: if ((tree.mods.flags & IMPLICIT_CLASS) != 0) { >> >> I'm not 100% sure about this. Another option would be to tweak Resolve::findType and make sure that `typeNotFound` (or some more specific message!) is returned when an implicit class is referred to by name. If you look at the first few lines in that method you will see: >> >> >> if (name == names.empty) >> return typeNotFound; // do not allow inadvertent "lookup" of anonymous types >> >> >> So, there's already some logic there for skipping some types. > > The main thing here is that it is done once at the source instead of every look up. The symbol should not exist in the compilation unit. Yep - I think the main consequence of this choice is the fact that we cannot generate a specific error message - but perhaps that's ok (after all, having a special message would equate to admitting that the compiler _does know_ about the name :-) ) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380003979 From mcimadamore at openjdk.org Thu Nov 2 12:09:07 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 12:09:07 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 11:57:09 GMT, Jim Laskey wrote: >> test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 1: >> >>> 1: /* >> >> Is the implicit class no longer discoverable through annotation processing? > > The class is discoverable but only as a regular class. Why is the test removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380002037 From mcimadamore at openjdk.org Thu Nov 2 12:15:05 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 12:15:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:53:09 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4057: >> >>> 4055: Name name = names.fromString(simplename); >>> 4056: JCModifiers implicitMods = F.at(Position.NOPOS) >>> 4057: .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.IMPLICIT_CLASS, List.nil()); >> >> I don't think the JVMS allows for a flag to have ACC_MANDATED flags? >> >> >> It is a limitation of the class file format that only formal parameters and modules can be flagged as ACC_MANDATED ([?4.7.24](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.24), [?4.7.25](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.25)) to indicate that, despite being compiler-generated, they are not considered implementation artifacts. There is no way to flag other compiler-generated constructs so that they too are not considered implementation artifacts (JLS ?13.1). This limitation means that reflective APIs of the Java SE Platform may not accurately indicate the "mandated" status of such constructs. > > The spec has been updated to include implicit classes. Uhmm. In the spec I see implicit classes named here: For reference, the following constructs are declared implicitly in source code, but are not marked as mandated because only formal parameters and modules can be so marked in a class file (JVMS ?4.7.24, JVMS ?4.7.25): ``` Note the `but are not marked as mandated`. I don't think javac sets the mandated flag for any of these. Note that ACC_MANDATED has the same value as the ACC_MODULE flag, so setting that flag on a class w/o at least filtering out when writing the classfile will be problematic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380009418 From jlaskey at openjdk.org Thu Nov 2 12:27:05 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:27:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com> On Thu, 2 Nov 2023 12:11:52 GMT, Maurizio Cimadamore wrote: >> The spec has been updated to include implicit classes. > > Uhmm. In the spec I see implicit classes named here: > > > For reference, the following constructs are declared implicitly in source code, but are not marked as mandated because only formal parameters and modules can be so marked in a class file (JVMS ?4.7.24, JVMS ?4.7.25): > ``` > > Note the `but are not marked as mandated`. > > I don't think javac sets the mandated flag for any of these. Note that ACC_MANDATED has the same value as the ACC_MODULE flag, so setting that flag on a class w/o at least filtering out when writing the classfile will be problematic. Hmmm. I'll check with Gavin, but I thought in discussions Alex said that it should be mandated. At any rate, seems the ACC_MANDATED should be removed for stated reasons. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380022715 From jlaskey at openjdk.org Thu Nov 2 12:33:27 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:33:27 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove MANDATED flag from implicit classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/b98e40f2..2bb3047a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 12:37:03 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:37:03 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 12:04:22 GMT, Maurizio Cimadamore wrote: >> The class is discoverable but only as a regular class. > > Why is the test removed? Since there is no way to detect an implicit class, the test is no longer relevant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380034414 From asotona at openjdk.org Thu Nov 2 13:54:33 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Nov 2023 13:54:33 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs Message-ID: Javap ignores --system option when searching for JDK classes. This patch prepends search over JDK system modules. Please review. Thanks, Adam ------------- Commit messages: - 8304446: javap --system flag doesn't override system APIs Changes: https://git.openjdk.org/jdk/pull/16476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304446 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16476/head:pull/16476 PR: https://git.openjdk.org/jdk/pull/16476 From alanb at openjdk.org Thu Nov 2 13:57:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 13:57:07 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 12:33:27 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove MANDATED flag from implicit classes src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 76: > 74: UNNAMED_CLASSES, > 75: @JEP(number=999, title="Implicit Classes and Instance Main Methods") > 76: IMPLICIT_CLASSES, I assume you'll change this to 463 before integrating. Can 445 be removed or is there an issue with the symbol database that means it has to stay for a release? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380180698 From alanb at openjdk.org Thu Nov 2 14:42:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 14:42:11 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 12:33:27 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove MANDATED flag from implicit classes src/java.base/share/classes/sun/launcher/LauncherHelper.java line 973: > 971: abort(null, "java.launcher.cls.error3", > 972: mainMethod.getDeclaringClass().getName()); > 973: } The simplification to LauncherHelper.validateMainClass looks okay but one thing is a bit annoying is the side effect to set mainType. What would you think about changing validateMainClass to return the Method for the main class and have checkAndLoadMain set mainType after validateMainClass succeeds, right not it gets set even if the validate fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380252317 From jlaskey at openjdk.org Thu Nov 2 14:56:33 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 14:56:33 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v5] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update JEP number in PreviewFeature ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/2bb3047a..05945ebb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 14:56:36 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 14:56:36 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 13:53:02 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove MANDATED flag from implicit classes > > src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 76: > >> 74: UNNAMED_CLASSES, >> 75: @JEP(number=999, title="Implicit Classes and Instance Main Methods") >> 76: IMPLICIT_CLASSES, > > I assume you'll change this to 463 before integrating. Can 445 be removed or is there an issue with the symbol database that means it has to stay for a release? Missed that. The issue is that Implicit Classes don't have any API and don't show up in the preview page. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380274616 From jlaskey at openjdk.org Thu Nov 2 14:56:38 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 14:56:38 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v5] In-Reply-To: References: Message-ID: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> On Thu, 2 Nov 2023 14:38:06 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update JEP number in PreviewFeature > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 973: > >> 971: abort(null, "java.launcher.cls.error3", >> 972: mainMethod.getDeclaringClass().getName()); >> 973: } > > The simplification to LauncherHelper.validateMainClass looks okay but one thing is a bit annoying is the side effect to set mainType. What would you think about changing validateMainClass to return the Method for the main class and have checkAndLoadMain set mainType after validateMainClass succeeds, right not it gets set even if the validate fails. Agree. Will fetch flags from second call from JVM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380276024 From mcimadamore at openjdk.org Thu Nov 2 15:36:08 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 15:36:08 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v5] In-Reply-To: References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 12:34:49 GMT, Jim Laskey wrote: >> Why is the test removed? > > Since there is no way to detect an implicit class, the test is no longer relevant. Right, but the test was still checking useful stuff - e.g. like the fact that the class generated by javac was final, etc (in accordance with the JLS). So some of that should be resurrected I think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380342689 From jlaskey at openjdk.org Thu Nov 2 15:45:26 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 15:45:26 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v6] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Don't store main method info globally. Use addition calls to fetch info. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/05945ebb..edbe208b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=04-05 Stats: 40 lines in 2 files changed: 21 ins; 10 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 15:49:15 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 15:49:15 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v6] In-Reply-To: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> References: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> Message-ID: <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> On Thu, 2 Nov 2023 14:53:44 GMT, Jim Laskey wrote: >> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 973: >> >>> 971: abort(null, "java.launcher.cls.error3", >>> 972: mainMethod.getDeclaringClass().getName()); >>> 973: } >> >> The simplification to LauncherHelper.validateMainClass looks okay but one thing is a bit annoying is the side effect to set mainType. What would you think about changing validateMainClass to return the Method for the main class and have checkAndLoadMain set mainType after validateMainClass succeeds, right not it gets set even if the validate fails. > > Agree. Will fetch flags from second call from JVM. Amazingly enough I seem to have the JNI straight on the first try. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380359994 From jlaskey at openjdk.org Thu Nov 2 15:49:17 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 15:49:17 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v6] In-Reply-To: References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 15:33:25 GMT, Maurizio Cimadamore wrote: >> Since there is no way to detect an implicit class, the test is no longer relevant. > > Right, but the test was still checking useful stuff - e.g. like the fact that the class generated by javac was final, etc (in accordance with the JLS). So some of that should be resurrected I think? Agree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380361777 From jlaskey at openjdk.org Thu Nov 2 16:19:07 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 16:19:07 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Revised implicit class test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/edbe208b..7c92e852 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=05-06 Stats: 93 lines in 2 files changed: 91 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlahoda at openjdk.org Thu Nov 2 17:36:17 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 2 Nov 2023 17:36:17 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: References: Message-ID: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> On Thu, 2 Nov 2023 16:19:07 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Revised implicit class test Added a few minor comments inline. src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 33: > 31: public class MainMethodFinder { > 32: /** > 33: * {@return true if method mets the requirements of a main method} Nit/typo Suggestion: * {@return true if the method meets the requirements of a main method} test/jdk/java/lang/Class/ImplicitClass/TestImplicitClass.java line 25: > 23: > 24: /* > 25: * @test As a mild preference, I would move this test into the javac/langtools tests. I don't think it tests the reflection anymore, it rather tests that javac desugars the code correctly. ------------- PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1710864094 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380519226 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380544805 From jlahoda at openjdk.org Thu Nov 2 17:36:19 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 2 Nov 2023 17:36:19 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 14:52:46 GMT, Jim Laskey wrote: >> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 76: >> >>> 74: UNNAMED_CLASSES, >>> 75: @JEP(number=999, title="Implicit Classes and Instance Main Methods") >>> 76: IMPLICIT_CLASSES, >> >> I assume you'll change this to 463 before integrating. Can 445 be removed or is there an issue with the symbol database that means it has to stay for a release? > > Missed that. The issue is that Implicit Classes don't have any API and don't show up in the preview page. Fixed. Regarding removal of `UNNAMED_CLASSES` here, there was an API annotated using this constant in `j.l.Class` (`isUnnamedClass()`). I suspect it unfortunately means we need to keep the enum constant as long as this method exists in the bootstrap JDK, i.e. until the bootstrap is switches to JDK 22. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380557036 From jlahoda at openjdk.org Thu Nov 2 17:36:22 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 2 Nov 2023 17:36:22 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com> On Thu, 2 Nov 2023 11:55:50 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 249: >> >>> 247: STRING_TEMPLATES(JDK21, Fragments.FeatureStringTemplates, DiagKind.PLURAL), >>> 248: UNNAMED_CLASSES(JDK21, Fragments.FeatureUnnamedClasses, DiagKind.PLURAL), >>> 249: IMPLICIT_CLASSES(JDK21, Fragments.FeatureImplicitClasses, DiagKind.PLURAL), >> >> Should this be JDK22? > > No. It should be left at the first preview level. `UNNAMED_CLASSES` should probably be removed, as I think it is fully replaced with `IMPLICIT_CLASSES`, and I don't think there are bootstrap problems here (unlike in `jdk.internal.java.PreviewFeature`). I would say it would make sense to set the version to `JDK22`, although the difference is very small given the feature is a preview and requires `-source 22` anyway. (Although we keep the `@since` value for the duration of preview.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380529383 From jlaskey at openjdk.org Thu Nov 2 17:49:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:49:12 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: <0Rm3u8y7eDy1QVUSco7BRq9HAT_P9ZusKALEKCiWFLg=.a3400dc4-88d1-43eb-86a8-92447ae127c0@github.com> On Thu, 2 Nov 2023 17:30:40 GMT, Jan Lahoda wrote: >> Missed that. The issue is that Implicit Classes don't have any API and don't show up in the preview page. Fixed. > > Regarding removal of `UNNAMED_CLASSES` here, there was an API annotated using this constant in `j.l.Class` (`isUnnamedClass()`). I suspect it unfortunately means we need to keep the enum constant as long as this method exists in the bootstrap JDK, i.e. until the bootstrap is switches to JDK 22. Correct ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380578763 From jlaskey at openjdk.org Thu Nov 2 17:49:15 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:49:15 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> References: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> Message-ID: On Thu, 2 Nov 2023 17:17:42 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Revised implicit class test > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 33: > >> 31: public class MainMethodFinder { >> 32: /** >> 33: * {@return true if method mets the requirements of a main method} > > Nit/typo > Suggestion: > > * {@return true if the method meets the requirements of a main method} Changing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380575947 From alanb at openjdk.org Thu Nov 2 17:49:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 17:49:16 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> References: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> Message-ID: On Thu, 2 Nov 2023 15:45:03 GMT, Jim Laskey wrote: > Amazingly enough I seem to have the JNI straight on the first try. Oh, I wasn't expecting that. My comment was suggesting we change LauncherHelper.checkAndLoadMain to set both appClass and mainType after the validate succeeds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380577942 From jlaskey at openjdk.org Thu Nov 2 17:49:18 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:49:18 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com> References: <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com> Message-ID: On Thu, 2 Nov 2023 17:21:02 GMT, Jan Lahoda wrote: >> No. It should be left at the first preview level. > > `UNNAMED_CLASSES` should probably be removed, as I think it is fully replaced with `IMPLICIT_CLASSES`, and I don't think there are bootstrap problems here (unlike in `jdk.internal.java.PreviewFeature`). I would say it would make sense to set the version to `JDK22`, although the difference is very small given the feature is a preview and requires `-source 22` anyway. (Although we keep the `@since` value for the duration of preview.) Changing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380574753 From jlaskey at openjdk.org Thu Nov 2 17:53:32 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:53:32 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v8] In-Reply-To: References: Message-ID: <4n7npXZsDTQF4dswNSRYXN49xfkFOkAIhF6TXtojb9g=.18c6dd36-5905-4caa-adc5-c058dcff6182@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Changes recommended by Jan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/7c92e852..afdd078f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=06-07 Stats: 4 lines in 4 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 17:56:13 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:56:13 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v8] In-Reply-To: References: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> Message-ID: On Thu, 2 Nov 2023 17:45:51 GMT, Alan Bateman wrote: >> Amazingly enough I seem to have the JNI straight on the first try. > >> Amazingly enough I seem to have the JNI straight on the first try. > > Oh, I wasn't expecting that. My comment was suggesting we change LauncherHelper.checkAndLoadMain to set both appClass and mainType after the validate succeeds. I thought it was a clearer way to get rid of the side effect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380585433 From jlaskey at openjdk.org Thu Nov 2 17:59:14 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:59:14 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> References: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> Message-ID: On Thu, 2 Nov 2023 17:26:19 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Revised implicit class test > > test/jdk/java/lang/Class/ImplicitClass/TestImplicitClass.java line 25: > >> 23: >> 24: /* >> 25: * @test > > As a mild preference, I would move this test into the javac/langtools tests. I don't think it tests the reflection anymore, it rather tests that javac desugars the code correctly. Moving ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380588699 From cushon at openjdk.org Thu Nov 2 18:08:21 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 2 Nov 2023 18:08:21 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode Message-ID: Hello, Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. ------------- Commit messages: - 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode Changes: https://git.openjdk.org/jdk/pull/16482/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319196 Stats: 80 lines in 4 files changed: 52 ins; 14 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/16482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16482/head:pull/16482 PR: https://git.openjdk.org/jdk/pull/16482 From forax at openjdk.org Thu Nov 2 18:13:17 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 2 Nov 2023 18:13:17 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com> References: <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com> Message-ID: On Thu, 2 Nov 2023 12:24:31 GMT, Jim Laskey wrote: >> Uhmm. In the spec I see implicit classes named here: >> >> >> For reference, the following constructs are declared implicitly in source code, but are not marked as mandated because only formal parameters and modules can be so marked in a class file (JVMS ?4.7.24, JVMS ?4.7.25): >> ``` >> >> Note the `but are not marked as mandated`. >> >> I don't think javac sets the mandated flag for any of these. Note that ACC_MANDATED has the same value as the ACC_MODULE flag, so setting that flag on a class w/o at least filtering out when writing the classfile will be problematic. > > Hmmm. I'll check with Gavin, but I thought in discussions Alex said that it should be mandated. At any rate, seems the ACC_MANDATED should be removed for stated reasons. It should be MANDATED in theory given it's not an artifact of the compilation like SYNTHETIC is. Sadly, as Maurizio said ACC_MANDATED has the same value as ACC_MODULE. I think there is a value to still make it as SYNTHETIC, apart if we add a new specific attribute for implicit classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380604311 From alanb at openjdk.org Thu Nov 2 18:34:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 18:34:13 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v8] In-Reply-To: References: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> Message-ID: On Thu, 2 Nov 2023 17:53:12 GMT, Jim Laskey wrote: > I thought it was a clearer way to get rid of the side effect. It means LauncherHelper.checkAndLoadMain description will need to be updated as it says that it checks the public static void main method. But okay, I'll go through what you have now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380625507 From cushon at openjdk.org Thu Nov 2 19:36:19 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 2 Nov 2023 19:36:19 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v2] In-Reply-To: References: Message-ID: > Hello, > > Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). > > As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. > > This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Add a null check, update affected tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16482/files - new: https://git.openjdk.org/jdk/pull/16482/files/20d192dd..0813717e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=00-01 Stats: 19 lines in 3 files changed: 5 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/16482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16482/head:pull/16482 PR: https://git.openjdk.org/jdk/pull/16482 From jlaskey at openjdk.org Thu Nov 2 20:36:52 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 20:36:52 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v9] In-Reply-To: References: Message-ID: <_-aKRLbUA-RNzGDfn4fFhRzB2A1jSUMeoRKIBZ3v5eE=.975a8dc0-951c-4664-b502-3ad2fe1992a8@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested corrections ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/afdd078f..742fed7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=07-08 Stats: 4 lines in 3 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 20:48:45 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 20:48:45 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: References: Message-ID: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove unnamed classes from examples.not-yet.txt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/742fed7d..72033bcc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From liach at openjdk.org Fri Nov 3 00:22:03 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Nov 2023 00:22:03 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 19:36:19 GMT, Liam Miller-Cushon wrote: >> Hello, >> >> Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). >> >> As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. >> >> This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Add a null check, update affected tests src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 2285: > 2283: return null; > 2284: } > 2285: Type enclosingType = enclClass().type; Suggestion: Type enclosingType = enclosingClass.type; src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 2289: > 2287: return enclosingType.getEnclosingType(); > 2288: } > 2289: if (!isStatic()) { Just curious, what happens in such a scenario: public class Outer { public static void work() { class Local { Local() {} // <- what's the implicitReceiverType here? } } } FYI javac currently is not marking such local classes in static methods as `static` in its `InnerClasses` attribute. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16482#discussion_r1380910642 PR Review Comment: https://git.openjdk.org/jdk/pull/16482#discussion_r1380914125 From cushon at openjdk.org Fri Nov 3 00:45:32 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 3 Nov 2023 00:45:32 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v3] In-Reply-To: References: Message-ID: > Hello, > > Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). > > As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. > > This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java Co-authored-by: liach <7806504+liach at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16482/files - new: https://git.openjdk.org/jdk/pull/16482/files/0813717e..4c230bfd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16482/head:pull/16482 PR: https://git.openjdk.org/jdk/pull/16482 From mchung at openjdk.org Fri Nov 3 01:10:17 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 3 Nov 2023 01:10:17 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> References: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> Message-ID: On Thu, 2 Nov 2023 20:48:45 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnamed classes from examples.not-yet.txt src/java.base/share/native/libjli/java.c line 539: > 537: "validateMainMethod", > 538: "(Ljava/lang/Class;)Ljava/lang/reflect/Method;"); > 539: CHECK_EXCEPTION_NULL_LEAVE(validateMainMethod); The comment in line 498-499 needs update as `LoadMainClass` no longer validates the main method. * Get the application's main class. It also checks if the main * method exists. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380953736 From cushon at openjdk.org Fri Nov 3 01:24:08 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 3 Nov 2023 01:24:08 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 00:18:33 GMT, Chen Liang wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a null check, update affected tests > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 2289: > >> 2287: return enclosingType.getEnclosingType(); >> 2288: } >> 2289: if (!isStatic()) { > > Just curious, what happens in such a scenario: > > public class Outer { > public static void work() { > class Local { > Local() {} // <- what's the implicitReceiverType here? > } > } > } > > FYI javac currently is not marking such local classes in static methods as `static` in its `InnerClasses` attribute. Good question! I debugged that example, and `getEnclosingType()` returns `NoType`, which I think is what we want. This is the logic that initializes the enclosing type and handles local classes: https://github.com/openjdk/jdk/blob/c788160f8acea7b58b54ad857b601bb7ffb53f8e/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java#L508-L519 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16482#discussion_r1380962373 From cushon at openjdk.org Fri Nov 3 01:31:26 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 3 Nov 2023 01:31:26 GMT Subject: RFR: 8225377: type annotations are not visible to javac plugins across compilation boundaries [v7] In-Reply-To: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> Message-ID: > Hello, > > Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377). > > --- > > To provide some background context and motivation for the bug fix, consider an example like: > > > class B { > @Nullable int f(int x) { > return x; > } > } > > > If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file. > > If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file. > > This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future. > > --- > > javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol. > > Some notes on the approach: > > * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types. > > * For initial test coverage, I have enabled test coverage for annotation processing of type annotations to also run t... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Revert "Initialize method receiver types if they have type annotations" This reverts commit 70712266bdbd16e80ba0c0089055ab3c48bb126b. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16407/files - new: https://git.openjdk.org/jdk/pull/16407/files/70712266..780313b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=05-06 Stats: 9 lines in 2 files changed: 0 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16407/head:pull/16407 PR: https://git.openjdk.org/jdk/pull/16407 From cushon at openjdk.org Fri Nov 3 01:31:27 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 3 Nov 2023 01:31:27 GMT Subject: RFR: 8225377: type annotations are not visible to javac plugins across compilation boundaries [v4] In-Reply-To: References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> Message-ID: On Wed, 1 Nov 2023 19:23:25 GMT, Liam Miller-Cushon wrote: > I made one more small update for receiver parameters and added an additional test case. Receiver parameters are not currently filled in for classes loaded from the classpath. (That is potentially an issue even without type annotations being present, I filed [JDK-8319196](https://bugs.openjdk.org/browse/JDK-8319196).) On second thought, I would like to defer that, I have switched back to the last version that was reviewed. The receiver parameter issue seems like a pre-existing problem that is doesn't just affect type annotations, I have proposed a separate fix for JDK-8319196. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16407#issuecomment-1791775635 From vromero at openjdk.org Fri Nov 3 05:19:14 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 3 Nov 2023 05:19:14 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> References: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> Message-ID: On Thu, 2 Nov 2023 20:48:45 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnamed classes from examples.not-yet.txt src/java.base/share/native/libjli/java.c line 544: > 542: > 543: /* Build platform specific argument array */ > 544: mainArgs = CreateApplicationArgs(env, argv, argc); we build the arguments always even if the main we will end up invoking receives no argument and thus these arguments will be discarded. Could it make sense to create the arguments only if they won't be discarded? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381163039 From asotona at openjdk.org Fri Nov 3 08:21:15 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Nov 2023 08:21:15 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v2] In-Reply-To: References: Message-ID: > Javap ignores --system option when searching for JDK classes. > This patch prepends search over JDK system modules. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Skip search over JDK modules for classes in unnamed package (mainly to skip JDK module-infos) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16476/files - new: https://git.openjdk.org/jdk/pull/16476/files/3734262a..78dc9840 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16476/head:pull/16476 PR: https://git.openjdk.org/jdk/pull/16476 From asotona at openjdk.org Fri Nov 3 08:39:37 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Nov 2023 08:39:37 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] 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 358 commits: - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - applied javadoc fix suggestions - fixed new benchmark - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java - removed trailing space - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - package info javadoc improvements - removed obsolete exports from BuildMicrobenchmark.gmk - ... and 348 more: https://git.openjdk.org/jdk/compare/ec79ab4b...5f4f47c4 ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=23 Stats: 32167 lines in 768 files changed: 14623 ins; 14055 del; 3489 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 jlaskey at openjdk.org Fri Nov 3 12:08:09 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:08:09 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: References: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> Message-ID: On Fri, 3 Nov 2023 01:06:56 GMT, Mandy Chung wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnamed classes from examples.not-yet.txt > > src/java.base/share/native/libjli/java.c line 539: > >> 537: "validateMainMethod", >> 538: "(Ljava/lang/Class;)Ljava/lang/reflect/Method;"); >> 539: CHECK_EXCEPTION_NULL_LEAVE(validateMainMethod); > > The comment in line 498-499 needs update as `LoadMainClass` no longer validates the main method. > > * Get the application's main class. It also checks if the main > * method exists. Changing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381578668 From jlaskey at openjdk.org Fri Nov 3 12:19:15 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:19:15 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: References: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> Message-ID: <6wiZx638zzfyr3EpxS-7-ImsqFmDHQbPqZTePp9K3bU=.7e1c8f9a-4017-4ac1-b2e6-dc083a6302c8@github.com> On Fri, 3 Nov 2023 05:01:19 GMT, Vicente Romero wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnamed classes from examples.not-yet.txt > > src/java.base/share/native/libjli/java.c line 544: > >> 542: >> 543: /* Build platform specific argument array */ >> 544: mainArgs = CreateApplicationArgs(env, argv, argc); > > we build the arguments always even if the main we will end up invoking receives no argument and thus these arguments will be discarded. Could it make sense to create the arguments only if they won't be discarded? Sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381587622 From jlaskey at openjdk.org Fri Nov 3 12:25:49 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:25:49 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v11] In-Reply-To: References: Message-ID: <-lo9E6xyDntDpnkpd2rhy2hCJ-WD0cXkjWvA2tkjURE=.b9aa02f3-b032-49ed-937f-4b64bda693e2@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Don't get args unless necessary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/72033bcc..4b3c03fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=09-10 Stats: 38 lines in 1 file changed: 22 ins; 12 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Fri Nov 3 12:31:32 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:31:32 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com> Message-ID: On Thu, 2 Nov 2023 18:10:27 GMT, R?mi Forax wrote: >> Hmmm. I'll check with Gavin, but I thought in discussions Alex said that it should be mandated. At any rate, seems the ACC_MANDATED should be removed for stated reasons. > > It should be MANDATED in theory given it's not an artifact of the compilation like SYNTHETIC is. Sadly, as Maurizio said ACC_MANDATED has the same value as ACC_MODULE. > I think there is a value to still make it as SYNTHETIC, apart if we add a new specific attribute for implicit classes. We're opting to not to flag the class as special. Implicit classes are just regular classes derived from syntactic sugar. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381606620 From jlaskey at openjdk.org Fri Nov 3 12:40:48 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:40:48 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey 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 12 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8315458 - Don't get args unless necessary - Remove unnamed classes from examples.not-yet.txt - Requested corrections - Changes recommended by Jan - Revised implicit class test - Don't store main method info globally. Use addition calls to fetch info. - Update JEP number in PreviewFeature - Remove MANDATED flag from implicit classes - Remove .orig files - ... and 2 more: https://git.openjdk.org/jdk/compare/f04a1529...0bd5b477 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/4b3c03fe..0bd5b477 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=10-11 Stats: 23833 lines in 485 files changed: 11893 ins; 4870 del; 7070 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From vromero at openjdk.org Fri Nov 3 14:34:27 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 3 Nov 2023 14:34:27 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey 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 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/8f2f4091...0bd5b477 src/java.base/share/native/libjli/java.c line 559: > 557: > 558: /* Build platform specific argument array */ > 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { nice, thanks src/java.base/share/native/libjli/java.c line 561: > 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { > 560: mainArgs = CreateApplicationArgs(env, argv, argc); > 561: CHECK_EXCEPTION_NULL_LEAVE(mainArgs); side: this is just a comment not proposing any change, I know it is a good practice to check for nulls here, but having a null here is really possible? how can we have a null here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381763339 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381775757 From jlahoda at openjdk.org Fri Nov 3 15:02:11 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 15:02:11 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v3] In-Reply-To: <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com> References: <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com> Message-ID: On Tue, 17 Oct 2023 16:03:25 GMT, Jim Laskey wrote: >> Update String Templates for a second preview. With the addition of >> >> - Expression type and throws are determined from the `process` method of the processor type and not the processor type. >> >> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . >> >> - Raw (generic) process types are no longer an error. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Cache process method type in JCStringTemplate Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1712905674 From jlaskey at openjdk.org Fri Nov 3 15:04:25 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 15:04:25 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 14:26:29 GMT, Vicente Romero wrote: >> Jim Laskey 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 12 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Don't get args unless necessary >> - Remove unnamed classes from examples.not-yet.txt >> - Requested corrections >> - Changes recommended by Jan >> - Revised implicit class test >> - Don't store main method info globally. Use addition calls to fetch info. >> - Update JEP number in PreviewFeature >> - Remove MANDATED flag from implicit classes >> - Remove .orig files >> - ... and 2 more: https://git.openjdk.org/jdk/compare/64f1c416...0bd5b477 > > src/java.base/share/native/libjli/java.c line 559: > >> 557: >> 558: /* Build platform specific argument array */ >> 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { > > nice, thanks, a minor addition to the condition: `&& argc > 0`? Need an empty array when argc == 0. > src/java.base/share/native/libjli/java.c line 561: > >> 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { >> 560: mainArgs = CreateApplicationArgs(env, argv, argc); >> 561: CHECK_EXCEPTION_NULL_LEAVE(mainArgs); > > side: this is just a comment not proposing any change, I know it is a good practice to check for nulls here, but having a null here is really possible? how can we have a null here? but I guess this also check for any other exception right? Yes it's a combo thing. This was the code that was there BTW. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381823409 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381824589 From vromero at openjdk.org Fri Nov 3 15:17:02 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 3 Nov 2023 15:17:02 GMT Subject: RFR: 8225377: type annotations are not visible to javac plugins across compilation boundaries [v4] In-Reply-To: References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> Message-ID: On Fri, 3 Nov 2023 01:27:18 GMT, Liam Miller-Cushon wrote: > > I made one more small update for receiver parameters and added an additional test case. Receiver parameters are not currently filled in for classes loaded from the classpath. (That is potentially an issue even without type annotations being present, I filed [JDK-8319196](https://bugs.openjdk.org/browse/JDK-8319196).) > > On second thought, I would like to defer that, I have switched back to the last version that was reviewed. The receiver parameter issue seems like a pre-existing problem that is doesn't just affect type annotations, I have proposed a separate fix for JDK-8319196. yep better to defer the receiver thing ------------- PR Comment: https://git.openjdk.org/jdk/pull/16407#issuecomment-1792625048 From vromero at openjdk.org Fri Nov 3 15:22:25 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 3 Nov 2023 15:22:25 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 15:00:41 GMT, Jim Laskey wrote: >> src/java.base/share/native/libjli/java.c line 559: >> >>> 557: >>> 558: /* Build platform specific argument array */ >>> 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { >> >> nice, thanks, a minor addition to the condition: `&& argc > 0`? > > Need an empty array when argc == 0. oh I see >> src/java.base/share/native/libjli/java.c line 561: >> >>> 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { >>> 560: mainArgs = CreateApplicationArgs(env, argv, argc); >>> 561: CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >> >> side: this is just a comment not proposing any change, I know it is a good practice to check for nulls here, but having a null here is really possible? how can we have a null here? but I guess this also check for any other exception right? > > Yes it's a combo thing. This was the code that was there BTW. yes I know it is previous code, I was just wondering how we could have a null exception here but it is true that other exceptions can occur ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381846743 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381848172 From jlaskey at openjdk.org Fri Nov 3 15:29:25 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 15:29:25 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v4] In-Reply-To: References: Message-ID: > Update String Templates for a second preview. With the addition of > > - Expression type and throws are determined from the `process` method of the processor type and not the processor type. > > - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . > > - Raw (generic) process types are no longer an error. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8315457 - Cache process method type in JCStringTemplate - Revert source - Revert @since 22 - Accept qualified STR and RAW - String Templates (second preview) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16202/files - new: https://git.openjdk.org/jdk/pull/16202/files/ae136779..2afadc69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=02-03 Stats: 53408 lines in 1930 files changed: 29390 ins; 10168 del; 13850 mod Patch: https://git.openjdk.org/jdk/pull/16202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202 PR: https://git.openjdk.org/jdk/pull/16202 From jlahoda at openjdk.org Fri Nov 3 16:32:16 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 16:32:16 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException Message-ID: For code like: enum E {A {}, B {} } Object o = E.A; switch (o) { case E.A -> System.err.println(o); default -> System.err.println("default"); } The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 ------------- Commit messages: - 8318144: Match on enum constants with body compiles but fails with MatchException Changes: https://git.openjdk.org/jdk/pull/16499/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318144 Stats: 109 lines in 3 files changed: 107 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16499/head:pull/16499 PR: https://git.openjdk.org/jdk/pull/16499 From cushon at openjdk.org Fri Nov 3 17:34:13 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 3 Nov 2023 17:34:13 GMT Subject: Integrated: 8225377: type annotations are not visible to javac plugins across compilation boundaries In-Reply-To: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com> Message-ID: On Fri, 27 Oct 2023 21:01:54 GMT, Liam Miller-Cushon wrote: > Hello, > > Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377). > > --- > > To provide some background context and motivation for the bug fix, consider an example like: > > > class B { > @Nullable int f(int x) { > return x; > } > } > > > If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file. > > If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file. > > This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future. > > --- > > javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol. > > Some notes on the approach: > > * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types. > > * For initial test coverage, I have enabled test coverage for annotation processing of type annotations to also run t... This pull request has now been integrated. Changeset: de6667cf Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/de6667cf11aa59d1bab78ae5fb235ea0b901d5c4 Stats: 303 lines in 2 files changed: 302 ins; 0 del; 1 mod 8225377: type annotations are not visible to javac plugins across compilation boundaries Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/16407 From liach at openjdk.org Fri Nov 3 23:53:06 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Nov 2023 23:53:06 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 16:26:49 GMT, Jan Lahoda wrote: > For code like: > > enum E {A {}, B {} } > Object o = E.A; > switch (o) { > case E.A -> System.err.println(o); > default -> System.err.println("default"); > } > > > The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: > https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 Marked as reviewed by liach (Author). src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 399: > 397: Class clazz = label.constantType().resolveConstantDesc(lookup); > 398: > 399: if (!(value instanceof Enum enumValue) || Minor comment: If we are more concerned about performance when the enum is in a mix-and-match with other types (say primitives etc.), we can move the `instanceof` test before the `constantType().resolveConstantDesc()` to avoid a Class lookup. ------------- PR Review: https://git.openjdk.org/jdk/pull/16499#pullrequestreview-1713656471 PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1382291935 From cushon at openjdk.org Sat Nov 4 00:02:21 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sat, 4 Nov 2023 00:02:21 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v4] In-Reply-To: References: Message-ID: > Hello, > > Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). > > As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. > > This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Add a test for annotated receiver types - Merge branch 'master' into JDK-8319196 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java Co-authored-by: liach <7806504+liach at users.noreply.github.com> - Add a null check, update affected tests - 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16482/files - new: https://git.openjdk.org/jdk/pull/16482/files/4c230bfd..d34ff8ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=02-03 Stats: 27230 lines in 606 files changed: 14207 ins; 5274 del; 7749 mod Patch: https://git.openjdk.org/jdk/pull/16482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16482/head:pull/16482 PR: https://git.openjdk.org/jdk/pull/16482 From alanb at openjdk.org Sat Nov 4 13:31:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Nov 2023 13:31:11 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v4] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 15:29:25 GMT, Jim Laskey wrote: >> Update String Templates for a second preview. With the addition of >> >> - Expression type and throws are determined from the `process` method of the processor type and not the processor type. >> >> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . >> >> - Raw (generic) process types are no longer an error. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315457 > - Cache process method type in JCStringTemplate > - Revert source > - Revert @since 22 > - Accept qualified STR and RAW > - String Templates (second preview) Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 424: > 422: * @since 21 > 423: */ > 424: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) I think you can drop both `@since` and `@PreviewFeature` from these methods. This in an internal interface, used for shared secrets, there is a lot of churn in JLA in each release. ------------- PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1713768565 PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1382392709 From alanb at openjdk.org Sat Nov 4 13:31:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Nov 2023 13:31:12 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v4] In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 14:31:46 GMT, Jim Laskey wrote: > Wasn't sure about that. Thx. When in doubt, JEP 12. Alex provided good guidance for API authors on how `@since` should be used with preview APIs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1382392982 From jlahoda at openjdk.org Mon Nov 6 07:34:38 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 07:34:38 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: References: Message-ID: > For code like: > > enum E {A {}, B {} } > Object o = E.A; > switch (o) { > case E.A -> System.err.println(o); > default -> System.err.println("default"); > } > > > The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: > https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Re-ordering tests as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16499/files - new: https://git.openjdk.org/jdk/pull/16499/files/cd27e6e9..5f40a8eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16499/head:pull/16499 PR: https://git.openjdk.org/jdk/pull/16499 From asotona at openjdk.org Mon Nov 6 08:39:27 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Nov 2023 08:39:27 GMT Subject: RFR: 8187591: -Werror turns incubator module warning to an error [v2] In-Reply-To: References: Message-ID: > -Werror turns incubator module warning to an error > This patch disables incubating module warning at compile time when "preview" lint category is disabled. > It also adds a test, adjusts "preview" lint category description and updates javac man pages. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: separate LintCategory.INCUBATING ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16454/files - new: https://git.openjdk.org/jdk/pull/16454/files/65378f60..0aee6895 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16454&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16454&range=00-01 Stats: 19 lines in 6 files changed: 12 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16454/head:pull/16454 PR: https://git.openjdk.org/jdk/pull/16454 From duke at openjdk.org Mon Nov 6 09:56:37 2023 From: duke at openjdk.org (Ryan Wallace) Date: Mon, 6 Nov 2023 09:56:37 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did Message-ID: Hi all, Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. Thanks, Ryan. ------------- Commit messages: - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did Changes: https://git.openjdk.org/jdk/pull/16423/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318971 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16423/head:pull/16423 PR: https://git.openjdk.org/jdk/pull/16423 From alanb at openjdk.org Mon Nov 6 10:08:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Nov 2023 10:08:13 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. This one probably needs discussion to decide if the JDK 8 or current behavior is the right behavior. Once agreed then we will need to add tests to ensure that the behavior doesn't change, and maybe an update to docs too. Have you dug into the history to see if this behavior change was deliberate or just not noticed before now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1794474588 From duke at openjdk.org Mon Nov 6 11:31:10 2023 From: duke at openjdk.org (Ryan Wallace) Date: Mon, 6 Nov 2023 11:31:10 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. I had a look and its been in since JDK 9 (https://bugs.openjdk.org/browse/JDK-8158295) but haven?t found any mention of this as a specific desired behaviour so I am going with just noticed now. Its not a major blocker as the user can either make sure the missing file is in place or exclude it from being added to the archive and rerun. I agree it will need some thought, I was of the opinion that we should fail upfront and notify the user of why. The JDK 8 behaviour doesn?t make sense as the state is recognised as an error and there are tests to validate this, but they do not validate the archive has not been created, in my opinion we shouldn?t continue on and create it. There are other areas in the jar tool in 8 that will clean up (delete) the archive that has been created if there is an error, this case just seems to fall through the cracks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1794612971 From alanb at openjdk.org Mon Nov 6 12:09:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Nov 2023 12:09:09 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: <_oOL_YIlhoyaWX5jQbP_uCnC52MIpXPB_aYECH-m5hg=.dcd75a71-943a-4e59-b64a-94e3443bd519@github.com> On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Thanks for checking the history. A plus to going back to JDK 8 behavior is that it make the `@contents` consistent with the file1, file2, file3 case where one/more of the files doesn't exist or a bad file path is specified. It also means that bugs/issues will be detected quicker. So I think it has positives, it's just that it's changing 6+ year old behavior so we have to be sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1794678429 From jlaskey at openjdk.org Mon Nov 6 12:51:34 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Nov 2023 12:51:34 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v5] In-Reply-To: References: Message-ID: <9uwfuPjY_0dSLi2a52bsIoRswDtAH5-ILNQm6wm1Zjs=.b4222a67-f020-40b8-b5c6-cbdb26f46116@github.com> > Update String Templates for a second preview. With the addition of > > - Expression type and throws are determined from the `process` method of the processor type and not the processor type. > > - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . > > - Raw (generic) process types are no longer an error. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove preview from JavaLangAccess ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16202/files - new: https://git.openjdk.org/jdk/pull/16202/files/2afadc69..4641ec05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=03-04 Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202 PR: https://git.openjdk.org/jdk/pull/16202 From jlaskey at openjdk.org Mon Nov 6 12:51:39 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Nov 2023 12:51:39 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v4] In-Reply-To: References: Message-ID: <6mtIcg0H0wbOwcAzlmWG9thAjUpDCzQe55aLQDGA33Q=.deaada83-150c-4e1d-85c3-c07c61ff62a5@github.com> On Sat, 4 Nov 2023 13:26:04 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into 8315457 >> - Cache process method type in JCStringTemplate >> - Revert source >> - Revert @since 22 >> - Accept qualified STR and RAW >> - String Templates (second preview) > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 424: > >> 422: * @since 21 >> 423: */ >> 424: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > > I think you can drop both `@since` and `@PreviewFeature` from these methods. This in an internal interface, used for shared secrets, there is a lot of churn in JLA in each release. Removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1383275177 From jlahoda at openjdk.org Mon Nov 6 12:58:25 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 12:58:25 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: <6gX1AIFAraJXNagvz0R81ffShpGYy8NAuEx3LVel_cE=.534fbf76-a97b-4610-a672-09f5f0b14569@github.com> On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey 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 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/caa2870d...0bd5b477 javac changes look reasonable to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1715097616 From mcimadamore at openjdk.org Mon Nov 6 13:56:27 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 13:56:27 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey 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 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/baf8d59f...0bd5b477 Javac changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1715227587 From cstein at openjdk.org Mon Nov 6 13:56:28 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 6 Nov 2023 13:56:28 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey 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 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/baf8d59f...0bd5b477 Changes in the two source launcher files `Main.java` and `SourceLauncherTest.java` look good to me - less code is more! ------------- PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1715230089 From vromero at openjdk.org Mon Nov 6 14:54:44 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 6 Nov 2023 14:54:44 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey 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 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/8e9e3542...0bd5b477 lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1715396892 From lancea at openjdk.org Mon Nov 6 15:21:15 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 6 Nov 2023 15:21:15 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 11:28:23 GMT, Ryan Wallace wrote: > I had a look and its been in since JDK 9 (https://bugs.openjdk.org/browse/JDK-8158295) but haven?t found any mention of this as a specific desired behaviour so I am going with just noticed now. Its not a major blocker as the user can either make sure the missing file is in place or exclude it from being added to the archive and rerun. > > I agree it will need some thought, I was of the opinion that we should fail upfront and notify the user of why. The JDK 8 behaviour doesn?t make sense as the state is recognised as an error and there are tests to validate this, but they do not validate the archive has not been created, in my opinion we shouldn?t continue on and create it. There are other areas in the jar tool in 8 that will clean up (delete) the archive that has been created if there is an error, this case just seems to fall through the cracks. As part of the decision process, we should consider the behavior of what simillar tools do in this area. We may also want to discuss the merits of whether there should be an option to toggle the behavior ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1795072524 From cstein at openjdk.org Mon Nov 6 15:45:05 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 6 Nov 2023 15:45:05 GMT Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code Programs [v5] 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 ?: Implicitly Declared Classes and Instance Main Method (2nd 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 two additional commits since the last revision: - Refine lookup of valid application classes - Address module graph related review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13712/files - new: https://git.openjdk.org/jdk/pull/13712/files/854d9991..a988ba0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=03-04 Stats: 37 lines in 2 files changed: 3 ins; 11 del; 23 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 Nov 6 15:50:15 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 6 Nov 2023 15:50:15 GMT Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code Programs [v4] In-Reply-To: References: <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com> Message-ID: On Fri, 27 Oct 2023 14:26:56 GMT, Archie Cobbs wrote: >> I'll add a comment explaining that the `MemoryClassLoader` is required here to compile referenced types from their source files on-the-fly. > > Random comment here, feel free to ignore... > > There appear to be two similar implementations of a "Memory" ClassLoader in the JDK... the one under discussion here, and `jdk.jshell.execution.DefaultLoaderDelegate.RemoteClassLoader`. Perhaps someday they could be consolidated. Comments added, Alan. Archie, that's true for the "in-memory" part - but this class loader also tries to find and compile new classes from the default file system on-the-fly, which the class loader in JShell does not (need to do). If both do share enough code, a consolidation would be good to have. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1383550068 From jlahoda at openjdk.org Mon Nov 6 16:20:23 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 16:20:23 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions Message-ID: Consider a simple module, like: module test {} And compile it with JDK 22 and JDK 21 using: javac --release 21 The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. This patch does two changes: a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. ------------- Commit messages: - Test cleanup. - Merge branch 'master' into JDK-8318913 - Fixing tests. - Retain packages for extra classes. - Handle permitted subtypes. - Fix for writing empty parameter names. - Fixing tests. - Fixing tests. - Cleanup - Fixing dependencies - ... and 7 more: https://git.openjdk.org/jdk/compare/667cca9d...522d58d6 Changes: https://git.openjdk.org/jdk/pull/16400/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16400&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318913 Stats: 554 lines in 11 files changed: 429 ins; 58 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/16400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16400/head:pull/16400 PR: https://git.openjdk.org/jdk/pull/16400 From vromero at openjdk.org Mon Nov 6 18:15:02 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 6 Nov 2023 18:15:02 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 07:34:38 GMT, Jan Lahoda wrote: >> For code like: >> >> enum E {A {}, B {} } >> Object o = E.A; >> switch (o) { >> case E.A -> System.err.println(o); >> default -> System.err.println("default"); >> } >> >> >> The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: >> https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Re-ordering tests as suggested. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 397: > 395: > 396: try { > 397: if (!(value instanceof Enum enumValue)) { this code seems to be here with the only purpose of casting `value` to `Enum`, if this is the case shouldn't this intention be more explicit? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1383763927 From jlahoda at openjdk.org Mon Nov 6 18:54:51 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 18:54:51 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: References: Message-ID: <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com> On Mon, 6 Nov 2023 18:12:10 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Re-ordering tests as suggested. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 397: > >> 395: >> 396: try { >> 397: if (!(value instanceof Enum enumValue)) { > > this code seems to be here with the only purpose of casting `value` to `Enum`, if this is the case shouldn't this intention be more explicit? This method is also used in the `typeSwitch` (i.e. ordinary pattern matching switch, which may contain qualified enum constants intermixed with patterns), and so the `value` may be any object. If it is not an Enum, we can avoid the potential costly resolution. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1383814245 From vromero at openjdk.org Mon Nov 6 19:04:29 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 6 Nov 2023 19:04:29 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com> References: <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com> Message-ID: On Mon, 6 Nov 2023 18:51:59 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 397: >> >>> 395: >>> 396: try { >>> 397: if (!(value instanceof Enum enumValue)) { >> >> this code seems to be here with the only purpose of casting `value` to `Enum`, if this is the case shouldn't this intention be more explicit? > > This method is also used in the `typeSwitch` (i.e. ordinary pattern matching switch, which may contain qualified enum constants intermixed with patterns), and so the `value` may be any object. If it is not an Enum, we can avoid the potential costly resolution. I see shouldn't we then have a test that stresses this code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1383825208 From jjg at openjdk.org Mon Nov 6 19:41:54 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 6 Nov 2023 19:41:54 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments Message-ID: Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. Notable features: * support for `///` documentation comments in `JavaTokenizer` * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library * updates to `DocCommentParser` to treat `///` comments as Markdown * updates to the standard doclet to render Markdown comments in HTML ------------- Commit messages: - JDK-8298405: Support Markdown in Documentation Comments Changes: https://git.openjdk.org/jdk/pull/16388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298405 Stats: 20574 lines in 184 files changed: 19938 ins; 237 del; 399 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From jlaskey at openjdk.org Mon Nov 6 19:53:03 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Nov 2023 19:53:03 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v13] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Rename unnamed class tests and examples ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/0bd5b477..3ffff0db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=11-12 Stats: 24 lines in 8 files changed: 12 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From rriggs at openjdk.org Mon Nov 6 20:01:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Nov 2023 20:01:43 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v13] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 19:53:03 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Rename unnamed class tests and examples Look good. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1716139190 From jlahoda at openjdk.org Mon Nov 6 20:47:06 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 20:47:06 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v3] In-Reply-To: References: Message-ID: > For code like: > > enum E {A {}, B {} } > Object o = E.A; > switch (o) { > case E.A -> System.err.println(o); > default -> System.err.println("default"); > } > > > The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: > https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adding tests as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16499/files - new: https://git.openjdk.org/jdk/pull/16499/files/5f40a8eb..cbc9cb56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=01-02 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16499/head:pull/16499 PR: https://git.openjdk.org/jdk/pull/16499 From jlahoda at openjdk.org Mon Nov 6 20:47:06 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 20:47:06 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: References: <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com> Message-ID: On Mon, 6 Nov 2023 19:01:38 GMT, Vicente Romero wrote: >> This method is also used in the `typeSwitch` (i.e. ordinary pattern matching switch, which may contain qualified enum constants intermixed with patterns), and so the `value` may be any object. If it is not an Enum, we can avoid the potential costly resolution. > > I see shouldn't we have a test that stresses this code? I mean that we are returning `false` for cases that are not enums? I thought there's quite a few such tests, but turns out there's just a few (or maybe only one). So adding some more: [cbc9cb5](https://github.com/openjdk/jdk/pull/16499/commits/cbc9cb569b06c2f3d5e503519082c6243b51f9c8). Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1383960309 From vromero at openjdk.org Mon Nov 6 21:04:32 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 6 Nov 2023 21:04:32 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v3] In-Reply-To: References: Message-ID: <0mHtAUXulQC-Wtq7GZEEBRPjhhEAFZRMAlSt6ottxwQ=.2ec4dfa2-4084-4962-9ec8-cef7cdb055f7@github.com> On Mon, 6 Nov 2023 20:47:06 GMT, Jan Lahoda wrote: >> For code like: >> >> enum E {A {}, B {} } >> Object o = E.A; >> switch (o) { >> case E.A -> System.err.println(o); >> default -> System.err.println("default"); >> } >> >> >> The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: >> https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adding tests as suggested. lgtm, thanks! ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16499#pullrequestreview-1716233470 From acobbs at openjdk.org Mon Nov 6 21:14:07 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 6 Nov 2023 21:14:07 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v20] In-Reply-To: References: Message-ID: > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge branch 'master' into SuperInit - Merge branch 'master' into SuperInit - Reword new errors to use the JLS term for "explicit constructor invocation". - After further review, revert 599d761 to avoid mutable state lying around. - Address review comments relating to error messages. - Have RefBeforeCtorCalledError extend StaticError and customize debug strings. - Change variable name "statik" -> "isStatic" per review recommendation. - Remove obsolete flag "constructorArgs". - Change the error message to match the applicable spec rule. - Merge branch 'master' into SuperInit - ... and 30 more: https://git.openjdk.org/jdk/compare/e4803e0c...bbdb814f ------------- Changes: https://git.openjdk.org/jdk/pull/13656/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=19 Stats: 1498 lines in 27 files changed: 1156 ins; 225 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From cushon at openjdk.org Mon Nov 6 23:14:02 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 6 Nov 2023 23:14:02 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v5] In-Reply-To: References: Message-ID: <9LkKUif_aVMYJitI-kckktnTSguKUn39bNfyXvFu9hI=.95894d11-11f3-4703-a41f-c5e80194bf90@github.com> > Hello, > > Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). > > As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. > > This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into JDK-8319196 - Only infer receiver types during class reading if receiver type annotations are present - Add a test for annotated receiver types - Merge branch 'master' into JDK-8319196 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java Co-authored-by: liach <7806504+liach at users.noreply.github.com> - Add a null check, update affected tests - 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16482/files - new: https://git.openjdk.org/jdk/pull/16482/files/d34ff8ab..32f0050a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=03-04 Stats: 1413 lines in 74 files changed: 805 ins; 277 del; 331 mod Patch: https://git.openjdk.org/jdk/pull/16482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16482/head:pull/16482 PR: https://git.openjdk.org/jdk/pull/16482 From cushon at openjdk.org Mon Nov 6 23:28:38 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 6 Nov 2023 23:28:38 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v5] In-Reply-To: <9LkKUif_aVMYJitI-kckktnTSguKUn39bNfyXvFu9hI=.95894d11-11f3-4703-a41f-c5e80194bf90@github.com> References: <9LkKUif_aVMYJitI-kckktnTSguKUn39bNfyXvFu9hI=.95894d11-11f3-4703-a41f-c5e80194bf90@github.com> Message-ID: On Mon, 6 Nov 2023 23:14:02 GMT, Liam Miller-Cushon wrote: >> Hello, >> >> Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). >> >> As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. >> >> This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into JDK-8319196 > - Only infer receiver types during class reading if receiver type annotations are present > - Add a test for annotated receiver types > - Merge branch 'master' into JDK-8319196 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java > > Co-authored-by: liach <7806504+liach at users.noreply.github.com> > - Add a null check, update affected tests > - 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode I have tentatively updated this to only fill in a receiver type during class reading if type annotations are present on the receiver, based on [discussion in the CSR](https://bugs.openjdk.org/browse/JDK-8319330?focusedId=14624193&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14624193). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16482#issuecomment-1797023539 From erikj at openjdk.org Tue Nov 7 00:36:31 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 7 Nov 2023 00:36:31 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. I believe the build changes look ok, just one comment. Would be good to have someone else look over them too as I was involved in writing this, and it's quite complex. make/modules/jdk.compiler/Gendata.gmk line 29: > 27: > 28: include $(SPEC) > 29: include MakeBase.gmk These shouldn't be needed. `ModuleWrapper.gmk` which is the file including this file already does all of this. ------------- PR Review: https://git.openjdk.org/jdk/pull/16400#pullrequestreview-1716555776 PR Review Comment: https://git.openjdk.org/jdk/pull/16400#discussion_r1384198427 From erikj at openjdk.org Tue Nov 7 00:37:32 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 7 Nov 2023 00:37:32 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments In-Reply-To: References: Message-ID: On Thu, 26 Oct 2023 23:29:00 GMT, Jonathan Gibbons wrote: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Build change looks trivially ok. ------------- PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-1716568732 From jpai at openjdk.org Tue Nov 7 07:52:30 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Nov 2023 07:52:30 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: <-QZ9xPRrv02N3BZBi2U2jblEHAhWkvmYCzMT8HSLhDI=.b4451c95-2895-456f-b4b9-f28ff40319e7@github.com> On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Hello Ryan, I ran a few experiments and I am unsure if we should be doing this change. Please consider this following scenario, when using the current implementation in mainline: echo "hello" > hello.txt jar -cf foo.jar missing.txt missing2.txt hello.txt ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1797979185 From duke at openjdk.org Tue Nov 7 11:06:30 2023 From: duke at openjdk.org (Ryan Wallace) Date: Tue, 7 Nov 2023 11:06:30 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Thanks [jaikiran](https://github.com/jaikiran), the issue with the current functionality on the mainline is that the jar tool is still processing and creating the temp jar file, it just doesn't move it to the working directory where the tool was ran from because there was a missing file supplied and then deletes the temp jar. If you were to run this with many/larger files that causes the jartool to take more time it is more noticeable. Maybe it is better to follow the JDK 8 JarTool behaviour and still produce a jar file without the missing files as we are providing a warning to notify that there were missing files not included in the jar. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1798286718 From jpai at openjdk.org Tue Nov 7 12:09:32 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Nov 2023 12:09:32 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 11:04:14 GMT, Ryan Wallace wrote: > the issue with the current functionality on the mainline is that the jar tool is still processing and creating the temp jar file, it just doesn't move it to the working directory where the tool was ran from because there was a missing file supplied and then deletes the temp jar. If you were to run this with many/larger files that causes the jartool to take more time it is more noticeable. Thank you for that detail. I now understand what we are attempting to improve. In that case, could you experiment by the changing the call sites of `expand(...)` method? Right now in mainline, `expand(...)` method is where we check if a file exists or not and when absent we write a error message and set the `ok = false`. The current proposed change in this PR throws an exception from here instead of writing the error message and setting `ok = false`. What we could do perhaps, is let expand(...) method continue to stay as-is and continue to write those error messages and set `ok = false`. Then at the call site(s) of expand() where we then create and write to the temporary jar file, we should probably first check if `ok = false` and if it is `false` then just return `false` from the `run()` method so that the temporary jar isn't created and the command exits with a non-zero exit code. That way we still report all missing files and don't end up creating the temporary jar. I haven't looked at the code in detail to see if this is feasible and/or if there are other issues this will show up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1798375151 From jlahoda at openjdk.org Tue Nov 7 12:09:46 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 7 Nov 2023 12:09:46 GMT Subject: Integrated: 8318144: Match on enum constants with body compiles but fails with MatchException In-Reply-To: References: Message-ID: <5N26pFp5SYukkm-OA-oru3EWCajncfuoXwFg1LihgNs=.81ab9394-1ee3-4562-af7c-5638e6fed34a@github.com> On Fri, 3 Nov 2023 16:26:49 GMT, Jan Lahoda wrote: > For code like: > > enum E {A {}, B {} } > Object o = E.A; > switch (o) { > case E.A -> System.err.println(o); > default -> System.err.println("default"); > } > > > The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: > https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 This pull request has now been integrated. Changeset: 541ff714 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/541ff7149f9c6480535219ab06a2576f8399703a Stats: 122 lines in 3 files changed: 120 ins; 0 del; 2 mod 8318144: Match on enum constants with body compiles but fails with MatchException Reviewed-by: liach, vromero ------------- PR: https://git.openjdk.org/jdk/pull/16499 From jlaskey at openjdk.org Tue Nov 7 12:29:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 7 Nov 2023 12:29:12 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v14] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8315458 - Rename unnamed class tests and examples - Merge remote-tracking branch 'upstream/master' into 8315458 - Don't get args unless necessary - Remove unnamed classes from examples.not-yet.txt - Requested corrections - Changes recommended by Jan - Revised implicit class test - Don't store main method info globally. Use addition calls to fetch info. - Update JEP number in PreviewFeature - ... and 4 more: https://git.openjdk.org/jdk/compare/d2ff11e4...7effbcff ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/3ffff0db..7effbcff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=12-13 Stats: 2973 lines in 123 files changed: 1757 ins; 376 del; 840 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 7 12:29:54 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 7 Nov 2023 12:29:54 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v6] In-Reply-To: References: Message-ID: <3NHJ2yDj2dW6Y4qPF8FmBkqkXcG7l-BzQ3EKWYArZMI=.28885188-9e99-46e8-81bd-6234023c1b1f@github.com> > Update String Templates for a second preview. With the addition of > > - Expression type and throws are determined from the `process` method of the processor type and not the processor type. > > - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . > > - Raw (generic) process types are no longer an error. Jim Laskey 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 eight additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8315457 - Remove preview from JavaLangAccess - Merge remote-tracking branch 'upstream/master' into 8315457 - Cache process method type in JCStringTemplate - Revert source - Revert @since 22 - Accept qualified STR and RAW - String Templates (second preview) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16202/files - new: https://git.openjdk.org/jdk/pull/16202/files/4641ec05..c616f48e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=04-05 Stats: 2467 lines in 114 files changed: 1740 ins; 357 del; 370 mod Patch: https://git.openjdk.org/jdk/pull/16202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202 PR: https://git.openjdk.org/jdk/pull/16202 From mr at openjdk.org Tue Nov 7 15:39:34 2023 From: mr at openjdk.org (Mark Reinhold) Date: Tue, 7 Nov 2023 15:39:34 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. Will this patch preserve the pre-release identifier (e.g., `-ea` or `-internal`), which was the behavior prior to JDK 22? If not, then it?s an incompatible change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1798908452 From alanb at openjdk.org Tue Nov 7 15:55:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 15:55:49 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v14] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 12:29:12 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Rename unnamed class tests and examples > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - ... and 4 more: https://git.openjdk.org/jdk/compare/f006108e...7effbcff Launcher changes look okay. There are a few more upcalls to methods on the launcher helper now so I assume you'll run the startup benchmarks to make sure it doesn't have any impact. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 899: > 897: /* > 898: * Return type so that launcher invokes the correct main > 899: */ If you are doing anymore edits then I think this method description could be improved to say that it returns the main method type. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1718039775 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1385134339 From alanb at openjdk.org Tue Nov 7 15:55:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 15:55:50 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v14] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 15:45:02 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Rename unnamed class tests and examples >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Don't get args unless necessary >> - Remove unnamed classes from examples.not-yet.txt >> - Requested corrections >> - Changes recommended by Jan >> - Revised implicit class test >> - Don't store main method info globally. Use addition calls to fetch info. >> - Update JEP number in PreviewFeature >> - ... and 4 more: https://git.openjdk.org/jdk/compare/f006108e...7effbcff > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 899: > >> 897: /* >> 898: * Return type so that launcher invokes the correct main >> 899: */ > > If you are doing anymore edits then I think this method description could be improved to say that it returns the main method type. Another suggestion, if you are editing more, is the description on LoadMainClass (in java.c) is confusingly worded, he currently says "Loads a class and verifies that the main class is present". It invokes the helper's checkAndLoadMain so maybe the comment could be adjusted to say that it calls checkAndLoadMain to load the main class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1385150582 From jlaskey at openjdk.org Tue Nov 7 16:19:33 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 7 Nov 2023 16:19:33 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v15] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update launch comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/7effbcff..d3581d89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=13-14 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 7 16:21:50 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 7 Nov 2023 16:21:50 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v14] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 15:51:22 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 899: >> >>> 897: /* >>> 898: * Return type so that launcher invokes the correct main >>> 899: */ >> >> If you are doing anymore edits then I think this method description could be improved to say that it returns the main method type. > > Another suggestion, if you are editing more, is the description on LoadMainClass (in java.c) is confusingly worded, he currently says "Loads a class and verifies that the main class is present". It invokes the helper's checkAndLoadMain so maybe the comment could be adjusted to say that it calls checkAndLoadMain to load the main class. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1385191813 From mchung at openjdk.org Tue Nov 7 17:46:46 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 7 Nov 2023 17:46:46 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v15] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 16:19:33 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update launch comments The changes in java.base looks fine. ------------- Marked as reviewed by mchung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1718330730 From abimpoudis at openjdk.org Tue Nov 7 18:24:59 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 7 Nov 2023 18:24:59 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v29] 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/jep455-20231030/specs/instanceof-jls.html Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Small cleanup in PrimitivePatternsSwitch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15638/files - new: https://git.openjdk.org/jdk/pull/15638/files/a7f778ca..e81f023a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=27-28 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 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 jlahoda at openjdk.org Tue Nov 7 19:19:22 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 7 Nov 2023 19:19:22 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 15:36:46 GMT, Mark Reinhold wrote: > Will this patch preserve the pre-release identifier (e.g., `-ea` or `-internal`), which was the behavior prior to JDK 22? If not, then it?s an incompatible change. Hm, no, the current version will always use the specification version. Should be easy to add the pre-release identifier, if desired. Probably the most difficult would be to tweak the tests. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1799660275 From darcy at openjdk.org Tue Nov 7 19:48:49 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 Nov 2023 19:48:49 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:58:23 GMT, Jim Laskey wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove .orig files > > Re .orig. Thank you Alan. @JimLaskey , please "/issue add JDK-8319133" to include the annotation processing related changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1799787133 From vromero at openjdk.org Tue Nov 7 20:00:26 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 7 Nov 2023 20:00:26 GMT Subject: RFR: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled [v2] In-Reply-To: References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> Message-ID: On Wed, 1 Nov 2023 19:19:15 GMT, Vicente Romero wrote: >> This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion is being thrown for a special, corner-ish, case. Basically having: >> >> package p; >> @Deprecated class T {} // see that class T is annotated >> >> and: >> >> package p; >> class Y { >> @interface A {} >> @interface A {} // error: class A is already defined >> T t; >> } >> >> class `Y` has a duplicate definition of annotation `A`. Now if class `T` is compiled first as in: >> >> `javac -d out/ p/T.java` >> >> and then we do: >> `javac -processor P -cp p:out/:. p/Y.java p/T.java` >> >> where P is the simplest possible annotation processor, basically doing nothing. IMO what is happening here is that during the second compilation, once the compiler find type `T` in class `Y`, given that T.class is in the classpath, it is loaded and the `@Deprecated` annotation is attached to symbol for type `T`. Then when the source for `T.java` is being compiled and its annotations are being processed we get to the code where the assertion is. Here the symbol for `T` is not a package but its metadata is not empty and so the assertion is thrown. The fix here is just removing the assertion as as shown by this example it is not an invariant. >> >> TIA > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - merge with remote branch > - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled @lahodaj thanks for the proposed fix, I think it is spot on! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16443#issuecomment-1799801296 From vromero at openjdk.org Tue Nov 7 20:00:24 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 7 Nov 2023 20:00:24 GMT Subject: RFR: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled [v3] In-Reply-To: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> Message-ID: > This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion is being thrown for a special, corner-ish, case. Basically having: > > package p; > @Deprecated class T {} // see that class T is annotated > > and: > > package p; > class Y { > @interface A {} > @interface A {} // error: class A is already defined > T t; > } > > class `Y` has a duplicate definition of annotation `A`. Now if class `T` is compiled first as in: > > `javac -d out/ p/T.java` > > and then we do: > `javac -processor P -cp p:out/:. p/Y.java p/T.java` > > where P is the simplest possible annotation processor, basically doing nothing. IMO what is happening here is that during the second compilation, once the compiler find type `T` in class `Y`, given that T.class is in the classpath, it is loaded and the `@Deprecated` annotation is attached to symbol for type `T`. Then when the source for `T.java` is being compiled and its annotations are being processed we get to the code where the assertion is. Here the symbol for `T` is not a package but its metadata is not empty and so the assertion is thrown. The fix here is just removing the assertion as as shown by this example it is not an invariant. > > TIA Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #2 from lahodaj/JDK-8191460 Attempting to improve the fix. - Attempting to improve the fix. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16443/files - new: https://git.openjdk.org/jdk/pull/16443/files/39a9bfb2..f32d464e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=01-02 Stats: 38 lines in 3 files changed: 21 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16443/head:pull/16443 PR: https://git.openjdk.org/jdk/pull/16443 From vromero at openjdk.org Tue Nov 7 20:10:40 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 7 Nov 2023 20:10:40 GMT Subject: RFR: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled [v4] In-Reply-To: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> Message-ID: > This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion is being thrown for a special, corner-ish, case. Basically having: > > package p; > @Deprecated class T {} // see that class T is annotated > > and: > > package p; > class Y { > @interface A {} > @interface A {} // error: class A is already defined > T t; > } > > class `Y` has a duplicate definition of annotation `A`. Now if class `T` is compiled first as in: > > `javac -d out/ p/T.java` > > and then we do: > `javac -processor P -cp p:out/:. p/Y.java p/T.java` > > where P is the simplest possible annotation processor, basically doing nothing. IMO what is happening here is that during the second compilation, once the compiler find type `T` in class `Y`, given that T.class is in the classpath, it is loaded and the `@Deprecated` annotation is attached to symbol for type `T`. Then when the source for `T.java` is being compiled and its annotations are being processed we get to the code where the assertion is. Here the symbol for `T` is not a package but its metadata is not empty and so the assertion is thrown. The fix here is just removing the assertion as as shown by this example it is not an invariant. > > TIA Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into JDK-8191460 - Merge pull request #2 from lahodaj/JDK-8191460 Attempting to improve the fix. - Attempting to improve the fix. - merge with remote branch - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled ------------- Changes: https://git.openjdk.org/jdk/pull/16443/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=03 Stats: 176 lines in 2 files changed: 172 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16443/head:pull/16443 PR: https://git.openjdk.org/jdk/pull/16443 From vromero at openjdk.org Tue Nov 7 21:01:10 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 7 Nov 2023 21:01:10 GMT Subject: RFR: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled [v5] In-Reply-To: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> Message-ID: > This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion is being thrown for a special, corner-ish, case. Basically having: > > package p; > @Deprecated class T {} // see that class T is annotated > > and: > > package p; > class Y { > @interface A {} > @interface A {} // error: class A is already defined > T t; > } > > class `Y` has a duplicate definition of annotation `A`. Now if class `T` is compiled first as in: > > `javac -d out/ p/T.java` > > and then we do: > `javac -processor P -cp p:out/:. p/Y.java p/T.java` > > where P is the simplest possible annotation processor, basically doing nothing. IMO what is happening here is that during the second compilation, once the compiler find type `T` in class `Y`, given that T.class is in the classpath, it is loaded and the `@Deprecated` annotation is attached to symbol for type `T`. Then when the source for `T.java` is being compiled and its annotations are being processed we get to the code where the assertion is. Here the symbol for `T` is not a package but its metadata is not empty and so the assertion is thrown. The fix here is just removing the assertion as as shown by this example it is not an invariant. > > TIA Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into JDK-8191460 - Merge branch 'master' into JDK-8191460 - Merge pull request #2 from lahodaj/JDK-8191460 Attempting to improve the fix. - Attempting to improve the fix. - merge with remote branch - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled ------------- Changes: https://git.openjdk.org/jdk/pull/16443/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=04 Stats: 176 lines in 2 files changed: 172 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16443/head:pull/16443 PR: https://git.openjdk.org/jdk/pull/16443 From duke at openjdk.org Wed Nov 8 09:42:25 2023 From: duke at openjdk.org (Ryan Wallace) Date: Wed, 8 Nov 2023 09:42:25 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v2] In-Reply-To: References: Message-ID: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Ryan Wallace has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - Merge branch 'master' into 8318971 - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16423/files - new: https://git.openjdk.org/jdk/pull/16423/files/07553306..612f4c05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=00-01 Stats: 30476 lines in 738 files changed: 15924 ins; 6266 del; 8286 mod Patch: https://git.openjdk.org/jdk/pull/16423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16423/head:pull/16423 PR: https://git.openjdk.org/jdk/pull/16423 From duke at openjdk.org Wed Nov 8 09:42:26 2023 From: duke at openjdk.org (Ryan Wallace) Date: Wed, 8 Nov 2023 09:42:26 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Thanks Jaikiran, I have amended the logic and now return false when we hit this scenario and it is working as you expected. It will stop processing when we find a missing file and not produce the jar while showing the existing error message. I agree this is better behaviour. I have updated the changes to reflect this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1801426138 From jpai at openjdk.org Wed Nov 8 11:09:58 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Nov 2023 11:09:58 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v2] In-Reply-To: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> References: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> Message-ID: <2oB2_gy51_2MnQLce9Xq6yDoI7GGH3T23dqKkzDkMGs=.90db7454-7f70-4a8c-b264-8870ef827c70@github.com> On Wed, 8 Nov 2023 09:42:25 GMT, Ryan Wallace wrote: >> Hi all, >> >> Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. >> >> Thanks, >> Ryan. > > Ryan Wallace has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - Merge branch 'master' into 8318971 > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did Thank you Ryan for trying this change. There's one more place in run() where we call this expand() and that happens when we want to update the jar file. (Previously) line 340 is where this call to expand() happens. Can you add a similar check after that call there and see if things continue to work? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1801665250 From duke at openjdk.org Wed Nov 8 13:40:21 2023 From: duke at openjdk.org (Konrad Windszus) Date: Wed, 8 Nov 2023 13:40:21 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: On Fri, 3 Nov 2023 08:39:37 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 > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 358 commits: > > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # test/jdk/tools/lib/tests/JImageValidator.java > - fixed jdk.jfr > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/module-info.java > - applied javadoc fix suggestions > - fixed new benchmark > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java > - removed trailing space > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/module-info.java > - package info javadoc improvements > - removed obsolete exports from BuildMicrobenchmark.gmk > - ... and 348 more: https://git.openjdk.org/jdk/compare/ec79ab4b...5f4f47c4 I would appreciate a hint in the javadocs why `Classfile.of` requires a byte array and cannot deal with inputstreams (iiuc this is due to the lazy reading which requires adjusting the offset back and forth potentially) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1801897871 From liach at openjdk.org Wed Nov 8 14:10:15 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Nov 2023 14:10:15 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: On Wed, 8 Nov 2023 13:31:32 GMT, Konrad Windszus wrote: > I would appreciate a hint in the javadocs why `Classfile.of` requires a byte array and cannot deal with inputstreams (iiuc this is due to the lazy reading which requires adjusting the offset back and forth potentially) You can simply call `ClassFile.of().parse(inputStream.readAllBytes())` instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1801960923 From asotona at openjdk.org Wed Nov 8 14:32:52 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 14:32:52 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v25] 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 360 commits: - fixed condy tests - Merge branch 'master' into JDK-8308753-preview - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - applied javadoc fix suggestions - fixed new benchmark - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java - removed trailing space - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - ... and 350 more: https://git.openjdk.org/jdk/compare/7bc8e4c8...29c8fad3 ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=24 Stats: 32301 lines in 783 files changed: 14623 ins; 14111 del; 3567 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 liach at openjdk.org Wed Nov 8 15:26:21 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Nov 2023 15:26:21 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v25] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <1O6wmxmmlST1cR3SkMDbz6AQPxQPQzR9LQ2lLX-Gfn4=.04c03978-f129-496e-831e-fdbfe8adf255@github.com> On Wed, 8 Nov 2023 14:32:52 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 > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 360 commits: > > - fixed condy tests > - Merge branch 'master' into JDK-8308753-preview > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # test/jdk/tools/lib/tests/JImageValidator.java > - fixed jdk.jfr > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/module-info.java > - applied javadoc fix suggestions > - fixed new benchmark > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java > - removed trailing space > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/module-info.java > - ... and 350 more: https://git.openjdk.org/jdk/compare/7bc8e4c8...29c8fad3 test/jdk/jdk/classfile/SignaturesTest.java line 1: > 1: /* The new test in this file for classDesc bug needs a migration too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1386795420 From ihse at openjdk.org Wed Nov 8 15:34:59 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 15:34:59 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. make/modules/jdk.compiler/Gendata.gmk line 42: > 40: $(eval $(call ReadImportMetaData)) > 41: > 42: # Modules that should be visible for 9 - the documented modules: While this is an old comment, it seems outdated. I assume "9" refers to "JDK 9", but that is no longer current. Maybe you can rephrase the comment while you're at it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16400#discussion_r1386809738 From vromero at openjdk.org Wed Nov 8 15:41:19 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 8 Nov 2023 15:41:19 GMT Subject: RFR: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled [v6] In-Reply-To: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> Message-ID: > This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion is being thrown for a special, corner-ish, case. Basically having: > > package p; > @Deprecated class T {} // see that class T is annotated > > and: > > package p; > class Y { > @interface A {} > @interface A {} // error: class A is already defined > T t; > } > > class `Y` has a duplicate definition of annotation `A`. Now if class `T` is compiled first as in: > > `javac -d out/ p/T.java` > > and then we do: > `javac -processor P -cp p:out/:. p/Y.java p/T.java` > > where P is the simplest possible annotation processor, basically doing nothing. IMO what is happening here is that during the second compilation, once the compiler find type `T` in class `Y`, given that T.class is in the classpath, it is loaded and the `@Deprecated` annotation is attached to symbol for type `T`. Then when the source for `T.java` is being compiled and its annotations are being processed we get to the code where the assertion is. Here the symbol for `T` is not a package but its metadata is not empty and so the assertion is thrown. The fix here is just removing the assertion as as shown by this example it is not an invariant. > > TIA Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #3 from lahodaj/JDK-8191460 Fixing build. - Fixing build. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16443/files - new: https://git.openjdk.org/jdk/pull/16443/files/76907fa6..e8f9ddad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=04-05 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16443/head:pull/16443 PR: https://git.openjdk.org/jdk/pull/16443 From duke at openjdk.org Wed Nov 8 15:49:18 2023 From: duke at openjdk.org (Konrad Windszus) Date: Wed, 8 Nov 2023 15:49:18 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <83E89Gq0Rn3H-WTsUJPx6L37WggoVHo7piExlpMSmMg=.82768fa9-9262-4fad-b87b-7c94a71d2d84@github.com> On Wed, 8 Nov 2023 14:07:04 GMT, Chen Liang wrote: > You can simply call `ClassFile.of().parse(inputStream.readAllBytes())` instead. I know, but for memory consumption reasons everyone should prefer just passing an InputStream. Is the memory consumption with `ClassFile.of().parse(Path)` any better (i.e. are you using a `java.io.RandomAccessFile` or `java.nio.channels.SeekableByteChannel` under the hood)? I think that deserves a sentence in the javadoc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1802159417 From duke at openjdk.org Wed Nov 8 16:06:15 2023 From: duke at openjdk.org (Ryan Wallace) Date: Wed, 8 Nov 2023 16:06:15 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v3] In-Reply-To: References: Message-ID: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Ryan Wallace has updated the pull request incrementally with one additional commit since the last revision: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16423/files - new: https://git.openjdk.org/jdk/pull/16423/files/612f4c05..c7b18741 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=01-02 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16423/head:pull/16423 PR: https://git.openjdk.org/jdk/pull/16423 From duke at openjdk.org Wed Nov 8 16:06:20 2023 From: duke at openjdk.org (Ryan Wallace) Date: Wed, 8 Nov 2023 16:06:20 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v2] In-Reply-To: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> References: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> Message-ID: On Wed, 8 Nov 2023 09:42:25 GMT, Ryan Wallace wrote: >> Hi all, >> >> Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. >> >> Thanks, >> Ryan. > > Ryan Wallace has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - Merge branch 'master' into 8318971 > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did Added and tested and it still works as expected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1802195024 From alanb at openjdk.org Wed Nov 8 16:09:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Nov 2023 16:09:56 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v2] In-Reply-To: References: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> Message-ID: On Wed, 8 Nov 2023 16:03:22 GMT, Ryan Wallace wrote: > Added and tested and it still works as expected. @ryawalla Would it be possible to update the PR description so there's a clear summary on the updated proposal? I think it aligns the behavior with what happens when a bad file path is specified on the jar command line, right? As I mentioned, we'll need to add tests, release note, and see what docs (jar man page?) need to be updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1802202054 From asotona at openjdk.org Wed Nov 8 16:20:19 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 16:20:19 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v26] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <1Tzm6V5U8360jlN6QksTfSxpCswVhEFbfpNcgNtOvzs=.0c0a444c-f5a6-4207-9e5e-a292eb514304@github.com> > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed SignaturesTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15706/files - new: https://git.openjdk.org/jdk/pull/15706/files/29c8fad3..af441580 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 Wed Nov 8 16:20:23 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 16:20:23 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v25] In-Reply-To: <1O6wmxmmlST1cR3SkMDbz6AQPxQPQzR9LQ2lLX-Gfn4=.04c03978-f129-496e-831e-fdbfe8adf255@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <1O6wmxmmlST1cR3SkMDbz6AQPxQPQzR9LQ2lLX-Gfn4=.04c03978-f129-496e-831e-fdbfe8adf255@github.com> Message-ID: On Wed, 8 Nov 2023 15:22:54 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 360 commits: >> >> - fixed condy tests >> - Merge branch 'master' into JDK-8308753-preview >> - Merge branch 'master' into JDK-8308753-preview >> >> # Conflicts: >> # test/jdk/tools/lib/tests/JImageValidator.java >> - fixed jdk.jfr >> - Merge branch 'master' into JDK-8308753-preview >> >> # Conflicts: >> # src/java.base/share/classes/module-info.java >> - applied javadoc fix suggestions >> - fixed new benchmark >> - Merge branch 'master' into JDK-8308753-preview >> >> # Conflicts: >> # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java >> - removed trailing space >> - Merge branch 'master' into JDK-8308753-preview >> >> # Conflicts: >> # src/java.base/share/classes/module-info.java >> - ... and 350 more: https://git.openjdk.org/jdk/compare/7bc8e4c8...29c8fad3 > > test/jdk/jdk/classfile/SignaturesTest.java line 1: > >> 1: /* > > The new test in this file for classDesc bug needs a migration too. Good point, thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1386878583 From ihse at openjdk.org Wed Nov 8 16:21:00 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 16:21:00 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: <8BGQzeJjj1KC5HShlTHPG08gAoaveXZDTyGRkyRooLI=.18ca0499-1d01-44d0-9b53-73f6ad723148@github.com> On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. The changes are indeed complex. I'm trying to tease out all the implications. I have a few questions/comments. 1) TransitiveDependencies seems to be unused now. I assume this is intended. But maybe the java file can be removed? 2) The definition from spec.gmk says: BUILD_JAVA_FLAGS := @BOOTCYCLE_JVM_ARGS_BIG@ BUILD_JAVA=@FIXPATH@ $(BUILD_JDK)/bin/java $(BUILD_JAVA_FLAGS) Thus it seems that BUILD_JAVA is using the "big" java flags (though I admit I did not follow to check exactly what BOOTCYCLE_JVM_ARGS_BIG means) . But the old code used JAVA_SMALL. Is this an oversight, an assumption that it does not matter, or a measurement-founded decision that it does not matter? Maybe we should add a BUILD_JAVA_SMALL; or maybe it is not worth it. I cannot really say which, though I lend towards the former. 3) The old code did `-add-exports java.base/jdk.internal.javac=java.compiler.interim,jdk.compiler.interim`. I can't say I understand what the meaning of it was, but I don't understand why it is removed now, either. I'd appreciate some explanation about this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1802223462 From ihse at openjdk.org Wed Nov 8 16:24:58 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 16:24:58 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. make/modules/jdk.compiler/Gendata.gmk line 75: > 73: $(wildcard $(MODULE_SRC)/share/data/symbols/*) \ > 74: $(MODULE_INFOS) \ > 75: $(foreach m, $(CT_MODULES) $(call FindTransitiveIndirectDepsForModules, $(CT_MODULES)), \ This dependency line is hard to read. Maybe extract it to a variable and depend on the contents of the variable instead? Also, this is the only place where CT_MODULES is used. I'd recommend also creating an intermediate variable like CT_TRANSITIVE_MODULES for $(call FindTransitiveIndirectDepsForModules, $(CT_MODULES)), and grouping all these declarations in the same place (either in the top of the file as now, or closer to the usage here). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16400#discussion_r1386889971 From ihse at openjdk.org Wed Nov 8 16:29:04 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 16:29:04 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 16:22:31 GMT, Magnus Ihse Bursie wrote: >> Consider a simple module, like: >> >> module test {} >> >> >> And compile it with JDK 22 and JDK 21 using: >> javac --release 21 >> >> The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. >> >> This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. >> >> This patch does two changes: >> a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. >> b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. >> >> The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. >> >> With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. > > make/modules/jdk.compiler/Gendata.gmk line 75: > >> 73: $(wildcard $(MODULE_SRC)/share/data/symbols/*) \ >> 74: $(MODULE_INFOS) \ >> 75: $(foreach m, $(CT_MODULES) $(call FindTransitiveIndirectDepsForModules, $(CT_MODULES)), \ > > This dependency line is hard to read. Maybe extract it to a variable and depend on the contents of the variable instead? > > Also, this is the only place where CT_MODULES is used. I'd recommend also creating an intermediate variable like CT_TRANSITIVE_MODULES for $(call FindTransitiveIndirectDepsForModules, $(CT_MODULES)), and grouping all these declarations in the same place (either in the top of the file as now, or closer to the usage here). In fact, it took me some time to realize these were dependencies, and not lines in the rule. Maybe if we also make a variable for the symbols/* dependencies, we can fit all dependencies in a single line? That'd definitely help with readability. Alternatively, do not separate each dependency on a single line, but start them directly after the colon, and just break lines when they no longer fit due to line length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16400#discussion_r1386893537 From ihse at openjdk.org Wed Nov 8 16:29:07 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 16:29:07 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. make/modules/jdk.compiler/Gendata.gmk line 101: > 99: > 100: ################################################################################ > 101: This too is provided by the framework, and is not needed in these "snippet" makefiles. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16400#discussion_r1386894723 From ihse at openjdk.org Wed Nov 8 16:35:01 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 16:35:01 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. make/Main.gmk line 974: > 972: # The ct.sym generation uses all the moduleinfos as input > 973: jdk.compiler-gendata: $(GENSRC_MODULEINFO_TARGETS) $(JAVA_TARGETS) > 974: ifeq ($(CREATE_BUILDJDK), true) I think I've sorted this out. The `buildjdk` COMPILER resolves to the newly built compiler if we do not have CREATE_BUILDJDK (which really means "USE_BUILDJDK"), and since they are built by jdk.compiler-launchers, we need to make that target first. Otoh, if we have a buildjdk, we're fine, unless we're in the process of creating a buildjdk, then we need to make sure we got the buildjdk first. Is this a proper reading of this? (I think this part could do with some comments, since the logic here is not exactly crystal clear...) But why would we even create ct-sym when creating a buildjdk? That seems like just a waste of time? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16400#discussion_r1386902562 From prappo at openjdk.org Wed Nov 8 17:41:12 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 8 Nov 2023 17:41:12 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments In-Reply-To: References: Message-ID: On Thu, 26 Oct 2023 23:29:00 GMT, Jonathan Gibbons wrote: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML I'll review this PR's tests first. Most of them look good. For the rest, comments inline. test/langtools/jdk/javadoc/tool/sampleapi/lib/sampleapi/generator/ModuleGenerator.java line 49: > 47: import sampleapi.util.PoorDocCommentTable; > 48: > 49: import static com.sun.tools.javac.parser.Tokens.Comment.CommentStyle.JAVADOC; To clarify, the change to this file is that you removed two unused imports, right? test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 37: > 35: > 36: import java.nio.file.Path; > 37: import java.util.ArrayList; Import in unused: Suggestion: test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 61: > 59: } > 60: > 61: ToolBox tb = new ToolBox(); Suggestion: private final ToolBox tb = new ToolBox(); test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 64: > 62: > 63: @Test > 64: public void testFindStandardTransformer_raw() throws Exception { Checked exceptions are not thrown: Suggestion: public void testFindStandardTransformer_raw() { test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 82: > 80: > 81: @Test > 82: public void testFindStandardTransformer_stream() throws Exception { Checked exceptions are not thrown here too: Suggestion: public void testFindStandardTransformer_stream() { test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 96: > 94: var sl = ServiceLoader.load(DocTrees.DocCommentTreeTransformer.class); > 95: return StreamSupport.stream(sl.spliterator(), false) > 96: .filter(p -> p.name().equals(name)) ServiceLoader specification suggests another way of streaming: Suggestion: return sl.stream() .map(ServiceLoader.Provider::get) .filter(t -> t.name().equals(name)) Would it be the same and more readable? test/langtools/tools/javac/classfiles/attributes/deprecated/DeprecatedTest.java line 26: > 24: /* > 25: * @test > 26: * @bug 8042261 8298405 This comment is not for this line, but for two compiler tests for `@deprecated` javadoc tag. It seemed quite contextual place to put it. Did I miss it, or you are planning to add a javadoc test that verifies that `@deprecated` appearing in a `///` comment has no [special meaning]() it has in classic `/** */` comments? [special meaning]: https://github.com/openjdk/jdk/blob/128363bf3b57dfa05b3807271b47851733c1afb9/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java#L1639-L1653 test/langtools/tools/javac/doctree/DocCommentTester.java line 1012: > 1010: // } > 1011: // return null; > 1012: // } Debugging leftover? test/langtools/tools/javac/doctree/FirstSentenceTest.java line 423: > 421: DocComment[DOC_COMMENT, pos:0 > 422: firstSentence: 1 > 423: RawText[MARKDOWN, pos:0, abc.|def.] It took me a while to understand why this test expects the first sentence to include the second line: ///abc. ///def. void simpleMarkdown() { } It's not because it's Markdown or the new `///` comment syntax. It's because the breakiterator thinks that `abc.\ndef.` is one sentence. Now, in this same file, on [line 123](https://github.com/openjdk/jdk/blob/128363bf3b57dfa05b3807271b47851733c1afb9/test/langtools/tools/javac/doctree/FirstSentenceTest.java#L119-L142), there's this test: /** * abc def ghi. * jkl mno pqr */ void dot_newline() { } If you compare its expectation to that of simpleMarkdown(), you'll see that the first sentence consists of the first line only: BREAK_ITERATOR DocComment[DOC_COMMENT, pos:1 firstSentence: 1 Text[TEXT, pos:1, abc_def_ghi.] body: 1 Text[TEXT, pos:15, jkl_mno_pqr] block tags: empty ] So, why does it seem to work differently for `///` and `/** */` comments? It turns out that a whitespace character immediately after newline is important for breakiterator to do its thing: ``` ? abc def ghi.\n jkl mno pqr ? ^ The problem with the simpleMarkdown test is that we cannot just indent the comment. That indentation will be deemed incidental whitespace and, thus, will removed. For example, suppose we do this: /// abc. /// def. void simpleMarkdown() { } The breakiterator will still see `abc.\ndef.`. Of course, we could do this: ///abc. /// def. void simpleMarkdown() { } But it would be a different comment. There's another test in this PR, [TestMarkdown.testFirstSentence](https://github.com/openjdk/jdk/blob/128363bf3b57dfa05b3807271b47851733c1afb9/test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdown.java#L68-L83). There, the first sentence consists only of the first line. This is likely because the second line starts with a capital letter. test/langtools/tools/javac/doctree/MDPrinter.java line 67: > 65: * Conceptually based on javac's {@code DPrinter}. > 66: */ > 67: public class MDPrinter { While DPrinter is used, MDPrinter isn't. (At least, I could't find any usages of it.) If you feel like MDPrinter is important, we should at least add a compile test for it, to protect it from bitrot. test/langtools/tools/javac/doctree/MarkdownTest.java line 464: > 462: ///{@summary abc ``code-span {@dummy ...}`` def {@code ...} } > 463: ///rest. > 464: void codeSpanInInlineTag() { } Initially, I thought that there were two empty code spans or perhaps two pairs of literal backticks. But it turns out that CommonMark actually [allows](https://spec.commonmark.org/0.30/#code-spans) this syntax for code spans: ``codespan`` I guess I've never had to insert a backtick inside a code span, or it was done differently in that flavour of Markdown I used. test/langtools/tools/javac/doctree/MarkdownTest.java line 555: > 553: // block tags: empty > 554: //] > 555: //*/ Just to clarify: it is supposed to be commented out, right? If uncommented, this test fails with a slightly different error. test/langtools/tools/javac/lexer/CommentTest.java line 24: > 22: */ > 23: > 24: /** Suggestion: /* Otherwise, some IDEs confuse this jtreg comment for a javadoc comment. test/langtools/tools/javac/lexer/CommentTest.java line 37: > 35: import java.util.Objects; > 36: > 37: import com.sun.tools.javac.parser.JavadocTokenizer; Unused import: Suggestion: test/langtools/tools/javac/lexer/CommentTest.java line 73: > 71: > 72: /** > 73: * Whitespace before the commennt is completely ignored. Typo: Suggestion: * Whitespace before the comment is completely ignored. ------------- Changes requested by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-1719995947 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386961537 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386970114 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386969740 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386971152 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386974907 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386985044 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386892431 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386854434 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386442552 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386406680 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386485173 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386487676 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386410910 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386411725 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386413193 From prappo at openjdk.org Wed Nov 8 17:41:14 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 8 Nov 2023 17:41:14 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:25:36 GMT, Pavel Rappo wrote: >> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. >> >> Notable features: >> >> * support for `///` documentation comments in `JavaTokenizer` >> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library >> * updates to `DocCommentParser` to treat `///` comments as Markdown >> * updates to the standard doclet to render Markdown comments in HTML > > test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 64: > >> 62: >> 63: @Test >> 64: public void testFindStandardTransformer_raw() throws Exception { > > Checked exceptions are not thrown: > Suggestion: > > public void testFindStandardTransformer_raw() { I might be mistaken, but this and the testFindStandardTransformer_stream methods look like we are testing ServiceLoader API. I would leave just the stream version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1386974146 From erikj at openjdk.org Wed Nov 8 20:01:59 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 8 Nov 2023 20:01:59 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: <9n64R-yPL-FjiPBc6UABsD0zW5YEWkF6ZhmvdnB_mv4=.a0434daf-91d2-41e5-b6cf-f401ccead7fe@github.com> On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. > The changes are indeed complex. I'm trying to tease out all the implications. I have a few questions/comments. > > 2. The definition from spec.gmk says: > > ``` > BUILD_JAVA_FLAGS := @BOOTCYCLE_JVM_ARGS_BIG@ > BUILD_JAVA=@FIXPATH@ $(BUILD_JDK)/bin/java $(BUILD_JAVA_FLAGS) > ``` > > Thus it seems that BUILD_JAVA is using the "big" java flags (though I admit I did not follow to check exactly what BOOTCYCLE_JVM_ARGS_BIG means) . But the old code used JAVA_SMALL. > > Is this an oversight, an assumption that it does not matter, or a measurement-founded decision that it does not matter? Maybe we should add a BUILD_JAVA_SMALL; or maybe it is not worth it. I cannot really say which, though I lend towards the former. If we had a BUILD_JAVA_SMALL I would probably have used it. In this case I probably couldn't be bothered as it's just one java invocation, so won't make much of a difference. However, it was a while since I wrote this, so I don't actually remember. OTOH, for every single invocations we add, the number goes up and will eventually make a significant impact. > > 3. The old code did `-add-exports java.base/jdk.internal.javac=java.compiler.interim,jdk.compiler.interim`. I can't say I understand what the meaning of it was, but I don't understand why it is removed now, either. I'd appreciate some explanation about this. The java.base module has this in module-info.java: exports jdk.internal.javac to java.compiler, jdk.compiler, jdk.incubator.vector, jdk.jshell; Before this patch we used interim langtools to run this buildtool. The interim JDK N tools are built into module names with the `.interim` suffix so not to clash with the JDK N-1 versions of these modules in the bootJDK. This means that when running the interim langtools, `java.base` isn't exporting jdk.internal.javac to the interim modules. In most other cases where we use the interim langtools modules, we add `$(INTERIMA_LANGTOOLS_ADD_EXPORTS)` to work around this. This tool instead defined its own smaller set of add-exports. In this patch, we are instead using the BUILD_JDK to run the tool, which is a real JDK N with langtools modules included. When using that, the exports in java.base are enough. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1802562841 From erikj at openjdk.org Wed Nov 8 21:17:58 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 8 Nov 2023 21:17:58 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: <6RYD-SZ7pvhaJGBgKQIEjhX2sguj7obDPVSqe_fnovQ=.e7ae67cc-1dd5-467d-8eb7-f3927152abfe@github.com> On Wed, 8 Nov 2023 16:31:47 GMT, Magnus Ihse Bursie wrote: >> Consider a simple module, like: >> >> module test {} >> >> >> And compile it with JDK 22 and JDK 21 using: >> javac --release 21 >> >> The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. >> >> This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. >> >> This patch does two changes: >> a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. >> b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. >> >> The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. >> >> With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. > > make/Main.gmk line 974: > >> 972: # The ct.sym generation uses all the moduleinfos as input >> 973: jdk.compiler-gendata: $(GENSRC_MODULEINFO_TARGETS) $(JAVA_TARGETS) >> 974: ifeq ($(CREATE_BUILDJDK), true) > > I think I've sorted this out. The `buildjdk` COMPILER resolves to the newly built compiler if we do not have CREATE_BUILDJDK (which really means "USE_BUILDJDK"), and since they are built by jdk.compiler-launchers, we need to make that target first. Otoh, if we have a buildjdk, we're fine, unless we're in the process of creating a buildjdk, then we need to make sure we got the buildjdk first. Is this a proper reading of this? > (I think this part could do with some comments, since the logic here is not exactly crystal clear...) > > But why would we even create ct-sym when creating a buildjdk? That seems like just a waste of time? If cross compiling, a BUILD_JDK can either be supplied by configure, or be built dynamically for the build platform. When not cross compiling, it's created implicitly by the build. There are two variables from configure that describe this: `CREATE_BUILDJDK` : true if we are cross compiling and need to explicitly create a build jdk for the build platform. `EXTERNAL_BUILDJDK`: true if a prebuilt build jdk has been supplied to configure. When CREATE_BUILDJDK is true, there is also the variable `CREATING_BUILDJDK` that is set men `Main.gmk` is called recursively to actually create a build jdk for the build platform. There are more comments for these cases around the jmod targets. However, while writing this I realize that we are missing a conditional on `EXTERNAL_BUILDJDK` being false. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16400#discussion_r1387207298 From jjg at openjdk.org Wed Nov 8 22:17:21 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 8 Nov 2023 22:17:21 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v2] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Customize support for Markdown headings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/128363bf..ea9c1614 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=00-01 Stats: 266 lines in 4 files changed: 254 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From erikj at openjdk.org Thu Nov 9 00:03:58 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 9 Nov 2023 00:03:58 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. I have updated the build changes in a branch here: https://github.com/erikj79/jdk/commits/pull/16400 In Main.gmk I'm trying to clarify the BUILD_JDK things with comments and correcting one of the cases with another conditional. In Gendata.gmk I removed some dead code (including the lines I commented on myself) and reorganized the prerequisites list as suggested by Magnus. I have also introduced a `BUILD_JAVA_SMALL`, we already had the args ready (just with a weird name which I corrected). In my testing it reduces the `user` time by more than half, so seems worth it. I'm still verifying the patch across all our build configs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1802935282 From cushon at openjdk.org Thu Nov 9 01:19:17 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 9 Nov 2023 01:19:17 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics Message-ID: Hi, Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. ------------- Commit messages: - 8291643: Consider omitting type annotations from type error diagnostics Changes: https://git.openjdk.org/jdk/pull/16578/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16578&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291643 Stats: 29 lines in 5 files changed: 23 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16578/head:pull/16578 PR: https://git.openjdk.org/jdk/pull/16578 From liach at openjdk.org Thu Nov 9 00:23:15 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 9 Nov 2023 00:23:15 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] In-Reply-To: <83E89Gq0Rn3H-WTsUJPx6L37WggoVHo7piExlpMSmMg=.82768fa9-9262-4fad-b87b-7c94a71d2d84@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <83E89Gq0Rn3H-WTsUJPx6L37WggoVHo7piExlpMSmMg=.82768fa9-9262-4fad-b87b-7c94a71d2d84@github.com> Message-ID: On Wed, 8 Nov 2023 15:45:56 GMT, Konrad Windszus wrote: > I know, but for memory consumption reasons everyone should prefer just passing an InputStream. Is the memory consumption with `ClassFile.of().parse(Path)` any better (i.e. are you using a `java.io.RandomAccessFile` or `java.nio.channels.SeekableByteChannel` under the hood)? I think that deserves a sentence in the javadoc. FYI `parse(Path)` is just a shortcut to read all bytes from a file, like `parse(Files.readAllBytes(path))`. Classfile implementation fetches the byte array very often (constant pool reading, lazy expansion) so keeping the bytes in a in-memory array is better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1802967277 From asotona at openjdk.org Thu Nov 9 08:52:57 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Nov 2023 08:52:57 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v27] 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 363 commits: - fixed lambda tests - Merge branch 'master' into JDK-8308753-preview - fixed SignaturesTest - fixed condy tests - Merge branch 'master' into JDK-8308753-preview - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - applied javadoc fix suggestions - fixed new benchmark - ... and 353 more: https://git.openjdk.org/jdk/compare/b0fc8082...8c80afff ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=26 Stats: 32311 lines in 785 files changed: 14623 ins; 14113 del; 3575 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 Thu Nov 9 10:57:58 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 9 Nov 2023 10:57:58 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. Thanks for the comments so far. I have locally added the pre-release text to the module versions and merged recent Erik's changes. I'll push the updated version in a few hours. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1803606278 From jlahoda at openjdk.org Thu Nov 9 14:09:39 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 9 Nov 2023 14:09:39 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions [v2] In-Reply-To: References: Message-ID: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. Jan Lahoda has updated the pull request incrementally with four additional commits since the last revision: - Fixing tests. - Merge remote-tracking branch 'erikj/pull/16400' into JDK-8318913 - Build fixes - Include pre-release version in the module version. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16400/files - new: https://git.openjdk.org/jdk/pull/16400/files/522d58d6..f3be97d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16400&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16400&range=00-01 Stats: 86 lines in 8 files changed: 49 ins; 9 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/16400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16400/head:pull/16400 PR: https://git.openjdk.org/jdk/pull/16400 From vromero at openjdk.org Thu Nov 9 16:05:06 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 9 Nov 2023 16:05:06 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v6] In-Reply-To: <3NHJ2yDj2dW6Y4qPF8FmBkqkXcG7l-BzQ3EKWYArZMI=.28885188-9e99-46e8-81bd-6234023c1b1f@github.com> References: <3NHJ2yDj2dW6Y4qPF8FmBkqkXcG7l-BzQ3EKWYArZMI=.28885188-9e99-46e8-81bd-6234023c1b1f@github.com> Message-ID: <0K0xamwKYF8WAEot9UxNl8ncxWFkonJiSDgCVqs8b7A=.755020db-142d-4572-9a59-e1e31a741945@github.com> On Tue, 7 Nov 2023 12:29:54 GMT, Jim Laskey wrote: >> Update String Templates for a second preview. With the addition of >> >> - Expression type and throws are determined from the `process` method of the processor type and not the processor type. >> >> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . >> >> - Raw (generic) process types are no longer an error. > > Jim Laskey 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 eight additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315457 > - Remove preview from JavaLangAccess > - Merge remote-tracking branch 'upstream/master' into 8315457 > - Cache process method type in JCStringTemplate > - Revert source > - Revert @since 22 > - Accept qualified STR and RAW > - String Templates (second preview) lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1722905748 From prappo at openjdk.org Thu Nov 9 16:43:00 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 9 Nov 2023 16:43:00 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 22:17:21 GMT, Jonathan Gibbons wrote: >> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. >> >> Notable features: >> >> * support for `///` documentation comments in `JavaTokenizer` >> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library >> * updates to `DocCommentParser` to treat `///` comments as Markdown >> * updates to the standard doclet to render Markdown comments in HTML > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Customize support for Markdown headings I see you've added a new feature and tests for it. test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdown.java line 613: > 611: /// Lorem ipsum. > 612: /// > 613: /// ## ATX-style subheading for executable Can we use Markdown headings inside block tags, such as `@apiNote`? If so, should they start from h5? If so, should we get a warning if they "overflow" h6? ------------- PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-1723026055 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1388270695 From vromero at openjdk.org Thu Nov 9 17:32:00 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 9 Nov 2023 17:32:00 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v5] In-Reply-To: <9LkKUif_aVMYJitI-kckktnTSguKUn39bNfyXvFu9hI=.95894d11-11f3-4703-a41f-c5e80194bf90@github.com> References: <9LkKUif_aVMYJitI-kckktnTSguKUn39bNfyXvFu9hI=.95894d11-11f3-4703-a41f-c5e80194bf90@github.com> Message-ID: On Mon, 6 Nov 2023 23:14:02 GMT, Liam Miller-Cushon wrote: >> Hello, >> >> Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). >> >> As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. >> >> This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into JDK-8319196 > - Only infer receiver types during class reading if receiver type annotations are present > - Add a test for annotated receiver types > - Merge branch 'master' into JDK-8319196 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java > > Co-authored-by: liach <7806504+liach at users.noreply.github.com> > - Add a null check, update affected tests > - 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode looks good to me, just minor comments src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 84: > 82: import static com.sun.tools.javac.jvm.ByteCodes.lushrl; > 83: import static com.sun.tools.javac.jvm.ByteCodes.lxor; > 84: import static com.sun.tools.javac.jvm.ByteCodes.ret; this import doesn't seem to be used now test/langtools/tools/javac/processing/model/element/TestExecutableReceiverType.java line 51: > 49: for (ExecutableElement e : ElementFilter.methodsIn( > 50: roundEnv.getElementsAnnotatedWith(ReceiverTypeKind.class))) { > 51: count += testExecutable(e); nit: indentation should be 4 spaces here, same issue below ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16482#pullrequestreview-1723109394 PR Review Comment: https://git.openjdk.org/jdk/pull/16482#discussion_r1388339579 PR Review Comment: https://git.openjdk.org/jdk/pull/16482#discussion_r1388319026 From darcy at openjdk.org Thu Nov 9 17:56:00 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 9 Nov 2023 17:56:00 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 10:55:06 GMT, Jan Lahoda wrote: >> Consider a simple module, like: >> >> module test {} >> >> >> And compile it with JDK 22 and JDK 21 using: >> javac --release 21 >> >> The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. >> >> This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. >> >> This patch does two changes: >> a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. >> b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. >> >> The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. >> >> With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. > > Thanks for the comments so far. I have locally added the pre-release text to the module versions and merged recent Erik's changes. I'll push the updated version in a few hours. @lahodaj, should this change get a CSR to cover the behavioral changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1804293641 From ihse at openjdk.org Thu Nov 9 17:59:00 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 9 Nov 2023 17:59:00 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 00:01:26 GMT, Erik Joelsson wrote: >> Consider a simple module, like: >> >> module test {} >> >> >> And compile it with JDK 22 and JDK 21 using: >> javac --release 21 >> >> The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. >> >> This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. >> >> This patch does two changes: >> a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. >> b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. >> >> The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. >> >> With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. > > I have updated the build changes in a branch here: https://github.com/erikj79/jdk/commits/pull/16400 > > In Main.gmk I'm trying to clarify the BUILD_JDK things with comments and correcting one of the cases with another conditional. In Gendata.gmk I removed some dead code (including the lines I commented on myself) and reorganized the prerequisites list as suggested by Magnus. I have also introduced a `BUILD_JAVA_SMALL`, we already had the args ready (just with a weird name which I corrected). In my testing it reduces the `user` time by more than half, so seems worth it. > > I'm still verifying the patch across all our build configs. @erikj79 Thanks for making these changes! That looks great. I think when Jan has incorporated those changes, the PR looks fine from a build perspective. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1804296653 From cushon at openjdk.org Thu Nov 9 18:21:14 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 9 Nov 2023 18:21:14 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v6] In-Reply-To: References: Message-ID: > Hello, > > Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). > > As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. > > This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Address review feedback * remove an unused import * fix indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16482/files - new: https://git.openjdk.org/jdk/pull/16482/files/32f0050a..3172f45e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16482/head:pull/16482 PR: https://git.openjdk.org/jdk/pull/16482 From cushon at openjdk.org Thu Nov 9 18:21:16 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 9 Nov 2023 18:21:16 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v5] In-Reply-To: References: <9LkKUif_aVMYJitI-kckktnTSguKUn39bNfyXvFu9hI=.95894d11-11f3-4703-a41f-c5e80194bf90@github.com> Message-ID: <6DMVUX346uIR17ok12o43RQ_WKMQL55V72_o4VwHScY=.c134d772-d3a0-4fea-996c-627dbae54fff@github.com> On Thu, 9 Nov 2023 17:29:04 GMT, Vicente Romero wrote: > looks good to me, just minor comments I addressed the comments, thanks for the review! I also updated the CSR [JDK-8319330](https://bugs.openjdk.org/browse/JDK-8319330) and moved it back to 'proposed'. > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 84: > >> 82: import static com.sun.tools.javac.jvm.ByteCodes.lushrl; >> 83: import static com.sun.tools.javac.jvm.ByteCodes.lxor; >> 84: import static com.sun.tools.javac.jvm.ByteCodes.ret; > > this import doesn't seem to be used now Done > test/langtools/tools/javac/processing/model/element/TestExecutableReceiverType.java line 51: > >> 49: for (ExecutableElement e : ElementFilter.methodsIn( >> 50: roundEnv.getElementsAnnotatedWith(ReceiverTypeKind.class))) { >> 51: count += testExecutable(e); > > nit: indentation should be 4 spaces here, same issue below Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/16482#issuecomment-1804326825 PR Review Comment: https://git.openjdk.org/jdk/pull/16482#discussion_r1388409119 PR Review Comment: https://git.openjdk.org/jdk/pull/16482#discussion_r1388409373 From cushon at openjdk.org Thu Nov 9 22:52:10 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 9 Nov 2023 22:52:10 GMT Subject: RFR: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode [v7] In-Reply-To: References: Message-ID: > Hello, > > Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). > > As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. > > This fix updates the implementation to return the implicit receiver type of methods that do not explicitly declare a receiver parameter in source, including for methods that were loaded from class files. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Add a null check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16482/files - new: https://git.openjdk.org/jdk/pull/16482/files/3172f45e..7aafb3bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16482&range=05-06 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16482/head:pull/16482 PR: https://git.openjdk.org/jdk/pull/16482 From vromero at openjdk.org Fri Nov 10 00:04:02 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 10 Nov 2023 00:04:02 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 14:09:39 GMT, Jan Lahoda wrote: >> Consider a simple module, like: >> >> module test {} >> >> >> And compile it with JDK 22 and JDK 21 using: >> javac --release 21 >> >> The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. >> >> This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. >> >> This patch does two changes: >> a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. >> b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. >> >> The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. >> >> With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. > > Jan Lahoda has updated the pull request incrementally with four additional commits since the last revision: > > - Fixing tests. > - Merge remote-tracking branch 'erikj/pull/16400' into JDK-8318913 > - Build fixes > - Include pre-release version in the module version. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16400#pullrequestreview-1723707279 From ihse at openjdk.org Fri Nov 10 00:41:59 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Nov 2023 00:41:59 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 16:25:59 GMT, Magnus Ihse Bursie wrote: >> Jan Lahoda has updated the pull request incrementally with four additional commits since the last revision: >> >> - Fixing tests. >> - Merge remote-tracking branch 'erikj/pull/16400' into JDK-8318913 >> - Build fixes >> - Include pre-release version in the module version. > > make/modules/jdk.compiler/Gendata.gmk line 101: > >> 99: >> 100: ################################################################################ >> 101: > > This too is provided by the framework, and is not needed in these "snippet" makefiles. These new lines should still be deleted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16400#discussion_r1388737415 From ihse at openjdk.org Fri Nov 10 00:44:59 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Nov 2023 00:44:59 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 14:09:39 GMT, Jan Lahoda wrote: >> Consider a simple module, like: >> >> module test {} >> >> >> And compile it with JDK 22 and JDK 21 using: >> javac --release 21 >> >> The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. >> >> This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. >> >> This patch does two changes: >> a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. >> b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. >> >> The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. >> >> With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. > > Jan Lahoda has updated the pull request incrementally with four additional commits since the last revision: > > - Fixing tests. > - Merge remote-tracking branch 'erikj/pull/16400' into JDK-8318913 > - Build fixes > - Include pre-release version in the module version. The build changes almost look good. Just remove the extra added lines at the end. I think this point too still remains: > 1. TransitiveDependencies seems to be unused now. I assume this is intended. But maybe the java file can be removed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1804897815 From vromero at openjdk.org Fri Nov 10 00:49:59 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 10 Nov 2023 00:49:59 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 00:47:10 GMT, Liam Miller-Cushon wrote: > Hi, > > Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. > > For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. > > An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. > > The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. looks good to me I guess your patch have uncovered a bug in stripMetadata ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16578#pullrequestreview-1723748188 PR Comment: https://git.openjdk.org/jdk/pull/16578#issuecomment-1804901144 From cushon at openjdk.org Fri Nov 10 01:06:58 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 10 Nov 2023 01:06:58 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 00:47:10 GMT, Liam Miller-Cushon wrote: > Hi, > > Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. > > For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. > > An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. > > The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. I have been looking at some other issues related to diagnostics and type annotations (e.g. [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226)), and I am now wondering if it would make sense to preserve type annotations on times some of the time. I think stripping them is a good default (the majority of diagnostics about types are not related to type annotations), but do you have thoughts on letting diagnostics opt-in to preserving the annotations? One possibility would be to have a trivial wrapper around the types used in diagnostic arguments, and then have the diagnostic formatter unwrap them and leave the annotations on: https://github.com/openjdk/jdk/blob/a95062b39a431b4937ab6e9e73de4d2b8ea1ac49/src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java#L202-L203 I am now also wondering if `AbstractDiagnosticFormatter` would be a better place to call `stripMetdata()` than where it currently is in `JCDIagnostic`. What do you think? (And sorry for no thinking of these issues until after opening the PR.) --- > > The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. > > I guess your patch have uncovered a bug in stripMetadata I wasn't sure if would be considered a bug or not, but it was unexpected. I'm not sure preserving the `ForAll` makes the diagnostic clearer, but it's also possible to update `stripMetadata()` to preserve it. The following would preserve the original diagnostics for `LambdaConv25`, do you have a preference? diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java index e295096bb6d..b914d5e4a43 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java @@ -446,7 +446,12 @@ public Type visitTypeVar(TypeVar t, Void aVoid) { public Type visitWildcardType(WildcardType wt, Void aVoid) { return super.visitWildcardType((WildcardType)wt.typeNoMetadata(), aVoid); } - }; + + @Override + public Type visitForAll(ForAll t, Void aVoid) { + return new ForAll(t.tvars, t.qtype.accept(this, aVoid)); + } + }; public Type preannotatedType() { return addMetadata(new Annotations()); ------------- PR Comment: https://git.openjdk.org/jdk/pull/16578#issuecomment-1804914364 From cushon at openjdk.org Fri Nov 10 01:27:13 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 10 Nov 2023 01:27:13 GMT Subject: RFR: 8043226: Better diagnostics for non-applicable type annotations Message-ID: 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 log regardless of their source position, and partially addresses the diagnostic ordering issues described by [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683). Before: test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java:16: error: cannot find symbol List<@TA java.lang.Object> of2; ^ symbol: class java location: class CantAnnotatePackages After: test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java:14: error: type annotations are not admissible at this location: @TA @TA java.lang.Object of1; ^ (to annotate a qualified type, write java.lang. at TA Object) ------------- Commit messages: - 8043226: Better diagnostics for non-applicable type annotations Changes: https://git.openjdk.org/jdk/pull/16592/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16592&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8043226 Stats: 290 lines in 17 files changed: 35 ins; 49 del; 206 mod Patch: https://git.openjdk.org/jdk/pull/16592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16592/head:pull/16592 PR: https://git.openjdk.org/jdk/pull/16592 From darcy at openjdk.org Fri Nov 10 03:52:56 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 10 Nov 2023 03:52:56 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 01:03:49 GMT, Liam Miller-Cushon wrote: > I guess your patch have uncovered a bug in stripMetadata FYI, in case it is relevant here, I ran into some (still unresolved AFAIK) issues in stripMeta data during work on JDK-8042981: "Strip type annotations in Types' utility methods", including type annotations not being stripped for primitive types. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16578#issuecomment-1805032818 From jlahoda at openjdk.org Fri Nov 10 07:31:01 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 10 Nov 2023 07:31:01 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v2] In-Reply-To: References: Message-ID: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> On Fri, 3 Nov 2023 08:21:15 GMT, Adam Sotona wrote: >> Javap ignores --system option when searching for JDK classes. >> This patch prepends search over JDK system modules. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > Skip search over JDK modules for classes in unnamed package (mainly to skip JDK module-infos) To me, looks reasonable. Is there a chance for a jtreg test? Two other minor comments inline. src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 28: > 26: package com.sun.tools.javap; > 27: > 28: import com.sun.tools.javac.file.Locations; Nit: seems unused. src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 864: > 862: fo = fileManager.getJavaFileForInput(moduleLocation, className, JavaFileObject.Kind.CLASS); > 863: } else { > 864: if (className.indexOf('.') > 0) try { I would put the try into a block - it is slightly longer, but much clear, I think. ------------- PR Review: https://git.openjdk.org/jdk/pull/16476#pullrequestreview-1724173952 PR Review Comment: https://git.openjdk.org/jdk/pull/16476#discussion_r1389013585 PR Review Comment: https://git.openjdk.org/jdk/pull/16476#discussion_r1389014202 From jlahoda at openjdk.org Fri Nov 10 07:34:58 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 10 Nov 2023 07:34:58 GMT Subject: RFR: 8187591: -Werror turns incubator module warning to an error [v2] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 08:39:27 GMT, Adam Sotona wrote: >> -Werror turns incubator module warning to an error >> This patch adds "incubating" lint on-by-default category and triggers incubating module warning accordingly. >> It also adds a test and updates javac man pages and jdk.compiler module-info javadoc. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > separate LintCategory.INCUBATING Looks OK to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16454#pullrequestreview-1724181816 From asotona at openjdk.org Fri Nov 10 08:38:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Nov 2023 08:38:09 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v3] In-Reply-To: References: Message-ID: > Javap ignores --system option when searching for JDK classes. > This patch prepends search over JDK system modules. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: applied suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16476/files - new: https://git.openjdk.org/jdk/pull/16476/files/78dc9840..1141201d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=01-02 Stats: 12 lines in 1 file changed: 4 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16476/head:pull/16476 PR: https://git.openjdk.org/jdk/pull/16476 From asotona at openjdk.org Fri Nov 10 08:38:12 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Nov 2023 08:38:12 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v2] In-Reply-To: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> References: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> Message-ID: On Fri, 10 Nov 2023 07:25:45 GMT, Jan Lahoda wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> Skip search over JDK modules for classes in unnamed package (mainly to skip JDK module-infos) > > src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 28: > >> 26: package com.sun.tools.javap; >> 27: >> 28: import com.sun.tools.javac.file.Locations; > > Nit: seems unused. Removed, thanks. > src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 864: > >> 862: fo = fileManager.getJavaFileForInput(moduleLocation, className, JavaFileObject.Kind.CLASS); >> 863: } else { >> 864: if (className.indexOf('.') > 0) try { > > I would put the try into a block - it is slightly longer, but much clear, I think. Fixed, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16476#discussion_r1389076255 PR Review Comment: https://git.openjdk.org/jdk/pull/16476#discussion_r1389076418 From asotona at openjdk.org Fri Nov 10 08:41:58 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Nov 2023 08:41:58 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v2] In-Reply-To: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> References: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> Message-ID: On Fri, 10 Nov 2023 07:28:30 GMT, Jan Lahoda wrote: > Is there a chance for a jtreg test? Unfortunately I haven't found a simple way to include a different JDK as `--system` for the test. Any suggestions are welcome. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16476#issuecomment-1805312908 From jlahoda at openjdk.org Fri Nov 10 13:36:11 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 10 Nov 2023 13:36:11 GMT Subject: RFR: 8308399: Recommend --release when -source and -target are misused Message-ID: This patch modifies some warning and error messages to recommend `--release` more loudly. Please see details below. Note that while the patch changes `compiler.warn.source.target.conflict` to `compiler.err.source.target.conflict`, there is no change in the set of accepted options and their combinations. This used to behave as an error, and still behaves as an error. So this patch only changes the console text from `warning: ...` to `error: ...`. + javac -source 8 /tmp/Test.java warning: [options] bootstrap class path is not set in conjunction with -source 8 not setting the bootstrap class path may lead to class files that cannot run on JDK 8 --release 8 is recommended instead of -source 8 because it sets the bootstrap class path automatically warning: [options] source value 8 is obsolete and will be removed in a future release warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. 3 warnings + javac -source 8 -target 8 /tmp/Test.java warning: [options] bootstrap class path is not set in conjunction with -source 8 not setting the bootstrap class path may lead to class files that cannot run on JDK 8 --release 8 is recommended instead of -source 8 -target 8 because it sets the bootstrap class path automatically warning: [options] source value 8 is obsolete and will be removed in a future release warning: [options] target value 8 is obsolete and will be removed in a future release warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. 4 warnings + javac -source 11 /tmp/Test.java warning: [options] location of system modules is not set in conjunction with -source 11 not setting the location of system modules may lead to class files that cannot run on JDK 11 --release 11 is recommended instead of -source 11 because it sets the location of system modules automatically 1 warning + javac -source 11 -target 11 /tmp/Test.java warning: [options] location of system modules is not set in conjunction with -source 11 not setting the location of system modules may lead to class files that cannot run on JDK 11 --release 11 is recommended instead of -source 11 -target 11 because it sets the location of system modules automatically 1 warning + javac -target 17 -source 11 /tmp/Test.java warning: [options] location of system modules is not set in conjunction with -source 11 not setting the location of system modules may lead to class files that cannot run on JDK 11 --release 11 is recommended instead of -source 11 -target 17 because it sets the location of system modules automatically 1 warning + javac -target 8 -source 11 /tmp/Test.java error: specified target release 8 is too old for the specified source release 11 --release 8 is recommended when compiling code to run on JDK 8 + javac -target 8 /tmp/Test.java error: specified target release 8 is too old for the default source release 22 --release 8 is recommended when compiling code to run on JDK 8 ------------- Commit messages: - Fixing test. - Fixing tests. - 8308399: Recommend --release when -source and -target are misused Changes: https://git.openjdk.org/jdk/pull/16612/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16612&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308399 Stats: 128 lines in 23 files changed: 73 ins; 9 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/16612.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16612/head:pull/16612 PR: https://git.openjdk.org/jdk/pull/16612 From cushon at openjdk.org Fri Nov 10 18:29:19 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 10 Nov 2023 18:29:19 GMT Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods [v2] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 04:58:16 GMT, Joe Darcy wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Update visitor; all langtools regression tests pass. >> - Merge branch 'master' into JDK-8042981 >> - JDK-8042981: Strip type annotations in Types' utility methods > > Still keep-alive. @jddarcy I had another look at this prompted by your comment in https://github.com/openjdk/jdk/pull/16578#issuecomment-1805032818, and I have a theory about why `stripMetadata()` isn't working reliably. `stripMetadata()` uses `typeNoMetadata()` to remove the metadata, which is implemented by using `baseType()` to get the original type before metadata was added. That works if all logic that adds metadata uses `cloneWithMetadata`, which creates a subclass that overrides `baseType()` to return the original type without metadata: https://github.com/openjdk/jdk/blob/c9077b8b816d2efe4559c71341228a8dc319604f/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#L748-L751 However there are a few places metadata is annotated to newly constructed type directly, and `baseType()` isn't overridden to return an unannotated type. I was able to enable the disables test cases in this PR and get them passing by debugging for locations where a `Type` is constructed and `baseType()` has non-empty metadata, and then modifying the locations where those types were constructed to set up `baseType()` correctly. I pushed the demo to a branch: https://github.com/cushon/jdk/commit/5910db7e42da8e67e703accfa8adbdb00ce429db That isn't a proposal for a complete fix, but I think it illustrates what the problem is. There are other places types are constructed that don't set up `baseType()`. This makes me suspicious that the other uses of `baseType()` may not be working as expected. I think that perhaps a better fix is to use a different approach for removing annotations from types in `Types` utility methods, which doesn't rely on the fragile association between types and an unannotated base type. The tests also pass with the following implementation: public Type stripMetadata2() { return accept(stripMetadata2, null); } private static final TypeMapping stripMetadata2 = new StructuralTypeMapping<>() { @Override public Type visitClassType(ClassType t, Void aVoid) { return super.visitClassType((ClassType)dropAnnotations(t), aVoid); } @Override public Type visitArrayType(ArrayType t, Void aVoid) { return super.visitArrayType((ArrayType)dropAnnotations(t), aVoid); } @Override public Type visitWildcardType(WildcardType wt, Void aVoid) { return super.visitWildcardType((WildcardType) dropAnnotations(wt), aVoid); } @Override public Type visitType(Type t, Void aVoid) { return dropAnnotations(t); } private static Type dropAnnotations(Type t) { return t.getMetadata(Annotations.class) != null ? t.dropMetadata(Annotations.class) : t; } }; ------------- PR Comment: https://git.openjdk.org/jdk/pull/8984#issuecomment-1806211798 From cushon at openjdk.org Fri Nov 10 18:41:56 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 10 Nov 2023 18:41:56 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 03:49:47 GMT, Joe Darcy wrote: > > I guess your patch have uncovered a bug in stripMetadata > > FYI, in case it is relevant here, I ran into some (still unresolved AFAIK) issues in stripMeta data during work on JDK-8042981: "Strip type annotations in Types' utility methods", including type annotations not being stripped for primitive types. Thanks! I had another look at that and left a comment in the PR: https://github.com/openjdk/jdk/pull/8984#issuecomment-1806211798 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16578#issuecomment-1806238317 From jlaskey at openjdk.org Fri Nov 10 20:00:28 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 10 Nov 2023 20:00:28 GMT Subject: RFR: JDK-8315458 JEP 463: Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v16] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with five additional commits since the last revision: - Simplified and compatible main method finding - Update LauncherHelper.java - Update tests - Misspelling - Clean up exception checks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/d3581d89..1bf935f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=14-15 Stats: 232 lines in 8 files changed: 99 ins; 102 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Fri Nov 10 20:48:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 10 Nov 2023 20:48:12 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v16] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 20:00:28 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with five additional commits since the last revision: > > - Simplified and compatible main method finding > - Update LauncherHelper.java > - Update tests > - Misspelling > - Clean up exception checks Hold off reviewing until I get things cleaned up - I accidentally pushed some experimental code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1806408880 From jlaskey at openjdk.org Sat Nov 11 15:53:41 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sat, 11 Nov 2023 15:53:41 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v17] In-Reply-To: References: Message-ID: <0LKNN6Pviv2PzMqRC_6ue3l989oNTOUQpPk3O-Ue9oM=.f07734f7-b94f-4dbf-baa5-b8b96d4e8c57@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Clean up previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/1bf935f4..abf48816 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=15-16 Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Sat Nov 11 16:00:37 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sat, 11 Nov 2023 16:00:37 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v18] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Reinstate test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/abf48816..dd6703e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Sat Nov 11 16:00:37 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sat, 11 Nov 2023 16:00:37 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v17] In-Reply-To: <0LKNN6Pviv2PzMqRC_6ue3l989oNTOUQpPk3O-Ue9oM=.f07734f7-b94f-4dbf-baa5-b8b96d4e8c57@github.com> References: <0LKNN6Pviv2PzMqRC_6ue3l989oNTOUQpPk3O-Ue9oM=.f07734f7-b94f-4dbf-baa5-b8b96d4e8c57@github.com> Message-ID: On Sat, 11 Nov 2023 15:53:41 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Clean up previous commit Things should be fine now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1806851245 From aturbanov at openjdk.org Mon Nov 13 12:52:03 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 13 Nov 2023 12:52:03 GMT Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code Programs [v5] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 15:45:05 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 ?: Implicitly Declared Classes and Instance Main Method (2nd 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 two additional commits since the last revision: > > - Refine lookup of valid application classes > - Address module graph related review comments src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 225: > 223: try { > 224: actualClass = Class.forName(actualName, false, firstClass.getClassLoader()); > 225: } catch (ClassNotFoundException ignore) { Suggestion: } catch (ClassNotFoundException ignore) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1391074179 From vromero at openjdk.org Mon Nov 13 17:14:14 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 13 Nov 2023 17:14:14 GMT Subject: RFR: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled [v7] In-Reply-To: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> Message-ID: > This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion is being thrown for a special, corner-ish, case. Basically having: > > package p; > @Deprecated class T {} // see that class T is annotated > > and: > > package p; > class Y { > @interface A {} > @interface A {} // error: class A is already defined > T t; > } > > class `Y` has a duplicate definition of annotation `A`. Now if class `T` is compiled first as in: > > `javac -d out/ p/T.java` > > and then we do: > `javac -processor P -cp p:out/:. p/Y.java p/T.java` > > where P is the simplest possible annotation processor, basically doing nothing. IMO what is happening here is that during the second compilation, once the compiler find type `T` in class `Y`, given that T.class is in the classpath, it is loaded and the `@Deprecated` annotation is attached to symbol for type `T`. Then when the source for `T.java` is being compiled and its annotations are being processed we get to the code where the assertion is. Here the symbol for `T` is not a package but its metadata is not empty and so the assertion is thrown. The fix here is just removing the assertion as as shown by this example it is not an invariant. > > TIA Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' into JDK-8191460 - Merge pull request #3 from lahodaj/JDK-8191460 Fixing build. - Fixing build. - Merge branch 'master' into JDK-8191460 - Merge branch 'master' into JDK-8191460 - Merge pull request #2 from lahodaj/JDK-8191460 Attempting to improve the fix. - Attempting to improve the fix. - merge with remote branch - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled ------------- Changes: https://git.openjdk.org/jdk/pull/16443/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16443&range=06 Stats: 184 lines in 2 files changed: 180 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16443/head:pull/16443 PR: https://git.openjdk.org/jdk/pull/16443 From jlaskey at openjdk.org Tue Nov 14 13:35:46 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 14 Nov 2023 13:35:46 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Filter abstract main methods and search interfaces for default main methods. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/dd6703e7..701ba84a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=17-18 Stats: 65 lines in 1 file changed: 48 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From asotona at openjdk.org Tue Nov 14 14:19:31 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 14 Nov 2023 14:19:31 GMT Subject: RFR: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled [v7] In-Reply-To: References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> Message-ID: On Mon, 13 Nov 2023 17:14:14 GMT, Vicente Romero wrote: >> This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion is being thrown for a special, corner-ish, case. Basically having: >> >> package p; >> @Deprecated class T {} // see that class T is annotated >> >> and: >> >> package p; >> class Y { >> @interface A {} >> @interface A {} // error: class A is already defined >> T t; >> } >> >> class `Y` has a duplicate definition of annotation `A`. Now if class `T` is compiled first as in: >> >> `javac -d out/ p/T.java` >> >> and then we do: >> `javac -processor P -cp p:out/:. p/Y.java p/T.java` >> >> where P is the simplest possible annotation processor, basically doing nothing. IMO what is happening here is that during the second compilation, once the compiler find type `T` in class `Y`, given that T.class is in the classpath, it is loaded and the `@Deprecated` annotation is attached to symbol for type `T`. Then when the source for `T.java` is being compiled and its annotations are being processed we get to the code where the assertion is. Here the symbol for `T` is not a package but its metadata is not empty and so the assertion is thrown. The fix here is just removing the assertion as as shown by this example it is not an invariant. >> >> TIA > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' into JDK-8191460 > - Merge pull request #3 from lahodaj/JDK-8191460 > > Fixing build. > - Fixing build. > - Merge branch 'master' into JDK-8191460 > - Merge branch 'master' into JDK-8191460 > - Merge pull request #2 from lahodaj/JDK-8191460 > > Attempting to improve the fix. > - Attempting to improve the fix. > - merge with remote branch > - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled > - 8191460: crash in Annotate with duplicate declaration and annotation processing enabled Looks good. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16443#pullrequestreview-1729838692 From vromero at openjdk.org Tue Nov 14 15:20:46 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 14 Nov 2023 15:20:46 GMT Subject: Integrated: 8191460: crash in Annotate with duplicate declaration and annotation processing enabled In-Reply-To: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> References: <7G5mBpPc99cyEHu9eFgnbJVXno2El20aM9F1YAc6VFI=.9996ba6c-e2e1-4368-932f-3624528a8f40@github.com> Message-ID: On Wed, 1 Nov 2023 04:45:36 GMT, Vicente Romero wrote: > This PR is removing an assertion in `com.sun.tools.javac.comp.Annotate`. The assertion is being thrown for a special, corner-ish, case. Basically having: > > package p; > @Deprecated class T {} // see that class T is annotated > > and: > > package p; > class Y { > @interface A {} > @interface A {} // error: class A is already defined > T t; > } > > class `Y` has a duplicate definition of annotation `A`. Now if class `T` is compiled first as in: > > `javac -d out/ p/T.java` > > and then we do: > `javac -processor P -cp p:out/:. p/Y.java p/T.java` > > where P is the simplest possible annotation processor, basically doing nothing. IMO what is happening here is that during the second compilation, once the compiler find type `T` in class `Y`, given that T.class is in the classpath, it is loaded and the `@Deprecated` annotation is attached to symbol for type `T`. Then when the source for `T.java` is being compiled and its annotations are being processed we get to the code where the assertion is. Here the symbol for `T` is not a package but its metadata is not empty and so the assertion is thrown. The fix here is just removing the assertion as as shown by this example it is not an invariant. > > TIA This pull request has now been integrated. Changeset: a75b6e56 Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/a75b6e569fe5f8e98326940f541423ac39b204a3 Stats: 184 lines in 2 files changed: 180 ins; 0 del; 4 mod 8191460: crash in Annotate with duplicate declaration and annotation processing enabled Co-authored-by: Jan Lahoda Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/16443 From cushon at openjdk.org Tue Nov 14 17:41:41 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 14 Nov 2023 17:41:41 GMT Subject: Integrated: 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 18:01:20 GMT, Liam Miller-Cushon wrote: > Hello, > > Please consider this fix for [JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode](https://bugs.openjdk.org/browse/JDK-8319196). > > As discussed in [the accompanying CSR](https://bugs.openjdk.org/browse/JDK-8319330), `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently returns `NoType` unless the receiver parameter syntax was present in source, which also means that `getReceiverType()` doesn't work for methods loaded from class files. > > This change updates the implementation to check if type annotations are present on the receiver type of a method read from bytecode, and fill in the receiver type of that method to host the type annotations. This pull request has now been integrated. Changeset: 346dbd6d Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/346dbd6d1c1ac24da374dcdf4f432c0adf68efeb Stats: 108 lines in 4 files changed: 79 ins; 14 del; 15 mod 8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/16482 From jjg at openjdk.org Tue Nov 14 22:50:51 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 14 Nov 2023 22:50:51 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v3] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Improve handling of embedded inline taglets ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/ea9c1614..ec7445d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=01-02 Stats: 424 lines in 12 files changed: 393 ins; 0 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From jjg at openjdk.org Tue Nov 14 23:24:16 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 14 Nov 2023 23:24:16 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v4] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/ec7445d2..843cc278 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=02-03 Stats: 11 lines in 1 file changed: 0 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From jjg at openjdk.org Tue Nov 14 23:26:35 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 14 Nov 2023 23:26:35 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v4] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 10:31:14 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespace > > test/langtools/tools/javac/doctree/MDPrinter.java line 67: > >> 65: * Conceptually based on javac's {@code DPrinter}. >> 66: */ >> 67: public class MDPrinter { > > While DPrinter is used, MDPrinter isn't. (At least, I could't find any usages of it.) If you feel like MDPrinter is important, we should at least add a compile test for it, to protect it from bitrot. ? > test/langtools/tools/javac/lexer/CommentTest.java line 24: > >> 22: */ >> 23: >> 24: /** > > Suggestion: > > /* > > Otherwise, some IDEs confuse this jtreg comment for a javadoc comment. ? > test/langtools/tools/javac/lexer/CommentTest.java line 37: > >> 35: import java.util.Objects; >> 36: >> 37: import com.sun.tools.javac.parser.JavadocTokenizer; > > Unused import: > Suggestion: ? > test/langtools/tools/javac/lexer/CommentTest.java line 73: > >> 71: >> 72: /** >> 73: * Whitespace before the commennt is completely ignored. > > Typo: > Suggestion: > > * Whitespace before the comment is completely ignored. ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393430926 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393432411 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393432778 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393433550 From jjg at openjdk.org Wed Nov 15 00:12:31 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Nov 2023 00:12:31 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v4] In-Reply-To: References: Message-ID: <0ZVcM3Dh7buB7gX0Fznz29_x1I6gWJjPsao2vxVOuus=.49fe643e-a1e1-45c4-a7b5-6161721a1649@github.com> On Wed, 8 Nov 2023 10:59:58 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespace > > test/langtools/tools/javac/doctree/FirstSentenceTest.java line 423: > >> 421: DocComment[DOC_COMMENT, pos:0 >> 422: firstSentence: 1 >> 423: RawText[MARKDOWN, pos:0, abc.|def.] > > It took me a while to understand why this test expects the first sentence to include the second line: > > ///abc. > ///def. > void simpleMarkdown() { } > > It's not because it's Markdown or the new `///` comment syntax. It's because the breakiterator thinks that `abc.\ndef.` is one sentence. > > Now, in this same file, on [line 123](https://github.com/openjdk/jdk/blob/128363bf3b57dfa05b3807271b47851733c1afb9/test/langtools/tools/javac/doctree/FirstSentenceTest.java#L119-L142), there's this test: > > /** > * abc def ghi. > * jkl mno pqr > */ > void dot_newline() { } > > If you compare its expectation to that of simpleMarkdown(), you'll see that the first sentence consists of the first line only: > > BREAK_ITERATOR > DocComment[DOC_COMMENT, pos:1 > firstSentence: 1 > Text[TEXT, pos:1, abc_def_ghi.] > body: 1 > Text[TEXT, pos:15, jkl_mno_pqr] > block tags: empty > ] > > So, why does it seem to work differently for `///` and `/** */` comments? It turns out that a whitespace character immediately after newline is important for breakiterator to do its thing: > ``` > ? abc def ghi.\n jkl mno pqr > ? ^ > > The problem with the simpleMarkdown test is that we cannot just indent the comment. That indentation will be deemed incidental whitespace and, thus, will removed. For example, suppose we do this: > > /// abc. > /// def. > void simpleMarkdown() { } > > The breakiterator will still see `abc.\ndef.`. Of course, we could do this: > > ///abc. > /// def. > void simpleMarkdown() { } > > But it would be a different comment. > > There's another test in this PR, [TestMarkdown.testFirstSentence](https://github.com/openjdk/jdk/blob/128363bf3b57dfa05b3807271b47851733c1afb9/test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdown.java#L68-L83). There, the first sentence consists only of the first line. This is likely because the second line starts with a capital letter. Good and interesting catch. As a general matter, there are two scenarios to consider: using a system-provided `BreakIterator` and using the fallback "simple iterator" in DocTreeMaker.getSentenceBreak. The latter is just a period followed by a single whitespace, or a paragraph break if there is no period. The system-provided `BreakIterator` is locale specific. I cannot easily find a public spec of the sentence breaker for the US locale, but experiments indicate it wants one of * period, single whitespace, uppercase letter * period, multiple whitespace Arguably, the test is lazy/broken for using all lower case, which is an atypical form for sentences and use of a sentence breaker. I'll modify at least the new parts of the test (using Markdown comments.). We can separately decide whether to likewise modify the original parts (using traditional comments) or whether to do that as a separate `noreg-self` bug fix for this test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393466027 From jjg at openjdk.org Wed Nov 15 00:26:39 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Nov 2023 00:26:39 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v4] In-Reply-To: References: Message-ID: <0Xdi3qFcxeEQnEZs8Q393_unbH7679dhaxuKTGViUhA=.36dc71a2-6b38-4ef1-96ae-b0931dfd94c4@github.com> On Wed, 8 Nov 2023 17:24:46 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespace > > test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 37: > >> 35: >> 36: import java.nio.file.Path; >> 37: import java.util.ArrayList; > > Import in unused: > Suggestion: ? > test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 61: > >> 59: } >> 60: >> 61: ToolBox tb = new ToolBox(); > > Suggestion: > > private final ToolBox tb = new ToolBox(); Yeah, I tend to be lax about modifiers in test code. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393475716 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393475034 From jjg at openjdk.org Wed Nov 15 00:26:41 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Nov 2023 00:26:41 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v4] In-Reply-To: <0ZVcM3Dh7buB7gX0Fznz29_x1I6gWJjPsao2vxVOuus=.49fe643e-a1e1-45c4-a7b5-6161721a1649@github.com> References: <0ZVcM3Dh7buB7gX0Fznz29_x1I6gWJjPsao2vxVOuus=.49fe643e-a1e1-45c4-a7b5-6161721a1649@github.com> Message-ID: On Wed, 15 Nov 2023 00:09:17 GMT, Jonathan Gibbons wrote: >> test/langtools/tools/javac/doctree/FirstSentenceTest.java line 423: >> >>> 421: DocComment[DOC_COMMENT, pos:0 >>> 422: firstSentence: 1 >>> 423: RawText[MARKDOWN, pos:0, abc.|def.] >> >> It took me a while to understand why this test expects the first sentence to include the second line: >> >> ///abc. >> ///def. >> void simpleMarkdown() { } >> >> It's not because it's Markdown or the new `///` comment syntax. It's because the breakiterator thinks that `abc.\ndef.` is one sentence. >> >> Now, in this same file, on [line 123](https://github.com/openjdk/jdk/blob/128363bf3b57dfa05b3807271b47851733c1afb9/test/langtools/tools/javac/doctree/FirstSentenceTest.java#L119-L142), there's this test: >> >> /** >> * abc def ghi. >> * jkl mno pqr >> */ >> void dot_newline() { } >> >> If you compare its expectation to that of simpleMarkdown(), you'll see that the first sentence consists of the first line only: >> >> BREAK_ITERATOR >> DocComment[DOC_COMMENT, pos:1 >> firstSentence: 1 >> Text[TEXT, pos:1, abc_def_ghi.] >> body: 1 >> Text[TEXT, pos:15, jkl_mno_pqr] >> block tags: empty >> ] >> >> So, why does it seem to work differently for `///` and `/** */` comments? It turns out that a whitespace character immediately after newline is important for breakiterator to do its thing: >> ``` >> ? abc def ghi.\n jkl mno pqr >> ? ^ >> >> The problem with the simpleMarkdown test is that we cannot just indent the comment. That indentation will be deemed incidental whitespace and, thus, will removed. For example, suppose we do this: >> >> /// abc. >> /// def. >> void simpleMarkdown() { } >> >> The breakiterator will still see `abc.\ndef.`. Of course, we could do this: >> >> ///abc. >> /// def. >> void simpleMarkdown() { } >> >> But it would be a different comment. >> >> There's another test in this PR, [TestMarkdown.testFirstSentence](https://github.com/openjdk/jdk/blob/128363bf3b57dfa05b3807271b47851733c1afb9/test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdown.java#L68-L83). There, the first sentence consists only of the first line. This is likely because the second line starts with a capital letter. > > Good and interesting catch. > > As a general matter, there are two scenarios to consider: using a system-provided `BreakIterator` and using the fallback "simple iterator" in DocTreeMaker.getSentenceBreak. > > The latter is just a period followed by a single whitespace, or a paragraph break if there is no period. > > The system-provided `BreakIterator` is locale specific. I cannot easily find a public spec of the sentence breaker for the US locale, but experiments indicate it wants one of > > * period, single whitespace, uppercase letter > * period, multiple whitespace > > Arguably, the test is lazy/broken for using all lower case, which is an atypical form for sentences and use of a sentence breaker. I'll modify at least the new parts of the test (using Markdown comments.). We can separately decide whether to likewise modify the original parts (using traditional comments) or whether to do that as a separate `noreg-self` bug fix for this test. After modifying the test to capitalize the pseudo-sentences, the test again passes, and the output with the break iterator is now the same as the default simple iterator. Yay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393474011 From jjg at openjdk.org Wed Nov 15 00:33:33 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Nov 2023 00:33:33 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v4] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:28:10 GMT, Pavel Rappo wrote: >> test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 64: >> >>> 62: >>> 63: @Test >>> 64: public void testFindStandardTransformer_raw() throws Exception { >> >> Checked exceptions are not thrown: >> Suggestion: >> >> public void testFindStandardTransformer_raw() { > > I might be mistaken, but this and the testFindStandardTransformer_stream methods look like we are testing ServiceLoader API. I would leave just the stream version. While these are weak tests, since they exercise different code patterns for access the standard transformer, such as may subsequently be included in any documentation. I would prefer to leave both tests in place. I have removed the unnecessary `throws` clauses. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393480117 From jjg at openjdk.org Wed Nov 15 00:33:36 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Nov 2023 00:33:36 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v4] In-Reply-To: References: Message-ID: <5LmN58g4_56xYuRsehl-rCjb09n3YO8snUPTjsJeU9k=.41ef3b1f-f276-419f-90b5-9b6043c057d8@github.com> On Wed, 8 Nov 2023 17:28:48 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespace > > test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 82: > >> 80: >> 81: @Test >> 82: public void testFindStandardTransformer_stream() throws Exception { > > Checked exceptions are not thrown here too: > Suggestion: > > public void testFindStandardTransformer_stream() { ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393480360 From jjg at openjdk.org Wed Nov 15 00:39:32 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Nov 2023 00:39:32 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v4] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:37:25 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespace > > test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 96: > >> 94: var sl = ServiceLoader.load(DocTrees.DocCommentTreeTransformer.class); >> 95: return StreamSupport.stream(sl.spliterator(), false) >> 96: .filter(p -> p.name().equals(name)) > > ServiceLoader specification suggests another way of streaming: > Suggestion: > > return sl.stream() > .map(ServiceLoader.Provider::get) > .filter(t -> t.name().equals(name)) > > Would it be the same and more readable? Hmm. It's longer, but arguably simpler to comprehend than using a spliterator. I've changed the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393484918 From jjg at openjdk.org Wed Nov 15 01:01:31 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Nov 2023 01:01:31 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 16:39:58 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Customize support for Markdown headings > > test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdown.java line 613: > >> 611: /// Lorem ipsum. >> 612: /// >> 613: /// ## ATX-style subheading for executable > > Can we use Markdown headings inside block tags, such as `@apiNote`? If so, should they start from h5? If so, should we get a warning if they "overflow" h6? Hmm. teeny-tiny "yes", dominated by a big "BUT". There is no easy simple direct support for Markdown in user-defined taglets, since there is no way to know the syntactic form of user-defined tags. We might be able to do something for user-defined tags given on the command line (with `-tag`) but in general we should be wary and think carefully about putting any headings inside any block tag, because block tags get converted to HTML definition lists. --- Separately, generally speaking, the Markdown headings in any doc comment should start at level 1 and increase from there. An offset will be added during translation to give the correct heading level in the overall page. There is a guard in the code (but no warning as yet) if you "overflow" heading level 6. For example, if you go overboard and use `#### my heading` in the comment for a method (where the offset for headings is 3), it will (currently) max out at level 6. Generating warnings for questionable Markdown is somewhat against the spirit of Markdown. It would seem a bit weird to warn against an obscure case like overflowing headings when the general policy for real errors is no message and just show the literal text. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1393499177 From vromero at openjdk.org Wed Nov 15 04:28:35 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 15 Nov 2023 04:28:35 GMT Subject: RFR: 8319987: compilation of sealed classes leads to infinite recursion Message-ID: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com> The compiler can throw a SOE when trying to compile an incorrect sealed classes hierarchy like: sealed interface Action permits Add {} sealed interface MathOp permits Add {} sealed static class Add implements MathOp permits Add {} The error is thrown while trying to prove if two classes are disjoint or not. The proposed solution is to keep a set with the pairs of classes analyzed so far and stop as soon as a the current pair of classes is already in the set. TIA ------------- Commit messages: - 8319987: compilation of sealed classes leads to infinite recursion Changes: https://git.openjdk.org/jdk/pull/16668/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16668&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319987 Stats: 58 lines in 3 files changed: 33 ins; 6 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/16668.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16668/head:pull/16668 PR: https://git.openjdk.org/jdk/pull/16668 From acobbs at openjdk.org Wed Nov 15 15:29:34 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 15 Nov 2023 15:29:34 GMT Subject: RFR: 8319987: compilation of sealed classes leads to infinite recursion In-Reply-To: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com> References: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com> Message-ID: On Wed, 15 Nov 2023 04:22:15 GMT, Vicente Romero wrote: > The compiler can throw a SOE when trying to compile an incorrect sealed classes hierarchy like: > > sealed interface Action permits Add {} > sealed interface MathOp permits Add {} > sealed static class Add implements MathOp permits Add {} > > The error is thrown while trying to prove if two classes are disjoint or not. The proposed solution is to keep a set with the pairs of classes analyzed so far and stop as soon as a the current pair of classes is already in the set. > > TIA src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1684: > 1682: } else { > 1683: pairsSeen.add(newPair); > 1684: } Minor simplification possible here: if (!pairsSeen.add(newPair)) return; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16668#discussion_r1394366621 From prappo at openjdk.org Wed Nov 15 15:43:55 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 15 Nov 2023 15:43:55 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v17] In-Reply-To: References: <0LKNN6Pviv2PzMqRC_6ue3l989oNTOUQpPk3O-Ue9oM=.f07734f7-b94f-4dbf-baa5-b8b96d4e8c57@github.com> Message-ID: <-9vMMWxs2cxsB4xoK1g37hZkdIaLWe30KsVssp1mgGU=.7680c892-9645-4c45-b511-52f02de42b3d@github.com> On Sat, 11 Nov 2023 15:57:40 GMT, Jim Laskey wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Clean up previous commit > > Things should be fine now. @JimLaskey, I read JEP 463 but couldn't find any statements on access level of an implicit class. `javap` shows that such a class has package access (as I assume it should). Here's the most relevant find in JEP, but it's not about the class. It's about class' members: > An implicit class is almost exactly like an explicitly declared class. Its members can have the same modifiers (e.g., private and static) and the modifiers have the same defaults (e.g., package access and instance membership). One key difference is that while an implicit class has a default zero-parameter constructor, it can have no other constructor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1812771590 From vromero at openjdk.org Wed Nov 15 15:45:35 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 15 Nov 2023 15:45:35 GMT Subject: RFR: 8319987: compilation of sealed classes leads to infinite recursion In-Reply-To: References: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com> Message-ID: <9jPTQJcLsVDxf_kb4qLdScSvp0S5hfUD2IFxU6xQl84=.bd89cffa-c13d-4842-931e-2230e807f715@github.com> On Wed, 15 Nov 2023 15:26:42 GMT, Archie Cobbs wrote: >> The compiler can throw a SOE when trying to compile an incorrect sealed classes hierarchy like: >> >> sealed interface Action permits Add {} >> sealed interface MathOp permits Add {} >> sealed static class Add implements MathOp permits Add {} >> >> The error is thrown while trying to prove if two classes are disjoint or not. The proposed solution is to keep a set with the pairs of classes analyzed so far and stop as soon as a the current pair of classes is already in the set. >> >> TIA > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1684: > >> 1682: } else { >> 1683: pairsSeen.add(newPair); >> 1684: } > > Minor simplification possible here: > > if (!pairsSeen.add(newPair)) > return; sure I like it thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16668#discussion_r1394390842 From jlaskey at openjdk.org Wed Nov 15 15:57:49 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 15 Nov 2023 15:57:49 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: References: Message-ID: On Tue, 14 Nov 2023 13:35:46 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Filter abstract main methods and search interfaces for default main methods. Look at the spec https://bugs.openjdk.org/browse/JDK-8319252 under 7.3 Compilation Units. - It is not abstract (8.1.1.1 ?). - It is final (8.1.1.2 ?). - It is a member of an unnamed package (7.4.2 ?) and **has package access**. Its direct superclass is Object (8.1.4 ?). - It does not have any direct superinterfaces (8.1.5 ?). - The body of the class contains every ClassMemberDeclaration (these are declarations of fields (8.3 ?), methods (8.4 ?), member classes (8.5 ?), and member interfaces (9.1.1.3 ?)) from the simple compilation unit. It is not possible for a simple compilation unit to declare an instance initializer (8.6 ?), static initializer (8.7 ?), or constructor (8.8 ?). -It has an implicitly declared default constructor (8.8.9 ?). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1812796001 From vromero at openjdk.org Wed Nov 15 16:11:45 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 15 Nov 2023 16:11:45 GMT Subject: RFR: 8319987: compilation of sealed classes leads to infinite recursion [v2] In-Reply-To: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com> References: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com> Message-ID: <0SHZ9MP38mDLOuTnuv7823MsGrf1sTdTRsvmAtK0Gt0=.3da9016b-602d-40a3-b351-29130811b3a9@github.com> > The compiler can throw a SOE when trying to compile an incorrect sealed classes hierarchy like: > > sealed interface Action permits Add {} > sealed interface MathOp permits Add {} > sealed static class Add implements MathOp permits Add {} > > The error is thrown while trying to prove if two classes are disjoint or not. The proposed solution is to keep a set with the pairs of classes analyzed so far and stop as soon as a the current pair of classes is already in the set. > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16668/files - new: https://git.openjdk.org/jdk/pull/16668/files/3de50c63..b6ff0235 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16668&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16668&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16668.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16668/head:pull/16668 PR: https://git.openjdk.org/jdk/pull/16668 From jjg at openjdk.org Wed Nov 15 18:58:43 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Nov 2023 18:58:43 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v5] In-Reply-To: References: Message-ID: <5D_gyGHDR52UTLCcFnUNSWYXjYgcy3jYnffOXZ70xsg=.e1389d08-c9ae-481f-9c53-1ccd1e389102@github.com> > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons 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/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/843cc278..39cdd2bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=03-04 Stats: 118 lines in 5 files changed: 72 ins; 2 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From jjg at openjdk.org Wed Nov 15 18:58:45 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Nov 2023 18:58:45 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v2] In-Reply-To: References: Message-ID: <0xaWRD1add432FW4NF8dhU3gi3q6BzPbhdnSMWKs2CY=.6ed27293-a889-4802-8e3f-e9f5d0a030e2@github.com> On Wed, 15 Nov 2023 00:58:51 GMT, Jonathan Gibbons wrote: >> test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdown.java line 613: >> >>> 611: /// Lorem ipsum. >>> 612: /// >>> 613: /// ## ATX-style subheading for executable >> >> Can we use Markdown headings inside block tags, such as `@apiNote`? If so, should they start from h5? If so, should we get a warning if they "overflow" h6? > > Hmm. teeny-tiny "yes", dominated by a big "BUT". > > There is no easy simple direct support for Markdown in user-defined taglets, since there is no way to know the syntactic form of user-defined tags. We might be able to do something for user-defined tags given on the command line (with `-tag`) but in general we should be wary and think carefully about putting any headings inside any block tag, because block tags get converted to HTML definition lists. > > --- > > Separately, generally speaking, the Markdown headings in any doc comment should start at level 1 and increase from there. An offset will be added during translation to give the correct heading level in the overall page. There is a guard in the code (but no warning as yet) if you "overflow" heading level 6. For example, if you go overboard and use `#### my heading` in the comment for a method (where the offset for headings is 3), it will (currently) max out at level 6. Generating warnings for questionable Markdown is somewhat against the spirit of Markdown. It would seem a bit weird to warn against an obscure case like overflowing headings when the general policy for real errors is no message and just show the literal text. Update: Markdown in tags defined by the user on the command-line works pretty much as expected: not great, but not bad. Headings in user-defined tags work, but are semantically questionable, since the tags are generated inside a definition list (which itself is maybe questionable, these days.). There is (currently) no special accommodation for the "virtual heading" in the presentation of the block tag. Headings, sections, HTML 5, Markdown and taglets are a complicated mess, and probably better discussed and tracked in JBS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1394643842 From vromero at openjdk.org Thu Nov 16 04:35:44 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 16 Nov 2023 04:35:44 GMT Subject: RFR: 8314621: ClassNotFoundException due to lambda reference to elided anonymous inner class Message-ID: <0cALyQ0wnNwLyNS0J05Gc5PCAzKGb8ZDKe4yx2DhyqQ=.a5ca4134-b7a9-4581-8a8f-ff63bdf1228a@github.com> If code like the one below is executed: class ClassNotFoundExceptionDueToPrunedCodeTest { public static void main(String... args) { var o = false ? new Object() {} : null; Runnable r = () -> { System.out.println(o == o); }; r.run(); } } the runtime throws ClassNotFoundException. What is happening here is that the compiler is doing some "optimizations" basically in this case not generating code for the "true part" of the conditional as it will never be executed. The issue here is that the type of `o` will be the type of the anonymous class pruned by this optimization. Later on `o` is captured by the lambda and thus the exception. The proposed solution here is not to prune dead code if it is defining an anonymous class to avoid similar situations. TIA ------------- Commit messages: - 8314621: ClassNotFoundException due to lambda reference to elided anonymous inner class Changes: https://git.openjdk.org/jdk/pull/16683/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16683&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314621 Stats: 216 lines in 5 files changed: 68 ins; 142 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16683.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16683/head:pull/16683 PR: https://git.openjdk.org/jdk/pull/16683 From jlahoda at openjdk.org Thu Nov 16 11:39:30 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 16 Nov 2023 11:39:30 GMT Subject: RFR: 8319987: compilation of sealed classes leads to infinite recursion [v2] In-Reply-To: <0SHZ9MP38mDLOuTnuv7823MsGrf1sTdTRsvmAtK0Gt0=.3da9016b-602d-40a3-b351-29130811b3a9@github.com> References: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com> <0SHZ9MP38mDLOuTnuv7823MsGrf1sTdTRsvmAtK0Gt0=.3da9016b-602d-40a3-b351-29130811b3a9@github.com> Message-ID: <2oW_cBHsTzdAMrpOaeKYlq36IeQNJ2asZ_QTHEDPnBE=.f7e859f7-010e-4c55-86f8-4ebe8ff2e85b@github.com> On Wed, 15 Nov 2023 16:11:45 GMT, Vicente Romero wrote: >> The compiler can throw a SOE when trying to compile an incorrect sealed classes hierarchy like: >> >> sealed interface Action permits Add {} >> sealed interface MathOp permits Add {} >> sealed static class Add implements MathOp permits Add {} >> >> The error is thrown while trying to prove if two classes are disjoint or not. The proposed solution is to keep a set with the pairs of classes analyzed so far and stop as soon as a the current pair of classes is already in the set. >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16668#pullrequestreview-1734165208 From jlahoda at openjdk.org Thu Nov 16 12:58:52 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 16 Nov 2023 12:58:52 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions [v3] In-Reply-To: References: Message-ID: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Removing TransitiveDependencies, as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16400/files - new: https://git.openjdk.org/jdk/pull/16400/files/f3be97d6..ac8fb43d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16400&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16400&range=01-02 Stats: 123 lines in 1 file changed: 0 ins; 123 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16400/head:pull/16400 PR: https://git.openjdk.org/jdk/pull/16400 From jlaskey at openjdk.org Thu Nov 16 13:28:08 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 16 Nov 2023 13:28:08 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v20] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update comment in Filer.java to include implicitly declared classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/701ba84a..598553f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=18-19 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlahoda at openjdk.org Thu Nov 16 13:48:32 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 16 Nov 2023 13:48:32 GMT Subject: RFR: 8314621: ClassNotFoundException due to lambda reference to elided anonymous inner class In-Reply-To: <0cALyQ0wnNwLyNS0J05Gc5PCAzKGb8ZDKe4yx2DhyqQ=.a5ca4134-b7a9-4581-8a8f-ff63bdf1228a@github.com> References: <0cALyQ0wnNwLyNS0J05Gc5PCAzKGb8ZDKe4yx2DhyqQ=.a5ca4134-b7a9-4581-8a8f-ff63bdf1228a@github.com> Message-ID: On Thu, 16 Nov 2023 04:29:51 GMT, Vicente Romero wrote: > If code like the one below is executed: > > > class ClassNotFoundExceptionDueToPrunedCodeTest { > public static void main(String... args) { > var o = false ? new Object() {} : null; > Runnable r = () -> { > System.out.println(o == o); > }; > r.run(); > } > } > > the runtime throws ClassNotFoundException. What is happening here is that the compiler is doing some "optimizations" basically in this case not generating code for the "true part" of the conditional as it will never be executed. The issue here is that the type of `o` will be the type of the anonymous class pruned by this optimization. Later on `o` is captured by the lambda and thus the exception. The proposed solution here is not to prune dead code if it is defining an anonymous class to avoid similar situations. > TIA Looks OK to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16683#pullrequestreview-1734409564 From vromero at openjdk.org Thu Nov 16 16:44:47 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 16 Nov 2023 16:44:47 GMT Subject: Integrated: 8319987: compilation of sealed classes leads to infinite recursion In-Reply-To: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com> References: <7PpjLF27NqUWZwn_Kjx4S-d2fsGz_RVg_5Xm6EIN5f0=.ddb7f6da-6814-41a4-951d-742c4a9417cf@github.com> Message-ID: <_nzpKIkOsHca9C11ChUmK7sanoOz6l1iGrtFu1QZ0rM=.091b3b15-a379-4ae7-b02a-fbfbac31555f@github.com> On Wed, 15 Nov 2023 04:22:15 GMT, Vicente Romero wrote: > The compiler can throw a SOE when trying to compile an incorrect sealed classes hierarchy like: > > sealed interface Action permits Add {} > sealed interface MathOp permits Add {} > sealed static class Add implements MathOp permits Add {} > > The error is thrown while trying to prove if two classes are disjoint or not. The proposed solution is to keep a set with the pairs of classes analyzed so far and stop as soon as a the current pair of classes is already in the set. > > TIA This pull request has now been integrated. Changeset: 52e2878c Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/52e2878cffd9cb704ad773b841dbab0d17eba896 Stats: 55 lines in 3 files changed: 30 ins; 6 del; 19 mod 8319987: compilation of sealed classes leads to infinite recursion Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/16668 From vromero at openjdk.org Thu Nov 16 16:46:31 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 16 Nov 2023 16:46:31 GMT Subject: RFR: 8314621: ClassNotFoundException due to lambda reference to elided anonymous inner class In-Reply-To: References: <0cALyQ0wnNwLyNS0J05Gc5PCAzKGb8ZDKe4yx2DhyqQ=.a5ca4134-b7a9-4581-8a8f-ff63bdf1228a@github.com> Message-ID: On Thu, 16 Nov 2023 13:46:03 GMT, Jan Lahoda wrote: > Looks OK to me. @lahodaj thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/16683#issuecomment-1814826215 From vromero at openjdk.org Thu Nov 16 16:52:45 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 16 Nov 2023 16:52:45 GMT Subject: Integrated: 8314621: ClassNotFoundException due to lambda reference to elided anonymous inner class In-Reply-To: <0cALyQ0wnNwLyNS0J05Gc5PCAzKGb8ZDKe4yx2DhyqQ=.a5ca4134-b7a9-4581-8a8f-ff63bdf1228a@github.com> References: <0cALyQ0wnNwLyNS0J05Gc5PCAzKGb8ZDKe4yx2DhyqQ=.a5ca4134-b7a9-4581-8a8f-ff63bdf1228a@github.com> Message-ID: On Thu, 16 Nov 2023 04:29:51 GMT, Vicente Romero wrote: > If code like the one below is executed: > > > class ClassNotFoundExceptionDueToPrunedCodeTest { > public static void main(String... args) { > var o = false ? new Object() {} : null; > Runnable r = () -> { > System.out.println(o == o); > }; > r.run(); > } > } > > the runtime throws ClassNotFoundException. What is happening here is that the compiler is doing some "optimizations" basically in this case not generating code for the "true part" of the conditional as it will never be executed. The issue here is that the type of `o` will be the type of the anonymous class pruned by this optimization. Later on `o` is captured by the lambda and thus the exception. The proposed solution here is not to prune dead code if it is defining an anonymous class to avoid similar situations. > TIA This pull request has now been integrated. Changeset: d6aa7c8b Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/d6aa7c8ba0e727356562561d939c4965b69d7817 Stats: 216 lines in 5 files changed: 68 ins; 142 del; 6 mod 8314621: ClassNotFoundException due to lambda reference to elided anonymous inner class Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/16683 From abimpoudis at openjdk.org Thu Nov 16 18:23:02 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 16 Nov 2023 18:23:02 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v30] 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/jep455-20231030/specs/instanceof-jls.html Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: - Merge branch 'master' into primitive-patterns - Small cleanup in PrimitivePatternsSwitch - Add test for instanceof as a pattern on with record patterns - Merge branch 'master' into primitive-patterns # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java - Add tests for new data types in switch statements - Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests - Fix SwitchBootstraps for pattern matching over longs - Merge branch 'master' into primitive-patterns - Improve javadoc of ExactConversionsSupport Co-authored-by: Raffaello Giulietti - Adjust javadoc on ExactConversionsSupport - ... and 26 more: https://git.openjdk.org/jdk/compare/9727f4bd...0a07af94 ------------- Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=29 Stats: 3199 lines in 41 files changed: 2943 ins; 111 del; 145 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 jlaskey at openjdk.org Thu Nov 16 19:09:57 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 16 Nov 2023 19:09:57 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v7] In-Reply-To: References: Message-ID: > Update String Templates for a second preview. With the addition of > > - Expression type and throws are determined from the `process` method of the processor type and not the processor type. > > - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . > > - Raw (generic) process types are no longer an error. Jim Laskey 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: - Merge remote-tracking branch 'upstream/master' into 8315457 - Merge remote-tracking branch 'upstream/master' into 8315457 - Remove preview from JavaLangAccess - Merge remote-tracking branch 'upstream/master' into 8315457 - Cache process method type in JCStringTemplate - Revert source - Revert @since 22 - Accept qualified STR and RAW - String Templates (second preview) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16202/files - new: https://git.openjdk.org/jdk/pull/16202/files/c616f48e..c798e310 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=05-06 Stats: 624014 lines in 1051 files changed: 85405 ins; 477079 del; 61530 mod Patch: https://git.openjdk.org/jdk/pull/16202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202 PR: https://git.openjdk.org/jdk/pull/16202 From jlaskey at openjdk.org Fri Nov 17 12:56:43 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 17 Nov 2023 12:56:43 GMT Subject: Integrated: JDK-8315457 Implement JEP 459: String Templates (Second Preview) In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 13:41:55 GMT, Jim Laskey wrote: > Update String Templates for a second preview. With the addition of > > - Expression type and throws are determined from the `process` method of the processor type and not the processor type. > > - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . > > - Raw (generic) process types are no longer an error. This pull request has now been integrated. Changeset: 9902d2eb Author: Jim Laskey URL: https://git.openjdk.org/jdk/commit/9902d2eb177072c108933056cba544cc5a34bb54 Stats: 69 lines in 16 files changed: 19 ins; 35 del; 15 mod 8315457: Implement JEP 459: String Templates (Second Preview) Reviewed-by: jlahoda, alanb, vromero ------------- PR: https://git.openjdk.org/jdk/pull/16202 From jlaskey at openjdk.org Fri Nov 17 13:56:13 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 17 Nov 2023 13:56:13 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v21] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Allow nested class of same name as file Since it doesn't create a conflicting symbol and would produce a confusing error otherwise. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/598553f8..889f3ecc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=19-20 Stats: 8 lines in 4 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From abimpoudis at openjdk.org Fri Nov 17 23:26:56 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 17 Nov 2023 23:26:56 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v31] 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 37 commits: - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Small cleanup in PrimitivePatternsSwitch - Add test for instanceof as a pattern on with record patterns - Merge branch 'master' into primitive-patterns # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java - Add tests for new data types in switch statements - Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests - Fix SwitchBootstraps for pattern matching over longs - Merge branch 'master' into primitive-patterns - Improve javadoc of ExactConversionsSupport Co-authored-by: Raffaello Giulietti - ... and 27 more: https://git.openjdk.org/jdk/compare/99570fbe...ca7cc2a6 ------------- Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=30 Stats: 3199 lines in 41 files changed: 2943 ins; 111 del; 145 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 jlaskey at openjdk.org Sat Nov 18 15:07:11 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sat, 18 Nov 2023 15:07:11 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v22] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: getMainMethod ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/889f3ecc..75f1e821 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=20-21 Stats: 224 lines in 4 files changed: 55 ins; 155 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Sat Nov 18 19:03:22 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sat, 18 Nov 2023 19:03:22 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v23] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update Class.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/75f1e821..468a20af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=21-22 Stats: 27 lines in 1 file changed: 26 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Sun Nov 19 01:42:10 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sun, 19 Nov 2023 01:42:10 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v24] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Clean up getMainMethod ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/468a20af..90d4d1c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=22-23 Stats: 21 lines in 1 file changed: 5 ins; 3 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Sun Nov 19 15:04:14 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sun, 19 Nov 2023 15:04:14 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v25] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add getMainMethod Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/90d4d1c5..8ef55fdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=23-24 Stats: 120 lines in 1 file changed: 120 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Sun Nov 19 20:14:10 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sun, 19 Nov 2023 20:14:10 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Additional tests for getMainMethod ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/8ef55fdf..27de4fec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=24-25 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From abimpoudis at openjdk.org Mon Nov 20 09:36:25 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 20 Nov 2023 09:36:25 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v32] 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 38 commits: - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Small cleanup in PrimitivePatternsSwitch - Add test for instanceof as a pattern on with record patterns - Merge branch 'master' into primitive-patterns # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java - Add tests for new data types in switch statements - Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests - Fix SwitchBootstraps for pattern matching over longs - Merge branch 'master' into primitive-patterns - ... and 28 more: https://git.openjdk.org/jdk/compare/de51aa19...584a4a30 ------------- Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=31 Stats: 3199 lines in 41 files changed: 2943 ins; 111 del; 145 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 Mon Nov 20 11:58:48 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Nov 2023 11:58:48 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v21] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 11:53:35 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Allow nested class of same name as file >> >> Since it doesn't create a conflicting symbol and would produce a confusing error otherwise. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 464: > >> 462: } >> 463: for (Symbol sym = s.owner; sym != null; sym = sym.owner) { >> 464: if (sym.kind == TYP && sym.name == name && sym.name != names.error && > > Looks good! I recommend adding a test for this (if not already done) - checking cases like: // A.java void m() { } class A {} but also where A is nested deeper: // A.java void m() { } class B { class A { } } And then also check that the test still works for other classes defined in the implicit unit: // A.java void m() { } class B { class B { } //error } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399096324 From mcimadamore at openjdk.org Mon Nov 20 11:58:48 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Nov 2023 11:58:48 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v21] In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 13:56:13 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Allow nested class of same name as file > > Since it doesn't create a conflicting symbol and would produce a confusing error otherwise. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 464: > 462: } > 463: for (Symbol sym = s.owner; sym != null; sym = sym.owner) { > 464: if (sym.kind == TYP && sym.name == name && sym.name != names.error && Looks good! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399091826 From jlaskey at openjdk.org Mon Nov 20 13:45:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 13:45:12 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v27] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Move Implicitly Declared Classes to single directory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/27de4fec..c5992d58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=25-26 Stats: 0 lines in 5 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From alanb at openjdk.org Mon Nov 20 13:53:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Nov 2023 13:53:52 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26] In-Reply-To: References: Message-ID: On Sun, 19 Nov 2023 20:14:10 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Additional tests for getMainMethod src/java.base/share/classes/java/lang/Class.java line 4839: > 4837: @PreviewFeature(feature=PreviewFeature.Feature.IMPLICIT_CLASSES) > 4838: @CallerSensitive > 4839: public Method getMainMethod() { This is a new addition in the last few days. It's somewhat surprising as the launch protocol has never really surfaced in the API, there's nothing to identify the main class for example. I'm in two minds on surfacing this but it does make the java launcher code much simpler. Class.getMethod/getMethods return public methods, the proposed getMainMethod may return a public or non-public method and may walk the class hierarchy. So I'm not sure about the naming, it feels more like a findMainMethod to emphasize the search or just mainMethod. The javadoc probably needs to be fleshed out a bit more to specify how the main method is found. It currently says "be declared this class's hierarchy" (typo) but it has to say more and make it clear that it may return a Method with a declared class that may be a superclass. "(@jls 8.4.2)", I assume that should be "{@jls 8.4.2}". The return description says "the candidate main method". This begs the question if there are other candidates, how do I find them? The SM permission check looks right, it has to be the same as getDeclaredMethod. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399233970 From cstein at openjdk.org Mon Nov 20 13:58:49 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 20 Nov 2023 13:58:49 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 13:50:45 GMT, Alan Bateman wrote: > [...] it does make the java launcher code much simpler. Yes. That's a very nice effect of surfacing the launch protocol directyl in `java.lang.Class` > So I'm not sure about the naming, it feels more like a `findMainMethod` to emphasize the search or just `mainMethod`. +1 for `findMainMethod`, and also an explicit `Optional` as the return type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399240835 From jlaskey at openjdk.org Mon Nov 20 14:47:26 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 14:47:26 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v28] In-Reply-To: References: Message-ID: <7lwdp_OMcqBVy3fCLGHE4ZwpFecsUCGSt_BkSYcRQyM=.49a40270-108b-4376-b2a6-08836690350c@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add nested class test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/c5992d58..5542947a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=26-27 Stats: 109 lines in 1 file changed: 109 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Mon Nov 20 17:17:19 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 17:17:19 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v21] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 11:55:57 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 464: >> >>> 462: } >>> 463: for (Symbol sym = s.owner; sym != null; sym = sym.owner) { >>> 464: if (sym.kind == TYP && sym.name == name && sym.name != names.error && >> >> Looks good! > > I recommend adding a test for this (if not already done) - checking cases like: > > // A.java > void m() { } > class A {} > > > but also where A is nested deeper: > > > // A.java > void m() { } > class B { > class A { } > } > > > And then also check that the test still works for other classes defined in the implicit unit: > > > // A.java > void m() { } > class B { > class B { } //error > } Added ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399513053 From jlahoda at openjdk.org Mon Nov 20 17:20:50 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 20 Nov 2023 17:20:50 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions [v4] In-Reply-To: References: Message-ID: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review comment - removing unnecessary lines. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16400/files - new: https://git.openjdk.org/jdk/pull/16400/files/ac8fb43d..70ab16d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16400&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16400&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16400/head:pull/16400 PR: https://git.openjdk.org/jdk/pull/16400 From jlaskey at openjdk.org Mon Nov 20 18:24:16 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 18:24:16 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v29] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update findMainMethod as requested ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/5542947a..abe35d53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=27-28 Stats: 22 lines in 3 files changed: 8 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Mon Nov 20 18:36:44 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 18:36:44 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 13:56:13 GMT, Christian Stein wrote: >> src/java.base/share/classes/java/lang/Class.java line 4839: >> >>> 4837: @PreviewFeature(feature=PreviewFeature.Feature.IMPLICIT_CLASSES) >>> 4838: @CallerSensitive >>> 4839: public Method getMainMethod() { >> >> This is a new addition in the last few days. It's somewhat surprising as the launch protocol has never really surfaced in the API, there's nothing to identify the main class for example. I'm in two minds on surfacing this but it does make the java launcher code much simpler. >> >> Class.getMethod/getMethods return public methods, the proposed getMainMethod may return a public or non-public method and may walk the class hierarchy. So I'm not sure about the naming, it feels more like a findMainMethod to emphasize the search or just mainMethod. >> >> The javadoc probably needs to be fleshed out a bit more to specify how the main method is found. It currently says "be declared this class's hierarchy" (typo) but it has to say more and make it clear that it may return a Method with a declared class that may be a superclass. >> >> "(@jls 8.4.2)", I assume that should be "{@jls 8.4.2}". >> >> The return description says "the candidate main method". This begs the question if there are other candidates, how do I find them? >> >> The SM permission check looks right, it has to be the same as getDeclaredMethod. > >> [...] it does make the java launcher code much simpler. > > Yes. That's a very nice effect of surfacing the launch protocol directyl in `java.lang.Class` > >> So I'm not sure about the naming, it feels more like a `findMainMethod` to emphasize the search or just `mainMethod`. > > +1 for `findMainMethod`, and also an explicit `Optional` as the return type. > > Or `Optional mainMethod()` similar to [ModuleDescriptor::mainClass](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/module/ModuleDescriptor.html#mainClass()) Updated. Optional is stylizing preference. Since this method is used frequently (almost always) at startup, loading extra classes should probably be avoided. It's not hard to simply `Optional.ofNullable(cls.findMainMethod())`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399597600 From jlahoda at openjdk.org Mon Nov 20 18:58:08 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 20 Nov 2023 18:58:08 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions [v2] In-Reply-To: References: Message-ID: <9MSelUgHbXKbq6YD59zaAhQhJsoFMn_P0UhLWmxTEJw=.ca7685ef-de64-4916-bc33-e04f6f333501@github.com> On Fri, 10 Nov 2023 00:42:43 GMT, Magnus Ihse Bursie wrote: > The build changes almost look good. Just remove the extra added lines at the end. > > I think this point too still remains: > > > 1. TransitiveDependencies seems to be unused now. I assume this is intended. But maybe the java file can be removed? Sorry it took so long. I believe these have been reflected in the patch now: - removal of TransitiveDependencies: https://github.com/openjdk/jdk/pull/16400/commits/ac8fb43dfa660bdfdf34cd7f119b0823cf391357 - removal of the extra lines: https://github.com/openjdk/jdk/pull/16400/commits/70ab16d078750c066a07afc88f569e8b45af83e4 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1819628827 From asotona at openjdk.org Mon Nov 20 19:13:51 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Nov 2023 19:13:51 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v28] 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 incrementally with one additional commit since the last revision: added new package-info snippets and fixed ClassFile::parse throws javadoc description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15706/files - new: https://git.openjdk.org/jdk/pull/15706/files/8c80afff..3860e6c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=26-27 Stats: 43 lines in 3 files changed: 36 ins; 0 del; 7 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 Nov 20 19:27:01 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Nov 2023 19:27:01 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v29] 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 365 commits: - 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 - fixed SignaturesTest - fixed condy tests - Merge branch 'master' into JDK-8308753-preview - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - ... and 355 more: https://git.openjdk.org/jdk/compare/6b96bb64...46ad6906 ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=28 Stats: 32339 lines in 784 files changed: 14659 ins; 14109 del; 3571 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 jlaskey at openjdk.org Mon Nov 20 20:45:22 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 20:45:22 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v30] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/abe35d53..b14c6a54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=28-29 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From cstein at openjdk.org Tue Nov 21 08:47:13 2023 From: cstein at openjdk.org (Christian Stein) Date: Tue, 21 Nov 2023 08:47:13 GMT Subject: RFR: 8320447: Remove obsolete `LintCategory.hidden` Message-ID: <1b6tJGBroO18EnrXSQSCpkxJMFZyda4zgs3a9YMGdxA=.2999eb37-9aa9-4c85-ab75-c495a673e2be@github.com> Please review this change that removes the `LintCategory.hidden` member. `LintCategory.hidden` is an obsolete member with no uses. It was used for a custom "internal" category, "sunapi". ------------- Commit messages: - Remove obsolete `LintCategory.hidden` Changes: https://git.openjdk.org/jdk/pull/16755/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16755&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320447 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16755.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16755/head:pull/16755 PR: https://git.openjdk.org/jdk/pull/16755 From jlahoda at openjdk.org Tue Nov 21 09:57:06 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 21 Nov 2023 09:57:06 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 08:38:09 GMT, Adam Sotona wrote: >> Javap ignores --system option when searching for JDK classes. >> This patch prepends search over JDK system modules. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > applied suggested changes Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16476#pullrequestreview-1741556690 From asotona at openjdk.org Tue Nov 21 10:08:34 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 21 Nov 2023 10:08:34 GMT Subject: Integrated: 8304446: javap --system flag doesn't override system APIs In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 13:49:17 GMT, Adam Sotona wrote: > Javap ignores --system option when searching for JDK classes. > This patch prepends search over JDK system modules. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 604d29a8 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/604d29a8c911c1064ba0fab17f9192bb4e640709 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod 8304446: javap --system flag doesn't override system APIs Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/16476 From abimpoudis at openjdk.org Tue Nov 21 10:08:47 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 21 Nov 2023 10:08:47 GMT Subject: RFR: 8312560: Annotation on Decomposed Record Component in Enhanced For Loop Fails Compilation Message-ID: <3-oKNoDlUTffP9LLnTo3cTTbH6FbTPACxkvYjP-YlX0=.3557c05f-6f8f-4f90-bc3c-56db8dffd171@github.com> This PR fixes the attribution of record patterns which have var and an annotation. The scheduling of the attribution was skipped for this occasion. ------------- Commit messages: - 8312560: Annotation on Decomposed Record Component in Enhanced For Loop Fails Compilation - Add test Changes: https://git.openjdk.org/jdk/pull/16745/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16745&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312560 Stats: 47 lines in 2 files changed: 44 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16745/head:pull/16745 PR: https://git.openjdk.org/jdk/pull/16745 From ihse at openjdk.org Tue Nov 21 10:20:10 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 21 Nov 2023 10:20:10 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions [v4] In-Reply-To: References: Message-ID: <9T3oRP6oweDe_Suigeg0k1PX1D_i3Zbg3KyzZZkab5M=.effc1035-6099-4fab-91f0-7274ea73d045@github.com> On Mon, 20 Nov 2023 17:20:50 GMT, Jan Lahoda wrote: >> Consider a simple module, like: >> >> module test {} >> >> >> And compile it with JDK 22 and JDK 21 using: >> javac --release 21 >> >> The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. >> >> This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. >> >> This patch does two changes: >> a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. >> b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. >> >> The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. >> >> With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comment - removing unnecessary lines. No worries. Build changes look fine now! ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16400#pullrequestreview-1741610352 From asotona at openjdk.org Tue Nov 21 10:33:22 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 21 Nov 2023 10:33:22 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v30] 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 366 commits: - 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 - fixed SignaturesTest - fixed condy tests - Merge branch 'master' into JDK-8308753-preview - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - ... and 356 more: https://git.openjdk.org/jdk/compare/e055fae1...48aa8ba8 ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=29 Stats: 32342 lines in 784 files changed: 14659 ins; 14109 del; 3574 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 prappo at openjdk.org Tue Nov 21 10:41:42 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 21 Nov 2023 10:41:42 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 15:54:26 GMT, Jim Laskey wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Filter abstract main methods and search interfaces for default main methods. > > Look at the spec https://bugs.openjdk.org/browse/JDK-8319252 under 7.3 Compilation Units. > > - It is not abstract (8.1.1.1 ?). > - It is final (8.1.1.2 ?). > - It is a member of an unnamed package (7.4.2 ?) and **has package access**. Its direct superclass is Object (8.1.4 ?). > - It does not have any direct superinterfaces (8.1.5 ?). > - The body of the class contains every ClassMemberDeclaration (these are declarations of fields (8.3 ?), methods (8.4 ?), member classes (8.5 ?), and member interfaces (9.1.1.3 ?)) from the simple compilation unit. It is not possible for a simple compilation unit to declare an instance initializer (8.6 ?), static initializer (8.7 ?), or constructor (8.8 ?). > -It has an implicitly declared default constructor (8.8.9 ?). @JimLaskey, in my experiments for JDK-8308715 (Create a mechanism for Implicitly Declared Class javadoc), I found that `javax.lang.model.util.Elements.getOrigin` reports `Origin.EXPLICIT` for the implicitly declared class and `Origin.MANDATED` for that class' constructor. Shouldn't they both be `Origin.MANDATED` because the elements are created from source, not class files, which have some limitations on `ACC_MANDATED`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1820659000 From jlaskey at openjdk.org Tue Nov 21 13:01:31 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 21 Nov 2023 13:01:31 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: References: Message-ID: <4jr199o9QUudtSL9ccL9_wt-4khvBgvEmLg_rXeCfDE=.791b2144-48c6-4ec2-b3a8-cb23ad4a1cb6@github.com> On Tue, 21 Nov 2023 10:38:36 GMT, Pavel Rappo wrote: >> Look at the spec https://bugs.openjdk.org/browse/JDK-8319252 under 7.3 Compilation Units. >> >> - It is not abstract (8.1.1.1 ?). >> - It is final (8.1.1.2 ?). >> - It is a member of an unnamed package (7.4.2 ?) and **has package access**. Its direct superclass is Object (8.1.4 ?). >> - It does not have any direct superinterfaces (8.1.5 ?). >> - The body of the class contains every ClassMemberDeclaration (these are declarations of fields (8.3 ?), methods (8.4 ?), member classes (8.5 ?), and member interfaces (9.1.1.3 ?)) from the simple compilation unit. It is not possible for a simple compilation unit to declare an instance initializer (8.6 ?), static initializer (8.7 ?), or constructor (8.8 ?). >> -It has an implicitly declared default constructor (8.8.9 ?). > > @JimLaskey, in my experiments for JDK-8308715 (Create a mechanism for Implicitly Declared Class javadoc), I found that `javax.lang.model.util.Elements.getOrigin` reports `Origin.EXPLICIT` for the implicitly declared class and `Origin.MANDATED` for that class' constructor. Shouldn't they both be `Origin.MANDATED` because the elements are created from source, not class files, which have some limitations on `ACC_MANDATED`? @pavelrappo Classes can?t be MANDATED. Looking at the code I see that EXPLICIT is the default return value when no other conditions apply. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1820879428 From darcy at openjdk.org Tue Nov 21 14:43:26 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 21 Nov 2023 14:43:26 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 10:38:36 GMT, Pavel Rappo wrote: >> Look at the spec https://bugs.openjdk.org/browse/JDK-8319252 under 7.3 Compilation Units. >> >> - It is not abstract (8.1.1.1 ?). >> - It is final (8.1.1.2 ?). >> - It is a member of an unnamed package (7.4.2 ?) and **has package access**. Its direct superclass is Object (8.1.4 ?). >> - It does not have any direct superinterfaces (8.1.5 ?). >> - The body of the class contains every ClassMemberDeclaration (these are declarations of fields (8.3 ?), methods (8.4 ?), member classes (8.5 ?), and member interfaces (9.1.1.3 ?)) from the simple compilation unit. It is not possible for a simple compilation unit to declare an instance initializer (8.6 ?), static initializer (8.7 ?), or constructor (8.8 ?). >> -It has an implicitly declared default constructor (8.8.9 ?). > > @JimLaskey, in my experiments for JDK-8308715 (Create a mechanism for Implicitly Declared Class javadoc), I found that `javax.lang.model.util.Elements.getOrigin` reports `Origin.EXPLICIT` for the implicitly declared class and `Origin.MANDATED` for that class' constructor. Shouldn't they both be `Origin.MANDATED` because the elements are created from source, not class files, which have some limitations on `ACC_MANDATED`? > @pavelrappo Classes can?t be MANDATED. Looking at the code I see that EXPLICIT is the default return value when no other conditions apply. While it is true that the class file format cannot capture MANDATED status for classes, that doesn't necessarily imply mandated-ness shouldn't be track for classes created from sources while inside javac. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821055805 From asotona at openjdk.org Tue Nov 21 15:14:19 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 21 Nov 2023 15:14:19 GMT Subject: Integrated: 8187591: -Werror turns incubator module warning to an error In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 15:33:24 GMT, Adam Sotona wrote: > -Werror turns incubator module warning to an error > This patch adds "incubating" lint on-by-default category and triggers incubating module warning accordingly. > It also adds a test and updates javac man pages and jdk.compiler module-info javadoc. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 53eb6f12 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/53eb6f126b1a56bc651cf1078a27ec697e2dcf37 Stats: 34 lines in 6 files changed: 27 ins; 0 del; 7 mod 8187591: -Werror turns incubator module warning to an error Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/16454 From jjg at openjdk.org Tue Nov 21 15:33:05 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 21 Nov 2023 15:33:05 GMT Subject: RFR: 8320447: Remove obsolete `LintCategory.hidden` In-Reply-To: <1b6tJGBroO18EnrXSQSCpkxJMFZyda4zgs3a9YMGdxA=.2999eb37-9aa9-4c85-ab75-c495a673e2be@github.com> References: <1b6tJGBroO18EnrXSQSCpkxJMFZyda4zgs3a9YMGdxA=.2999eb37-9aa9-4c85-ab75-c495a673e2be@github.com> Message-ID: <4S85Ve-rYu4xZuSGQGOcdlVus7DEh6coH8EjpugCWm0=.c5a3dd07-1ae0-4e40-a59c-bcbe687b27b6@github.com> On Tue, 21 Nov 2023 08:41:00 GMT, Christian Stein wrote: > Please review this change that removes the `LintCategory.hidden` member. > > `LintCategory.hidden` is an obsolete member with no uses. It was used for a custom "internal" category, "sunapi". Marked as reviewed by jjg (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16755#pullrequestreview-1742318596 From alanb at openjdk.org Tue Nov 21 15:37:31 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Nov 2023 15:37:31 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v30] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 20:45:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update test src/java.base/share/classes/java/lang/Class.java line 4847: > 4845: @PreviewFeature(feature=PreviewFeature.Feature.IMPLICIT_CLASSES) > 4846: @CallerSensitive > 4847: public Method findMainMethod() { Renaming it to findMainMethod separates it from the existing getXXXMethod methods (good) but it makes it more obvious that this is a method for launchers. I'm not 100% sure that java.lang.Class is the right place for this, it feels out of place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1400785014 From abimpoudis at openjdk.org Tue Nov 21 17:21:33 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 21 Nov 2023 17:21:33 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v33] 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 39 commits: - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Small cleanup in PrimitivePatternsSwitch - Add test for instanceof as a pattern on with record patterns - Merge branch 'master' into primitive-patterns # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java - Add tests for new data types in switch statements - Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests - Fix SwitchBootstraps for pattern matching over longs - ... and 29 more: https://git.openjdk.org/jdk/compare/61d81d64...2b2405cc ------------- Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=32 Stats: 3199 lines in 41 files changed: 2943 ins; 111 del; 145 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 jlaskey at openjdk.org Tue Nov 21 17:52:49 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 21 Nov 2023 17:52:49 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update Class.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/b14c6a54..fd0c92f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=29-30 Stats: 34 lines in 1 file changed: 9 ins; 17 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From prappo at openjdk.org Tue Nov 21 18:44:23 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 21 Nov 2023 18:44:23 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: <4jr199o9QUudtSL9ccL9_wt-4khvBgvEmLg_rXeCfDE=.791b2144-48c6-4ec2-b3a8-cb23ad4a1cb6@github.com> References: <4jr199o9QUudtSL9ccL9_wt-4khvBgvEmLg_rXeCfDE=.791b2144-48c6-4ec2-b3a8-cb23ad4a1cb6@github.com> Message-ID: On Tue, 21 Nov 2023 12:58:42 GMT, Jim Laskey wrote: >> @JimLaskey, in my experiments for JDK-8308715 (Create a mechanism for Implicitly Declared Class javadoc), I found that `javax.lang.model.util.Elements.getOrigin` reports `Origin.EXPLICIT` for the implicitly declared class and `Origin.MANDATED` for that class' constructor. Shouldn't they both be `Origin.MANDATED` because the elements are created from source, not class files, which have some limitations on `ACC_MANDATED`? > > @pavelrappo Classes can?t be MANDATED. Looking at the code I see that EXPLICIT is the default return value when no other conditions apply. @JimLaskey, I note that something weird is happening in relation to comments on method declarations. Comments on field declarations might be affected too, but I haven't checked. Comments on method declarations are correctly captured only if those declarations are minimal. That is, if they consist of a result, name, and parameters. Whenever modifiers like public, protected, private, static, or final appear, the comments disappear. Briefly looking at `com.sun.tools.javac.parser.JavacParser` code (which I have no clue what is doing), I assume the comments are getting misattributed to some other tokens. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821458574 From jlaskey at openjdk.org Tue Nov 21 18:55:25 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 21 Nov 2023 18:55:25 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 17:52:49 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java The comments are attached to the modifiers (first thing it encounters.) I?m sure the javadoc toolset has a method that gets the comments from the right thing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821475235 From prappo at openjdk.org Tue Nov 21 19:02:28 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 21 Nov 2023 19:02:28 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 18:51:55 GMT, Jim Laskey wrote: > I?m sure the javadoc toolset has a method that gets the comments from the right thing. That's exactly where those comments disappear from, javadoc. Comments of normal class methods and comments of methods of implicitly declared class seem to be tree-ified differently. Can these comments become lost during copying/reconstruction? I'll try to figure out more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821492952 From prappo at openjdk.org Tue Nov 21 19:21:27 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 21 Nov 2023 19:21:27 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 18:59:51 GMT, Pavel Rappo wrote: > I'll try to figure out more. So this method seems to be a proximate-ish cause for that behaviour: `JavacParser.topLevelMethodOrFieldDeclaration`. If it gets `null` or comment to attach to `JCTree.JCMethodDecl` later depends on the presence of modifiers. This is not the case with normal class methods, where the comments are robustly attached regardless of whether modifiers are present. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821538640 From alanb at openjdk.org Tue Nov 21 19:21:30 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Nov 2023 19:21:30 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 17:52:49 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java src/java.base/share/classes/java/lang/Class.java line 4823: > 4821: * signatures in a class." > 4822: *

{@link SecurityException SecurityExceptions} can halt > 4823: * the search. In this case, a null is returned. I see the latest update changes this to return null if denied by the SM. This seems very inconsistent with the other methods so I'm wondering why this has changed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1401056196 From jlaskey at openjdk.org Tue Nov 21 19:50:23 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 21 Nov 2023 19:50:23 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 19:16:06 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Class.java > > src/java.base/share/classes/java/lang/Class.java line 4823: > >> 4821: * signatures in a class." >> 4822: *

{@link SecurityException SecurityExceptions} can halt >> 4823: * the search. In this case, a null is returned. > > I see the latest update changes this to return null if denied by the SM. This seems very inconsistent with the other methods so I'm wondering why this has changed? Requested by CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1401089920 From jjg at openjdk.org Tue Nov 21 20:44:22 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 21 Nov 2023 20:44:22 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: <7WfOKRXJUWg0CT8T4RqwC5VzgJp2ZEbnvrr39TLpJHk=.517338f9-dfe0-4b7d-bf18-b117818aa98a@github.com> On Tue, 21 Nov 2023 18:51:55 GMT, Jim Laskey wrote: > The comments are attached to the modifiers (first thing it encounters.) I?m sure the javadoc toolset has a method that gets the comments from the right thing. In the AST created by the parser, doc comments should be attached to _declarations_ (`JCClassDecl`, `JCMethodDecl`, `JCVariableDecl` etc) not modifiers. There is nothing in the javadoc toolset that _gets the comments from the right thing_. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821645764 From vromero at openjdk.org Tue Nov 21 22:41:19 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 21 Nov 2023 22:41:19 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type Message-ID: Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. TIA [1] https://bugs.openjdk.org/browse/JDK-8225377 ------------- Commit messages: - 8320001: javac crashes while adding type annotations to constructor's return type Changes: https://git.openjdk.org/jdk/pull/16774/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16774&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320001 Stats: 151 lines in 2 files changed: 150 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16774/head:pull/16774 PR: https://git.openjdk.org/jdk/pull/16774 From cushon at openjdk.org Tue Nov 21 22:52:04 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 21 Nov 2023 22:52:04 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 22:28:11 GMT, Vicente Romero wrote: > Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. > > TIA > [1] https://bugs.openjdk.org/browse/JDK-8225377 This looks good to me. Thanks for the fix! test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java line 119: > 117: .classpath(classes, classDir) > 118: .options("-processor", SimpleProcessor.class.getName()) > 119: .files(yWrapper) It should be equivalent to use `.classes("Y")` to request annotation processing of `Y` directly, and avoid the need for `YWrapper`. But either way is fine. ------------- Marked as reviewed by cushon (Committer). PR Review: https://git.openjdk.org/jdk/pull/16774#pullrequestreview-1743283268 PR Review Comment: https://git.openjdk.org/jdk/pull/16774#discussion_r1401304274 From vromero at openjdk.org Tue Nov 21 23:25:04 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 21 Nov 2023 23:25:04 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 22:48:45 GMT, Liam Miller-Cushon wrote: >> Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. >> >> TIA >> [1] https://bugs.openjdk.org/browse/JDK-8225377 > > test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java line 119: > >> 117: .classpath(classes, classDir) >> 118: .options("-processor", SimpleProcessor.class.getName()) >> 119: .files(yWrapper) > > It should be equivalent to use `.classes("Y")` to request annotation processing of `Y` directly, and avoid the need for `YWrapper`. But either way is fine. thanks for your comment, yes I tried that but all of the APIs we offer in JavacTasks were failing stating that the file was not a source file, this is why I decided to use a wrapper ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16774#discussion_r1401326705 From wmdietl at openjdk.org Tue Nov 21 23:34:08 2023 From: wmdietl at openjdk.org (Werner Dietl) Date: Tue, 21 Nov 2023 23:34:08 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type In-Reply-To: References: Message-ID: <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com> On Tue, 21 Nov 2023 22:28:11 GMT, Vicente Romero wrote: > Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. > > TIA > [1] https://bugs.openjdk.org/browse/JDK-8225377 src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 2335: > 2333: } > 2334: mt.thrown = thrown.toList(); > 2335: /* possible information loss if the type of the method is void then we can't add type @vicente-romero-oracle Could we open a follow-up issue to add a standard way to retrieve these type annotations? Type use annotations on constructors are valid Java >= 8 syntax and they are stored in the classfiles, so it would be nice to also get the annotations out of a classfile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16774#discussion_r1401331446 From cushon at openjdk.org Tue Nov 21 23:34:12 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 21 Nov 2023 23:34:12 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 23:22:47 GMT, Vicente Romero wrote: >> test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java line 119: >> >>> 117: .classpath(classes, classDir) >>> 118: .options("-processor", SimpleProcessor.class.getName()) >>> 119: .files(yWrapper) >> >> It should be equivalent to use `.classes("Y")` to request annotation processing of `Y` directly, and avoid the need for `YWrapper`. But either way is fine. > > thanks for your comment, yes I tried that but all of the APIs we offer in JavacTasks were failing stating that the file was not a source file, this is why I decided to use a wrapper That's weird, I tried it out before commenting and it worked for me, I was able to reproduce the crash and then see the test pass with the fix using: diff --git a/test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java b/test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java index 50c596ac79b..49f694a9a4f 100644 --- a/test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java +++ b/test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java @@ -98,12 +98,6 @@ class Y { @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) @interface TA {} - """, - """ - class YWrapper { - // just to make the compiler load the class file for class Y above - Y y; - } """); // we need to compile Y first @@ -116,7 +110,7 @@ class YWrapper { new JavacTask(tb) .classpath(classes, classDir) .options("-processor", SimpleProcessor.class.getName()) - .files(yWrapper) + .classes("Y") .outdir(classes) .run(Task.Expect.SUCCESS); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16774#discussion_r1401331846 From cushon at openjdk.org Tue Nov 21 23:42:05 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 21 Nov 2023 23:42:05 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type In-Reply-To: <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com> References: <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com> Message-ID: On Tue, 21 Nov 2023 23:30:28 GMT, Werner Dietl wrote: >> Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. >> >> TIA >> [1] https://bugs.openjdk.org/browse/JDK-8225377 > > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 2335: > >> 2333: } >> 2334: mt.thrown = thrown.toList(); >> 2335: /* possible information loss if the type of the method is void then we can't add type > > @vicente-romero-oracle Could we open a follow-up issue to add a standard way to retrieve these type annotations? > Type use annotations on constructors are valid Java >= 8 syntax and they are stored in the classfiles, so it would be nice to also get the annotations out of a classfile. That seems worth considering to me as a potential follow-up. One note is that as far as I can tell the current `javax.lang.model` implementation doesn't allow retrieving type annotations on constructors, I don't think this issue is specific to class loading. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16774#discussion_r1401336644 From vromero at openjdk.org Wed Nov 22 00:07:04 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 22 Nov 2023 00:07:04 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type In-Reply-To: References: <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com> Message-ID: On Tue, 21 Nov 2023 23:39:44 GMT, Liam Miller-Cushon wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 2335: >> >>> 2333: } >>> 2334: mt.thrown = thrown.toList(); >>> 2335: /* possible information loss if the type of the method is void then we can't add type >> >> @vicente-romero-oracle Could we open a follow-up issue to add a standard way to retrieve these type annotations? >> Type use annotations on constructors are valid Java >= 8 syntax and they are stored in the classfiles, so it would be nice to also get the annotations out of a classfile. > > That seems worth considering to me as a potential follow-up. One note is that as far as I can tell the current `javax.lang.model` implementation doesn't allow retrieving type annotations on constructors, I don't think this issue is specific to class loading. yes makes total sense, I will create a follow-up ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16774#discussion_r1401348445 From wmdietl at openjdk.org Wed Nov 22 00:07:05 2023 From: wmdietl at openjdk.org (Werner Dietl) Date: Wed, 22 Nov 2023 00:07:05 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type In-Reply-To: References: <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com> Message-ID: On Tue, 21 Nov 2023 23:39:44 GMT, Liam Miller-Cushon wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 2335: >> >>> 2333: } >>> 2334: mt.thrown = thrown.toList(); >>> 2335: /* possible information loss if the type of the method is void then we can't add type >> >> @vicente-romero-oracle Could we open a follow-up issue to add a standard way to retrieve these type annotations? >> Type use annotations on constructors are valid Java >= 8 syntax and they are stored in the classfiles, so it would be nice to also get the annotations out of a classfile. > > That seems worth considering to me as a potential follow-up. One note is that as far as I can tell the current `javax.lang.model` implementation doesn't allow retrieving type annotations on constructors, I don't think this issue is specific to class loading. @cushon Yes, at the moment we have to manually get to these annotations in the AST and from the classfile. Having a standard API for both source and bytecode would be nice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16774#discussion_r1401350292 From vromero at openjdk.org Wed Nov 22 00:38:12 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 22 Nov 2023 00:38:12 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 23:31:08 GMT, Liam Miller-Cushon wrote: >> thanks for your comment, yes I tried that but all of the APIs we offer in JavacTasks were failing stating that the file was not a source file, this is why I decided to use a wrapper > > That's weird, I tried it out before commenting and it worked for me, I was able to reproduce the crash and then see the test pass with the fix using: > > > diff --git a/test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java b/test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java > index 50c596ac79b..49f694a9a4f 100644 > --- a/test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java > +++ b/test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnosOnConstructorsTest.java > @@ -98,12 +98,6 @@ class Y { > @Target(ElementType.TYPE_USE) > @Retention(RetentionPolicy.RUNTIME) > @interface TA {} > - """, > - """ > - class YWrapper { > - // just to make the compiler load the class file for class Y above > - Y y; > - } > """); > > // we need to compile Y first > @@ -116,7 +110,7 @@ class YWrapper { > new JavacTask(tb) > .classpath(classes, classDir) > .options("-processor", SimpleProcessor.class.getName()) > - .files(yWrapper) > + .classes("Y") > .outdir(classes) > .run(Task.Expect.SUCCESS); > } yup your are right, will fix the test, it seems like I tried another combination of options ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16774#discussion_r1401369424 From vromero at openjdk.org Wed Nov 22 00:42:47 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 22 Nov 2023 00:42:47 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to constructor's return type [v2] In-Reply-To: References: Message-ID: <9wYvTt7aFxk9SOxi4n0znMKeWr3YA2Pf69_mIUZv1nI=.f96b1943-7b0f-401e-965c-e848dcd10bbe@github.com> > Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. > > TIA > [1] https://bugs.openjdk.org/browse/JDK-8225377 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16774/files - new: https://git.openjdk.org/jdk/pull/16774/files/ed0e312d..483f7287 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16774&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16774&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16774/head:pull/16774 PR: https://git.openjdk.org/jdk/pull/16774 From vromero at openjdk.org Wed Nov 22 01:06:35 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 22 Nov 2023 01:06:35 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to the return type of a constructor [v3] In-Reply-To: References: Message-ID: > Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. > > TIA > [1] https://bugs.openjdk.org/browse/JDK-8225377 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: changing test's summary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16774/files - new: https://git.openjdk.org/jdk/pull/16774/files/483f7287..0938db68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16774&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16774&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16774/head:pull/16774 PR: https://git.openjdk.org/jdk/pull/16774 From vromero at openjdk.org Wed Nov 22 01:36:03 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 22 Nov 2023 01:36:03 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to the return type of a constructor [v3] In-Reply-To: References: <4G8kxRHiQuo2rhgsfzEfrWDH3ucyHyC5Wx-qldxycOs=.9f482ff8-12a4-4e76-8e8f-bb0abf61262d@github.com> Message-ID: <9WGf0HeoFjA9JgTZKJz-s17dAuxLoNfPfhwvhid7ZNw=.c9645aff-6e9a-4267-86fe-03ae20cda776@github.com> On Wed, 22 Nov 2023 00:04:40 GMT, Werner Dietl wrote: >> That seems worth considering to me as a potential follow-up. One note is that as far as I can tell the current `javax.lang.model` implementation doesn't allow retrieving type annotations on constructors, I don't think this issue is specific to class loading. > > @cushon Yes, at the moment we have to manually get to these annotations in the AST and from the classfile. Having a standard API for both source and bytecode would be nice. I have created: https://bugs.openjdk.org/browse/JDK-8320562 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16774#discussion_r1401399225 From aturbanov at openjdk.org Wed Nov 22 09:40:10 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 22 Nov 2023 09:40:10 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v5] In-Reply-To: <5D_gyGHDR52UTLCcFnUNSWYXjYgcy3jYnffOXZ70xsg=.e1389d08-c9ae-481f-9c53-1ccd1e389102@github.com> References: <5D_gyGHDR52UTLCcFnUNSWYXjYgcy3jYnffOXZ70xsg=.e1389d08-c9ae-481f-9c53-1ccd1e389102@github.com> Message-ID: On Wed, 15 Nov 2023 18:58:43 GMT, Jonathan Gibbons wrote: >> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. >> >> Notable features: >> >> * support for `///` documentation comments in `JavaTokenizer` >> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library >> * updates to `DocCommentParser` to treat `///` comments as Markdown >> * updates to the standard doclet to render Markdown comments in HTML > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 178: > 176: List postamble = isHtmlFile ? content(Phase.POSTAMBLE) : List.nil(); > 177: > 178: int pos = textKind == DocTree.Kind.MARKDOWN ? 0 Suggestion: int pos = textKind == DocTree.Kind.MARKDOWN ? 0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1401760748 From cstein at openjdk.org Wed Nov 22 09:52:14 2023 From: cstein at openjdk.org (Christian Stein) Date: Wed, 22 Nov 2023 09:52:14 GMT Subject: Integrated: 8320447: Remove obsolete `LintCategory.hidden` In-Reply-To: <1b6tJGBroO18EnrXSQSCpkxJMFZyda4zgs3a9YMGdxA=.2999eb37-9aa9-4c85-ab75-c495a673e2be@github.com> References: <1b6tJGBroO18EnrXSQSCpkxJMFZyda4zgs3a9YMGdxA=.2999eb37-9aa9-4c85-ab75-c495a673e2be@github.com> Message-ID: On Tue, 21 Nov 2023 08:41:00 GMT, Christian Stein wrote: > Please review this change that removes the `LintCategory.hidden` member. > > `LintCategory.hidden` is an obsolete member with no uses. It was used for a custom "internal" category, "sunapi". This pull request has now been integrated. Changeset: ceb02903 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/ceb0290335269374da3a366a5d24dd0b7fa722a0 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod 8320447: Remove obsolete `LintCategory.hidden` Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk/pull/16755 From jlaskey at openjdk.org Wed Nov 22 15:29:08 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 22 Nov 2023 15:29:08 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v32] In-Reply-To: References: Message-ID: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Handle javadoc on top level elements properly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/fd0c92f8..222e3346 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=30-31 Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From clanger at openjdk.org Wed Nov 22 16:14:23 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 22 Nov 2023 16:14:23 GMT Subject: RFR: 8320601: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-all Message-ID: java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already problem listed on linux-x64. However, the issue is not processor specific. We see the failure on linux on other architectures as well. ------------- Commit messages: - Update ProblemList.txt Changes: https://git.openjdk.org/jdk/pull/16784/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16784&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320601 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16784.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16784/head:pull/16784 PR: https://git.openjdk.org/jdk/pull/16784 From jlahoda at openjdk.org Wed Nov 22 16:22:07 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 22 Nov 2023 16:22:07 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to the return type of a constructor [v3] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 01:06:35 GMT, Vicente Romero wrote: >> Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. >> >> TIA >> [1] https://bugs.openjdk.org/browse/JDK-8225377 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > changing test's summary Looks reasonable at this time. Thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16774#pullrequestreview-1744858583 From wdietl at gmail.com Wed Nov 22 17:55:30 2023 From: wdietl at gmail.com (Werner Dietl) Date: Wed, 22 Nov 2023 12:55:30 -0500 Subject: Type use annotations on instanceof patterns Message-ID: Hi all, Take the following program: ```` import java.lang.annotation.Target; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; public class InstanceOfPatternVariable { public void doSomething(final Object x) { if (x instanceof @TA Float) { } if (x instanceof @TA Boolean b) { } } @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) @interface TA {} } ```` This successfully compiles with javac (anything >=16 should work, I used javac 21.0.1). I think there are two issues: 1) When looking at the bytecode with `javap -v InstanceOfPatternVariable.class` I only see one use of @TA: RuntimeVisibleTypeAnnotations: 0: #19(): INSTANCEOF, offset=1 InstanceOfPatternVariable$TA The JSL 15.20.2 [1] says "An instanceof expression may perform either type comparison or pattern matching." The JVMS 4.7.20-B [2] talks about how type annotations on "instanceof expressions" are stored. It would therefore seem to me that both occurrences of TA should be stored in the class file. 2) When looking at the generated ASTs, for the first InstanceOfTree, getType() returns `@TA Float`. For the second InstanceOfTree, getType() only returns `Boolean`, without the type annotation attached. For the second InstanceOfTree, getPattern() seems to return a BindingPatternTree that contains a VariableTree which has `@TA Boolean` type. It would seem more consistent if getType() for both trees returns an annotated type. Thoughts? I did not find an existing bug report related to type annotations and binding patterns. Did I miss one? Thanks, cu, WMD. [1] https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.20.2 [2] https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.20-410 -- https://ece.uwaterloo.ca/~wdietl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaskey at openjdk.org Wed Nov 22 20:30:22 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 22 Nov 2023 20:30:22 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v32] In-Reply-To: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> References: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> Message-ID: On Wed, 22 Nov 2023 15:29:08 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Handle javadoc on top level elements properly I wasn't succinct. I meant modifier tokens. At any rate, I found the issue. VirtualParser was copying `keepDocComments` and `docComments`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1823463925 From alex.buckley at oracle.com Wed Nov 22 20:48:59 2023 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Nov 2023 12:48:59 -0800 Subject: Type use annotations on instanceof patterns In-Reply-To: References: Message-ID: <50d8b279-2f79-4926-ae10-aa6b08e44322@oracle.com> On 11/22/2023 9:55 AM, Werner Dietl wrote: > ? ? ? ? if (x instanceof @TA Float) { > ? ? ? ? if (x instanceof @TA Boolean b) { > > ? ? @Target(ElementType.TYPE_USE) > ? ? @Retention(RetentionPolicy.RUNTIME) > ? ? @interface TA {} > > 1) When looking at the bytecode with `javap -v > InstanceOfPatternVariable.class` I only see one use of @TA: > > ? ? ? RuntimeVisibleTypeAnnotations: > ? ? ? ? 0: #19(): INSTANCEOF, offset=1 > ? ? ? ? ? InstanceOfPatternVariable$TA > > The JSL 15.20.2 [1] says "An instanceof expression may perform either > type comparison or pattern matching." > The JVMS 4.7.20-B [2] talks about how type annotations on "instanceof > expressions" are stored. > It would therefore seem to me that both occurrences of TA should be > stored in the class file. (You mean both occurrences of the annotation `@TA`. The annotation interface `TA` is a distinct thing.) Yes, both occurrences of `@TA` should be stored. Let's "prove it" for the second occurrence. The type pattern `Boolean b` is defined (per 14.30.1) as a local variable declaration. The annotation `@TA` which syntactically appears as a modifier on that declaration is interpreted according to 9.7.4. How? The annotation interface `TA` is defined with TYPE_USE, which means (per 9.6.4.1) that `TA` is applicable in type contexts. One of the type contexts (per 4.11) is: "The type in a local variable declaration in either a statement ... or a pattern". So, the following rule in 9.7.4 applies: ``` - If the annotation's interface is applicable in type contexts, and not in the declaration context corresponding to the declaration, then the annotation is deemed to apply only to the type which is closest to the annotation. ``` This means that the annotation `@TA` is a type annotation (applying to the use of the `Boolean` type within a local variable declaration) and not a declaration annotation on the overall local variable declaration `Boolean b`. Great -- type annotations integrate with type patterns in the JLS as you would expect. Consequently, `@TA` should appear in the RVTA attribute via a localvar_target item. Perhaps javac is emitting the item but javap is unable to render it. Alex From vromero at openjdk.org Wed Nov 22 21:52:36 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 22 Nov 2023 21:52:36 GMT Subject: RFR: 8320001: javac crashes while adding type annotations to the return type of a constructor [v4] In-Reply-To: References: Message-ID: > Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. > > TIA > [1] https://bugs.openjdk.org/browse/JDK-8225377 Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into JDK-8320001 - changing test's summary - addressing review comments - 8320001: javac crashes while adding type annotations to constructor's return type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16774/files - new: https://git.openjdk.org/jdk/pull/16774/files/0938db68..990c3d3b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16774&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16774&range=02-03 Stats: 9339 lines in 291 files changed: 6218 ins; 1317 del; 1804 mod Patch: https://git.openjdk.org/jdk/pull/16774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16774/head:pull/16774 PR: https://git.openjdk.org/jdk/pull/16774 From mbaesken at openjdk.org Thu Nov 23 09:02:05 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 23 Nov 2023 09:02:05 GMT Subject: RFR: 8320601: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-all In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 15:59:38 GMT, Christoph Langer wrote: > java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already problem listed on linux-x64. However, the issue is not processor specific. We see the failure on linux on other architectures as well. Makes sense to do it on all Linux CPU archs; however I wonder about the following - is there maybe some environment variable setting missing in the test that otherwise would make the test run successfully ? In the test java/lang/invoke/lambda/LambdaFileEncodingSerialization.java we set already https://github.com/openjdk/jdk/blob/8db7bad992a0f31de9c7e00c2657c18670539102/test/jdk/java/lang/invoke/lambda/LambdaFileEncodingSerialization.java#L83 ` env.put("LC_ALL", "en_US.UTF-8"); // Ensure locale supports the test requirements, lambda with a UTF char` is that maybe not sufficient on some systems and some other env var must be set ? ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16784#pullrequestreview-1745975621 PR Comment: https://git.openjdk.org/jdk/pull/16784#issuecomment-1824017867 From prappo at openjdk.org Thu Nov 23 10:48:23 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 23 Nov 2023 10:48:23 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v32] In-Reply-To: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> References: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> Message-ID: On Wed, 22 Nov 2023 15:29:08 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Handle javadoc on top level elements properly I've checked your recent commit [222e334](https://github.com/openjdk/jdk/pull/16461/commits/222e3346ac61a9116014791fac0ad60ef3950949) and can confirm that it fixes the issue with comments; thanks. Feel free to add a tests for it. Regardless of whether the compiler has such a test, javadoc will have its own test. So it will be covered. But javadoc test will be indirect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1824193504 From angelos.bimpoudis at oracle.com Thu Nov 23 13:49:15 2023 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Thu, 23 Nov 2023 13:49:15 +0000 Subject: Type use annotations on instanceof patterns In-Reply-To: References: Message-ID: Thanks for the analysis and report Opened https://bugs.openjdk.org/browse/JDK-8320660 ________________________________ From: compiler-dev on behalf of Werner Dietl Sent: 22 November 2023 18:55 To: compiler-dev Subject: Type use annotations on instanceof patterns Hi all, Take the following program: ```` import java.lang.annotation.Target; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; public class InstanceOfPatternVariable { public void doSomething(final Object x) { if (x instanceof @TA Float) { } if (x instanceof @TA Boolean b) { } } @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) @interface TA {} } ```` This successfully compiles with javac (anything >=16 should work, I used javac 21.0.1). I think there are two issues: 1) When looking at the bytecode with `javap -v InstanceOfPatternVariable.class` I only see one use of @TA: RuntimeVisibleTypeAnnotations: 0: #19(): INSTANCEOF, offset=1 InstanceOfPatternVariable$TA The JSL 15.20.2 [1] says "An instanceof expression may perform either type comparison or pattern matching." The JVMS 4.7.20-B [2] talks about how type annotations on "instanceof expressions" are stored. It would therefore seem to me that both occurrences of TA should be stored in the class file. 2) When looking at the generated ASTs, for the first InstanceOfTree, getType() returns `@TA Float`. For the second InstanceOfTree, getType() only returns `Boolean`, without the type annotation attached. For the second InstanceOfTree, getPattern() seems to return a BindingPatternTree that contains a VariableTree which has `@TA Boolean` type. It would seem more consistent if getType() for both trees returns an annotated type. Thoughts? I did not find an existing bug report related to type annotations and binding patterns. Did I miss one? Thanks, cu, WMD. [1] https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.20.2 [2] https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.20-410 -- https://ece.uwaterloo.ca/~wdietl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaskey at openjdk.org Thu Nov 23 14:45:51 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 23 Nov 2023 14:45:51 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v33] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Move findMainMethod to non-public access ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/222e3346..420f6b42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=31-32 Stats: 155 lines in 6 files changed: 77 ins; 72 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 23 15:55:42 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 23 Nov 2023 15:55:42 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/420f6b42..690dac1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=32-33 Stats: 131 lines in 1 file changed: 0 ins; 131 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlahoda at openjdk.org Fri Nov 24 06:33:24 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 24 Nov 2023 06:33:24 GMT Subject: Integrated: 8318913: The module-infos for --release data do not contain pre-set versions In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote: > Consider a simple module, like: > > module test {} > > > And compile it with JDK 22 and JDK 21 using: > javac --release 21 > > The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. > > This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. > > This patch does two changes: > a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. > b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. > > The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. > > With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. This pull request has now been integrated. Changeset: fc314740 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b Stats: 730 lines in 14 files changed: 470 ins; 184 del; 76 mod 8318913: The module-infos for --release data do not contain pre-set versions Co-authored-by: Erik Joelsson Reviewed-by: vromero, ihse ------------- PR: https://git.openjdk.org/jdk/pull/16400 From duke at openjdk.org Fri Nov 24 07:35:17 2023 From: duke at openjdk.org (Jorge =?UTF-8?B?U29sw7NyemFubw==?=) Date: Fri, 24 Nov 2023 07:35:17 GMT Subject: RFR: 8318913: The module-infos for --release data do not contain pre-set versions [v4] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 17:20:50 GMT, Jan Lahoda wrote: >> Consider a simple module, like: >> >> module test {} >> >> >> And compile it with JDK 22 and JDK 21 using: >> javac --release 21 >> >> The results of the compilations will differ: when compiling with JDK 21, the mandated java.base dependency will get a version, possibly like "21-internal". When compiling with JDK 22, the version of the java.base dependency will be empty. >> >> This is a) because `module-info.class`es in `ct.sym` do not have any module version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather `lib/modules`, which may contain a range of version specifiers. >> >> This patch does two changes: >> a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a simple version. For `--release N`, the version is `N`. >> b) tweaks the whole build so that `ct.sym` is used always for `--release`, a `lib/modules` is never used. I.e. the appropriate classfiles are copied into `ct.sym`. This not only allows for a general approach to module versions, but simplifies the `--release` handling in javac, and should enable future improvements. This is, however, a relatively big change. >> >> The use of `lib/modules` for `--release ` was made to improve build performance, but the build has been updated since this has been introduced, so the slowdown caused by rebuilding `ct.sym` should be much lower now. >> >> With these changes, compiling with `--release N` should record the same dependency versions in `module-info` on JDK N and JDK N + 1. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comment - removing unnecessary lines. Hi, just some comments to get this clear, using Maven this issue [breaks the reproducible builds](https://issues.apache.org/jira/browse/MCOMPILER-542) since the JDK version is recorded on the module-info.class, breaking the reproducible build when using a different minor version. In Maven there is a PR that will drop the version using ASM on the maven-compiler-plugin matching the behavior of building with JDK N+1. With this change in the JDK, Maven could follow as long the recorded version is always the same on every minor release if the premise "For --release N, the version is N.", is fulfilled, in other words, it should always use the specification version (java.specification.version), this is to provide a workaround to this issue even for older JDK version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1824105718 From alanb at openjdk.org Fri Nov 24 11:03:25 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 11:03:25 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34] In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 15:55:42 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove Test src/java.base/share/classes/java/lang/Class.java line 4797: > 4795: PublicMethods.MethodList res = getMethodsRecursive(name, parameterTypes, true, publicOnly); > 4796: return res == null ? null : getReflectionFactory().copyMethod(res.getMostSpecific()); > 4797: } Would you mind moving this up to follow getDeclaredPublicMethods, as these are the two are the method finders exposed via JavaLangAccess. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1404226792 From alanb at openjdk.org Fri Nov 24 11:32:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 11:32:23 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34] In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 15:55:42 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove Test src/java.base/share/classes/jdk/internal/misc/MethodFinder.java line 40: > 38: } > 39: > 40: private static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess(); The new shared secret and usage looks fine. It would be good to add a short class description and method description and make it clear it's for launcher usage, we don't want this used for anything else. Personally I would move JLA to to the top rather than after the constructor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1404252179 From jlaskey at openjdk.org Fri Nov 24 12:56:40 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 24 Nov 2023 12:56:40 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/690dac1d..d7895da7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=33-34 Stats: 68 lines in 2 files changed: 57 ins; 9 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Fri Nov 24 12:56:42 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 24 Nov 2023 12:56:42 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 11:00:18 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove Test > > src/java.base/share/classes/java/lang/Class.java line 4797: > >> 4795: PublicMethods.MethodList res = getMethodsRecursive(name, parameterTypes, true, publicOnly); >> 4796: return res == null ? null : getReflectionFactory().copyMethod(res.getMostSpecific()); >> 4797: } > > Would you mind moving this up to follow getDeclaredPublicMethods, as these are the two method finders exposed via JavaLangAccess. Updated > src/java.base/share/classes/jdk/internal/misc/MethodFinder.java line 40: > >> 38: } >> 39: >> 40: private static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess(); > > The new shared secret and usage looks fine. It would be good to add a short class description and method description and make it clear it's for launcher usage, we don't want this used for anything else. Personally I would move JLA to to the top rather than after the constructor. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1404324242 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1404324338 From clanger at openjdk.org Mon Nov 27 08:25:18 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 27 Nov 2023 08:25:18 GMT Subject: Integrated: 8320601: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-all In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 15:59:38 GMT, Christoph Langer wrote: > java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already problem listed on linux-x64. However, the issue is not processor specific. We see the failure on linux on other architectures as well. This pull request has now been integrated. Changeset: f6e5559a Author: Christoph Langer URL: https://git.openjdk.org/jdk/commit/f6e5559ae9d1c8b84b31af5d36e93b43e7731ba5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8320601: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-all Reviewed-by: mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/16784 From asotona at openjdk.org Mon Nov 27 09:20:34 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 27 Nov 2023 09:20:34 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v31] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <96gFYL2iQI4xJubLzYNfxYbB2_D7xXqrR9FSWd4zN0s=.f11bc6d0-4c67-44be-820a-3e1f76fd9a49@github.com> > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 369 commits: - 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 - fixed SignaturesTest - fixed condy tests - ... and 359 more: https://git.openjdk.org/jdk/compare/28d3762b...deb064fc ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=30 Stats: 32361 lines in 787 files changed: 14660 ins; 14113 del; 3588 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 Nov 27 10:01:50 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 27 Nov 2023 10:01:50 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v32] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com> > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed SwitchBootstrapTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15706/files - new: https://git.openjdk.org/jdk/pull/15706/files/deb064fc..dd9a4aa7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=30-31 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 cushon at google.com Mon Nov 27 15:43:07 2023 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 27 Nov 2023 07:43:07 -0800 Subject: Type use annotations on instanceof patterns In-Reply-To: <50d8b279-2f79-4926-ae10-aa6b08e44322@oracle.com> References: <50d8b279-2f79-4926-ae10-aa6b08e44322@oracle.com> Message-ID: I think the issue is that the code to generate LOCAL_VARIABLE locations here [1] only handles variables that have non-empty live ranges, so type annotations on unused variables are never generated. [1] https://github.com/openjdk/jdk/blob/6aa197667ad05bd93adf3afc7b06adbfb2b18a22/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java#L2115-L2125 Consider this example, where type annotations are emitted for type patterns and locals, but not if they are unused: import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; public class InstanceOfPatternVariable { public void doSomething(final Object x) { if (x instanceof @TA(0) String z) {} @TA(1) String b; if (x instanceof @TA(2) String c) { System.err.println(c); } @TA(3) String d = null; System.err.println(d); } @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) @interface TA { int value(); } } Which results in: RuntimeVisibleTypeAnnotations: 0: #37(#38=I#39): LOCAL_VARIABLE, {start_pc=24, length=7, index=3} InstanceOfPatternVariable$TA( value=2 ) 1: #37(#38=I#40): LOCAL_VARIABLE, {start_pc=33, length=8, index=3} InstanceOfPatternVariable$TA( value=3 ) On Wed, Nov 22, 2023 at 12:49?PM Alex Buckley wrote: > On 11/22/2023 9:55 AM, Werner Dietl wrote: > > if (x instanceof @TA Float) { > > if (x instanceof @TA Boolean b) { > > > > @Target(ElementType.TYPE_USE) > > @Retention(RetentionPolicy.RUNTIME) > > @interface TA {} > > > > 1) When looking at the bytecode with `javap -v > > InstanceOfPatternVariable.class` I only see one use of @TA: > > > > RuntimeVisibleTypeAnnotations: > > 0: #19(): INSTANCEOF, offset=1 > > InstanceOfPatternVariable$TA > > > > The JSL 15.20.2 [1] says "An instanceof expression may perform either > > type comparison or pattern matching." > > The JVMS 4.7.20-B [2] talks about how type annotations on "instanceof > > expressions" are stored. > > It would therefore seem to me that both occurrences of TA should be > > stored in the class file. > > (You mean both occurrences of the annotation `@TA`. The annotation > interface `TA` is a distinct thing.) > > Yes, both occurrences of `@TA` should be stored. Let's "prove it" for > the second occurrence. > > The type pattern `Boolean b` is defined (per 14.30.1) as a local > variable declaration. The annotation `@TA` which syntactically appears > as a modifier on that declaration is interpreted according to 9.7.4. How? > > The annotation interface `TA` is defined with TYPE_USE, which means (per > 9.6.4.1) that `TA` is applicable in type contexts. One of the type > contexts (per 4.11) is: "The type in a local variable declaration in > either a statement ... or a pattern". So, the following rule in 9.7.4 > applies: > > ``` > - If the annotation's interface is applicable in type contexts, and not > in the declaration context corresponding to the declaration, then the > annotation is deemed to apply only to the type which is closest to the > annotation. > ``` > > This means that the annotation `@TA` is a type annotation (applying to > the use of the `Boolean` type within a local variable declaration) and > not a declaration annotation on the overall local variable declaration > `Boolean b`. > > Great -- type annotations integrate with type patterns in the JLS as you > would expect. Consequently, `@TA` should appear in the RVTA attribute > via a localvar_target item. Perhaps javac is emitting the item but javap > is unable to render it. > > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vromero at openjdk.org Mon Nov 27 16:26:32 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 27 Nov 2023 16:26:32 GMT Subject: Integrated: 8320001: javac crashes while adding type annotations to the return type of a constructor In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 22:28:11 GMT, Vicente Romero wrote: > Fix for [1] introduced a regression that is making some internal tests fail. Basically fix for [1] is trying to add annotations read from the class file to the corresponding symbol. Constructors are a bit special given that its return type is `void` thus type annotations can't be added to them. This fix is proposing just dropping the type annotation if it applies to the return type of a constructor. > > TIA > [1] https://bugs.openjdk.org/browse/JDK-8225377 This pull request has now been integrated. Changeset: 5e24aaf4 Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/5e24aaf4f7f11862ec8ac9d5c3e65d614104fb2c Stats: 143 lines in 2 files changed: 142 ins; 0 del; 1 mod 8320001: javac crashes while adding type annotations to the return type of a constructor Reviewed-by: cushon, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/16774 From mcimadamore at openjdk.org Mon Nov 27 17:07:15 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 27 Nov 2023 17:07:15 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v20] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 21:14:07 GMT, Archie Cobbs wrote: >> This is a first draft of a patch for JEP 447. >> >> Summary of changes: >> >> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` >> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context >> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` >> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement >> >> The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. >> >> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge branch 'master' into SuperInit > - Merge branch 'master' into SuperInit > - Reword new errors to use the JLS term for "explicit constructor invocation". > - After further review, revert 599d761 to avoid mutable state lying around. > - Address review comments relating to error messages. > - Have RefBeforeCtorCalledError extend StaticError and customize debug strings. > - Change variable name "statik" -> "isStatic" per review recommendation. > - Remove obsolete flag "constructorArgs". > - Change the error message to match the applicable spec rule. > - Merge branch 'master' into SuperInit > - ... and 30 more: https://git.openjdk.org/jdk/compare/e4803e0c...bbdb814f Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13656#pullrequestreview-1750941148 From acobbs at openjdk.org Mon Nov 27 17:30:34 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 27 Nov 2023 17:30:34 GMT Subject: Integrated: 8194743: Compiler implementation for Statements before super() In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 20:40:18 GMT, Archie Cobbs wrote: > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. This pull request has now been integrated. Changeset: 12e983a7 Author: Archie Cobbs Committer: Vicente Romero URL: https://git.openjdk.org/jdk/commit/12e983a72e72ed56741ddc45e47d337716a8da65 Stats: 1499 lines in 27 files changed: 1156 ins; 227 del; 116 mod 8194743: Compiler implementation for Statements before super() Reviewed-by: vromero, jwaters, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/13656 From wdietl at gmail.com Mon Nov 27 17:35:12 2023 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 27 Nov 2023 12:35:12 -0500 Subject: Type use annotations on instanceof patterns In-Reply-To: References: <50d8b279-2f79-4926-ae10-aa6b08e44322@oracle.com> Message-ID: Thanks for the analysis, Alex, and for filing the bug, Angelos! Looking at Liam's additional example (thanks for looking into this!), it now makes sense that the type annotations on the pattern variable did not show up in my example. It seems a bit surprising, given how the JVMS talks about all instanceof expressions. Maybe there should be two entries, one for the instanceof expression and one for the pattern variable? I do hope we can get the annotated type mirror from InstanceOfTree#getType(), even if the pattern variable has no live range. Best, cu, WMD. On Mon, Nov 27, 2023 at 11:53?AM Liam Miller-Cushon wrote: > I think the issue is that the code to generate LOCAL_VARIABLE locations > here [1] only handles variables that have non-empty live ranges, so type > annotations on unused variables are never generated. > > [1] > https://github.com/openjdk/jdk/blob/6aa197667ad05bd93adf3afc7b06adbfb2b18a22/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java#L2115-L2125 > > Consider this example, where type annotations are emitted for type > patterns and locals, but not if they are unused: > > import java.lang.annotation.ElementType; > import java.lang.annotation.Retention; > import java.lang.annotation.RetentionPolicy; > import java.lang.annotation.Target; > > public class InstanceOfPatternVariable { > > public void doSomething(final Object x) { > if (x instanceof @TA(0) String z) {} > @TA(1) > String b; > if (x instanceof @TA(2) String c) { > System.err.println(c); > } > @TA(3) > String d = null; > System.err.println(d); > } > > @Target(ElementType.TYPE_USE) > @Retention(RetentionPolicy.RUNTIME) > @interface TA { > int value(); > } > } > > Which results in: > > RuntimeVisibleTypeAnnotations: > 0: #37(#38=I#39): LOCAL_VARIABLE, {start_pc=24, length=7, index=3} > InstanceOfPatternVariable$TA( > value=2 > ) > 1: #37(#38=I#40): LOCAL_VARIABLE, {start_pc=33, length=8, index=3} > InstanceOfPatternVariable$TA( > value=3 > ) > > On Wed, Nov 22, 2023 at 12:49?PM Alex Buckley > wrote: > >> On 11/22/2023 9:55 AM, Werner Dietl wrote: >> > if (x instanceof @TA Float) { >> > if (x instanceof @TA Boolean b) { >> > >> > @Target(ElementType.TYPE_USE) >> > @Retention(RetentionPolicy.RUNTIME) >> > @interface TA {} >> > >> > 1) When looking at the bytecode with `javap -v >> > InstanceOfPatternVariable.class` I only see one use of @TA: >> > >> > RuntimeVisibleTypeAnnotations: >> > 0: #19(): INSTANCEOF, offset=1 >> > InstanceOfPatternVariable$TA >> > >> > The JSL 15.20.2 [1] says "An instanceof expression may perform either >> > type comparison or pattern matching." >> > The JVMS 4.7.20-B [2] talks about how type annotations on "instanceof >> > expressions" are stored. >> > It would therefore seem to me that both occurrences of TA should be >> > stored in the class file. >> >> (You mean both occurrences of the annotation `@TA`. The annotation >> interface `TA` is a distinct thing.) >> >> Yes, both occurrences of `@TA` should be stored. Let's "prove it" for >> the second occurrence. >> >> The type pattern `Boolean b` is defined (per 14.30.1) as a local >> variable declaration. The annotation `@TA` which syntactically appears >> as a modifier on that declaration is interpreted according to 9.7.4. How? >> >> The annotation interface `TA` is defined with TYPE_USE, which means (per >> 9.6.4.1) that `TA` is applicable in type contexts. One of the type >> contexts (per 4.11) is: "The type in a local variable declaration in >> either a statement ... or a pattern". So, the following rule in 9.7.4 >> applies: >> >> ``` >> - If the annotation's interface is applicable in type contexts, and not >> in the declaration context corresponding to the declaration, then the >> annotation is deemed to apply only to the type which is closest to the >> annotation. >> ``` >> >> This means that the annotation `@TA` is a type annotation (applying to >> the use of the `Boolean` type within a local variable declaration) and >> not a declaration annotation on the overall local variable declaration >> `Boolean b`. >> >> Great -- type annotations integrate with type patterns in the JLS as you >> would expect. Consequently, `@TA` should appear in the RVTA attribute >> via a localvar_target item. Perhaps javac is emitting the item but javap >> is unable to render it. >> >> Alex >> > -- https://ece.uwaterloo.ca/~wdietl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Mon Nov 27 18:45:26 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 27 Nov 2023 18:45:26 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 In-Reply-To: References: Message-ID: <5vvx35OFQByttXi78XninlFdmr7NAc-ryvxSz1Uz-cM=.d5acd0ff-996d-4bee-8673-00489253122b@github.com> On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote: > Time to start making preparations for JDK 23. Changes requested by liach (Author). src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 1: > 1: /* `latestMajorVersion` below should be updated to return `JAVA_23_VERSION` as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1713657511 PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1382292651 From darcy at openjdk.org Mon Nov 27 18:45:24 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 18:45:24 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 Message-ID: Time to start making preparations for JDK 23. ------------- Commit messages: - Add symbol files for JDK 22 build 25. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Adjust expected release date. - Fix omission in Classfile.java - JDK-8319413: Start of release updates for JDK 23 Changes: https://git.openjdk.org/jdk/pull/16505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319413 Stats: 7694 lines in 70 files changed: 7656 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 Mon Nov 27 18:45:26 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 18:45:26 GMT Subject: RFR: 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. Nothing exception in this batch of start-of-release updates. Clean local testing results on tier 1. The symbol files correspond to JDK 22 build 25 and will be updated with subsequent builds as usual. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16505#issuecomment-1828413515 From darcy at openjdk.org Mon Nov 27 18:45:30 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 18:45:30 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 In-Reply-To: <5vvx35OFQByttXi78XninlFdmr7NAc-ryvxSz1Uz-cM=.d5acd0ff-996d-4bee-8673-00489253122b@github.com> References: <5vvx35OFQByttXi78XninlFdmr7NAc-ryvxSz1Uz-cM=.d5acd0ff-996d-4bee-8673-00489253122b@github.com> Message-ID: On Fri, 3 Nov 2023 23:52:45 GMT, Chen Liang wrote: >> Time to start making preparations for JDK 23. > > src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 1: > >> 1: /* > > `latestMajorVersion` below should be updated to return `JAVA_23_VERSION` as well. Good catch; fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1382295414 From darcy at openjdk.org Mon Nov 27 20:24:16 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 20:24:16 GMT Subject: RFR: JDK-8320803: Update SourceVersion.RELEASE_22 description for language changes Message-ID: Quick doc-only fix. ------------- Commit messages: - JDK-8320803: Update SourceVersion.RELEASE_22 description for language changes Changes: https://git.openjdk.org/jdk/pull/16832/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16832&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320803 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16832.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16832/head:pull/16832 PR: https://git.openjdk.org/jdk/pull/16832 From jjg at openjdk.org Mon Nov 27 20:28:04 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 27 Nov 2023 20:28:04 GMT Subject: RFR: JDK-8320803: Update SourceVersion.RELEASE_22 description for language changes In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 20:17:44 GMT, Joe Darcy wrote: > Quick doc-only fix. Marked as reviewed by jjg (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16832#pullrequestreview-1751293919 From darcy at openjdk.org Mon Nov 27 20:39:18 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 20:39:18 GMT Subject: Integrated: JDK-8320803: Update SourceVersion.RELEASE_22 description for language changes In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 20:17:44 GMT, Joe Darcy wrote: > Quick doc-only fix. This pull request has now been integrated. Changeset: 6871a2ff Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/6871a2ff1207d3ee70973b1c4ee9bd09969c185b Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod 8320803: Update SourceVersion.RELEASE_22 description for language changes Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk/pull/16832 From darcy at openjdk.org Mon Nov 27 21:00:13 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 21:00:13 GMT Subject: RFR: JDK-8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes Message-ID: Straightforward test update for a new language feature. ------------- Commit messages: - JDK-8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes Changes: https://git.openjdk.org/jdk/pull/16833/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16833&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320806 Stats: 17 lines in 1 file changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16833.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16833/head:pull/16833 PR: https://git.openjdk.org/jdk/pull/16833 From iris at openjdk.org Mon Nov 27 22:46:05 2023 From: iris at openjdk.org (Iris Clark) Date: Mon, 27 Nov 2023 22:46:05 GMT Subject: RFR: 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. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1751551968 From darcy at openjdk.org Mon Nov 27 23:39:25 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 23:39:25 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com> Message-ID: <-Tw35Sh8XjisOJEIbFFVf_xE7asoSucQDV97LsOkWdA=.5f97af1f-86b1-47b2-9d92-752f0b40f6fd@github.com> On Thu, 2 Nov 2023 17:42:48 GMT, Jim Laskey wrote: >> `UNNAMED_CLASSES` should probably be removed, as I think it is fully replaced with `IMPLICIT_CLASSES`, and I don't think there are bootstrap problems here (unlike in `jdk.internal.java.PreviewFeature`). I would say it would make sense to set the version to `JDK22`, although the difference is very small given the feature is a preview and requires `-source 22` anyway. (Although we keep the `@since` value for the duration of preview.) > > Changing I had the same question when reading over the changes if JDK21 or JDK22 should be used for IMPLICIT_CLASSES. I think it would help if the comment of the Feature enum documented what the expected protocol was for previewing features. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1406896429 From darcy at openjdk.org Mon Nov 27 23:49:26 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 23:49:26 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 12:56:40 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Requested changes test/langtools/tools/javac/ImplicitClass/TestImplicitClass.java line 35: > 33: import java.lang.reflect.Modifier; > 34: > 35: public class TestImplicitClass { The test looks to be testing core reflection behavior (i.e. runtime behavior) and not compile-time behavior via javax.lang.model. Core reflection tests should be done too, but done the core libraries tests, not langtools tests. I might have overlooked it, but if some other exercise of compile-time modeling is not being done, please restore and update accordingly the sort of tests previously done in the now-deleted test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1406905612 From dholmes at openjdk.org Tue Nov 28 06:36:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Nov 2023 06:36:05 GMT Subject: RFR: 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. Hotspot change is trivially fine, but too insignificant to hit the Approve button. Thanks ------------- PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1752152672 From prappo at openjdk.org Tue Nov 28 09:44:27 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 28 Nov 2023 09:44:27 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 12:56:40 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Requested changes Jim, consider merging this PR with master to catch up. This PR is almost 250 commits behind master. That is a month of work. Also, if you merge, we could use this PR as a [dependency](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) for other PRs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1829444791 From pminborg at openjdk.org Tue Nov 28 10:24:39 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 28 Nov 2023 10:24:39 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v32] In-Reply-To: <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com> Message-ID: <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com> On Mon, 27 Nov 2023 10:01:50 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 > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed SwitchBootstrapTest src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1404: > (failed to retrieve contents of file, check the PR for context) Is there a more scalable way to express the major class version? The current approach means we have to add two fields per year. Maybe a lookup function would be better? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1407534887 From cstein at openjdk.org Tue Nov 28 10:34:10 2023 From: cstein at openjdk.org (Christian Stein) Date: Tue, 28 Nov 2023 10:34:10 GMT Subject: RFR: 8306914: Implement JEP 458: Launch Multi-File Source-Code Programs [v5] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 15:45:05 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 ?: Implicitly Declared Classes and Instance Main Method (2nd 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 two additional commits since the last revision: > > - Refine lookup of valid application classes > - Address module graph related review comments Thanks for pointing out the extra space characters, @turbanoff -- I will remove them and some more in a clean-up commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13712#issuecomment-1829537128 From asotona at openjdk.org Tue Nov 28 13:06:31 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 28 Nov 2023 13:06:31 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v32] In-Reply-To: <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com> <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com> Message-ID: On Tue, 28 Nov 2023 10:21:25 GMT, Per Minborg wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed SwitchBootstrapTest > > src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1404: > >> (failed to retrieve contents of file, check the PR for context) > Is there a more scalable way to express the major class version? The current approach means we have to add two fields per year. Maybe a lookup function would be better? This is explicit list of supported class file versions, so I don't see any other way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1407726710 From jlaskey at openjdk.org Tue Nov 28 13:52:53 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 13:52:53 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: References: Message-ID: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge remote-tracking branch 'upstream/master' into 8315458 - Requested changes - Remove Test - Move findMainMethod to non-public access - Handle javadoc on top level elements properly - Update Class.java - Update test - Update findMainMethod as requested - Add nested class test - Move Implicitly Declared Classes to single directory - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba ------------- Changes: https://git.openjdk.org/jdk/pull/16461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=35 Stats: 1294 lines in 51 files changed: 439 ins; 723 del; 132 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From alanb at openjdk.org Tue Nov 28 14:18:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 14:18:36 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: <2FFWAcDn5vw9HOG1T-TVKU1N3wE1_hn_GCos6UUfjx8=.cab3fb18-4550-4190-8b65-78592e0d298e@github.com> On Tue, 28 Nov 2023 13:52:53 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Requested changes > - Remove Test > - Move findMainMethod to non-public access > - Handle javadoc on top level elements properly > - Update Class.java > - Update test > - Update findMainMethod as requested > - Add nested class test > - Move Implicitly Declared Classes to single directory > - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba src/java.base/share/classes/java/lang/Class.java line 2896: > 2894: * @param parameterTypes the parameter array > 2895: * @return the list of {@code Method} objects for the public methods of > 2896: * this class matching the specified name and parameters The return description seems to be copied from getDeclaredPublicMethods, I think you can drop it as the method description is clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407832086 From jlaskey at openjdk.org Tue Nov 28 14:35:08 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 14:35:08 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: <2FFWAcDn5vw9HOG1T-TVKU1N3wE1_hn_GCos6UUfjx8=.cab3fb18-4550-4190-8b65-78592e0d298e@github.com> References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> <2FFWAcDn5vw9HOG1T-TVKU1N3wE1_hn_GCos6UUfjx8=.cab3fb18-4550-4190-8b65-78592e0d298e@github.com> Message-ID: On Tue, 28 Nov 2023 14:15:48 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Requested changes >> - Remove Test >> - Move findMainMethod to non-public access >> - Handle javadoc on top level elements properly >> - Update Class.java >> - Update test >> - Update findMainMethod as requested >> - Add nested class test >> - Move Implicitly Declared Classes to single directory >> - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba > > src/java.base/share/classes/java/lang/Class.java line 2896: > >> 2894: * @param parameterTypes the parameter array >> 2895: * @return the list of {@code Method} objects for the public methods of >> 2896: * this class matching the specified name and parameters > > The return description seems to be copied from getDeclaredPublicMethods, I think you can drop it as the method description is clear. * @return the {@code Method} object for the method found from this class matching * the specified name and parameters, or null if not found ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407856392 From jlaskey at openjdk.org Tue Nov 28 14:47:39 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 14:47:39 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v37] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update Class.java comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/daacc0ba..f313cc96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=36 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=35-36 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From alanb at openjdk.org Tue Nov 28 14:47:47 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 14:47:47 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: On Tue, 28 Nov 2023 13:52:53 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Requested changes > - Remove Test > - Move findMainMethod to non-public access > - Handle javadoc on top level elements properly > - Update Class.java > - Update test > - Update findMainMethod as requested > - Add nested class test > - Move Implicitly Declared Classes to single directory > - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba test/jdk/tools/launcher/modules/basic/LauncherErrors.java line 97: > 95: .shouldContain("Error: Unable to load main class " + MAIN_CLASS + " in module " + TEST_MODULE) > 96: .shouldContain("java.security.AccessControlException") > 97: .shouldNotHaveExitValue(0); The updates to the launcher tests look okay but I'm wondering if the "Caused by:" is the output now? I get it that the "Unable to ..." message has changed but has the format of the cause changed too? I assume you'll fix up the copyright date on Arrrrgs and LauncherErrors before integrating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407880682 From jlaskey at openjdk.org Tue Nov 28 15:05:42 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 15:05:42 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v38] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Create TestImplicitClass.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/f313cc96..c4fc2f9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=37 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=36-37 Stats: 217 lines in 1 file changed: 217 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 28 15:05:56 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 15:05:56 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 23:46:00 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Requested changes > > test/langtools/tools/javac/ImplicitClass/TestImplicitClass.java line 35: > >> 33: import java.lang.reflect.Modifier; >> 34: >> 35: public class TestImplicitClass { > > The test looks to be testing core reflection behavior (i.e. runtime behavior) and not compile-time behavior via javax.lang.model. > > Core reflection tests should be done too, but done the core libraries tests, not langtools tests. > > I might have overlooked it, but if some other exercise of compile-time modeling is not being done, please restore and update accordingly the sort of tests previously done in the now-deleted > > test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java Added ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407907660 From alanb at openjdk.org Tue Nov 28 15:54:27 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 15:54:27 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: On Tue, 28 Nov 2023 13:52:53 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Requested changes > - Remove Test > - Move findMainMethod to non-public access > - Handle javadoc on top level elements properly > - Update Class.java > - Update test > - Update findMainMethod as requested > - Add nested class test > - Move Implicitly Declared Classes to single directory > - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba Marked as reviewed by alanb (Reviewer). src/java.base/share/native/libjli/java.c line 415: > 413: CHECK_EXCEPTION_FAIL(); > 414: (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); > 415: return 1; I think we should add a comment to each of the 4 invokeXXXX functions to say that they return 1 if the main method completes successfully or it throws. Just trying to head off someone asking why there isn't a CHECK_XXX after the CallStaticVoidMethod/CallVoidMethod. ------------- PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1753261575 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407995550 From ihse at openjdk.org Tue Nov 28 17:07:20 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 28 Nov 2023 17:07:20 GMT Subject: RFR: 8320915: Update copyright year in build files Message-ID: <-4RrV3-LPfsh3BT-qwj3WtF1szg-_6Tt3RxnysPpNeo=.f2b0fee1-7d0c-4c43-bc4f-39ad9fec1150@github.com> Over the year, even though we have tried to be diligent, there have been commits that modify files without updating the copyright year. Here is a mass update of the copyright years in the build system (`make/**`, `.github/**`). Feel free to verify that these files have indeed been modified in 2023 :-), or trust my tools + manual verification. Also, as far as I (and my tools) can tell, this is the only files modified in 2023 that have not had their header updated. ------------- Commit messages: - 8320915: Update copyright year in build files Changes: https://git.openjdk.org/jdk/pull/16858/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16858&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320915 Stats: 69 lines in 69 files changed: 0 ins; 0 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/16858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16858/head:pull/16858 PR: https://git.openjdk.org/jdk/pull/16858 From vromero at openjdk.org Tue Nov 28 18:25:05 2023 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 28 Nov 2023 18:25:05 GMT Subject: RFR: 8308399: Recommend --release when -source and -target are misused In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 13:30:10 GMT, Jan Lahoda wrote: > This patch modifies some warning and error messages to recommend `--release` more loudly. Please see details below. > > Note that while the patch changes `compiler.warn.source.target.conflict` to `compiler.err.source.target.conflict`, there is no change in the set of accepted options and their combinations. This used to behave as an error, and still behaves as an error. So this patch only changes the console text from `warning: ...` to `error: ...`. > > > + javac -source 8 /tmp/Test.java > warning: [options] bootstrap class path is not set in conjunction with -source 8 > not setting the bootstrap class path may lead to class files that cannot run on JDK 8 > --release 8 is recommended instead of -source 8 because it sets the bootstrap class path automatically > warning: [options] source value 8 is obsolete and will be removed in a future release > warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. > 3 warnings > > > > + javac -source 8 -target 8 /tmp/Test.java > warning: [options] bootstrap class path is not set in conjunction with -source 8 > not setting the bootstrap class path may lead to class files that cannot run on JDK 8 > --release 8 is recommended instead of -source 8 -target 8 because it sets the bootstrap class path automatically > warning: [options] source value 8 is obsolete and will be removed in a future release > warning: [options] target value 8 is obsolete and will be removed in a future release > warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. > 4 warnings > > > > + javac -source 11 /tmp/Test.java > warning: [options] location of system modules is not set in conjunction with -source 11 > not setting the location of system modules may lead to class files that cannot run on JDK 11 > --release 11 is recommended instead of -source 11 because it sets the location of system modules automatically > 1 warning > > > > + javac -source 11 -target 11 /tmp/Test.java > warning: [options] location of system modules is not set in conjunction with -source 11 > not setting the location of system modules may lead to class files that cannot run on JDK 11 > --release 11 is recommended instead of -source 11 -target 11 because it sets the location of system modules automatically > 1 warning > > > > + javac -target 17 -source 11 /tmp/Test.java > warning: [options] location of system modules is not set in conjunction with -source 11 > not setting the location of system modules may lead to class files that cannot run on JDK 11 > --release... looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16612#pullrequestreview-1753591115 From jlaskey at openjdk.org Tue Nov 28 19:10:45 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 19:10:45 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v39] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: - Merge remote-tracking branch 'upstream/master' into 8315458 - Create TestImplicitClass.java - Update Class.java comment - Merge remote-tracking branch 'upstream/master' into 8315458 - Requested changes - Remove Test - Move findMainMethod to non-public access - Handle javadoc on top level elements properly - Update Class.java - Update test - ... and 33 more: https://git.openjdk.org/jdk/compare/dc256fbc...6ce7c84a ------------- Changes: https://git.openjdk.org/jdk/pull/16461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=38 Stats: 1511 lines in 52 files changed: 656 ins; 723 del; 132 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 28 20:04:45 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 20:04:45 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v40] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/6ce7c84a..0d01c488 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=39 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=38-39 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 28 20:04:49 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 20:04:49 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: On Tue, 28 Nov 2023 14:43:36 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Requested changes >> - Remove Test >> - Move findMainMethod to non-public access >> - Handle javadoc on top level elements properly >> - Update Class.java >> - Update test >> - Update findMainMethod as requested >> - Add nested class test >> - Move Implicitly Declared Classes to single directory >> - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba > > test/jdk/tools/launcher/modules/basic/LauncherErrors.java line 97: > >> 95: .shouldContain("Error: Unable to load main class " + MAIN_CLASS + " in module " + TEST_MODULE) >> 96: .shouldContain("java.security.AccessControlException") >> 97: .shouldNotHaveExitValue(0); > > The updates to the launcher tests look okay but I'm wondering if the "Caused by:" is the output now? I get it that the "Unable to ..." message has changed but has the format of the cause changed too? > > I assume you'll fix up the copyright date on Arrrrgs and LauncherErrors before integrating. "Caused by:" has (always) been missing from the named module version of the error message. I'll add in and modify the test accordingly. Updated copyright. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1408356364 From jlaskey at openjdk.org Tue Nov 28 20:15:06 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 20:15:06 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v41] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add comments to invokeXXXX functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/0d01c488..30170407 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=40 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=39-40 Stats: 16 lines in 1 file changed: 15 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 28 20:15:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 20:15:12 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: <50sgilEAyAxziPJyoaVqfwv9e3xFAXtSo2cTsUCu3lE=.4baff79c-fbe0-4fdd-bd92-921af3e1fb89@github.com> On Tue, 28 Nov 2023 15:51:37 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Requested changes >> - Remove Test >> - Move findMainMethod to non-public access >> - Handle javadoc on top level elements properly >> - Update Class.java >> - Update test >> - Update findMainMethod as requested >> - Add nested class test >> - Move Implicitly Declared Classes to single directory >> - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba > > src/java.base/share/native/libjli/java.c line 415: > >> 413: CHECK_EXCEPTION_FAIL(); >> 414: (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >> 415: return 1; > > I think we should add a comment to each of the 4 invokeXXXX functions to say that they return 1 if the main method completes successfully or it throws. Just trying to head off someone asking why there isn't a CHECK_XXX after the CallStaticVoidMethod/CallVoidMethod. Comments added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1408365265 From erikj at openjdk.org Tue Nov 28 23:19:06 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 28 Nov 2023 23:19:06 GMT Subject: RFR: 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. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1754115586 From darcy at openjdk.org Wed Nov 29 03:15:12 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 03:15:12 GMT Subject: RFR: JDK-8320941: Discuss receiver type handling Message-ID: 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.) ------------- Commit messages: - JDK-8320941: Discuss receiver type handling - JDK-8320940: Fix typo in java.lang.Double Changes: https://git.openjdk.org/jdk/pull/16874/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320941 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16874/head:pull/16874 PR: https://git.openjdk.org/jdk/pull/16874 From darcy at openjdk.org Wed Nov 29 03:15:13 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 03:15:13 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.) In retrospect, it may have been better to define TypeMirror ExecutableType.getReceiverType() to instead be VariableElement ExecutableType.getReceiverParameter() However, it is far too late to make that change. @cushon , does this spec update properly capture the intended semantics of your recent change for JDK-8319196? Once the wording of the spec update is worked out, I'll file the CSR in due course. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16874#issuecomment-1831143529 PR Comment: https://git.openjdk.org/jdk/pull/16874#issuecomment-1831144924 From pminborg at openjdk.org Wed Nov 29 08:49:28 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 29 Nov 2023 08:49:28 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 Tue, 28 Nov 2023 13:03:48 GMT, Adam Sotona wrote: >> src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1404: >> >>> (failed to retrieve contents of file, check the PR for context) >> Is there a more scalable way to express the major class version? The current approach means we have to add two fields per year. Maybe a lookup function would be better? > > 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? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1408941961 From jlahoda at openjdk.org Wed Nov 29 12:31:18 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 29 Nov 2023 12:31:18 GMT Subject: Integrated: 8308399: Recommend --release when -source and -target are misused In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 13:30:10 GMT, Jan Lahoda wrote: > This patch modifies some warning and error messages to recommend `--release` more loudly. Please see details below. > > Note that while the patch changes `compiler.warn.source.target.conflict` to `compiler.err.source.target.conflict`, there is no change in the set of accepted options and their combinations. This used to behave as an error, and still behaves as an error. So this patch only changes the console text from `warning: ...` to `error: ...`. > > > + javac -source 8 /tmp/Test.java > warning: [options] bootstrap class path is not set in conjunction with -source 8 > not setting the bootstrap class path may lead to class files that cannot run on JDK 8 > --release 8 is recommended instead of -source 8 because it sets the bootstrap class path automatically > warning: [options] source value 8 is obsolete and will be removed in a future release > warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. > 3 warnings > > > > + javac -source 8 -target 8 /tmp/Test.java > warning: [options] bootstrap class path is not set in conjunction with -source 8 > not setting the bootstrap class path may lead to class files that cannot run on JDK 8 > --release 8 is recommended instead of -source 8 -target 8 because it sets the bootstrap class path automatically > warning: [options] source value 8 is obsolete and will be removed in a future release > warning: [options] target value 8 is obsolete and will be removed in a future release > warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. > 4 warnings > > > > + javac -source 11 /tmp/Test.java > warning: [options] location of system modules is not set in conjunction with -source 11 > not setting the location of system modules may lead to class files that cannot run on JDK 11 > --release 11 is recommended instead of -source 11 because it sets the location of system modules automatically > 1 warning > > > > + javac -source 11 -target 11 /tmp/Test.java > warning: [options] location of system modules is not set in conjunction with -source 11 > not setting the location of system modules may lead to class files that cannot run on JDK 11 > --release 11 is recommended instead of -source 11 -target 11 because it sets the location of system modules automatically > 1 warning > > > > + javac -target 17 -source 11 /tmp/Test.java > warning: [options] location of system modules is not set in conjunction with -source 11 > not setting the location of system modules may lead to class files that cannot run on JDK 11 > --release... This pull request has now been integrated. Changeset: 65dfcae6 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/65dfcae6d6c11e8dcb807a2559278fb082e095b9 Stats: 128 lines in 23 files changed: 73 ins; 9 del; 46 mod 8308399: Recommend --release when -source and -target are misused Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/16612 From jlahoda at openjdk.org Wed Nov 29 13:33:05 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 29 Nov 2023 13:33:05 GMT Subject: RFR: JDK-8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes In-Reply-To: References: Message-ID: <067AWRziZPR5ffmcHi7Q2SZiiG-VsLfun5-vZd-zeBU=.19bc187c-6a21-4ba7-969c-30c2222f0f6f@github.com> On Mon, 27 Nov 2023 20:54:09 GMT, Joe Darcy wrote: > Straightforward test update for a new language feature. Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16833#pullrequestreview-1755270476 From jlaskey at openjdk.org Wed Nov 29 14:30:50 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 29 Nov 2023 14:30:50 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v42] In-Reply-To: References: Message-ID: <5BIJJ2_LH-qdn05gcgQk6Fx4D9X5XgTmQFsbp5HNXjQ=.860c8efa-521b-49e0-adb2-f05819c53aaf@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Windows line endings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/30170407..2f7fdded Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=41 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=40-41 Stats: 217 lines in 1 file changed: 0 ins; 0 del; 217 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlahoda at openjdk.org Wed Nov 29 14:51:33 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 29 Nov 2023 14:51:33 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v42] In-Reply-To: <5BIJJ2_LH-qdn05gcgQk6Fx4D9X5XgTmQFsbp5HNXjQ=.860c8efa-521b-49e0-adb2-f05819c53aaf@github.com> References: <5BIJJ2_LH-qdn05gcgQk6Fx4D9X5XgTmQFsbp5HNXjQ=.860c8efa-521b-49e0-adb2-f05819c53aaf@github.com> Message-ID: <2M4oi4qxtjx11NMnq_jaH7jjYG5SV2HSO4ypHH1-P6E=.86e7cd2d-d074-48dd-9b3c-1bbe23bc351f@github.com> On Wed, 29 Nov 2023 14:30:50 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Windows line endings javac changes seem reasonably to me. Adding two nits to `InstanceMainTest.java`. test/jdk/tools/launcher/InstanceMainTest.java line 45: > 43: """, > 44: > 45: // instance dominating instance Nit: Suggestion: // instance dominating static test/jdk/tools/launcher/InstanceMainTest.java line 84: > 82: """, > 83: > 84: // unnamed class dominating instance Nit: Suggestion: // main with args dominating main without args ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1755452564 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409394109 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409395226 From vromero at openjdk.org Wed Nov 29 15:18:09 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 29 Nov 2023 15:18:09 GMT Subject: RFR: JDK-8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 20:54:09 GMT, Joe Darcy wrote: > Straightforward test update for a new language feature. looks good ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16833#pullrequestreview-1755522436 From jlaskey at openjdk.org Wed Nov 29 15:25:15 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 29 Nov 2023 15:25:15 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Update test/jdk/tools/launcher/InstanceMainTest.java Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> - Update test/jdk/tools/launcher/InstanceMainTest.java Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/2f7fdded..7ed4045a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=42 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=41-42 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From darcy at openjdk.org Wed Nov 29 17:28:16 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 17:28:16 GMT Subject: Integrated: JDK-8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 20:54:09 GMT, Joe Darcy wrote: > Straightforward test update for a new language feature. This pull request has now been integrated. Changeset: b68356b2 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/b68356b267ad8f2da0d4f84de82b3b0042b4acd0 Stats: 17 lines in 1 file changed: 14 ins; 0 del; 3 mod 8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes Reviewed-by: jlahoda, vromero ------------- PR: https://git.openjdk.org/jdk/pull/16833 From darcy at openjdk.org Wed Nov 29 19:00:30 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 19:00:30 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v2] 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 seven commits: - Merge branch 'master' into JDK-8319413 - Add symbol files for JDK 22 build 25. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Adjust expected release date. - Fix omission in Classfile.java - JDK-8319413: Start of release updates for JDK 23 ------------- Changes: https://git.openjdk.org/jdk/pull/16505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=01 Stats: 7694 lines in 70 files changed: 7656 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 Wed Nov 29 20:10:29 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 20:10:29 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 15:25:15 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/jdk/tools/launcher/InstanceMainTest.java > > Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> > - Update test/jdk/tools/launcher/InstanceMainTest.java > > Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 129: > 127: Element enclosing = e.getEnclosingElement(); > 128: > 129: // Don't print out the constructor of an anonymous Please add back "class" so that the comment reads "Don't print out the constructor of an anonymous class." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409810773 From darcy at openjdk.org Wed Nov 29 20:20:31 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 20:20:31 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 15:00:43 GMT, Jim Laskey wrote: >> test/langtools/tools/javac/ImplicitClass/TestImplicitClass.java line 35: >> >>> 33: import java.lang.reflect.Modifier; >>> 34: >>> 35: public class TestImplicitClass { >> >> The test looks to be testing core reflection behavior (i.e. runtime behavior) and not compile-time behavior via javax.lang.model. >> >> Core reflection tests should be done too, but done the core libraries tests, not langtools tests. >> >> I might have overlooked it, but if some other exercise of compile-time modeling is not being done, please restore and update accordingly the sort of tests previously done in the now-deleted >> >> test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java > > Added To clarify, there should be separate tests of what implicit classes look like under core reflection and under javax.lang.model. As currently written, the current test is a core reflection tests located under the javac/annotation processing test area, which is a misplacement. Please move this test to core reflection, replacing 445's test/jdk/java/lang/Class/UnnamedClass/TestUnnamedClass.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409819479 From darcy at openjdk.org Wed Nov 29 20:20:33 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 20:20:33 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 15:25:15 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/jdk/tools/launcher/InstanceMainTest.java > > Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> > - Update test/jdk/tools/launcher/InstanceMainTest.java > > Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> test/langtools/tools/javac/processing/model/element/TestImplicitClass.java line 120: > 118: > 119: /* > 120: * From JEP 445 JLS changes: Update JEP number. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409820065 From cushon at openjdk.org Wed Nov 29 22:02:04 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 29 Nov 2023 22:02:04 GMT Subject: RFR: JDK-8320941: Discuss receiver type handling In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 03:10:14 GMT, Joe Darcy wrote: > @cushon , does this spec update properly capture the intended semantics of your recent change for JDK-8319196? Yes, thanks, I think this captures the intended semantics from JDK-8319196. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16874#issuecomment-1832767736 From darcy at openjdk.org Thu Nov 30 04:43:03 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 30 Nov 2023 04:43:03 GMT Subject: RFR: JDK-8320941: Discuss receiver type handling In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 21:59:22 GMT, Liam Miller-Cushon wrote: > > @cushon , does this spec update properly capture the intended semantics of your recent change for JDK-8319196? > > Yes, thanks, I think this captures the intended semantics from JDK-8319196. Thanks @cushon ; CSR now ready for review: https://bugs.openjdk.org/browse/JDK-8321061. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16874#issuecomment-1833098014 From abimpoudis at openjdk.org Thu Nov 30 11:08:18 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 30 Nov 2023 11:08:18 GMT Subject: RFR: 8320145: Compiler should accept final variable in Record Pattern Message-ID: 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. ------------- Commit messages: - 8320145: Compiler should accept final variable in Record Pattern Changes: https://git.openjdk.org/jdk/pull/16899/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16899&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320145 Stats: 48 lines in 3 files changed: 44 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16899.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16899/head:pull/16899 PR: https://git.openjdk.org/jdk/pull/16899 From jlaskey at openjdk.org Thu Nov 30 12:47:31 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 30 Nov 2023 12:47:31 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 20:07:50 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/jdk/tools/launcher/InstanceMainTest.java >> >> Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> >> - Update test/jdk/tools/launcher/InstanceMainTest.java >> >> Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> > > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 129: > >> 127: Element enclosing = e.getEnclosingElement(); >> 128: >> 129: // Don't print out the constructor of an anonymous > > Please add back "class" so that the comment reads "Don't print out the constructor of an anonymous class." Done > test/langtools/tools/javac/processing/model/element/TestImplicitClass.java line 120: > >> 118: >> 119: /* >> 120: * From JEP 445 JLS changes: > > Update JEP number. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1410623183 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1410623324 From jlaskey at openjdk.org Thu Nov 30 12:54:10 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 30 Nov 2023 12:54:10 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v44] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Correct comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/7ed4045a..cb0ed86b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=43 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=42-43 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 30 12:54:13 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 30 Nov 2023 12:54:13 GMT Subject: Integrated: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 18:56:13 GMT, Jim Laskey wrote: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. This pull request has now been integrated. Changeset: 04ad98ed Author: Jim Laskey URL: https://git.openjdk.org/jdk/commit/04ad98ed32cf899404a3ae13e24407e53be7ebc6 Stats: 1529 lines in 52 files changed: 671 ins; 723 del; 135 mod 8315458: Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) Reviewed-by: jlahoda, mcimadamore, vromero, rriggs, alanb, mchung ------------- PR: https://git.openjdk.org/jdk/pull/16461 From prappo at openjdk.org Thu Nov 30 15:06:15 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 30 Nov 2023 15:06:15 GMT Subject: RFR: 8321114: Rename "Unnamed Classes" to "Implicitly Declared Classes" better 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. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/16904/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16904&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321114 Stats: 18 lines in 8 files changed: 0 ins; 0 del; 18 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 jlaskey at openjdk.org Thu Nov 30 16:14:18 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 30 Nov 2023 16:14:18 GMT Subject: RFR: 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. LGTM ------------- Marked as reviewed by jlaskey (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16904#pullrequestreview-1757839510 From jlahoda at openjdk.org Thu Nov 30 17:33:06 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 30 Nov 2023 17:33:06 GMT Subject: RFR: 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. Looks OK to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16899#pullrequestreview-1758062151 From shade at openjdk.org Thu Nov 30 20:34:20 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Nov 2023 20:34:20 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 Fri, 6 Oct 2023 21:55:30 GMT, Joe Darcy wrote: >> Change annotation processing to be opt-in rather than opt-out. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos. 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1834517085 From darcy at openjdk.org Thu Nov 30 20:48:21 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 30 Nov 2023 20:48:21 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v3] 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 eight commits: - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Add symbol files for JDK 22 build 25. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Adjust expected release date. - Fix omission in Classfile.java - JDK-8319413: Start of release updates for JDK 23 ------------- Changes: https://git.openjdk.org/jdk/pull/16505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=02 Stats: 7694 lines in 70 files changed: 7656 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 Nov 30 21:13:22 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 30 Nov 2023 21:13:22 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 20:31:45 GMT, Aleksey Shipilev 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1834565493 From iris at openjdk.org Thu Nov 30 22:12:09 2023 From: iris at openjdk.org (Iris Clark) Date: Thu, 30 Nov 2023 22:12:09 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 20:48:21 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 eight commits: > > - Merge branch 'master' into JDK-8319413 > - Merge branch 'master' into JDK-8319413 > - Add symbol files for JDK 22 build 25. > - Merge branch 'master' into JDK-8319413 > - Merge branch 'master' into JDK-8319413 > - Adjust expected release date. > - Fix omission in Classfile.java > - JDK-8319413: Start of release updates for JDK 23 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1758548243 From darcy at openjdk.org Thu Nov 30 23:49:24 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 30 Nov 2023 23:49:24 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4] 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 symbol files to JDK 22 b26. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16505/files - new: https://git.openjdk.org/jdk/pull/16505/files/d5cb53c8..9daf1014 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=02-03 Stats: 2876 lines in 43 files changed: 2738 ins; 97 del; 41 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